Dívida técnica explicada para gestores

No primeiro ano, a equipe entregava uma funcionalidade nova por ciclo. No terceiro, uma mudança que parece simples, como incluir um campo no pedido, vem com uma estimativa de semanas, um alerta de "isso pode quebrar o faturamento" e um olhar de cansaço. Ninguém ficou pior no trabalho. O sistema ficou mais caro de mexer.

Esse custo tem nome: dívida técnica. O termo é de engenharia, mas a decisão sobre ele é de gestão, porque envolve prioridade, capacidade e risco. Este texto explica o conceito sem jargão, mostra como reconhecer os sintomas e propõe mecanismos concretos para pagar a dívida sem parar o roadmap.

A metáfora que funciona, e onde ela quebra

A ideia vem do mundo financeiro. Quando a equipe escolhe um atalho para entregar mais rápido, ela pega um empréstimo. O principal é o trabalho que foi pulado: o teste que não foi escrito, a regra duplicada em três lugares, o módulo que deveria ter sido separado. Os juros são o tempo extra que cada mudança futura consome por causa desse atalho.

A metáfora é boa porque deixa claro que dívida não é pecado. Empresas tomam crédito o tempo todo para aproveitar uma oportunidade. Lançar antes do concorrente, cumprir uma obrigação legal com data marcada ou validar uma hipótese com pouco investimento são bons motivos para aceitar um atalho.

Ela quebra em três pontos que o gestor precisa conhecer:

• Não existe extrato. Ninguém recebe um boleto mensal dizendo quanto de juros o sistema cobrou. O custo aparece diluído em estimativas maiores e em bugs, e por isso é fácil ignorar.
• Os juros não são fixos. Uma dívida num módulo que ninguém toca praticamente não cobra nada. A mesma dívida no coração do sistema, onde toda funcionalidade passa, cobra a cada entrega.
• Parte dela vence sem aviso. Uma biblioteca sem atualização de segurança, um servidor com sistema operacional fora de suporte ou uma versão de linguagem abandonada não geram só lentidão. Geram risco, e às vezes a conta chega de uma vez.

Os sintomas que o gestor já sente

Você não precisa ler código para perceber dívida técnica. Ela aparece em sinais de gestão:

• Estimativas crescentes para coisas parecidas. Uma tela de cadastro que levava pouco tempo agora leva muito mais, sem que o pedido tenha ficado mais complexo.
• Bugs que voltam. O mesmo problema é corrigido duas, três vezes, porque a regra existe em vários lugares e a correção acerta só um deles.
• Medo de mexer. A equipe evita certos módulos. Frases como "melhor não encostar nisso" ou "só a Fulana entende essa parte" são dívida falando.
• Efeitos colaterais inesperados. Mudar o relatório de vendas quebra a emissão de nota. Partes que deveriam ser independentes estão amarradas.
• Entregas que precisam de janela especial. Publicar uma versão exige madrugada, plantão e roteiro manual de vinte passos.
• Integrações que ninguém quer tocar. Qualquer ajuste no conector com o ERP vira projeto.
• Onboarding longo. Uma pessoa nova no time demora muito para conseguir entregar algo sozinha.

Nenhum sintoma isolado prova nada. Vários ao mesmo tempo indicam que os juros já estão consumindo uma parte relevante da capacidade da equipe.

Dívida consciente e dívida acidental

Nem toda dívida nasce igual, e tratar todas da mesma forma leva a decisões ruins.

Dívida consciente é a que foi escolhida. A equipe sabia que o atalho tinha custo, aceitou por um motivo de negócio e registrou. Por exemplo: o primeiro módulo de cobrança suporta só um meio de pagamento, com o código organizado de um jeito que não escala para cinco. Tudo bem, desde que exista um registro dizendo o que foi pulado e quando convém pagar.

Dívida acidental é a que ninguém escolheu. Ela vem de requisitos que mudaram depois que o código foi escrito, de pressa sem registro, de rotatividade de equipe, de fornecedores diferentes que mexeram no mesmo sistema com padrões diferentes. É a mais perigosa, porque ninguém sabe o tamanho dela.

Existe ainda a dívida que nasce simplesmente do tempo. Código que estava bom há alguns anos pode estar ruim hoje porque a empresa mudou: abriu filiais, passou a vender em marketplace, trocou de ERP. O sistema não piorou, o negócio andou e ele ficou para trás.

A conversa útil com a equipe técnica não é "por que vocês deixaram isso acontecer", é "quanto disso foi escolha, quanto foi acidente e quanto é simplesmente o negócio que mudou". As três pedem respostas diferentes.

Como tornar a dívida visível

Dívida invisível não entra na priorização. O primeiro passo prático é transformá-la em algo que o gestor consiga ver e comparar com funcionalidades.

Um registro de dívida. Uma lista viva, no mesmo lugar onde fica o backlog, em que cada item descreve em linguagem de negócio:

• o que está errado ou foi pulado;
• onde dói: quais funcionalidades, processos ou integrações são afetados;
• o sintoma observável: lentidão, bug recorrente, risco de segurança, dificuldade de mudança;
• o que acontece se nada for feito;
• uma estimativa aproximada do esforço para resolver.

"Refatorar o módulo de pedidos" não serve. "A regra de desconto está repetida no site, no app e no painel interno; toda alteração de política comercial exige mexer em três lugares e já gerou divergência de preço entre canais" serve, porque qualquer diretor entende.

Sinais medidos, não opiniões. Algumas medidas simples ajudam a acompanhar a tendência sem transformar o assunto em auditoria:

