É só uma alteração: a mudança que destrói o planejamento

Leitura: ~8 minutos — mudança de escopo e planejamento

Ouvir resumo (40s) — voz gerada por IA, narração dos pontos principais do post.

Depois de décadas desenvolvendo sistemas, aprendi a desconfiar de uma frase que esconde uma mudança maiúscula: “Beto, é só uma alteraçãozinha”.

Ninguém fala essa frase com má intenção. Pelo contrário: ela nasce cheia de boas intenções, num corredor, num café, num WhatsApp entre reuniões. O cliente pede isolado, com voz de quem não quer incomodar, e a palavra “zinha” faz o trabalho sujo — reduz o pedido a nada, antes de qualquer análise. E o problema é exatamente esse: a mudança cheia de boas intenções é sempre pedida isoladamente, descolada do resto do sistema, do resto do cronograma, do resto do que já está em andamento.

A frase soa inofensiva porque quem pede enxerga só a ponta: a tela. “Só muda aqui no campo.” Quem já manteve ERP de verdade sabe que a tela é a parte visível de um iceberg — o que está embaixo é banco, API, teste, documento, integração, treinamento. É só uma alteração para quem não precisa descer até lá.

E aqui mora a armadilha mais cruel: como o pedido parece pequeno, ele nem entra no processo. Não vira solicitação formal, não passa por análise de impacto, não é avaliado contra o escopo acordado. Ele entra direto na cola do time, entre afazeres, e o planejamento só descobre a mudança quando ela já está dentro.

Planejamento: o efeito cascata de uma “alteração de tela” no sistema

Deixo um exemplo concreto, desses que ninguém esquece porque já viveu um igual. Uma alteração de tela parece pequena até você listar o que ela arrasta: e o planejamento é quem paga cada item dessa lista.

• Banco de dados: nova coluna, ajuste de tipo, migração de dado existente — e cuidado com a informação histórica que não se encaixa na regra nova.
• API: endpoint alterado, contrato atualizado, e todo consumidor daquele contrato precisa ser verificado — inclusive integrações de terceiros que ninguém lembrou que existiam.
• Interface: no Posseidom, hoje em migração do legado Web Forms com C sharp para .NET 10 e Angular, significa às vezes escrever a mesma funcionalidade duas vezes — no legado e no novo front.
• Testes: caso de teste da funcionalidade alterada, mais os casos de regressão de tudo que toca aquela regra. Regra fiscal que aparece em cinco módulos são cinco vezes de verificação.
• Documentação: manual do usuário, documentação técnica, materiais de treinamento. Quem não atualiza entrega sistema diferente do que foi ensinado.
• Treinamento de usuários: o usuário que aprendeu o fluxo antigo precisa reaprender. Esse custo é invisível no pedido e aparece no suporte depois.

Soma tudo e a “alteraçãozinha” de uma tarde se mostra o que é: uma semana de trabalho espalhada por quatro áreas do sistema. Uma semana que nenhum cronograma previu, porque ninguém pediu para analisar o impacto antes de aceitar.

O detalhe que mais dói: esse efeito não aparece de uma vez. Ele vai aparecendo pingado — no sprint seguinte, na prova do cliente, no suporte. Quando o time percebe que o prazo estourou, a mudança já foi engolida tanto faz vezes que ninguém sabe apontar onde começou.

Mudança de escopo ou correção de defeito? Planejamento em risco

Antes de avaliar qualquer alteração, classifique-a. São coisas diferentes, com donos diferentes e consequências diferentes:

• Correção de defeito é o sistema fazendo algo que estava especificado e faz errado. Isso estava no escopo, o custo já está no orçamento, e ninguém deveria discutir prazo por causa disso.
• Mudança de escopo é o sistema fazendo algo que não estava especificado. Isso é um pedido novo — que só deve entrar com o impacto medido e a aprovação formal dada.

A fronteira é importante por uma razão simples: quem paga a conta. Correção de defeito é conta de quem desenvolveu (a empresa, o time). Mudança de escopo é conta de quem solicitou. Quando essas duas coisas se confundem — e “é só uma alteração” é especialista em misturá-las — o projeto começa a devolver lucro para o cliente sem que ninguém perceba, e o cronograma estoura por causa de trabalho que não estava lá.

O pior cenário é o inverso: o time aceita tudo como “correçãozinha” por medo de discussão, e três meses depois o fornecedor está entregando trabalho extra de graça, com time cansado, e o cliente nem sabe que ganhou de presente. Ou o cliente descobre no final, quando a cobrança surge, e a relação queima.

Análise de impacto antes de aprovar: a pergunta que evita o estrago

Se a mudança está pedida, o passo seguinte não é aceitar nem recusar: é analisar impacto. Antes de aprovar qualquer solicitação, responda sistematicamente:

1. Banco de dados: a mudança exige alteração de estrutura ou migração de dado histórico? 2. API: algum contrato muda? Quantos consumidores dependem dele? 3. Interface: quantas telas são alcançadas — só as evidentes? 4. Testes: quantos casos precisam ser alterados? Que regressão precisa rodar? 5. Integrações: algum fluxo externo quebra — fiscal, contábil, e-commerce, EDI? 6. Documentação e treinamento: o que precisa ser reescrito, e quem precisa reaprender?

