Estimativa de prazo: por que erramos sempre e o que reduz o erro

Existe um padrão que se repete em qualquer time, com qualquer metodologia, em qualquer empresa: a tarefa estimada em três dias leva sete. E o mais curioso é que isso continua acontecendo com gente experiente, que já errou centenas de vezes antes.

Isso não é falta de competência. É um viés cognitivo bem estudado — a tendência de subestimar o tempo de uma tarefa própria, mesmo sabendo que tarefas semelhantes levaram mais tempo no passado.

Não dá para eliminar. Dá para reduzir bastante o estrago, e é sobre isso que quero falar.

Por que o erro é sistemático, e sempre para o mesmo lado

Repare que a estimativa quase nunca erra para mais. É sempre para menos. Isso indica causa estrutural, não aleatoriedade.

Três razões que explicam a maior parte:

• Estimamos o caminho feliz. Ao imaginar a tarefa, sua cabeça monta a versão em que tudo funciona: o código roda, o ambiente sobe, a API responde. Não existe cenário mental em que a dependência quebra na sexta à tarde — mas ele existe no calendário.
• Esquecemos o trabalho ao redor. Programar é uma fatia do que a tarefa exige. Revisar, corrigir o que a revisão apontou, testar em homologação, resolver conflito, atualizar documentação, responder no chat. Quando alguém diz "três dias", geralmente está estimando só a fatia de escrever.
• Ignoramos a fila. A tarefa pode levar três dias de trabalho e sete de calendário, porque no meio tem duas reuniões, um incidente e dois dias esperando revisão de alguém ocupado.

A pergunta "quanto tempo leva?" tem duas respostas muito diferentes: tempo de trabalho e tempo de calendário. Quem pergunta quer a segunda; quem responde calcula a primeira.

O que funciona de verdade

1. Olhar o histórico em vez de imaginar o futuro

A correção com melhor retorno, e a menos usada. Antes de estimar, procure duas ou três tarefas parecidas que o time já entregou e veja quanto tempo levaram de verdade, do início ao fim.

Isso funciona porque contorna o viés: você não está prevendo, está consultando. E o histórico já inclui, automaticamente, tudo que a imaginação exclui — as reuniões, os incidentes, a espera por revisão.

Não precisa de ferramenta. Precisa que alguém tenha anotado quando a tarefa começou e quando terminou.

2. Estimar faixa, não ponto

"Cinco dias" comunica uma precisão que não existe. "Entre quatro e nove dias" é honesto — e a largura da faixa carrega informação: faixa apertada é sinal de que o time entende bem o problema; faixa larga avisa que há incerteza real, o que é exatamente o que a liderança precisa saber.

Quando alguém insiste em um número único, ofereça o topo da faixa. Prazo cumprido constrói confiança; prazo otimista quebrado destrói.

3. Quebrar até caber em um dia

Existe uma relação direta entre tamanho da tarefa e erro de estimativa. Tarefa de dois dias erra pouco. Tarefa de "umas duas semanas" erra muito, porque "duas semanas" é o jeito de dizer "não sei".

Quebre até cada pedaço caber em um dia. Duas coisas acontecem: a soma fica mais precisa, e — mais importante — ao quebrar, você descobre o que não sabia. É durante a quebra que aparece o "espera, e a migração dos dados antigos?".

Se um pedaço não quebra porque você não entende o suficiente, isso não é falha de planejamento. É a descoberta mais valiosa da reunião.

4. Separar o que é desconhecido do que é trabalho

Existem dois tipos de tarefa, e tratá-las igual é erro caro:

• Trabalho conhecido: você já fez algo parecido, sabe o caminho. Aqui a estimativa é razoável.
• Desconhecido: ninguém sabe se a abordagem funciona. Isso não é estimável.

Para o segundo tipo, não estime — reserve tempo. "Dois dias para investigar e voltar com uma resposta" é um compromisso honesto e cumprível. Depois da investigação, aí sim existe base para estimar.

Boa parte dos prazos catastroficamente errados nasce de tratar desconhecido como trabalho conhecido.

Duas práticas que não funcionam

Multiplicar por dois. Parece esperto e falha de dois jeitos: nas tarefas simples você fica com folga demais e o trabalho se expande para preencher; nas complexas, dobrar não é suficiente. Pior — o time percebe o multiplicador e começa a estimar já descontando, e aí você multiplica um número inflado.

Colchão escondido. Quando ninguém sabe onde está a folga, ela some. A tarefa "de cinco dias com dois de colchão" simplesmente vira uma tarefa de sete dias na cabeça de todo mundo. Se precisa de folga, declare como folga do projeto, visível.

A conversa que ninguém quer ter

Boa parte do problema não é técnica. É que a resposta honesta é impopular, e todo mundo aprende isso rápido.

Quando a estimativa realista não cabe no prazo desejado, o caminho fácil é diminuir o número. O caminho útil é apresentar as opções reais:

• Entregar menos escopo no prazo.
• Entregar tudo depois.
• Entregar no prazo com qualidade menor — e nomear o que isso significa: sem teste, sem tratamento de erro, sem funcionar em celular.

Essas três são as opções que existem. Quando o time só diz "vai dar", ele está escolhendo a terceira sem avisar — e a dívida aparece depois, sem contexto.

O sinal de que a estimativa está sendo usada errado

Estimativa serve para planejar. Quando vira instrumento de cobrança, o time responde de forma previsível: infla tudo, para nunca errar.

Aí você tem estimativas confortáveis, precisão zero e um planejamento que não descreve mais a realidade. E ninguém vai te contar que isso está acontecendo.

O teste: quando alguém estoura um prazo, a reação é entender o que aconteceu ou cobrar explicação? A primeira produz estimativas melhores com o tempo. A segunda produz estimativas maiores.

O resumo

Olhe o histórico em vez de imaginar. Dê faixa em vez de ponto. Quebre até caber em um dia. Separe desconhecido de trabalho, e reserve tempo para o primeiro em vez de estimar. E quando o prazo não couber, apresente as três opções reais em vez de encolher o número.

Você vai continuar errando — o viés não vai embora. Só vai errar bem menos, e com muito mais clareza sobre onde a incerteza estava desde o começo.