Gerenciamento do cronograma: caminho crítico, folga e compressão do cronograma

Um cronograma não é uma lista de datas. É um modelo de como o trabalho depende de outro trabalho, e o resultado real dele é a resposta a uma única pergunta: quais atividades, se atrasarem um dia, empurram a data de término em um dia? Todo o resto (o gráfico de barras, o relatório de marcos, o histograma de recursos) é apresentação em cima desse modelo.

Este guia constrói o modelo do zero com um exemplo pequeno que você consegue acompanhar com lápis e papel, e depois mostra o que fazer com ele: nivelar recursos, comprimir um cronograma longo demais e manter uma linha de base significativa quando a realidade se afasta dela. Ele pressupõe que você já tem uma decomposição do trabalho, assunto do guia de fundamentos do gerenciamento de projetos.

Dos pacotes de trabalho à sequência

O planejamento do cronograma começa transformando cada pacote de trabalho em uma ou mais atividades (os verbos, onde a estrutura analítica guardava os substantivos) e decidindo depois o que precisa vir antes do quê. Duas disciplinas trazem retorno imediato: toda atividade tem exatamente um responsável, e toda atividade tem um critério de conclusão claro, para que um "em andamento" não possa durar semanas.

Há quatro tipos de dependência, e usar o tipo certo evita muita serialização artificial.

TI cobre a grande maioria dos casos. II e TT são o que permite modelar com honestidade um trabalho que se sobrepõe, em vez de forçar uma sequência falsa. IT é raro e aparece principalmente em viradas de sistema.

A antecipação é uma espera negativa: começar uma sucessora antes de a predecessora terminar, como iniciar os testes de integração dois dias antes de o último componente ficar pronto. A espera é um tempo imposto que não consome esforço: a cura do concreto, um prazo regulatório de aviso prévio de duas semanas, uma reindexação do banco de dados que roda de madrugada. Modele as esperas explicitamente em vez de inflar a duração de uma atividade, porque uma espera não tem custo e não pode ser encurtada com mais recursos, e escondê-la dentro de uma duração faz o cronograma mentir sobre as duas coisas.

Diferencie as dependências obrigatórias, inerentes ao trabalho, das arbitrárias, que refletem uma preferência ou um hábito. É nas dependências arbitrárias que a compressão do cronograma costuma encontrar folga, então marque-as ao criá-las.

Estimando durações

Três técnicas cobrem a maior parte das necessidades, e em geral elas são combinadas.

A estimativa análoga extrapola a partir de uma atividade passada comparável: a última migração de tamanho parecido levou nove dias, esta é um pouco maior, digamos doze. Rápida, barata e tão boa quanto a comparação.

A estimativa paramétrica usa uma taxa medida: 40 telas a 1,5 dia por tela dão 60 dias. É a técnica mais defensável quando a taxa existe de verdade, e perigosa quando o parâmetro é inventado para justificar um número.

A estimativa de três pontos captura a incerteza explicitamente com um valor otimista, um mais provável e um pessimista. A forma ponderada pela distribuição beta, associada ao PERT, é:

Expected duration   te = (O + 4M + P) / 6
Standard deviation  sd = (P - O) / 6

Backend build:  O = 6 days, M = 9 days, P = 18 days
   te = (6 + 36 + 18) / 6 = 10 days
   sd = (18 - 6) / 6 = 2 days

Interpretation: ~10 days expected; roughly 95% confidence
of finishing within te + 2sd = 14 days.

Repare como a cauda longa eleva o valor esperado acima do mais provável: essa assimetria é a realidade das atividades de software, em que as coisas dão errado com mais frequência do que dão excepcionalmente certo. O dimensionamento relativo no nível do time é outra ferramenta para outra pergunta, abordada em estimativa e planejamento.

Um caminho crítico resolvido passo a passo

Pegue uma entrega pequena com nove atividades. As durações estão em dias úteis.

A passagem de ida vai da esquerda para a direita e calcula o início e o término mais cedo de cada atividade. Uma atividade começa assim que todas as predecessoras terminam, então, quando várias convergem, considera-se o maior término. A passagem de volta percorre depois a rede da direita para a esquerda a partir do fim do projeto e calcula o início e o término mais tarde de cada atividade sem empurrar essa data de término; quando uma atividade tem várias sucessoras, considera-se o menor início mais tarde.

O projeto leva 29 dias, e existem dois caminhos críticos: A–B–D–G–H–I e A–C–E–G–H–I somam 29 cada um. Só F tem folga, de nove dias, porque, embora os scripts fiquem prontos no dia 15, o ensaio da migração não pode começar até os testes de integração terminarem no dia 24. A folga livre de F também é de nove dias, já que atrasá-la até esse ponto não afeta o início mais cedo de nenhuma sucessora.

Daí saem duas leituras práticas. Primeira: os scripts de migração não são urgentes, então pegar esse desenvolvedor emprestado por uma semana não custa nada; o cronograma mostra onde a folga realmente está, coisa que a intuição raramente acerta. Segunda: como há dois caminhos críticos, encurtar só o desenvolvimento do backend não muda absolutamente nada, porque o caminho do frontend continua indo até o dia 19. Esse é o erro mais comum na compressão de cronogramas, e ele só fica visível se você calcular a rede em vez de avaliar o gráfico de barras a olho.

Apresentação e nivelamento

