Quase todo projeto que morre não morre no começo. Ele morre em 90%. O código existe, a tela abre, o fluxo principal funciona numa demonstração cuidadosamente ensaiada — e mesmo assim ele não entra no ar. Passa uma semana, passa um mês, passa um trimestre. O time continua trabalhando. A entrega continua a duas semanas de distância, permanentemente.
Essa cena é tão comum que virou piada de corredor, e é justamente por ser comum que ela merece um tratamento sério. Ela não é falta de esforço, não é falta de talento e quase nunca é falta de ferramenta. Existe pesquisa empírica de três décadas sobre exatamente esse fenômeno, e ela aponta para causas bem menos glamourosas do que "o time não se dedicou".
O "quase pronto" é uma medida, não um sentimento
Vale começar desarmando a ideia de que isso é impressão. Uma revisão sistemática de todas as pesquisas de acurácia de estimativa disponíveis à época, conduzida por Kjetil Moløkken-Østvold e Magne Jørgensen, encontrou que 60% a 80% dos projetos de software sofrem estouro de esforço e/ou de prazo, com estouro médio de esforço na faixa de 30% a 40%. Especificamente para prazo, a frequência fica entre 65% e 80%, com magnitude de 20% a 25%.
Repare no formato desse dado. Não é "projetos ruins estouram". É a distribuição inteira deslocada: estourar é o comportamento típico, não a exceção. Na pesquisa que os mesmos autores conduziram na indústria norueguesa, 76% dos projetos estouraram esforço, com magnitude média de 41%.
Um detalhe da mesma pesquisa costuma passar batido e explica muito: o tipo de cliente muda o tamanho do estouro. Projetos para o setor público estouraram esforço em 67% na média, contra 21% nos privados. O que muda entre um e outro não é a dificuldade técnica — é quanto de conversa, aprovação e negociação de escopo existe entre uma decisão e a próxima.
A estimativa já nasce torta, e avisar não resolve
Aqui está o achado mais desconfortável dessa literatura, e o que mais muda a forma de trabalhar de quem entende o que ele significa.
Jørgensen, revisando os estudos sobre estimativa por especialista, descreve um experimento em que os estimadores foram expostos a uma informação sobre o custo que o cliente esperava. A estimativa deles se moveu na direção dessa expectativa — o que já seria previsível. O achado forte é o seguinte: o efeito permaneceu mesmo quando os estimadores foram explicitamente avisados de que o cliente nada sabia sobre custos reais e de que aquela informação era irrelevante. Mais: os próprios profissionais subestimaram fortemente o quanto tinham sido influenciados.
A conclusão prática que o autor tira disso é dura e vale ser lida devagar: avisar não basta. Se o estimador for exposto à âncora, ele ancora — sabendo ou não. A única proteção confiável é não expor.
Se a expectativa de prazo do cliente entra na sala antes da estimativa, o número que sai de lá não é uma estimativa. É a expectativa do cliente com um jaleco técnico.
O mesmo corpo de revisão registra um segundo mecanismo, mais banal e igualmente caro: estouros de custo aparecem associados à falta de dados documentados de tarefas anteriores. Quando não existe registro do que as últimas dez entregas semelhantes custaram de verdade, o estimador recorre à memória — e a memória é otimista por construção, porque lembra do resultado e esquece dos tropeços.
O risco real não está na média, está na cauda
Se a conversa parasse na média de estouro, o problema seria administrável: reserve 30% a mais e siga. Não é assim que se comporta.
Bent Flyvbjerg e Alexander Budzier analisaram 1.471 projetos de TI e encontraram estouro médio de custo de 27%. Só que a média esconde a forma da distribuição: um em cada seis projetos da amostra era um "cisne negro", com estouro médio de custo de 200% e estouro de prazo de quase 70%. Não é que os projetos erram um pouco em torno de uma média confortável — é que a maioria erra pouco e uma minoria significativa erra de forma catastrófica.
Um trabalho posterior dos mesmos autores, com 5.392 projetos de TI, mostrou que esses estouros seguem uma distribuição de lei de potência, com cauda gorda. A consequência gerencial é direta: quem planeja assumindo que o erro se distribui normalmente subestima grosseiramente a chance do estouro extremo. E o mecanismo que os autores propõem e demonstram por simulação é o que interessa para este artigo — interdependência entre componentes. Um problema num único componente desencadeia reação em cadeia nos componentes acoplados a ele.
Guarde essa palavra: acoplamento. Ela vai voltar.
Onde o tempo realmente vai
Existe uma imagem mental predominante do trabalho de software: o desenvolvedor escrevendo código. Ela está errada em proporção.
Um estudo da Microsoft Research com 5.971 respostas válidas — de 37.792 convites, 15,5% de taxa de resposta — pediu aos desenvolvedores que relatassem o dia de trabalho anterior em minutos. O resultado por atividade foi: escrever e ler código, 15% do dia (84 minutos); corrigir bugs, 14% (74 minutos); reuniões, 15% (85 minutos); testar, 8%; e-mail, 10%; revisar código, 5%. Num subgrupo de "dia de reunião", que representa 8,5% dos respondentes, as reuniões consumiram mais de quatro horas — 46% do dia — sobrando cerca de hora e meia para desenvolvimento.
Um segundo estudo, este de campo, acompanhou 79 desenvolvedores profissionais ao longo de 3.244 horas de trabalho, capturando interação em todas as aplicações e não apenas na IDE. Achado central: até 58% do tempo é gasto em compreensão de programa — entender o que já existe antes de poder mudá-lo. Desenvolvedores sêniores gastam um percentual significativamente menor que juniores nessa atividade.
Uma ressalva honesta, e o próprio estudo da Microsoft a faz: o percentual de tempo "codando" reportado na literatura varia de 9% a 61% conforme a metodologia. Qualquer artigo que cite um único número como se fosse fato consolidado está simplificando demais. O que sobrevive à variação metodológica não é o número exato, e sim a direção: a fatia de digitar código é minoritária, e a de entender contexto é enorme.
Junte isso ao acoplamento da seção anterior e o "quase pronto" começa a fazer sentido mecânico. Quanto maior o bloco de trabalho acumulado sem verificação, mais contexto precisa ser reconstruído para cada correção, e mais componentes cada correção pode perturbar.
O tamanho do lote é a variável que você controla
Aqui está a virada prática deste texto. A estimativa é enviesada de forma que avisos não corrigem. A cauda da distribuição é gorda e imprevisível por natureza. Nada disso está sob o seu controle direto.
O tamanho do lote está.
A DORA — o programa de pesquisa de engenharia de software mantido pelo Google Cloud — publica uma definição operacional incomumente concreta: qualquer lote de código que leve mais de uma semana para ser concluído e verificado é grande demais. A orientação é trabalhar em incrementos de horas a poucos dias, e a referência para um lote pequeno é algo que possa ser testado e implantado em produção em menos de uma hora.
Vale a transparência: essa prescrição da DORA é qualitativa. Em nenhuma edição, de 2016 a 2025, a DORA publicou um tamanho de efeito numérico para tamanho de lote — nos relatórios recentes ele aparece como moderador, em rótulos ordinais, sem coeficiente. Quem quiser número precisa ir à literatura acadêmica. E lá o número existe, é antigo e é brutal.
Purushothaman e Perry mediram a probabilidade de uma mudança introduzir erro em função do seu tamanho, e a relação cresce monotonicamente:
| Tamanho da mudança | Taxa de erro |
|---|---|
| 0 a 5 linhas | 5,9% |
| 10 a 20 linhas | 13,5% |
| 30 a 50 linhas | 20,6% |
| 100 a 200 linhas | 25,5% |
| 200 a 500 linhas | 45,8% |
| mais de 500 linhas | 68,6% |
Uma mudança de até cinco linhas erra em 6% das vezes. Uma de mais de quinhentas erra em 69%. Não é uma diferença de grau — é uma mudança de regime. E o mesmo trabalho registra o dado que fecha o ciclo do "quase pronto": cerca de 40% das mudanças feitas para corrigir defeitos introduziram um ou mais outros defeitos. É assim que um projeto passa três meses a duas semanas do fim.
O achado se repete em outra metodologia. Analisando 78.954 transações no Eclipse e 109.658 no Mozilla, Śliwerski, Zimmermann e Zeller mostraram que as mudanças que induzem correção posterior são cerca de três vezes maiores que as que não induzem — média de 7,49 contra 2,61 arquivos no Eclipse.
O relatório Accelerate State of DevOps 2024 descreve os grupos de desempenho de entrega com números fechados:
| Grupo | Lead time | Frequência de deploy | Taxa de falha em mudanças |
|---|---|---|---|
| Elite | menos de 1 dia | sob demanda | 5% |
| High | 1 dia a 1 semana | diário a semanal | 20% |
| Medium | 1 semana a 1 mês | semanal a mensal | 10% |
| Low | 1 a 6 meses | mensal a semestral | 40% |
Vale registrar uma inconsistência que está no próprio relatório oficial e que costuma ser suavizada por quem cita a tabela: o grupo Medium aparece com taxa de falha de 10%, menor que a do grupo High, de 20%. A tabela não sustenta uma leitura simples de "quanto mais rápido, mais estável". O que ela sustenta com folga é o contraste entre os extremos: o grupo Low, que entrega em lotes de meses, falha em 40% das mudanças e leva de uma semana a um mês para se recuperar de um deploy ruim. Na comparação direta entre Elite e Low, o mesmo relatório aponta lead time 127 vezes mais rápido e recuperação 2.293 vezes mais rápida.
A leitura útil não é "seja elite". É mais modesta e mais acionável: lote de meses e recuperação de semanas andam juntos, e é exatamente essa combinação que produz a sensação de projeto permanentemente a duas semanas do fim.
E aqui cabe uma segunda ressalva, porque o oposto também é vendido com excesso de confiança. A tabela acima descreve cadência de release, e cadência não é a mesma coisa que tamanho de lote. Dá perfeitamente para fazer release semanal empurrando um lote gigante acumulado — e esse é o pior dos dois mundos, porque paga o custo do ritual sem colher o benefício da verificação.
O que a evidência sustenta com força é a afirmação mais específica: o tamanho da mudança prevê defeito. Isso está medido, é monotônico e se repete em metodologias independentes, separadas por anos e por base de dados. "Entregar mais rápido melhora a qualidade" é uma conclusão bem mais frouxa do que essa, e não é o que este artigo defende.
A IA mudou o volume, não o gargalo
Como este texto é de 2026, seria desonesto não tratar da pergunta óbvia: a assistência de IA não resolve isso sozinha?
Os dados primários dizem que não, e dizem de um jeito específico que vale entender.
O experimento mais direto sobre isso é um ensaio randomizado da METR. Dezesseis desenvolvedores experientes — com cinco anos de média nos próprios repositórios em que trabalhariam, projetos maduros de mais de um milhão de linhas — receberam 246 tarefas reais, sorteadas entre "IA permitida" e "IA proibida". O resultado medido: permitir IA aumentou o tempo de conclusão em 19%. Os desenvolvedores ficaram mais lentos.
O que torna esse estudo importante para o nosso assunto não é o 19%. É o que aconteceu com a percepção. Antes de começar, os participantes previram que a IA os deixaria 24% mais rápidos. Depois de terminar — já tendo vivido a lentidão, tarefa por tarefa — eles ainda estimaram ter sido 20% acelerados. A percepção não se corrigiu com a experiência direta do contrário.
Especialistas erraram mais que os praticantes: 34 economistas consultados previram redução de 39% no tempo; 54 especialistas em aprendizado de máquina, 38%.
Volte agora à segunda seção deste artigo, sobre ancoragem. É o mesmo formato de erro: uma crença sobre duração que não se corrige por aviso nem por experiência. E o próprio estudo mostra que não se trata de gente ruim em estimar — a correlação entre tempo previsto e tempo real das tarefas ficou em 0,64 com IA e 0,59 sem. Eles sabem julgar dificuldade. O que está invertido é especificamente a expectativa sobre o efeito da ferramenta.
O mecanismo aparece na análise de 128 gravações de tela: sob IA permitida, os desenvolvedores passam menos tempo escrevendo código e mais tempo formulando prompt, esperando geração e revisando saída — e aceitam menos de 44% do que a IA gera. O trabalho não desapareceu; mudou de natureza, de produção para auditoria.
A pesquisa de larga escala mostra o mesmo custo pelo lado da experiência declarada. Na edição de 2025 do Stack Overflow Developer Survey, com mais de 49.000 respostas, a frustração mais citada — por 66% dos respondentes — é "soluções de IA que estão quase certas, mas não completamente", e 45,2% dizem que depurar código gerado por IA consome mais tempo. "Quase certo" é precisamente o material de que o "quase pronto" é feito.
Na edição de 2024, a DORA reportou que um aumento de 25% na adoção de IA estava associado a ganhos em qualidade de documentação (+7,5%), qualidade de código (+3,4%) e velocidade de revisão (+3,1%) — e simultaneamente a queda de 1,5% no throughput de entrega e de 7,2% na estabilidade de entrega.
Na edição de 2025, baseada em quase 5.000 profissionais e mais de 100 horas de dados qualitativos, o quadro se moveu em parte: 90% dos respondentes usam IA no trabalho, com mediana de duas horas por dia interagindo com ela, e mais de 80% dizem que ela aumentou sua produtividade. A relação com throughput, que era negativa em 2024, passou a ser positiva. Mas a relação com estabilidade de entrega permaneceu negativa.
E a DORA foi um passo além: testou se a adoção de IA amorteceria o dano causado por essa instabilidade, e não encontrou evidência disso. A instabilidade segue impactando resultados de produto, o que — nas palavras do relatório — pode em última análise anular qualquer ganho percebido de throughput.
Sobre confiança, convém citar o número certo, porque ele circula deformado: em 2025, cerca de 70% dos respondentes expressam algum grau de confiança na qualidade do código gerado por IA, 30% se mostram mais reservados, e 7% dizem não ter confiança nenhuma. Na edição de 2024, os que relatavam pouca ou nenhuma confiança eram 39%. A confiança subiu; a instabilidade medida não cedeu junto.
Isto é: a ferramenta acelerou a produção de mudança. O gargalo nunca foi produzir mudança. Era verificar mudança, e verificar depende de lote pequeno e feedback rápido. Acelerar a entrada de um funil sem alargar a saída não aumenta a vazão — aumenta a fila.
Repare no encaixe entre as três fontes desta seção, que foram produzidas por gente diferente com método diferente. A METR mede, em laboratório, tempo subindo enquanto a percepção diz que caiu. O Stack Overflow registra, na escala de dezenas de milhares, que o custo dominante é o "quase certo". A DORA observa, no nível da organização, throughput subindo e estabilidade caindo. É a mesma história contada de três alturas — e a versão da própria DORA sobre o mecanismo é econômica: o tempo economizado na criação é frequentemente realocado para auditoria e verificação.
O que um prazo curto de verdade compra
Existe uma confusão frequente entre prazo curto e pressa. Elas são opostas.
Pressa é manter o escopo e comprimir o tempo. Prazo curto de verdade é fixar o tempo e deixar o escopo ser a variável. As duas coisas produzem resultados invertidos, e a pesquisa acima explica por quê:
- Fixar o tempo neutraliza a âncora. Se o prazo é um dado da conversa e não uma saída dela, a expectativa do cliente deixa de contaminar a estimativa, porque não há estimativa de prazo a contaminar. A pergunta muda de "quanto tempo leva?" para "o que cabe aqui dentro?" — e essa segunda pergunta é respondível.
- Lote curto corta a cauda. A cauda gorda de Flyvbjerg vem de reação em cadeia entre componentes acoplados. Um lote que precisa ficar pronto em dias tem menos componentes simultaneamente em aberto, e portanto menos superfície para a reação se propagar.
- Verificação frequente preserva contexto. Se até 58% do tempo vai para compreender o que já existe, verificar enquanto o contexto ainda está fresco na cabeça de quem escreveu é economia direta, não burocracia.
- O que não couber vira informação, não dívida. Escopo cortado por decisão explícita é uma decisão registrada. Escopo cortado por atropelo no último dia é um defeito esperando para ser descoberto.
Nada disso exige transformação cultural, comitê ou metodologia com nome próprio. Exige uma decisão chata e repetida: encurtar o intervalo entre construir e verificar, e aceitar que o preço disso é entregar menos por vez.
Como isso vira método
O padrão que sustenta os quatro pontos acima é simples de descrever e difícil de manter sozinho, porque a pressão do dia a dia empurra na direção contrária — sempre parece mais eficiente juntar mais um item antes de fechar o bloco.
Na prática, o que funciona é ter o prazo fixado por fora, um interlocutor que force o corte de escopo quando ele precisa acontecer, e um ritmo de verificação que não dependa de disciplina heroica. É exatamente essa a forma do programa MaxVision: 15 dias corridos, duas calls por semana, escopo negociado contra o relógio e não contra o desejo, com o projeto indo ao ar no fim. O prazo curto não é uma promessa de marketing — é o mecanismo, e é o que a pesquisa acima explica.
Se você reconheceu seu projeto na primeira frase deste texto, o diagnóstico raramente é técnico. O bloco em aberto está grande demais para ser verificado, e cada semana adicional o torna mais caro de fechar, não menos.
Fontes e referências
- Moløkken-Østvold & Jørgensen — A Review of Surveys on Software Effort Estimation (ISESE 2003) e A Survey on Software Estimation in the Norwegian Industry (2004)
- Jørgensen — A Review of Studies on Expert Estimation of Software Development Effort (Journal of Systems and Software, 2004)
- Jørgensen & Moløkken — How Large Are Software Cost Overruns? A Review of the 1994 CHAOS Report (Information and Software Technology, vol. 48, n. 4, abril/2006, pp. 297–301)
- Eveleens & Verhoef — The Rise and Fall of the Chaos Report Figures (IEEE Software, vol. 27, n. 1, jan-fev/2010, pp. 30–36)
- Flyvbjerg & Budzier — Why Your IT Project May Be Riskier Than You Think (Harvard Business Review, 2011; preprint)
- Flyvbjerg, Budzier, Lee, Keil, Lunn & Bester — The Empirical Reality of IT Project Cost Overruns: Discovering a Power-Law Distribution (Journal of Management Information Systems, vol. 39, n. 3, 2022)
- Meyer, Barr, Bird & Zimmermann — Today Was a Good Day: The Daily Life of Software Developers (IEEE TSE, vol. 47, n. 5, 2021; preprint Microsoft Research, 2019)
- Xia, Bao, Lo, Xing, Hassan & Li — Measuring Program Comprehension: A Large-Scale Field Study with Professionals (IEEE TSE, vol. 44, n. 10, 2018)
- Purushothaman & Perry — Toward Understanding the Rhetoric of Small Source Code Changes (IEEE TSE, vol. 31, n. 6, 2005, pp. 511–526)
- Śliwerski, Zimmermann & Zeller — When Do Changes Induce Fixes? (MSR 2005)
- Becker, Rush, Barnes & Rein (METR) — Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (julho/2025)
- Stack Overflow Developer Survey 2025 — seção de IA (mais de 49.000 respostas, 177 países)
- DORA — Working in small batches (capability oficial)
- Accelerate State of DevOps Report 2024 (PDF oficial, 22/10/2024)
- Google Cloud / DORA — Announcing the 2024 DORA report (22/10/2024)
- Google Cloud / DORA — Announcing the 2025 DORA Report (23/09/2025)
Dados de relatório e de pesquisa conferidos em agosto de 2026. Números de edições futuras da DORA podem revisar as relações descritas aqui.
