Existe uma pergunta que quase nenhuma empresa de tecnologia consegue responder: quanto custou a última estimativa que deu errado.
Não é uma pergunta retórica. É um número concreto, em horas, que existe em algum lugar da operação. O problema é que está misturado com o resto do trabalho e não há como isolá-lo.
O retrabalho existe, mas não tem nome próprio
Código que precisa ser refeito. Entregas rejeitadas na revisão. Tickets reabertos uma semana depois de fechados. Funcionalidade construída sobre um requisito que mudou depois.
Tudo isso é trabalho real, feito por gente do time, e consome horas que são lançadas. Mas na maioria das operações essas horas entram na mesma categoria do desenvolvimento novo. E, uma vez ali, deixam de ser distinguíveis.
Nas 1.632 conversas que tivemos com líderes de empresas de tecnologia —software houses, consultorias de TI, times de desenvolvimento sob medida— 162 relatam desvios entre as horas estimadas e as executadas. O desvio aparece. O que não dá para fazer é explicá-lo.
Como resumiu um dos entrevistados: "Horas faturáveis versus não faturáveis: não têm isso. Não está automatizado."
O que se perde quando tudo fica misturado
Separar o retrabalho não é uma questão de organização contábil. Muda três coisas.
A primeira: o custo de uma estimativa errada deixa de ser invisível. Se o retrabalho está dentro das horas faturáveis, um projeto que precisou de 80 horas de retrabalho parece igual a um que não precisou de nenhuma. Os dois entregaram. Os dois faturaram. Mas um deixou bem menos margem, e ninguém consegue apontar onde.
A segunda: o histórico fica contaminado. Na hora de estimar um projeto parecido, busca-se o anterior e olha-se quantas horas levou. Se nesse número existem 80 horas de retrabalho que ninguém identificou, a nova estimativa já começa inflada — ou pior, é reduzida "porque desta vez vai sair melhor" e começa curta.
A terceira: a conversa com o cliente perde evidência. Quando o retrabalho veio de uma mudança de requisito do lado do cliente, poder mostrá-lo separado transforma uma discussão de percepções em uma conversa com dados.
Quase nunca está onde todo mundo acha
Algo que aparece sistematicamente quando uma empresa separa o retrabalho pela primeira vez: a surpresa não é quanto existe, e sim onde está.
O projeto que todos apontavam como problemático costuma ter menos retrabalho do que o esperado. E ele aparece concentrado em lugares que ninguém olhava: uma integração específica, um cliente em particular, uma etapa do processo que parecia resolvida.
É informação que não dá para intuir. Só aparece quando o dado existe.
E agora existe uma fonte nova
A adoção de ferramentas de AI somou uma camada a esse problema. Segundo a Developer Survey 2025 do Stack Overflow, com mais de 49.000 desenvolvedores em 177 países, 84% já usam ou planejam usar ferramentas de AI, mas apenas 29% confiam na precisão do que elas produzem —era 40% na medição anterior—. E 66% dedicam mais tempo do que o previsto corrigindo código que fica "quase bom".
Essas horas de correção são retrabalho. E estão sendo lançadas, na maioria dos casos, como desenvolvimento novo.
A análise da GitClear sobre 623 milhões de alterações de código entre 2023 e 2026 aponta na mesma direção: a duplicação de blocos subiu 81% enquanto a refatoração caiu 70%. O volume de output sobe e a estrutura que o sustenta se degrada. Essa diferença volta como retrabalho, no mesmo projeto ou no seguinte.
Por onde começar
Separar o retrabalho é o movimento mais barato de toda a operação: não exige comprar nada.
Defina a categoria. Uma terceira opção de lançamento, ao lado de desenvolvimento novo e suporte. Com um critério escrito do que entra: retrabalho por erro próprio, por mudança de requisito, por entrega rejeitada.
Combine com o time antes de implementar. Se o time interpretar isso como uma métrica de controle individual, os dados vão sair enviesados. O enquadramento importa: isso mede decisões de estimativa e de escopo, não o desempenho de uma pessoa.
Dê três meses antes de tirar conclusões. Um mês de dados não basta para distinguir um projeto atípico de um padrão.
E o ponto que organiza todo o resto: o dado já existe na sua operação. O time lança horas todos os dias. Só falta que essas horas possam ser lidas.
Voltar ao Blog