Por que Estimar Tarefas é Tão Difícil e Por que Desenvolvedores Odeiam Isso

Quase todo desenvolvedor (até quem está começando a carreira) pode, em algum momento, ouvir a famosa pergunta: “Quando você acha que essa tarefa fica pronta?” e a gente trava por um instante até perceber que não sabe.

Nós, humanos, somos ruins em prever o futuro, então muitas vezes erramos na estimativa de tarefas. Alguns desenvolvedores podem ver isso como microgerenciamento, mas a verdade é que o PM (Product Manager) precisa saber disso, não porque quer microgerenciar (tá, tem gente que microgerencia, mas vamos deixar essas pessoas de fora), e sim porque precisa priorizar o roadmap de features para que a cadeia de liderança, do PM ao CEO e aos investidores, consiga ver se os objetivos dos times estão alinhados com os objetivos da empresa e o que pode ficar para trás agora pelo bem maior.

Mas estimar tarefas é uma frustração comum entre desenvolvedores, porque na real às vezes a gente não sabe exatamente quando algo vai ficar pronto, talvez porque é algo totalmente novo (domínio novo, tecnologia nova) ou porque existem muitas conexões externas cuja complexidade a gente não consegue medir.

Pra ser sincero, em mais de 10 anos de carreira em desenvolvimento de software, nunca vi um projeto que foi estimado para ser entregue na data alvo definida sem cortar escopo, fazer hora extra etc...

Vamos explorar isso :)

Os Desafios da Estimativa de Tarefas

1. Incerteza e Complexidade: Até os desenvolvedores mais experientes erram estimativas, porque desenvolvimento de software é complexo por natureza e esconde muita incerteza. Imagine que você quer implementar uma integração com um parceiro externo: você lê a documentação deles nos detalhes e estima a duração da tarefa, mas quando começa a implementar descobre que essa API às vezes dá timeout e que até a resposta dela para um payload específico é diferente do que você esperava. Aí você vai precisar construir um mecanismo novo para lidar com esses timeouts e mapear com cuidado alguns desses cenários de erro.
2. Requisitos que Mudam: Você começa uma tarefa com todos os requisitos definidos, mas no meio dela, quando alguém começa a testar, percebe que em vez de uma lista agora querem uma tabela, e essa tabela não existe no design system atual. O que foi planejado pode facilmente dobrar de tempo, já que agora você vai precisar construir e publicar o componente.
3. Interdependências: A gente pode tentar quebrar o máximo de tarefas em unidades pequenas, mas às vezes algumas tarefas dependem de outra, e atrasar uma tarefa pode afetar a estimativa inteira das outras.
4. Falta de Dados Históricos: Quando um time acabou de ser formado, não temos dados históricos de métricas como lead time, nem métricas da empresa sobre partes específicas do sistema. Isso piora quando pensamos em projetos inovadores ou experimentais (Oi, I.A. 👋🏾).

Por que Desenvolvedores Não Gostam de Estimar

1. Pressão e Estresse: Conheço gente que gosta de trabalhar sob pressão, mas a maioria simplesmente não gosta. É estressante dar estimativas precisas quando você está sob pressão. Estimativas que não se cumprem podem levar a sentimentos de fracasso ou frustração.
2. Distração do Desenvolvimento: Às vezes estimar leva muito tempo, principalmente em projetos grandes, e isso pode ser visto como uma distração do código de verdade... Já vi muitas vezes desenvolvedores preferirem focar em progresso concreto em vez de prazos especulativos.
3. Desalinhamento com a Realidade: Estimativas muitas vezes não batem com a realidade de tarefas complexas. Imagine que você precisa construir uma feature totalmente nova para ser lançada em 2 meses, para um evento em que a empresa vai apresentar. Gera muita frustração quando essas expectativas externas baseadas em estimativas não batem com o progresso real (para os dois lados, desenvolvedores e gestores).

Estratégias para Melhorar a Estimativa

1. Metodologias Ágeis: Não quero entrar em detalhes sobre metodologias ágeis, já que existem várias e cada uma funciona de um jeito em empresas diferentes, mas uma coisa boa que essas metodologias trazem é confiar em dados e no papel do desenvolvimento iterativo para refinar estimativas. Quando eu trabalhava como consultor de software, testamos vários tipos de medição para prever para nossos clientes quando algo poderia ser entregue, e uma que deu ótimo retorno foi o lead time: coletávamos os dados mês a mês para entender a velocidade do time e tentar prever a data de entrega.
2. Quebrar as Tarefas: Outra coisa que já vi funcionar bem é quebrar tarefas maiores em menores. Essa é uma das estratégias mais eficazes que um time pode usar, porque quebrando as tarefas você tem code reviews mais rápidos, deploys mais rápidos, pessoas trabalhando em paralelo e menos chance de introduzir bugs.
3. Revisão e Ajuste Constantes: Revise as estimativas de tempos em tempos para garantir que ainda estão no caminho certo e ajuste quando precisar. Os times podem iterar e ajustar as estimativas conforme entregam, levando em conta essas dinâmicas. Isso também permite identificar possíveis bloqueios a tempo e mudar os prazos de trabalho para uma estimativa melhor e mais flexível.

Conclusão

Estimar tarefas é difícil, e não existe um jeito certo de fazer isso, só o jeito que funciona para você e para o seu time. Dá para seguir as estratégias que listei aqui, mas no fim é você quem testa e decide se funcionam e se vale a pena continuar assim. Lembre-se: como quase tudo na vida, a gente só melhora fazendo várias vezes, então tente, experimente e itere nas estratégias.