Débito técnico não é problema de engenharia — é risco de negócio

O que ninguém conta no balanço

Débito técnico é o conjunto de decisões técnicas postergadas ou mal tomadas que geram custo crescente ao longo do tempo. Assim como dívida financeira, ele acumula juros — só que esses juros aparecem na forma de features que levam semanas quando deveriam levar dias, bugs recorrentes que nunca somem de vez e sistemas que ninguém mais quer tocar.

O problema não é a existência do débito. Todo software de produção real carrega algum. O problema é quando ele ultrapassa o ponto em que o time gasta mais energia mantendo o que existe do que criando o que o negócio precisa.

Como o débito se manifesta no P&L

Os sinais financeiros do débito técnico raramente aparecem etiquetados como tal no relatório de custos. Eles aparecem como:

• Slowdown de entrega — sprints que ficam progressivamente mais lentas sem aumento de escopo
• Custo de incidente crescente — chamados, plantões, revertes e horas de engenharia para apagar incêndios
• Turnover técnico elevado — engenheiros sêniores pedem demissão porque não aguentam trabalhar na base de código
• Dificuldade de onboarding — novos membros do time levam meses para ser produtivos
• Oportunidades perdidas — features que o negócio pediu e o time disse que "não dá para fazer agora"

Um estudo da McKinsey estimou que entre 20% e 40% do valor de patrimônio tecnológico de empresas está sendo destruído pelo débito técnico acumulado. Para uma empresa com orçamento de tecnologia de R$ 10 milhões, isso representa até R$ 4 milhões desperdiçados anualmente.

O modelo mental correto: débito com juros compostos

O que torna o débito técnico perigoso é que ele não é linear — é exponencial. Um módulo legado sem cobertura de testes que hoje custa 2 horas para qualquer mudança vai custar 8 horas em 18 meses, não pelo volume de código, mas pela camada de remendos que se acumula sobre ele.

Como líderes devem quantificar o débito

1. Lead time de feature — quanto tempo, em média, leva desde o pedido até a entrega em produção?
2. Taxa de retrabalho — qual percentual das horas de engenharia vai para correções de problemas já conhecidos?
3. MTTR — quanto tempo o time leva para resolver incidentes?
4. Custo de change failure — quantas entregas em produção causam incidente ou precisam de rollback?

Remediação: não existe bala de prata

• Strangler Fig Pattern — substituir partes do sistema legado progressivamente, sem big bang rewrite
• Boy Scout Rule — qualquer módulo tocado sai melhor do que entrou
• Teto de débito explícito — definir com o negócio qual é o nível aceitável de débito
• Investment Fridays — proteger ciclos de engenharia dedicados exclusivamente a qualidade