Pediram a um grupo de estudantes que estimasse quando entregaria a tese. A média das previsões ficou em torno de trinta e quatro dias. Questionados sobre o pior cenário imaginável, responderam algo perto de quarenta e nove. O prazo real de conclusão passou de cinquenta e cinco dias, quase o dobro da previsão média.
Jean Pierre Lessa e Santos Ferreira, diretor de tecnologia, aponta que o mesmo padrão se repete na gestão de projetos de tecnologia, com um agravante: no software, a estimativa vira contrato assinado, data de campanha e promessa feita a cliente. O erro deixa de ser curiosidade acadêmica e passa a ter preço.
Por que a estimativa fica sempre abaixo do prazo real?
Porque a cabeça estima o caminho feliz. Quem planeja imagina a tarefa acontecendo sem interrupção, sem reunião imprevista, sem dependência de um terceiro que demora dois dias para responder a um e-mail. A memória colabora com o engano, guardando os dias em que tudo fluiu e apagando as semanas em que nada saiu do lugar.
O detalhe mais duro daquele estudo é outro. Nem o cenário pessimista dos estudantes alcançou o prazo real, o que mostra que o problema não se resolve pedindo à equipe que pense no pior. Pessimismo sob encomenda continua ancorado na mesma previsão otimista de origem.
Somar a estimativa de cada tarefa dá o prazo do projeto?
Não, e a razão é estatística. Cada tarefa tem uma duração mais provável e uma cauda longa de coisas que podem dar errado, e essa cauda não é simétrica: nada termina na metade do tempo, mas muita coisa leva o triplo. Ainda assim, Jean Pierre Lessa e Santos Ferreira nota que é a soma dos números centrais que vira cronograma oficial.
As dependências pioram o quadro. Quando uma etapa espera a anterior, o atraso de uma não é compensado pelo adiantamento de outra, porque adiantamento raramente aparece e, quando aparece, ninguém antecipa a etapa seguinte. Basta uma tarefa do caminho crítico escorregar para a sequência inteira escorregar junto. Atrasos se acumulam. Ganhos evaporam.
Uma margem fixa de segurança resolve?
Vinte por cento a mais é a fórmula preferida, e ela costuma sumir na primeira semana. A folga colocada no fim do cronograma não tem dono, então funciona como espaço livre: o escopo cresce até ocupá-la, e a reserva é consumida antes de surgir o primeiro problema de verdade.
Margem por porcentagem também erra a mão porque trata tarefas diferentes como se carregassem o mesmo risco. Daí a sugestão de Jean Pierre Lessa e Santos Ferreira: concentrar proteção onde a incerteza está, em vez de espalhá-la por igual, o que exige separar o que a equipe já fez daquilo que ninguém nunca tentou.
More Read
E quando a data já foi prometida?
Aí a variável que sobra é o escopo. Data fixa com escopo fixo só se ajusta pela qualidade, e essa é a única das três que ninguém combina em reunião: ela apenas acontece, na forma do teste que não foi escrito e da revisão que virou formalidade.
A saída prática é negociar recorte, e não prazo. O especialista comenta que entregar metade do escopo na data prometida costuma valer mais do que entregar tudo dois meses depois, desde que a metade escolhida seja a que o usuário realmente usa. Definir essa metade é trabalho de produto, não de cronograma.
Prazo é consequência do tamanho da entrega
Projetos de doze meses erram mais do que projetos de seis por um motivo simples: quanto maior a janela, maior o número de coisas que mudam dentro dela. Prioridade, time, fornecedor, regra de negócio. Estimar melhor não corrige isso, porque a incerteza não está na conta, está no tempo.
Reduzir o tamanho da entrega é o único ajuste que ataca a origem do erro. Pedaços menores chegam antes ao usuário, produzem dado real sobre o ritmo da equipe e transformam a estimativa seguinte em medição, não em aposta. A régua interna de um time só melhora quando existe histórico para compará-la.
