Como Lidar Com Tod

O que é dívida técnica e por que ela existe

Dívida técnica é um empréstimo que seu time pega do futuro para entregar algo agora. Não é um conceito abstrato — ela se materializa em código legado, testes que ninguém rodou, documentação desatualizada e serviços que funcionam só porque as pessoas esqueceram de desligar. Eu não costumo chamar de "dívida" nas conversas com devs. Chamo de escolha. Sempre houve um trade-off. O problema é que a maioria dos times assume a dívida sem saber o valor dos juros.

como lidar com tod no dia a dia

Existem três abordagens principais. A primeira é ignorar até o sistema cair. A segunda é tentar zerar tudo e não entregar. A terceira, que funciona na prática, é tratar a dívida como um portfólio gerenciável, não como um vilão. Você precisa de um inventário. Comece com uma pesquisa simples no repositório: procure pragmas como // TODO, // HACK, // FIXME. Use grep ou search no GitHub/GitLab. Esse é seu ponto de partida, não sua solução final.

O método que eu uso funciona assim: classifique cada item encontrado em três categorias usando uma escala de custo-benefício.

• Dívida crítica: código que quebra em produção pelo menos uma vez por mês, gera hotfix ou causa tempo de inatividade. Trata-se com prioridade máxima.
• Dívida moderada: código que funciona mas é doloroso de manter. Adiciona tempo de desenvolvimento, aumenta chance de bug. Agendar refatoração em sprints futuros.
• Dívida tolerável: conhecimento ou convenção que não gera impacto operacional imediato. Documentar e deixar como está por enquanto.

Isso parece simples, mas resolve 80% do caos. O erro comum é achar que toda dívida é igual. Não é. Tratar todas como críticas gasta sprint inteiro sem entregar nada novo. Deixar todas como toleráveis vira sujeira acumulada que ninguém consegue mais limpar.

edge case real: quando a dívida não aparece em lugar nenhum

Em um projeto meu há alguns anos, tínhamos um serviço de processamento de arquivos que funcionava perfeitamente nos testes e falhava só em produção, aleatoriamente, a cada duas semanas. Nenhum TODO, nenhum HACK no código. A causa raiz era uma biblioteca de terceiros com comportamento de thread safety questionável em versões específicas. A dívida estava escondida na dependência, não no código-fonte. A solução foi escrever um wrapper que isolava as operações críticas e adicionava retry com backoff exponencial. Não refatoramos a biblioteca. Não atualizamos a versão. Criamos uma camada de defesa. Custo: dois dias de trabalho. Benefício: eliminação dos incidentes semanais que antes consumiam quatro horas de on-call por semana.

Lições disso: dívida técnica frequentemente vive em lugares que você não espera. Dependências, configurações de infraestrutura, contratos de API com outros times. Seu inventário precisa cobrir essas áreas também.

estratégias que realmente funcionam

A primeira é dedicar tempo recorrente. Um ou dois dias por sprint para dívida técnica é o mínimo viável. Menos que isso é apenas remanejamento, não resolução. Se seu time não consegue reservar esse tempo, o problema não é a dívida. É a cultura de entrega. A segunda estratégia é a regra do menino limpador. Sempre que você tocar em um trecho de código problemático para adicionar uma feature, gaste 15 minutos melhorando aquele trecho. Deixe-o um pouco menos doloroso para a próxima pessoa. Isso se chama boy scout rule e funciona porque o custo marginal é baixo — você já está lá, já entende o contexto, já tem os testes passando.

A terceira é mais polêmica: às vezes a melhor decisão é reescrever. Não evite reescritas por vaidade. Se um módulo consome mais de 30% do tempo de desenvolvimento do time e não evolui há seis meses, avalie seriamente uma reescrita incremental. Façam isso módulo por módulo, não tudo de uma vez. Reescrita big bang quase sempre falha.

o que não funciona

Reuniões semanais para discutir dívida técnica sem ação concreta. Isso vira terapia de desenvolvimento. As pessoas desabafam, ninguém faz nada, a dívida continua crescendo. Metas arbitrárias como "reduzir dívida em 20% este trimestre". Como você mede 20% de dívida? A métrica mais útil é lead time para mudanças. Se o lead time aumentou consistentemente, a dívida está crescendo. Se estabilizou ou diminuiu, você está vencendo.

Automatizar a descoberta e achar que resolvidam. Ferramentas como SonarQube, CodeQL e linters apontam problemas. Elas não dizem qual problema importa. Interpretar os resultados exige contexto de negócio. Sem isso, você gasta tempo refatorando o que não gera valor.

quando a dívida técnica é a escolha certa

Existem situações legítimas onde assumir dívida é correto. Lançamento de produto para validar mercado. Proof of concept para decisões estratégicas. Prazos regulatórios iminentes. Nessas horas, a dívida não é falha — é investimento calculado. O erro é não registrar. Anote no backlog. Dê um prazo para quitação. Sem registro, a dívida se torna permanente. Sem prazo, ela se acumula com juros compostos que ninguém percebe até doer.

monitoramento prático

Use estas métricas no seu Kanban ou planilha:

• Lead time médio para mudanças (sempre subindo = dívida crescendo)
• Frequência de deploy (diminuindo = time travado em manutenção)
• Percentual de tempo dedicado a dívida vs. novas features (ideal: 15-25% para dívida)
• Tempo médio de resolução de bugs recorrentes (aumentando = dívida acumulando)

Se três ou mais dessas métricas pioraram no último trimestre, sua gestão de dívida técnica está falhando. Ajuste antes que o custo aumente exponencialmente. Não existe limpeza completa. Dívida técnica nunca chega a zero, e tentar alcançar zero é desperdício de recurso. O objetivo é manter os juros sob controle enquanto você continua entregando valor. É um equilíbrio, não uma jornada com destino final.