Custo de mudança: por que simples não é simples
"É só incluir um campo." A frase parece pequena, objetiva, inofensiva. E costuma vir com: "Isso deve ser rápido, né?" A verdade incômoda é que em sistema complexo nada é "só incluir um campo". Mudança em software não é só esforço técnico. É alteração estrutural, coordenação entre áreas, risco operacional e custo organizacional.
A tela parece simples: formulário, botão, campo novo. A tela é a ponta do iceberg. Por baixo podem estar banco, validações, APIs, integrações, relatórios, batch, eventos assíncronos, auditoria, permissões, versionamento. Cada camada soma custo. Alguém escreve: "Adicionar campo 'Motivo do cancelamento' obrigatório." O campo tem que entrar na base, ser validado no backend, aparecer na API, no payload de integração, nos relatórios, no histórico, e ser compatível com dado antigo. Precisa migração pros registros que já existem? E se tiver integração externa? De repente "um campo" vira projeto.
Custo de mudança = esforço técnico + risco + coordenação + teste + impacto organizacional. Esforço técnico é o óbvio. Risco operacional: mudar em produção sempre carrega risco — plano de rollback? Feature flag? Coordenação: se a mudança envolve backend, frontend, dados, integração e infra, entra alinhamento, deploy junto, janela de release. Teste consome tempo. Impacto organizacional — treinamento, documentação, contrato com parceiro — raramente entra na estimativa técnica, mas existe.
Sistema mais maduro costuma ser mais caro de mudar. Mais integrações, mais relatórios, mais consumidores, mais histórico. Alguém pede: "Adicionar campo de taxa adicional no pedido." Por trás: impacta comissão? Nota fiscal? Contabilidade? ERP? Se mexe em dinheiro, o nível de cuidado sobe. Chamar algo de simples sem validar a estrutura reduz a percepção de complexidade e pode comprometer credibilidade. Mudança pequena pode não ser isolada: mudar texto de botão é pequeno e isolado; mudar regra de cálculo pode ser pouco código e muito conectado. O que importa é o isolamento, não só o tamanho.
Sistema antigo acumula código difícil de mexer, dependências obscuras, documentação incompleta. Qualquer mudança exige investigação — e investigação consome tempo. Uma alteração que parece simples pode exigir ajuste em enum, validação, relatório, BI, API e parceiro. Antes de dizer que é simples: isso mexe em estrutura, regra, contrato, dados históricos? Envolve integração, dinheiro ou vários times? "Já que estamos mexendo nisso, vamos aproveitar e ajustar aquilo também." Juntar várias mudanças na mesma entrega aumenta o risco. Escopo acumulado gera instabilidade.
Mudança frequente em área sensível gera medo. O time passa a evitar mexer; dívida técnica cresce. Enquanto outros dizem "isso é pequeno", você diz: "Vamos validar o impacto estrutural antes de estimar." Antes de prometer prazo: "Qual é o custo real dessa mudança?" E custo real não é só tempo de desenvolvimento; é impacto sistêmico. Quem entende o custo real prioriza melhor. Às vezes uma funcionalidade desejada tem custo desproporcional — aí dá pra negociar alternativa, ajustar escopo, adiar ou simplificar.
A tela pode parecer simples; a estrutura raramente é. Quem está maduro não promete pelo que vê; promete pelo que entende.
No próximo post: idempotência. Porque repetir ação não deveria gerar efeito duplicado — e muitas vezes gera.
