Dívida técnica com prazo: como torná-la visível e negociável

Dívida técnica com prazo: como torná-la visível e negociável

Toda equipe conhece a dívida técnica do próprio sistema. O problema raramente é falta de consciência, é falta de tradução.

"O código está ruim" não compete com uma feature que gera receita. "Cada mudança nesse módulo leva três vezes mais tempo e gera dois incidentes por mês" compete.

Dívida técnica é uma metáfora financeira, use como tal

A analogia funciona quando você leva os juros a sério. Toda dívida tem três dimensões:

• Principal: o esforço de corrigir

• Juros: o custo recorrente de não corrigir

• Prazo: quando a correção precisa acontecer

Um item de dívida técnica sem essas três dimensões é apenas uma reclamação.

Torne os juros mensuráveis

Os juros aparecem em métricas que o negócio entende:

• Tempo médio de entrega de mudanças naquele módulo

• Frequência de incidentes

• Custo de suporte

• Tempo de onboarding de novos desenvolvedores

Coletar esses números por área do sistema transforma percepção em evidência.

Classifique antes de priorizar

Nem toda dívida técnica merece atenção. Separe em três grupos:

• Dívida que bloqueia evolução: impede mudanças necessárias

• Dívida que gera risco: segurança, dados, disponibilidade

• Dívida de conforto: código feio que funciona

Só os dois primeiros grupos justificam alocação de capacidade.

Dê dono e prazo a cada item

Um item de dívida técnica sem responsável é uma intenção. Registre cada um com dono técnico, prazo-alvo e critério objetivo de quitação.

Exemplos de critério objetivo:

• Reduzir o tempo de build de 18 para 6 minutos

• Eliminar o acoplamento entre faturamento e estoque

Critério objetivo evita a discussão infinita sobre quando está pronto.

Reserve capacidade, não sobras

A prática mais eficaz é alocar uma fatia fixa da capacidade de cada ciclo para dívida técnica, entre 10% e 20%, dependendo do estágio do produto.

Reservar "o que sobrar" garante que nada será feito, porque nunca sobra.

Quem sustenta o sistema também paga essa conta

Dívida técnica acumulada aparece primeiro no custo de manutenção. A ITCODE trata esse acúmulo em sustentação e modernização, com diagnóstico e plano de correções.

Quando a decisão é sobre o que construir primeiro, o artigo Software sob medida: quando vale a pena investir traz critérios para separar o essencial do acessório. E para priorização técnica com apoio externo, a assessoria técnica atua nesse ponto.

Conclusão

Dívida técnica deixa de ser um problema quando vira item de portfólio, com dono, prazo, custo e impacto declarados. A conversa deixa de ser sobre qualidade de código e passa a ser sobre risco e velocidade, que é o idioma que a gestão entende.