6 minutos de leitura

Reconstruir um sistema é uma das decisões mais complexas que lideranças de Tecnologia podem enfrentar. Não se trata apenas de reescrever código, mas de entender quando insistir no legado se torna mais caro (em tempo, dinheiro e oportunidade) do que começar de novo. E, acima de tudo, saber se a organização está pronta para lidar com a transição.

Convidamos Julio Henrique Salina, CTO na Getrak (Localiza&Co), para compartilhar como ele toma decisões desse tipo no dia a dia. Nesta entrevista, ele fala sobre limites técnicos e estratégicos, trade-offs inevitáveis, sinais de alerta e o que realmente faz um rebuild dar certo.

BossaBox — Quando você pensa em reconstruir um software, qual é o primeiro “alerta vermelho” que te faz pausar e repensar?

Julio Henrique — O primeiro sinal que me trava não é técnico, é o organizacional. Se eu percebo que a liderança não entende o impacto de um rebuild, ou que o time ainda não amadureceu o suficiente para sustentar o novo enquanto mantém o legado vivo, eu pauso. Reescrever é sedutor. Parece que vai resolver tudo. Mas, se a companhia não estiver pronta para viver o caos controlado que vem no pacote, reconstruir vira suicídio tecnológico.

Outro ponto importante a citar, é quando o motivo principal para reconstrução está ligado apenas à insatisfação técnica ou ao desejo pessoal do time, sem uma clara justificativa estratégica de negócio.

Digo sempre que reconstruções bem-sucedidas precisam resolver problemas reais, críticos e alinhados diretamente à sustentabilidade, escalabilidade e valor estratégico da companhia, e não apenas atender a interesses técnicos pontuais.

BossaBox — Qual o maior trade-off que você já teve que aceitar para manter um sistema legado em pé enquanto o novo era desenvolvido?

Julio Henrique — O maior trade-off foi a decisão consciente de sacrificar temporariamente velocidade e flexibilidade técnica, aceitando custos operacionais mais altos e complexidade adicional na manutenção do legado. Fiz isso em troca de preservar a estabilidade do negócio e garantir a continuidade da operação enquanto o novo sistema era desenvolvido com qualidade, sem comprometer o atendimento às demandas de clientes e stakeholders.

LEIA TAMBÉM: O desafio da reconstrução de software: Riscos e estratégias de mitigação

BossaBox — Quais os aspectos mais críticos que você considera antes de abandonar a melhoria contínua e partir para a reconstrução?

Julio Henrique — Alguns pontos se impõem, na minha opinião:

• A curva de entrega desacelerando mesmo com times maduros.
• A arquitetura limitando mudanças estruturais, não por falta de criatividade, mas por impossibilidade técnica mesmo.
• O custo de oportunidade, ou seja, quando manter o atual significa perder o timing de mercado, o rebuild deixa de ser escolha e vira sobrevivência.
• Quando a manutenção do legado se torna financeiramente inviável, consumindo tempo e recursos que deveriam estar investidos em inovação, por exemplo.
• Quando o investimento em melhorias contínuas já não gera resultados satisfatórios e fica evidente que a reconstrução tende a oferecer retornos superiores no longo prazo.

BossaBox — Quais os indícios técnicos e estratégicos que mostram que otimizar já não é mais suficiente?

Julio Henrique — Quando cada sprint vira um exercício de contenção. Quando refatorar um módulo consome mais energia da turma do que escrever um novo do zero. E principalmente, quando o time começa a esconder a complexidade porque ninguém mais consegue explicar o sistema sem usar analogias esotéricas rs.

Olhando agora do ponto de vista estratégico, o alerta vem quando o software vira gargalo no roadmap, quando não dá mais pra inovar porque inovar exige tempo que o código não permite comprar. Sem falar do risco operacional crescente, ou seja, instabilidade frequente, downtime elevado ou problemas recorrentes que comprometem confiança e credibilidade da companhia perante clientes e parceiros.

BossaBox — Como alinhar expectativas entre tech e negócio durante um processo tão técnico quanto o rebuild?

Julio Henrique — Traduzindo impacto técnico em valor de negócio, o tempo todo, quase que como uma religião, precisa estar enraizado. Não se trata de vender sonho, mas de mostrar o custo de não agir, de não fazer nada. Um bom rebuild começa com clareza, o que será entregue, quando, por quê, e o que deixará de ser feito no processo.

Sem essa transparência, o negócio interpreta como lentidão ou desperdício. Com ela, entende que reconstruir é, muitas vezes, o único caminho para escalar com saúde.

BossaBox — Em sua visão, o que diferencia um rebuild bem-sucedido de um que fracassa?

Julio Henrique — Foco, simples assim. Ganha quem sabe o que precisa ser mantido, o que pode ser descartado e, principalmente, o que não deve ser reconstruído. Muita gente erra ao tentar reescrever tudo com o mesmo escopo, os mesmos problemas e nenhuma simplificação. Um rebuild de sucesso entrega valor progressivo, não uma “big bang” que nunca chega. E ele é liderado por quem entende tanto de negócio quanto de código, porque no fim, reconstruir é um ato técnico, mas também profundamente estratégico.