Conversa difícil: como o CTO comunica que o produto precisa de rewrite

A palavra "rewrite" trava qualquer reunião executiva. O problema raramente é técnico — é de comunicação. Veja o template que squads sêniores usam para apresentar rewrite ao CEO/CFO/board, e por que squad gerenciado executa rewrite sem parar a operação.

Por Victhor Araújo

Victhor Araújo

Todo CTO em algum momento da empresa precisa apresentar a palavra mais difícil para o board: rewrite. O sistema legado não escala, não documenta, não atrai talento, não cumpre compliance. A engenharia sabe há meses; o CFO ouve hoje pela primeira vez. A reação previsível: "vocês querem refazer tudo?".

O problema raramente é a decisão técnica — é a comunicação. Squad sênior apresenta rewrite como decisão de risco e timing, não como queixa de engenharia. A Revin tem template que mudou a conversa em 3 clientes nos últimos 2 anos: rewrite foi aprovado em primeira reunião, executado sem parar operação.

Para CTOs que precisam vender rewrite ao CEO/CFO/board, e para founders que ouviram a palavra e estão decidindo se aprovam ou demitem o CTO.

Apresentar rewrite como decisão de risco (não como queixa de dev) muda a resposta do board

🚫 Por que a apresentação tradicional falha

O CTO chega na reunião com slides técnicos: "código é spaghetti, sem testes, framework antigo, time não consegue evoluir". O CFO ouve "vocês querem gastar dinheiro fazendo a mesma coisa de novo". O CEO ouve "engenharia não está dando conta". O resultado é defesa, não decisão.

O problema: o CTO está apresentando sintoma (código ruim) sem traduzir em consequência (risco em dinheiro e tempo). Sem essa tradução, é impossível para o executivo decidir racionalmente.

📋 O template em 4 slides que funciona

Slide 1 — O custo de NÃO fazer rewrite nos próximos 12 meses

Em USD: capacidade de feature perdida (devs gastam X% em workaround), custo de incidente esperado (probabilidade × impacto), custo de turnover por frustração técnica, custo de não conseguir compliance que cliente está pedindo. Total em 12 meses.

Esse slide muda a conversa. Sem ele, executivo só vê o custo do rewrite; com ele, vê o custo de ambos os caminhos.

Slide 2 — O escopo definido (não "vamos refazer tudo")

Rewrite parcial é regra; rewrite total é exceção. Liste módulos a serem reescritos (geralmente 30-50% do sistema), módulos a serem mantidos (50-70%), e por que cada divisão. "Vamos reescrever pagamentos e autenticação porque X; o módulo de relatório fica como está porque Y".

Slide 3 — A estratégia de não-parada (strangler pattern)

Executivo tem medo de "parar operação por 6 meses para refazer". A resposta correta: strangler pattern. Versão nova roda em paralelo com a antiga, tráfego migra módulo por módulo via feature flag, rollback possível a qualquer momento. Operação não para; cliente não percebe.

Esse slide elimina o maior medo executivo. Sem ele, o "não" do board é quase garantido.

Slide 4 — A cadência de entrega e quando o board mede sucesso

Milestone mensal com métrica de negócio (não métrica técnica). Mês 1: módulo de auth migrado, latência de login -40%. Mês 2: pagamentos migrados, falha de transação -60%. Mês 3-6: continuação. Sem milestones de negócio, rewrite vira projeto opaco; com eles, vira investimento mensurável.

Squad gerenciado executa rewrite com strangler pattern — operação não para, valor continua entregue

🛠️ Como squad gerenciado executa rewrite sem parar operação

• Strangler pattern por default — versão nova convive com antiga, migração gradual com feature flag.
• Time dividido em "manutenção da legado" + "construção do novo". Squad sênior tem capacidade para os dois.
• Métricas paralelas: legacy e new system reportados juntos por 6-12 meses até desativação completa.
• Rollback documentado por módulo — não é "tudo ou nada", é "módulo X voltou ao legacy se falhar".

💸 O cenário onde rewrite NÃO é a resposta

Squad sênior também sabe dizer "não" a rewrite. Casos:

• Time não tem maturidade para conduzir rewrite — vira refator infinito sem progresso.
• Produto está em product-market fit em validação — focar em iteração, não rearquitetura.
• Custo de manutenção do legado é < 30% do custo de rewrite. Conta não fecha.

A Revin opera com viés "refator antes de rewrite, rewrite quando refator não cabe". Cliente vai economizar dinheiro mais vezes do que vai aprovar rewrite — e essa honestidade é diferencial.

📢 Tem sistema legado pedindo decisão e CTO está sem framework para apresentar? Agende um Diagnostic Sprint — a Revin entrega análise em 2 semanas com slides prontos para o board.

🎯 Conclusão: rewrite é decisão executiva traduzida pela engenharia

O CTO que apresenta rewrite como problema técnico recebe "não". O CTO que apresenta como decisão de risco com escopo, estratégia de não-parada e métrica de negócio recebe "sim". Squad sênior conduz essa tradução; squad genérico fica reclamando em retro.

📢 Conheça nossos cases para ver onde a Revin conduziu rewrite com cliente sem parar a operação.