Por que parei de estimar: um argumento baseado em dados contra previsões de software

Published: at 03:30 PMSuggest Changes
Por que parei de estimar: um argumento baseado em dados contra previsões de software

Como aumentamos a entrega de features em 40% e salvamos nossa sanidade

“A release India vai ser entregue amanhã.”

Essas quatro palavras costumavam gerar um tipo específico de pavor na Complyance. Significava que as próximas 24 horas seriam caóticas, code reviews apressados, e aquela sensação familiar de empurrar algo que sabíamos que não estava pronto.

Já tínhamos passado por isso nove vezes. Alpha até India, seguindo o alfabeto da aviação. Releases de seis semanas, features cuidadosamente estimadas, promessas feitas para clientes enterprise baseadas nessas estimativas.

Todos. Os. Releases. O mesmo padrão:

Depois da release “India”, fizemos algo radical: jogamos o sistema inteiro fora.

Sem mais releases. Sem mais estimativas. Sem mais promessas baseadas em chutes.

O resultado? A entrega de features aumentou 40%. O moral da equipe mudou complatemente. E paradoxalmente, nossos clientes ficaram mais felizes mesmo sem recebermos datas.

Esta é a história de como aprendemos o que a pesquisa vem nos dizendo há décadas. E por que a maioria das equipes ainda está errando.

O Problema Trilionário das Estimativas

O CHAOS Report do Standish Group, que estudou mais de 50.000 projetos, descobriu que apenas 29% dos projetos de TI têm sucesso (no prazo, no orçamento, com resultados satisfatórios), enquanto 19% são falhas completas e 52% são problemáticos. O custo total das falhas de projeto? Estimados US$ 260 bilhões anuais apenas nos EUA, segundo múltiplas análises da indústria.

Mais revelador: múltiplos estudos da indústria mostram consistentemente que estimativas de software estão tipicamente erradas por um fator de 2-4x, e isso não melhorou em décadas apesar de ferramentas e metodologias melhores.

O que minha experiência nesta indústria me ensinou? Não somos ruins em estimar. Estamos tentando prever o fundamentalmente imprevisível.

A Física do Desenvolvimento de Software

O desenvolvimento de software viola as leis que fazem a estimativa funcionar em outros campos:

1. O Efeito do Observador

No momento em que você estima uma tarefa, você a modifica. Equipes inconscientemente ajustam seu trabalho para se adequar à estimativa: correndo quando estão “atrasadas”, polindo demais quando estão “adiantadas”. Isso é conhecido como Lei de Parkinson: o trabalho se expande para preencher o tempo disponível para sua conclusão. A estimativa se torna a realidade.

2. O Cone da Incerteza é uma Mentira

O famoso “Cone da Incerteza” sugere que estimativas melhoram com o tempo. Mas pesquisas mostram que no desenvolvimento moderno de software, a incerteza frequentemente aumenta conforme você aprende mais. Por quê? Porque bom desenvolvimento de software é sobre descobrir o que você deveria construir, não apenas construir o que foi planejado.

Na Complyance, vivemos essa realidade por 54 semanas através de nove releases. Cada “melhoria simples de 2 semanas” tinha um iceberg escondido por baixo. Só na release “India”, três features foram estimadas em uma semana cada. Tempo final de entrega? Cinco semanas, duas semanas, e três dias respectivamente.

Mas aqui está o ponto: sempre conseguimos fazer funcionar. Não porque nossas estimativas melhoraram, mas porque somos engenheiros inteligentes que fariam o que fosse necessário. Incluindo aquele finais de semana regados à redbull e madrugadas de trabalho: para cumprir o prazo arbitrário que definimos para nós mesmos.

A estimativa não estava prevendo o trabalho. O trabalho estava se conformando à estimativa, a um tremendo custo humano.

3. A Cascata de Complexidade

A complexidade de software segue uma distribuição de lei de potência. A maioria das mudanças são triviais, algumas são moderadas, mas uma pequena porcentagem são exponencialmente complexas. O problema? Você não pode dizer qual é qual até estar no meio do caminho. Esse padrão é bem documentado em múltiplos projetos de software e códigos.

Através dos nossos nove releases, vimos esse padrão repetidamente: tarefas “simples” que revelaram problemas fundamentais de arquitetura, e features “complexas” que se mostraram diretas graças a bibliotecas ou abordagens existentes que descobrimos durante a implementação.