Cada “sim” desses cobra tempo de gente especializada. Some o tempo de banco, mais o de API, mais o de front, mais o de teste — e você chega no custo real da mudança. Esse número quase nunca é parecido com o censo de “uma tarde”. Aí sim coloca-o no cronograma: essa semana extra vem a algum preço — atraso no marco que estava prometido, custo que já não está no orçamento, ou coisa que precisa sair no lugar da mudança (trade-off de escopo).

Análise de impacto não é para segurar o cliente. É para o cliente decidir com informação real. Ele pode olhar para a semana extra e dizer “vale a pena” ou “agora não”. As duas respostas são saudáveis. A única resposta destrutiva é a que ninguém perguntou.

Registro de quem solicitou e de quem aprovou: a rastreabilidade que salva

Análise sem registro é opinião que some. Toda solicitação de mudança precisa, no mínimo, de três linhas:

• Quem solicitou: nome, data, descrição do pedido original (palavras do solicitante, não a versão polida do time).
• Quem aprovou: quem assina, com base na análise de impacto e no custo.
• Baseline: qual versão do escopo, prazo e custo estava vigente quando a mudança entrou — e qual passa a valer depois.

Sem isso, a consequência é sempre a mesma: culpa difusa. Seis meses depois ninguém lembra por que o prazo estourou, quem pediu aquilo, quem concordou. O time lembra que “o cliente pediu um ajuste”. O cliente lembra que “só foi uma alteraçãozinha”. E cada lado carrega sua versão da história, nenhuma registrou, e a discussão se resolve no grito ou no desconto de nota.

Com registro, a conta vira aritmética: foram onze solicitações no trimestre, cada uma com impactos declarados e aprovados por alguém. A reunião deixa de ser sobre culpa e passa a ser sobre decisão — continuar, reduzir ritmo, renegociar. É por isso que registro de quem solicitou e registro de quem aprovou não são burocracia: são a memória do projeto.

Controle integrado de mudanças: o método do PMI no mundo real

Tudo que descrevi tem nome formal no PMI: Controle Integrado de Mudanças. Os ingredientes:

• Baseline de escopo, prazo e custo: o retrato acordado do projeto, a régua contra a qual toda mudança é medida. Sem baseline, “mudança” não existe — tudo parece continuação do combinado.
• Processo formal de solicitação: todo pedido vira documento, com descrição, justificativa e impacto avaliado.
• Aprovação formal: alguém com autoridade (sozinho ou em uma comissão de controle de mudanças, a famosa CCB) decide, e a decisão fica registrada.
• Avaliação de impacto financeiro e de qualidade: quanto custa, que risco introduz no que já está funcionando.

Agora o aviso honesto, de quem já viu projeto morrer dos dois lados: o método vira desastre quando é aplicado com burocracia de cartório. Formulário de vinte campos para mudar o texto de um botão, CCB que se reúne uma vez por mês, mudanças urgentes morrendo na fila. Isso não é controle, é desistência do time em pedir — e o pedido volta a nascer no corredor, só que agora escondido.

No Posseidom, o método funciona com simplicidade deliberada: o básico suficiente. Toda mudança que não é correção de defeito documentada vira solicitação — mesmo que a solicitação seja um texto curto. Tem impacto listado, estimado por quem vai executar, e aprovada por quem tem autoridade. O tamanho da formalidade escala com o tamanho do impacto: mudança de regra fiscal em módulo financeiro merece reunião e assinatura; ajuste de rótulo de tela merece uma linha no registro. O processo não é para deixar tudo lento — é para deixar tudo enxergado.

O nome técnico dessa capacidade é maturidade, e existe um detalhe: maturidade não se declara, se percebe no que acontece quando alguém pede “só uma alteração”.

Conclusão

A frase “é só uma alteração” não descreve o tamanho do pedido — descreve apenas a dificuldade de quem pede para enxergar o impacto. O pedido é sempre genuíno e quase sempre o efeito é maior do que parece.

E isso não é motivo para desconfiar do cliente. É motivo para construir defesa: análise de impacto antes de aprovar, baseline que serve de régua, registro de quem solicitou e de quem aprovou, e um controle integrado de mudanças simples o bastante para ser usado. Quando essas peças estão no lugar, a frase perde o poder de destruir o planejamento — porque o pedido passa a entrar pela porta certa, com o custo na mesa, e a decisão passa a ser informada.

Enxergar antes de aprovar é a única defesa. A pergunta que desarma a palavra “zinha” é simples: “que mais isso mexe?”. A resposta pode ser uma tarde, e aí aceite e execute; pode ser uma semana atravessando quatro áreas, e aí renegocie. O que não pode é aprovar no escuro: pedido com o custo na mesa vira decisão informada, e separa projeto maduro de refém do corredor.

—

Leitura relacionada

• Estamos produzindo código mais rápido do que lemos — o consumo mental de código é o gargalo silencioso da era da geração assistida por IA.
• O sistema cresceu. Mas ninguém recalculou o preço. — o custo de manter software muda de escala quando o sistema cresce, e alguém precisa recalcular.
• Seu banco de dados sabe mais sobre sua empresa do que a documentação — o impacto de toda mudança começa no banco, não na tela.