Custo de mudança 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.
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, 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, 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, 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 trata dessa passagem, e o texto sobre por que os orçamentos de sistema interno variam tanto ajuda a comparar propostas que respondem a essa pergunta de formas diferentes.
Sistemas seguem mudando depois de entregues. No case da Colo Saúde, 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.
Cases relacionados
Reconheceu a sua operação neste artigo?
Agende o Diagnóstico de Arquitetura Operacional: 30 minutos para mapear onde está o gargalo da sua operação. Sem proposta na primeira conversa.
Agendar diagnóstico