A conversa começa sempre da mesma forma: "Nosso time era ágil. Agora cada feature leva o triplo do tempo. O que aconteceu?"
O que aconteceu tem nome: dívida técnica. E ela não aparece de uma hora para outra — ela se acumula silenciosamente, sprint a sprint, decisão a decisão, até chegar no momento em que o custo de entrega explode e ninguém consegue apontar exatamente onde o problema começou.
O que é dívida técnica de verdade
O termo foi cunhado por Ward Cunningham nos anos 90 para descrever uma escolha consciente: fazer algo de forma mais simples agora, sabendo que você vai "pagar" depois com refatoração. Era uma metáfora financeira positiva — dívida estratégica para mover rápido.
O problema é que a maior parte da dívida técnica no mundo real não é estratégica. Ela é acidental, invisível, e nunca foi decidida conscientemente por ninguém.
Existem três tipos principais:
- Dívida deliberada: "Vamos fazer gambiarra agora, depois arrumamos." Às vezes faz sentido. Raramente é paga.
- Dívida inadvertida: "Só entendemos o design certo depois de terminar." Inevitável. Precisa de espaço para ser corrigida.
- Dívida entrópica: O sistema funciona, mas ninguém mais entende por quê. Documentação sumiu. O autor foi embora. Ninguém ousa mexer.
A mais perigosa é a entrópica. Ela não aparece em nenhum backlog. Ela só aparece quando algo quebra — e aí o custo de investigação + correção é altíssimo.
Como a dívida técnica mata a velocidade
O mecanismo é previsível. A dívida cria fricção cognitiva: engenheiros precisam entender sistemas complexos antes de modificá-los. Cria acoplamento oculto: mexer em A quebra B de forma inesperada. Cria medo: ninguém quer ser o responsável por derrubar produção.
O resultado prático? Times que deveriam entregar uma feature em uma semana gastam três semanas só para entender onde ela deve ser plugada — e mais duas para garantir que não quebrou nada ao redor.
Existe uma curva bem conhecida: nos primeiros meses de um produto, a velocidade é alta. Com o tempo, sem investimento em qualidade, a velocidade cai. Depois de 2 a 3 anos sem atenção, muitos times chegam a uma situação em que novas features exigem tanto trabalho de estabilização que o produto efetivamente para.
O erro mais comum: tratar dívida técnica como problema técnico
CTOs frequentemente cometem um erro de enquadramento aqui: tratam dívida técnica como assunto de engenharia, quando ela é, fundamentalmente, um assunto de negócio.
Dívida técnica não resolvida tem custo direto mensurável:
- Mais horas de engenharia por feature entregue
- Maior taxa de bugs em produção (e custo de correção)
- Turnover de engenheiros — pessoas boas não querem trabalhar em sistemas ruins
- Menor capacidade de resposta a oportunidades de mercado
- Risco de incidentes de maior impacto à medida que o sistema fica mais frágil
Quando você traduz dívida técnica em impacto de negócio, a conversa com a liderança muda completamente.
Como avaliar sua dívida técnica
Antes de decidir o que pagar, você precisa saber o que deve. Algumas abordagens práticas:
Mapeamento de pontos de dor
Pergunte diretamente ao time: "Quais áreas do sistema você mais teme mexer?" As respostas apontam para onde a dívida é mais crítica. Áreas que todo engenheiro evita são áreas que já estão custando caro.
Análise de tempo de ciclo por área
Compare o tempo médio para entregar uma feature em diferentes partes do sistema. Outliers negativos geralmente coincidem com as áreas de maior dívida técnica.
Taxa de bugs por módulo
Módulos com taxa de bugs desproporcional tendem a ser áreas com alta dívida técnica. A causa é acoplamento excessivo e cobertura de testes insuficiente.
O que vale pagar e o que não vale
Nem toda dívida precisa ser paga. A decisão deve ser baseada em dois eixos: impacto no negócio e custo de correção.
Dívida em sistemas legados que ninguém mais usa? Ignore. Dívida na API principal que processa 80% do seu volume? Prioridade alta, independente do custo.
Uma regra prática útil: reserve consistentemente de 15% a 20% da capacidade de engenharia para qualidade técnica — refatoração, testes, documentação, modernização de dependências. Não como projeto pontual, mas como prática contínua.
Times que não reservam esse espaço tendem a chegar, em 18 a 24 meses, ao ponto em que precisam de um "projeto de reescrita" — que é caro, arriscado, e frequentemente subestimado em escopo e duração.
A conversa que precisa acontecer
Se você está num ponto em que a velocidade de entrega do time caiu significativamente e a causa parece ser a complexidade acumulada do sistema, você precisa de uma análise honesta do estado técnico do produto.
Essa análise não é um exercício de culpa — é um ponto de partida para decisão. Quanta dívida existe? Onde está concentrada? Qual é o custo real de carregá-la? Qual é o custo de endereçá-la? E como priorizar dentro da realidade do negócio?
Essas são perguntas com respostas. E respondê-las corretamente vale mais do que qualquer feature nova no roadmap.