# Custo de mudança em software: o que os dados mostram > Corrigir tarde custa 100 vezes mais? Em 171 projetos, o efeito não apareceu de forma consistente. Nossa leitura: o custo depende de onde a regra mora. - Autor: Marlon Trettin - Publicado: 2026-10-28 · Atualizado: 2026-10-28 - Idioma: pt-BR - Canonical: https://yowpi.com/blog/custo-de-mudanca-em-software-o-que-os-dados-mostram --- Corrigir tarde custa dezenas de vezes mais? Nem sempre. A regra vem de curvas de 1981 cujos dados de base nunca foram publicados, e um estudo com 171 projetos não encontrou esse efeito de forma consistente. Uma hipótese mais útil: o custo de mudar depende de onde a decisão mora no sistema. ## TL;DR - A regra de que o custo de corrigir cresce dezenas de vezes até as fases finais vem de curvas de 1981 cujos pontos de dados originais não foram publicados. - Em 171 projetos de 2006 a 2014, o esforço para corrigir um problema tardio ficou perto do esforço de corrigi-lo cedo na maioria dos pares de fases. As maiores medianas ficaram entre 2,5 e 3 vezes. - O estudo mede defeitos em equipes com processo disciplinado, não mudanças de escopo pedidas pelo negócio. Ele não prova que mudar tarde é barato. - Nossa leitura, que os dados não testam: para quem contrata, a pergunta útil é em quantos lugares uma regra vive no sistema. ## De onde vem a regra de que mudar tarde custa 100 vezes mais? Uma das origens é Barry Boehm, que em 1981 publicou curvas de custo por fase do projeto. Segundo a [descrição de Tim Menzies e coautores](https://arxiv.org/abs/1609.04886), uma delas mostra um aumento de 40 vezes até o teste de aceitação, e outra, de 100 vezes para projetos maiores antes da entrega. A mesma descrição registra que os pontos de dados por trás dessas curvas nunca foram publicados, e que Boehm relatou, em 1980, uma curva mais plana para projetos pequenos. A ideia se espalhou. Segundo [Steve McConnell](https://stevemcconnell.com/articles/an-ounce-of-prevention/), Boehm e Philip Papaccio estimaram em 1988 que um defeito de requisito que chega à produção pode custar de 50 a 200 vezes mais para corrigir do que perto de onde nasceu. Menzies e coautores citam ainda razões de 1 para 137 na Toshiba e de 1 para 117 na IBM, relatadas por participantes de workshops, também sem dados brutos. Nada disso é invenção, e a ideia de que o problema fica mais caro quando é descoberto tarde é intuitiva. O ponto é que ela circula como número fixo, e o estudo a seguir a trata como hipótese a testar. ## O que um estudo com 171 projetos encontrou? Encontrou pouca evidência do efeito. Tim Menzies, William Nichols, Forrest Shull e Lucas Layman analisaram 171 projetos de software conduzidos entre 2006 e 2014, de 45 organizações em 6 países, todos registrados num banco de dados do Team Software Process (TSP). Eles compararam o esforço para corrigir um problema na fase em que ele nasceu com o esforço para corrigi-lo em fases posteriores. O resultado, publicado no arXiv, é que as medianas dessas razões ficaram perto de 1 na maioria dos pares. As maiores foram de 3,0, entre planejamento e teste unitário, e de 2,54, entre requisitos e teste de integração. No percentil 90, o maior valor também foi 3,0. Quase todas as comparações não diferiram de forma significativa. Os autores concluem que não há evidência consistente nem substancial do efeito e sugerem que ele pode ser um resquício histórico, presente só de forma intermitente em certos tipos de projeto. ## O que esse estudo não prova? Não prova que mudar um sistema tarde é barato. Primeiro, todos os projetos usaram o TSP, um processo disciplinado criado pelo empregador de dois dos autores. Um projeto sem esse tipo de processo não é o retrato dessa amostra. Segundo, o estudo mede esforço para corrigir defeitos. Ele não mede o que a empresa perde enquanto espera, nem uma mudança de escopo pedida pelo negócio depois de o sistema estar no ar, que é o caso que mais interessa a quem contrata. E os próprios autores admitem que não tinham um grupo de controle para comparar o TSP com outros processos. O que fica é mais modesto: o multiplicador não é uma constante. Em alguns projetos o custo cresce com o tempo, em outros não, e a pergunta passa a ser o que explica a diferença. ## O que faz o custo de mudar variar? Os dados não respondem, e o que segue é leitura nossa. Um ponto de partida é um [artigo de David Parnas](https://doi.org/10.1145/361598.361623), de 1972, na *Communications of the ACM*. Parnas propõe que um sistema não seja dividido a partir de um fluxograma, e sim de uma lista de decisões difíceis ou prováveis de mudar, com cada módulo escondendo uma delas do resto. No exemplo que ele analisa, a decomposição que ele defende confina uma mudança na forma de guardar os dados a um único módulo. Na convencional, a mesma mudança exige alterar todos. Traduzido para a operação de uma empresa: o custo de mudar uma regra depende de em quantos lugares ela foi escrita. Quando a regra mora num só ponto, mudá-la é uma alteração. Quando está espalhada, cada cópia é uma chance de esquecer uma, e o erro aparece semanas depois, longe de onde nasceu. Isso é um problema de arquitetura, não de tecnologia: a ferramenta pesa menos do que o lugar onde as decisões da empresa moram. ## Um exemplo prático: a regra de comissão de uma corretora O cenário é hipotético, sem números medidos. Uma corretora de seguros com 40 pessoas muda a regra de comissão de um ramo. No primeiro desenho do sistema, a regra aparece na planilha de cálculo, numa tela de cadastro, num relatório e na integração com o financeiro. Mudar significa achar os quatro lugares. Se um for esquecido, a divergência só aparece no fechamento do mês, quando a diferença já virou conciliação manual. No segundo desenho, a regra é uma tabela com data de vigência, lida por todas as telas e integrações. A mesma mudança vira uma linha nova com a data de início. O pedido de negócio é idêntico, e o custo de mudar depende muito menos da fase em que o pedido chegou. O que separa os dois desenhos foi decidido no começo, quando alguém perguntou onde a regra deveria morar. ## Como usar isso ao contratar um sistema? Com três passos curtos, antes de aprovar o escopo. O primeiro é listar as cinco decisões que mais provavelmente mudam nos próximos 12 meses: regra de comissão, tabela de preços, campos do cadastro, alçada de aprovação, o que cada perfil pode ver. O segundo é perguntar a quem vai construir, por escrito, em quantos lugares cada uma dessas decisões vai existir. A resposta honesta para várias será "em um", e para algumas será "em dois ou três, e aqui está o motivo". O terceiro é testar antes da entrega. Peça para mudar uma dessas regras no protótipo e observe quantas telas ou integrações precisam ser tocadas. É uma forma barata de ver o custo de mudar antes de pagar por ele. O artigo sobre [o que falta para um protótipo aprovado virar sistema](/blog/prototipo-aprovado-o-que-falta-para-virar-sistema) trata dessa passagem, e o texto sobre [por que os orçamentos de sistema interno variam tanto](/blog/orcamento-de-sistema-interno-por-que-os-precos-variam) ajuda a comparar propostas que respondem a essa pergunta de formas diferentes. Sistemas seguem mudando depois de entregues. No [case da Colo Saúde](/cases/colo-saude), a Yowpi assumiu uma plataforma herdada, reduziu em 60% o consumo de capacidade da plataforma original, dado do case publicado, e a evolução seguiu com a mesma equipe. É um exemplo de sistema que continuou evoluindo depois de pronto, não uma prova do efeito descrito no estudo. ## Perguntas frequentes **A integração com o que já uso vai ser complicada. Isso encarece mudar depois?** Pode encarecer, porque cada integração é um lugar onde uma regra pode estar copiada. A pergunta do segundo passo vale aqui também: quais dados saem do sistema novo para os que você já usa, e qual deles é a fonte de cada regra. Em nossa leitura, uma integração em que só um lado define a regra tende a ser mais barata de mudar do que duas que a repetem. **Não tenho equipe qualificada para implementar. Como avalio a resposta de um fornecedor?** Peça a resposta por escrito e compare entre propostas. Quem entende a sua operação responde com nomes de regras e lugares, como "a comissão fica na tabela de vigência e as telas só a consultam". Uma resposta genérica sobre "arquitetura flexível" não diz em quantos lugares uma mudança vai tocar. **Não sei se o retorno compensa. Então congelo o escopo para não pagar por mudança?** Congelar o escopo é uma leitura que o estudo não sustenta. Ele não diz que mudar é sempre barato. Diz que o custo depende do projeto. Em vez de congelar, separe o que é estável do que é provável de mudar e dê a este último um lugar único. Assim, o escopo pode crescer sem que cada pedido novo mexa em tudo. ## O próximo passo Se hoje cada mudança de regra no seu sistema vira uma caça aos lugares onde ela está escrita, o Diagnóstico de Arquitetura Operacional, uma sessão de trabalho de 30 minutos, serve para mapear onde cada decisão mora antes de planejar a próxima mudança: [agende o diagnóstico](/contato).