Software legado não aceita mudança isolada

Num software novo, você altera uma regra. Num software legado com vinte anos, você altera uma regra e precisa descobrir quantas outras coisas aprenderam a depender dela.

Leitura: ~8 minutos

Ouvir resumo (44s) — voz gerada por IA, narração dos pontos principais deste artigo.

A análise de impacto

Toda solicitação de mudança em software legado maduro começa pequena e termina grande. O cliente pede “só um campo a mais na tela de pedido”, e a pergunta certa não é “quanto custa” — é “o que mais quebra se esse campo existir”. Análise de impacto é rastrear cada superfície que lê, grava, valida ou exibe aquele dado.

Em softwares legados que mantenho há mais de vinte anos, já vi um campo de “ponto de referência do endereço” virar dependência de nota fiscal, de relatório de expedição e de integração que nem sabíamos que existia. Se tivesse aceitado o pedido como trivial, teria descoberto cada dependência na produção, uma por vez, com cliente na linha. Análise de impacto é o preço de admitir que você não sabe tudo o que o software legado faz.

Dependências invisíveis

O maior passivo de um software legado não é o código velho — é o código esquecido: triggers de 2004 que recalculam saldo, batch de madrugada com lógica de negócio que só existe naquele arquivo, consultas customizadas que viraram “comportamento padrão”, stored procedures que quatro das cinco pessoas que as mantinham já deixaram a empresa.

Essas dependências não aparecem no diff nem no teste unitário do módulo mexido. Aparecem quando o fiscal liga dizendo que o relatório saiu errado, ou quando a integração do cliente para sem erro no log. Num software legado nosso, uma mudança simples no cadastro de produto derrubou uma rotina de precificação que nem constava na documentação — descobrimos que ela existia porque os preços mudaram sozinhos numa madrugada. Aprendi com dor que o inventário de dependências é sempre menor que a realidade: por isso caçá-las vale mais que a memória de quem “conhece o software todo”.

Stakeholders esquecidos e documentação

Quando a solicitante é o comercial, quem assina o impacto costuma ser o fiscal, a contabilidade, o expeditor, o cliente integrado. Esses grupos não participam da conversa inicial porque nem sabem que ela está acontecendo — e depois descobrem a mudança pelo efeito, não pelo comunicado.

O clássico: a área muda a tela de pedido, os testes passam, e a nota sai com CFOP diferente porque a regra de enquadramento dependia de um campo que mudou de semântica. Quem paga não é o time de TI — é o cliente exposto em fiscalização: “esqueci de chamar o fiscal” tem custo de multa e reputação, não de retrabalho. Regra prática: aprovar só depois de listar quem consome aquilo do lado fiscal e operacional — e chamar todos, um a um. Stakeholder esquecido é depósito de susto futuro.

ERP maduro convive com a verdade: boa parte do seu comportamento não está documentada — existe no código, nas telas e na memória de quem usa, e a memória se aposenta. Já levei meses para reconstruir a regra de transferência interestadual porque quem a entendia saiu, e nenhum documento registrava por que aquele cálculo era como era. Nesse cenário, documentar a mudança importa tanto quanto fazê-la: o que mudou, por quê, o que se decidiu não mudar, como era antes. Cada vez que um time “economizou” essa etapa, gastamos muito mais depois descobrindo. Documentação incompleta não é problema estético: é ausência de testemunha.

Em software novo, teste unitário cobre o módulo. Em software legado, isso é engano: o módulo mexido funciona, e o que quebra está a três módulos de distância. Teste de regressão é o que revela os efeitos colaterais — fluxo completo de venda, emissão fiscal, fechamento, expedição — e roda sempre que a mudança toca dado compartilhado. Homologação cumpre papel complementar: é onde os stakeholders esquecidos veem seu fluxo antes do estrago na produção. Assumi deploys sem regressão suficiente e a conta veio com juros; hoje, tocar algo fiscal ou de estoque exige cenários de regressão escritos, não de cabeça.

Rollback precisa ser desenhado antes de subir, porque depois a pressão decide por você — e sempre decide errado. Backup restaurado devolve o software, mas apaga o que foi legítimo na janela: pedidos, notas, movimentações; às vezes a resposta certa é rollback parcial — e isso se escreve antes. Antes de qualquer deploy sensível, três exigências: backup validado com restauração real, ordem reversível das migrações e janela de decisão. Rollback não testado é ficção com nome convidativo.

