Como eu estimava tarefas no começo — e porque errava sempre
Em 2019 eu estimava em horas e entregava em dias. Levou algumas conversas difíceis para entender que estimativa não é previsão — é comunicação.
"Quanto tempo você acha que isso leva?"
Respondi "umas duas horas" com confiança. Levou dois dias.
Não porque fui lento. Porque não tinha contado: ler a documentação da API, descobrir que o endpoint que precisava estava em versão beta, debugar o formato de resposta que era diferente do que a doc dizia, e mais meia hora de testes para ter certeza que funcionava em caso de erro.
"Duas horas" era o tempo de escrever o código. Não era o tempo de resolver o problema.
Essa distinção — tempo de código vs. tempo de solução — é o erro que quase todo dev júnior comete.
O tempo de código é o que você imagina fazendo. O tempo de solução inclui tudo que você precisa entender antes de escrever, os obstáculos que não estavam no spec, e a verificação que o que você fez realmente funciona.
Um bom heurístico que aprendi depois: quando você está estimando, pense em todas as partes do problema. Depois multiplique por 1.5 se for coisa que você já fez antes. Por 2 se for algo novo. Por 3 se tiver dependência de terceiro (API externa, outra equipe, documentação incerta).
Nunca tinha pensado assim. Estimava o código, não o problema.
Mas o maior erro não era errar a estimativa.
Era não comunicar quando percebia que ia errar.
Hoje sei que se você percebe no meio do caminho que sua estimativa foi otimista, a coisa certa é falar antes de ser perguntado. "Estimei X, vai levar Y por causa de Z." Isso dá ao cliente ou ao time a chance de ajustar. Silêncio não ajuda ninguém.
Na época eu ficava quieto e tentava compensar trabalhando mais rápido. Não funciona. Código apressado gera mais problema do que o atraso original teria gerado.
Não existe estimativa perfeita em software. O problema não é errar — é não aprender com o padrão dos próprios erros.
Toda vez que terminei uma tarefa mais tarde do que estimei, aprendi a voltar e perguntar: por que errei? O que não contei? O que era imprevisível vs. o que eu poderia ter previsto se tivesse pensado mais?
Depois de alguns meses fazendo isso, minhas estimativas ficaram melhores. Não porque aprendi uma fórmula — porque aprendi o meu próprio padrão de onde eu subestimo.
Essa semana: pega a última tarefa que você terminou mais tarde do que estimou. Escreve em 3 linhas por que errou. Você vai encontrar um padrão.