Um gráfico de Gantt mostra a rede como barras sobre um calendário. É excelente para comunicação e péssimo como ferramenta de planejamento por si só, porque um gráfico de barras desenhado à mão codifica datas sem dependências: quando uma barra se move, nenhuma outra acompanha, e o plano vira ficção sem ninguém perceber. Gere sempre o gráfico a partir da rede. Mostre o caminho crítico em uma cor diferente, sinalize os marcos com losangos e resista à vontade de exibir quatrocentas linhas para um comitê diretor quando nove barras de resumo transmitem a mensagem.

Marcos são indicadores de duração zero de um estado significativo: design aprovado, ambiente de integração disponível, aceite do usuário assinado. Eles funcionam melhor em relatórios do que percentuais porque são binários. Um gráfico de tendência de marcos, que plota a data prevista de cada marco a cada período de reporte, é o relatório de cronograma mais informativo que existe, já que uma linha que deriva de forma constante para a direita revela um problema meses antes de o marco ser perdido.

Aí os recursos entram em conflito com o plano. O nivelamento de recursos ajusta o cronograma para que a demanda nunca ultrapasse a disponibilidade; como pode atrasar atividades, ele pode estender a data de término do projeto e mudar qual caminho é crítico. A suavização de recursos só ajusta as atividades dentro da folga disponível, então a data de término é preservada, mas a demanda só é achatada até onde a folga permite. Se um mesmo especialista aparece nos dois caminhos críticos do exemplo acima, o nivelamento vai alongar o projeto, e nenhum relatório vai mudar isso.

Comprimindo um cronograma

Quando a data de término calculada é posterior à exigida, existem exatamente duas técnicas legítimas e uma alternativa honesta.

O crashing adiciona recursos às atividades críticas para encurtá-las, o que custa dinheiro e não escala de forma linear: dobrar o time raramente corta a duração pela metade, e colocar mais gente num trabalho já em andamento costuma atrasá-lo. Faça o crashing primeiro na atividade crítica cujo dia economizado sai mais barato, e recalcule a rede após cada passo, porque a compressão muda qual caminho é crítico.

Continuando o exemplo, suponha que o prazo seja de 25 dias em vez de 29:

Acelerar H economiza um dia nos dois caminhos por 2.000: claramente o primeiro passo. Acelerar G economiza mais um dia nos dois por 6.000. Acelerar D ou E não economiza nada, a menos que os dois sejam acelerados, por 13.000 no total para dois dias. Então chegar a 25 dias custa 21.000 e mexe em quatro atividades, enquanto o intuitivo "vamos acelerar o backend" teria gastado 8.000 sem economizar nada.

O fast tracking sobrepõe atividades que estavam em série, normalmente convertendo uma dependência término para início em início para início com antecipação. Não custa dinheiro, mas compra risco de retrabalho: começar o frontend antes de o design de interfaces estar concluído significa que parte dele será construída duas vezes. Aplique fast tracking primeiro às dependências arbitrárias, nunca às obrigatórias, e registre o risco adicional no registro de riscos.

A alternativa honesta é reduzir o escopo. Em geral é mais barato e mais seguro do que qualquer uma das duas técnicas, e é a opção que aparece por último na conversa.

Linha de base, mudanças e acompanhamento

Depois que o cronograma for acordado, congele uma cópia como linha de base. Tudo o que vier depois é medido em relação a ela, e ela só muda por meio de um controle de mudanças aprovado; caso contrário, o plano é reescrito discretamente todo mês para bater com a realidade, e o projeto parece estar no prazo até o dia em que deixa de estar.

Um processo de mudanças que funciona: uma avaliação de impacto em prazo, custo e risco; uma decisão de quem tem autoridade naquele patamar; uma nova linha de base só se a mudança for aprovada; e um registro preservado da linha de base anterior. Refazer a linha de base é legítimo após uma mudança real de escopo e ilegítimo como forma de apagar uma variação.

Acompanhe medindo o progresso em relação à rede, e não ao tempo de calendário decorrido. As perguntas que valem a pena toda semana são: alguma atividade crítica está atrasada? Quanta folga foi consumida nos caminhos quase críticos? As previsões dos marcos estão derivando? Alguma premissa de dependência deixou de valer? A variação de prazo em termos de custo é tratada em gerenciamento do valor agregado, que converte a mesma informação em dinheiro e oferece um índice para acompanhar a tendência.

Principais pontos

• O objetivo de um modelo de cronograma é identificar quais atividades não podem atrasar; o gráfico de barras é apresentação, e desenhá-lo sem uma rede de dependências gera um plano incapaz de reagir.
• Use os quatro tipos de dependência e modele as esperas explicitamente em vez de inflar durações, e marque as dependências arbitrárias, porque é nelas que a compressão encontra folga.
• Calcule a folga com uma passagem de ida e outra de volta; folga total é margem em relação à data de término, e folga livre é a margem que não afeta nenhuma sucessora.
• Uma rede pode ter vários caminhos críticos, e comprimir só um deles não adianta nada: recalcule sempre após cada passo de compressão.
• O nivelamento pode estender a data de término, a suavização não; se um especialista está em dois caminhos críticos, o cronograma vai se alongar.
• Defina a linha de base do cronograma e só a altere por decisões registradas; refazer a linha de base para apagar uma variação destrói a única referência que você tinha.