Software novo e software legado

A mesma solicitação — “mude a validação do prazo de entrega” — em software novo é uma alteração, um teste, um deploy. As dependências são visíveis, os autores estão no time, e o pior caso é o próprio módulo. Em software legado com vinte anos, a frase implica perguntas que o solicitante não imagina: quais clientes dependem do comportamento atual? Qual versão da API assumia aquilo? Qual relatório fiscal herdou a validação da regra de 2009? A diferença não é o código — é a rede ao redor dele. Times acostumados a software novo travam em software legado porque estimam a edição e esquecem o ecossistema; a competência de quem mantém ERP é mapear a rede antes de tocá-la.

Regras antigas que ficam

Parte do comportamento “esquisito” de um ERP velho não é dívida técnica, é direito adquirido do negócio. Aquele cálculo estranho no desconto existe porque um cliente grande negociou em 2011; aquela travancinha de validação, porque um fiscal exigiu depois de uma autuação. O código parece errado; o histórico diz que ele foi comprado caro. Por isso, mexer numa regra velha exige investigar a origem antes de “corrigir”: apagar um workaround que virou política destrói contrato ou expectativa de cliente sem que nenhum teste perceba. Regra antiga não se remove por parecer errada — se remove com origem documentada, validação do dono do negócio e regressão em torno dela. O estranho, em software legado de vinte anos, costuma ser história, não erro.

Reduzir risco antes do deploy

Reduzir risco em software legado maduro é mais processo do que tecnologia. Do lado do processo: rastrear dependências com ferramenta, transformar a análise de impacto em requisito de aprovação, fatiar a mudança em partes reversíveis, congelar o entorno na janela e comunicar quem consome — incluindo os esquecidos. No lado técnico: feature flag para desligar sem novo deploy, dados de homologação realistas (com variedade de CFOP e estados, não só os casos felizes) e monitoramento do dia seguinte olhando relatórios e integrações que o impacto apontou. Nada disso elimina o risco: reduz a probabilidade e o tamanho do estrago.

O que o PMI formalizou

Quem lê o PMBOK acha essas lições formalizadas faz tempo. Gestão de riscos (identificar, analisar, planejar resposta) é a análise de impacto antes da aprovação. Gestão da qualidade é o que em software chamamos de regressão e homologação. Gestão de stakeholders é a regra do fiscal esquecido. Controle de mudanças é nenhuma alteração integrada ao baseline sem avaliação formal de impacto — e a gerência de integração amarra o todo, exatamente o que falha quando uma tela muda e a nota despenca.

Mantendo um ERP de varejo e atacado há mais de vinte anos, levei susto suficiente para respeitar qualquer mudança que pareça simples. A que marcou subiu verde, testes passaram, e a integração do cliente parou no dia seguinte por um layout que ninguém lembrava que existia. Desde então: mudança sem caçar dependências, sem chamar fiscal e sem rollback testado não entra em produção — se não dá para descrever o que pode quebrar e como voltar atrás, ela ainda não está pronta. Software legado não aceita mudança isolada — e quem opera um aceita isso antes de abrir o editor.

O PMI chama isso de controle integrado de mudanças, e a expressão é literal: uma alteração nunca é um evento isolado — ela reentra no escopo, no risco, na qualidade e na comunicação do projeto todo. Quem trata cada solicitação como ticket avulso vai descobrir o custo dessa visão na produção, na nota fiscal e na relação com o cliente. Quem trata como gestão de risco operacional dorme melhor na madrugada do deploy.

Leitura relacionada

• Cliente aprovou mudança, não autoriza a destruir a base — a governança que vem antes da mudança: aprovação de cliente não é autorização para mexer onde não pode.
• Software legado não é sinônimo de sistema inútil — o contraponto: legado é passivo quando esconde dependências, é ativo quando carrega regras que o negócio comprou caro.
• Você não tem problema de pipeline. Você tem problema de código que ninguém entende. — a raiz das dependências invisíveis: código sem dono e sem testemunha virando risco silencioso.

Duzentas vezes por ano isso funciona sem incidente, e é esse número que engana. A prática que sobrou de vinte anos de sustos: aprovar uma alteração só depois de escrever, no registro, quem mais ela toca, quais testes de regressão cobrem esses pontos e como o software volta ao estado anterior. Qualquer resposta em branco = mudança ainda não pronta, seja campo de tela, cálculo de imposto ou API de e-commerce.