A linha de base de um gráfico de Gantt é uma versão de referência salva do cronograma do projeto, exibida ao lado do plano atual ou do progresso real. Ela permite comparar o prazo originalmente aprovado com o que agora parece provável e com o que já aconteceu. Uma linha de base não promete que a incerteza desapareceu.
A distinção importante é entre linha de base, previsão e realizado. A linha de base preserva uma referência acordada. A previsão muda à medida que a equipe aprende. As datas reais registram eventos concluídos. Se esses campos forem substituídos juntos, o gráfico deixa de explicar a movimentação do cronograma.
Este guia trata de interpretação e revisão em equipe, e não de instruções para um aplicativo específico de planejamento. O NextRetro é uma ferramenta de retrospectiva, não um mecanismo de agendamento Gantt; mantenha o cronograma oficial no sistema de planejamento do projeto.
O que deve constar na linha de base do cronograma?
Uma linha de base útil conecta atividades, dependências, calendários e marcos relevantes. Salvar uma imagem de datas arbitrárias não torna o plano confiável. Confirme como o cronograma representa a disponibilidade de recursos e quais premissas determinam as datas importantes de conclusão.
O Guia de Avaliação de Cronogramas do GAO dos EUA trata a manutenção de uma linha de base e a atualização do cronograma com base no progresso real como práticas distintas. Nosso método de revisão abaixo aplica essa distinção à reunião de decisão de uma equipe pequena; ele não substitui uma avaliação especializada do cronograma.
Registre a data de aprovação, o escopo, a versão e as premissas da linha de base. Especifique quem pode aprovar mudanças. Um projeto com compromissos contratuais ou regulatórios pode precisar de controles além dos exemplos simples apresentados aqui.
Não espere o fim da entrega para escolher a referência que faz o desempenho parecer melhor. Se o projeto usa planejamento progressivo, documente quais partes estão detalhadas, quais ainda são incertas e como o detalhamento aprovado será preservado.
Leia em conjunto as datas da linha de base, da previsão e do realizado
Considere este trecho hipotético de um projeto. Datas e atividades foram inventadas para explicar.
| Item | Término na linha de base | Previsão atual | Término real | Pergunta de revisão |
|---|---|---|---|---|
| Mapeamento de dados acordado | 4 nov. | — | 6 nov. | Por que o acordo levou mais tempo? |
| Ensaio da migração concluído | 11 nov. | 16 nov. | — | Qual atividade precedente ou restrição de capacidade mudou? |
| Aceitação operacional | 18 nov. | 23 nov. | — | A equipe receptora aceita a nova janela de prontidão? |
Um item concluído precisa de uma data real, não de uma previsão que continua mudando. Um item inacabado precisa de uma previsão realista, não da linha de base antiga copiada para o campo do plano atual porque ninguém quer comunicar um atraso.
Também diferencie tempo corrido de tempo útil. Cinco dias corridos e cinco dias úteis são comparações diferentes. Declare a convenção antes de calcular a variação, sobretudo quando as equipes adotam feriados ou calendários operacionais distintos.
Nem todo atraso muda a data de conclusão do projeto. Examine a lógica das dependências e a flexibilidade disponível antes de declarar que uma tarefa atrasada significa um projeto atrasado. Por outro lado, um pequeno atraso em uma transferência importante pode importar mais que várias grandes mudanças em outros pontos.
Revisão de variação em 30 minutos
Leve o cronograma atual, sua linha de base e uma lista curta dos itens cuja movimentação poderia mudar uma decisão. Evite revisar cada barra só porque ela existe.
Primeiros cinco minutos: concordem sobre a versão de referência e a data de status. Confirmem se o progresso real está atualizado. Registrem lacunas conhecidas nos dados antes de interpretar o gráfico.
Próximos dez minutos: examinem uma cadeia de trabalho importante. Perguntem o que mudou no escopo, na sequência, na disponibilidade, no esforço ou nos compromissos externos. Separem eventos sustentados por evidências de explicações plausíveis.
Próximos dez minutos: comparem as respostas possíveis. A equipe pode eliminar uma espera desnecessária, mudar a sequência com segurança, obter uma decisão ou reduzir o escopo autorizado? Que custo ou risco a aceleração traria? Mais pessoas ou horas extras têm consequências; não são correções automáticas.
Últimos cinco minutos: registrem a decisão, a pessoa responsável e a atualização da previsão. Se um compromisso precisar mudar, sigam o processo de aprovação estabelecido pelo projeto. Preservem a linha de base anterior e a justificativa de qualquer substituição autorizada.
Esses tempos são um formato sugerido de facilitação. Um programa complexo pode precisar de uma análise mais profunda de riscos do cronograma, em vez de uma reunião mais curta.
Exemplo trabalhado: a tarefa atrasada não era a única causa
Em uma migração de software hipotética, o ensaio termina quatro dias úteis depois da linha de base. A primeira explicação é “os testes demoraram demais”. A equipe está prestes a reduzir a próxima janela de testes para recuperar tempo.
A revisão acompanha as evidências para trás. A execução dos testes levou exatamente o tempo planejado. O trabalho começou tarde porque a equipe de operações que receberia o serviço não havia aprovado os dados de teste semelhantes aos de produção, e a pessoa aprovadora indicada não estava disponível.
Reduzir o tempo dos testes não resolveria essa causa e poderia enfraquecer as evidências de prontidão. Em vez disso, a equipe combina uma verificação de aceitação antecipada para o próximo ensaio e confirma uma pessoa substituta para a decisão conforme as regras de aprovação existentes.
A equipe atualiza a previsão e mantém a linha de base original visível. A retrospectiva registra uma lição reutilizável: identifique a disponibilidade para aprovações ao planejar a dependência, em vez de presumir que a pessoa indicada estará sempre disponível.
Ainda há impacto no cronograma. Uma boa explicação não o apaga. O patrocinador recebe a previsão revisada com opções e contrapartidas, não uma alegação de que o atraso deixou de contar.
Quando a equipe deve estabelecer uma nova linha de base?
Estabelecer uma nova linha de base muda a referência de comparação aprovada. Isso pode ser adequado após uma alteração de escopo autorizada ou uma grande redefinição do compromisso de entrega. Não deve ser a resposta rotineira a uma variação desfavorável.
Arquive a linha de base original, identifique o novo escopo e as datas aprovados e explique quais comparações os relatórios futuros usarão. Se apenas um pacote de trabalho mudou, evite reescrever silenciosamente o histórico que não tem relação com ele.
Uma nova linha de base pode ajudar a gerenciar o trabalho restante, enquanto a antiga continua útil para aprendizado. Esses objetivos são compatíveis. Os relatórios devem esclarecer se uma afirmação compara com o compromisso original ou com o plano autorizado posteriormente.
Não confunda uma previsão de trabalho com uma nova linha de base aprovada. A previsão pode e deve se tornar mais realista sem esperar que todas as premissas de planejamento sejam renegociadas formalmente.
Transforme evidências do cronograma em uma retrospectiva útil
Na próxima retrospectiva, escolha um padrão recorrente: espera por aprovações, integração subestimada, falta de capacidade ou transferências otimistas. Evite transformar a reunião em uma busca por culpados para cada atividade atrasada.
Pergunte que decisão a equipe poderia ter tomado antes com as informações já disponíveis. Em seguida, defina um experimento, como confirmar a disponibilidade de quem revisará antes de assumir um compromisso de marco, e uma forma de verificar se a mudança reduz aquele padrão específico de espera.
Use o guia de itens de ação de retrospectiva para registrar o experimento e o checklist de facilitação para preparar a conversa. O cronograma fornece evidências; a retrospectiva oferece um ciclo deliberado de aprendizado.
Perguntas frequentes
Uma linha de base é o mesmo que um prazo?
Não. Uma linha de base é uma versão de referência do cronograma. Um prazo é uma restrição ou compromisso de tempo. Um cronograma pode conter vários prazos, e sua linha de base preserva como a equipe planejou originalmente cumpri-los.
Devemos atualizar a linha de base quando uma tarefa atrasa?
Atualize a previsão atual para refletir a realidade. Altere a linha de base aprovada apenas de acordo com a governança acordada pelo projeto, preservando sua versão anterior e a justificativa. Substituições rotineiras dificultam interpretar o desempenho original.
Um gráfico de Gantt pode provar por que um projeto atrasou?
Um gráfico pode mostrar horários e relações de dependência, mas não estabelece todas as causas. Antes de escolher uma ação corretiva, investigue explicações concorrentes usando registros de tarefas, decisões, evidências de capacidade e relatos dos participantes.