• tempo entre começar uma tarefa e colocá-la em produção;
• quantidade de correções que voltam a abrir o mesmo problema;
• frequência de falhas depois de uma publicação;
• módulos que concentram a maior parte dos bugs e das mudanças.

O cruzamento dos dois últimos é valioso: o módulo que muda muito e quebra muito é onde a dívida cobra mais juros. É por ali que se começa.

Pagar junto com a funcionalidade, não em projeto separado

O instinto de muita empresa é juntar tudo num "projeto de refatoração" de alguns meses. Quase sempre dá errado. O negócio fica meses sem novidades, a pressão cresce, o projeto é interrompido no meio e a empresa fica com metade do sistema no padrão novo e metade no antigo, que é pior do que antes.

O caminho mais seguro é a regra do escoteiro: quem passa por um trecho de código para entregar algo deixa aquele trecho um pouco melhor. Se a próxima funcionalidade mexe no cálculo de frete, a estimativa já inclui organizar o cálculo de frete. A dívida é paga exatamente onde os juros estão sendo cobrados, e o gestor vê o benefício na própria entrega.

Isso exige duas coisas da gestão:

1. Aceitar estimativas honestas. Se a equipe diz que a funcionalidade inclui arrumar a base, pressionar para "fazer só a parte visível" é pedir mais empréstimo.
2. Não separar "tarefa de negócio" de "tarefa técnica" na priorização. A melhoria técnica que viabiliza a funcionalidade faz parte dela.

Uma fatia fixa da capacidade para a saúde do código

Nem toda dívida está no caminho de uma funcionalidade. Atualização de dependências, troca de uma biblioteca abandonada, melhoria no processo de publicação e criação de testes automatizados em áreas críticas precisam de espaço próprio.

O mecanismo que funciona é reservar uma fatia fixa da capacidade em todo ciclo para esse trabalho. O tamanho da fatia é uma decisão conjunta entre gestão e liderança técnica, e deve crescer quando os sintomas pioram e diminuir quando a saúde do sistema melhora. O ponto não é a proporção exata; é que ela seja previsível e protegida. Se a fatia é a primeira coisa sacrificada quando aperta o prazo, ela não existe.

Para essa fatia não virar caixa-preta, a equipe apresenta no fim de cada ciclo o que foi pago e qual sintoma melhorou. Menos tempo para publicar, menos incidentes naquele módulo, uma dependência crítica atualizada. Isso constrói confiança dos dois lados.

A mesma lógica vale para a manutenção contínua de qualquer sistema em produção, que detalhamos em manutenção evolutiva de software.

Quando a dívida já pede modernização

Há um ponto em que pagar aos poucos não é mais suficiente. Alguns sinais de que a conversa mudou de patamar:

• A plataforma está fora de suporte. Linguagem, framework, banco de dados ou sistema operacional sem atualização de segurança.
• O conhecimento acabou. Ninguém na equipe entende partes centrais, e a documentação não existe. Se esse é o seu caso, comece por assumir o sistema legado de forma segura antes de decidir qualquer coisa.
• O desempenho virou limite de negócio, e o diagnóstico mostra que a causa está na estrutura, não em ajustes pontuais. Vale separar uma coisa da outra com um diagnóstico de performance antes de concluir.
• A fatia fixa nunca alcança a dívida. Mesmo protegida, ela só impede que a situação piore.

Nesse cenário, a decisão é entre refatorar por partes ou reconstruir, e ela tem riscos bem conhecidos. A análise completa está em reescrever ou refatorar um sistema legado. Mesmo na modernização, a recomendação costuma ser incremental: substituir módulo por módulo, com o sistema antigo e o novo convivendo, em vez de apostar tudo numa virada única.

Erros comuns na gestão da dívida técnica

• Tratar como problema só da equipe técnica. A dívida afeta prazo, custo de mudança e risco operacional. É assunto de diretoria.
• Proibir atalhos. Sem dívida consciente, a empresa perde velocidade quando ela mais importa. O problema é o atalho sem registro e sem plano.
• Pedir "zerar a dívida". Todo sistema vivo tem alguma. A meta é mantê-la num nível em que os juros não travem o negócio.
• Refatorar o que ninguém usa. Esforço técnico deve seguir o mapa de onde os juros são cobrados, não o gosto pessoal de quem escreve o código.
• Trocar de fornecedor esperando que a dívida desapareça. Ela fica no código. Um fornecedor novo precisa de tempo para entendê-la antes de começar a pagá-la.

Checklist para a próxima reunião com a equipe técnica

• Existe um registro de dívida escrito em linguagem de negócio?
• Sabemos quais módulos mudam muito e quebram muito?
• As estimativas incluem arrumar o trecho que será alterado?
• Há uma fatia da capacidade protegida para saúde do código em todo ciclo?
• Alguma parte da plataforma está sem atualização de segurança?
• Conseguimos publicar uma versão sem roteiro manual e sem janela especial?
• Alguém nomeado responde pela saúde técnica do sistema?

Se mais da metade das respostas for "não" ou "não sei", o primeiro passo é um diagnóstico, não um projeto de reescrita.

Colocando a dívida na mesa

Na Pervian Tech, avaliar dívida técnica faz parte do trabalho de arquitetura de software: olhamos o código, o processo de entrega e o histórico de incidentes e devolvemos um mapa em linguagem de negócio, com o que pagar primeiro e o que pode esperar. O plano é sempre sob medida, porque a dívida de cada sistema cobra juros em lugares diferentes.

O investimento é definido sob consulta, depois de um diagnóstico inicial gratuito que mostra o tamanho real do problema. Se as estimativas da sua equipe só crescem, conte o que está acontecendo.