Depois de nove releases, nossa precisão de estimativas não estava melhorando. Por quê? Porque cada release nos ensinava mais sobre o que não sabíamos.

Os Custos Escondidos Que Ninguém Fala

Vamos fazer as contas do que a estimativa realmente custa:

Custos diretos (baseado em pesquisa da indústria e nosso próprio rastreamento):

Custos indiretos (mais difíceis de medir, mas mais prejudiciais):

Com um salário médio de desenvolvedor de $130.000/ano, isso são 6.3 semanas × 10 desenvolvedores = 63 semanas de produtividade perdida anualmente. Isso é mais de um ano completo de desenvolvedor de capacidade perdida apenas com overhead de estimativas.

A Transformação: O Que Realmente Funciona

Depois da release “India”, fizemos a mudança. Hoje na Complyance fazemos assim, e mostro alguns dados que provam que a mudança está funcionando:

1. De Releases para Fluxo Contínuo

Antes (Alpha até India): Releases de 6 semanas, batching de features, planning poker, sessões de planejamento de release, modo crise da última semana

Depois: Deploy contínuo, uma reunião semanal de refinamento (nossa única reunião restante de uma longa lista), entrega diária, CI e CD de verdade.

A mudança psicológica foi imediata. Sem mais “calmaria da semana 1” seguida de “pânico da semana 6”. Apenas progresso estável e sustentável. Nossa velocidade realmente se tornou previsível, não através de estimativas, mas através de fluxo consistente.

2. Pequenas entregas ao invés de grandes deploys

Você deve estar argumentando: mas você pode claramente fazer o deploys de features novas durante uma release usando feature flags. Corretíssimo, fazíamos assim. Mas a questão era que no setup anterior, toda feature devia ter um escopo sempre menor ou igual ao tamanho da release, e muitas vezes isso não acontecia.

Ao invés de estimar uma “feature completa” e agrupá-la para um release, entregamos incrementos:

Nossos clientes agora veem progresso diariamente ao invés de a cada 6 semanas. Eles podem começar a usar features imediatamente. E podemos pivotar baseado em feedback real, não requisitos imaginados.

3. Tempo Fixo, Escopo Variável

Comprometemos com faixas de tempo, não listas de features:

Isso inverte toda a conversa. Em vez de “Quando X vai estar pronto?” vira “Qual o máximo de valor que podemos entregar até a data Y?“

4. Previsão Probabilística Quando Necessário

Quando absolutamente precisamos fornecer previsões (para compliance regulatório, contratos grandes, etc.), usamos previsão probabilística baseada em dados reais:

Isso é tanto mais honesto quanto mais preciso que estimativas tradicionais.

Os Resultados: Mais Que Apenas Números

Depois de abandonar releases e estimativas:

Os números:

O lado humano:

A métrica mais reveladora? Não tivemos um único “modo crise” desde que abandonamos as estimativas. Nem um.

5. A Mentalidade de Investimento

Tratamos desenvolvimento como um investidor trata startups:

Nenhum VC pergunta a uma startup “Quantos dias vai levar para alcançar product-market fit?” Eles investem em etapas e ajustam baseado em resultados.

Os Contra-Argumentos (E Por Que Estão Errados)

“Mas precisamos de previsibilidade para planejamento de negócio!”

Você está recebendo previsibilidade falsa agora. Análises da indústria mostram consistentemente que estimativas tradicionais estão erradas em 100-200% em média. Previsões meteorológicas são mais precisas em 7 dias do que a maioria das estimativas de software em 7 dias.

Previsibilidade real vem da entrega consistente de valor, não chutes precisos sobre o futuro.

“Como escolhemos entre projetos sem estimativas?”

Custo do Atraso. Em vez de perguntar “Quanto tempo?” pergunte “Quanto custa esperar?” Um cálculo aproximado de valor/semana perdido supera uma estimativa precisa de tempo de desenvolvimento toda vez.

“Nossos contratos exigem compromissos de escopo fixo e tempo fixo!”

Enfrentamos isso na Complyance. Vários clientes enterprise tinham compromissos de roadmap baseados nas nossas promessas de release de 6 semanas. Aqui está como lidamos com a transição:

  1. Mostramos a eles nossos dados reais de entrega (promessas versus realidade ao longo de 9 releases)
  2. Oferecemos um acordo melhor: entrega contínua com capacidade de mudar prioridades a qualquer momento
  3. Garantimos throughput (features por mês) em vez de features específicas por datas específicas

Resultado? A transição correu mais suavemente que esperado, com clientes se adaptando bem à abordagem de entrega contínua.

Se isso não funcionar, considere: O governo do Reino Unido economizou £800 milhões mudando para contratos ágeis. Se a aquisição governamental pode evoluir, a sua também pode.

“Isso nunca funcionaria em indústrias regulamentadas!”

Na verdade é onde a entrega contínua brilha. Reguladores se importam com resultados e gestão de risco, não com seus story points. Na verdade, entrega contínua frequentemente melhora compliance reduzindo tamanhos de lote e aumentando rastreabilidade. Releases menores e mais frequentes são mais fáceis de auditar e reverter se necessário.

O Movimento #NoEstimates Estava Certo o Tempo Todo

Allen Holub, uma das principais vozes do movimento #NoEstimates, coloca de forma direta: “Estimativas são desperdício. Não apenas não são necessárias, mas introduzem disfunção na equipe.”

Na Complyance, vivemos essa disfunção por 54 semanas. Toda estimativa se tornou um compromisso. Todo compromisso se tornou uma crise. Toda crise corroeu a confiança.

Ron Jeffries, signatário do Manifesto Ágil, coloca ainda mais diretamente em sua análise sobre estimativas:

“Estimativas de itens de backlog são desnecessárias para desenvolvimento Ágil eficaz. Como são desnecessárias, devem ser eliminadas até que se prove que são necessárias.”

Mas aqui é onde tanto Holub quanto nossa experiência vão além: Mesmo com segurança psicológica perfeita e sem pressão de prazo, estimativas são desperdício. Elas estão respondendo a pergunta errada.

A pergunta certa não é “Quanto tempo isso vai levar?” É “No que devemos trabalhar em seguida para entregar mais valor?”

Como Holub diz: “Planejamento acontece constantemente. Suas projeções mudam toda vez que você completa uma story.” Foi exatamente isso que descobrimos - previsibilidade real vem de medir o que realmente entregamos, não adivinhar o que podemos entregar.

Seu Desafio de 30 Dias Sem Estimativas

Inspirado pelo movimento #NoEstimates

Ainda cético? Tente isso:

  1. Semana 1-2: Rastreie tudo mas não estime. Apenas construa e meça.
  2. Semana 3: Compartilhe diariamente o que completou, não o que planejou.
  3. Semana 4: Faça previsões usando seus dados reais, não chutes.
  4. Semana 5: Compare resultados com seu último sprint estimado.

Equipes que abraçam essa abordagem relatam o mesmo padrão: menos tempo falando sobre trabalho, mais tempo fazendo trabalho, desenvolvedores mais felizes, e, surpreendentemente, stakeholders mais felizes.

A Conclusão: Um Novo Modelo Mental

Aqui está a mudança fundamental: Desenvolvimento de software não é construção. É descoberta.

Quando você constrói uma casa, você sabe o que está construindo. Os desconhecidos são mínimos. Estimativas funcionam.

Quando você desenvolve software, você está descobrindo:

Você não pode estimar descoberta assim como Colombo não podia estimar quanto tempo levaria para “chegar às Índias.” Ele estava resolvendo o problema completamente errado.

As empresas que estão tendo sucesso hoje, de Spotify à Amazon à Netflix, não estimam melhor. Elas construíram sistemas que tornam estimativas irrelevantes. Elas entregam continuamente, medem constantemente, e pivotam rapidamente.

A pergunta não é “Como podemos estimar melhor?”

É “Como podemos construir sistemas onde estimativas não importam?”

Pare de estimar. Comece a entregar. Seus usuários estão esperando.

Qual sua experiência com estimativas? Já tentou trabalhar sem estimativas? Compartilhe sua história nos comentários ou entre em contato diretamente. Respondo a todas as mensagens.

Leituras Complementares

Foto do cabeçalho por Josh A. D. no Unsplash

Post Anterior
Software produzido em massa? Temos. Por que programar com IA funciona (se você souber usar)
Próximo Post
Como encontrar o equilíbrio entre não se apressar para mostrar serviço e superar expectativas em startups early stage