Dívida técnica é sempre erro do time de desenvolvimento?

Não. Boa parte é consequência de decisões legítimas de prazo, tomadas com informação da época. O problema não é contrair a dívida, é não registrá-la e descobrir o juro anos depois.

Como sei se o meu sistema tem dívida alta?

Compare estimativas com o passado. Se uma mudança que levava três dias hoje leva duas semanas, sem que o pedido tenha ficado mais complexo, você está pagando juros.

Vale a pena reescrever o sistema do zero?

Raramente. Reescrita costuma custar mais que o previsto, congela evoluções por meses e recria dívidas novas. A abordagem que funciona é isolar e substituir por partes, mantendo o sistema em produção.

Dívida técnica: o que custa para o seu negócio

Dívida técnica é o custo extra que você paga em toda mudança futura por causa de atalhos tomados no passado. A metáfora é financeira e precisa: você antecipou uma entrega tomando emprestado tempo do futuro, e o futuro cobra juros, em forma de prazo, risco e dependência de pessoas específicas.

Para quem gerencia, ela não aparece como código feio. Aparece como orçamento que cresce sem que o pedido tenha ficado maior.

Como a dívida chega até a diretoria

Cinco sintomas, todos observáveis sem entender de programação:

Estimativas inflam com o tempo. A mesma classe de pedido que levava três dias há dois anos leva duas semanas hoje. Ninguém sabe explicar direito.
Correções geram novos problemas. Arrumar uma coisa quebra outra em lugar aparentemente sem relação.
Só uma pessoa consegue mexer. Existe uma parte do sistema que todos evitam, e as férias dessa pessoa travam decisões.
Deploy vira evento. Publicar mudança exige fim de semana, aviso à operação e plano de retorno.
A resposta a todo pedido é "é complicado". Sem que o pedido em si seja complicado.

Se três desses aparecem, o problema não é falta de esforço da equipe. É estrutura.

A conta que traduz dívida em dinheiro

Dá para estimar o juro sem auditoria técnica:

Sinal	Como medir	Custo aproximado
Inflação de prazo	Estimativa média hoje ÷ estimativa média há 2 anos	Diferença × custo hora × volume de mudanças
Retrabalho pós-entrega	% de entregas que voltam com defeito	Horas de correção por mês
Indisponibilidade	Horas de parada por trimestre	Receita ou custo operacional parado
Concentração de conhecimento	Nº de pessoas capazes de alterar cada módulo	Risco, não custo direto
Tempo até publicar	Da conclusão do código até estar no ar	Atraso de todo ganho de negócio

A linha mais subestimada é a última. Se leva três semanas entre "pronto" e "no ar", cada melhoria entregue rende três semanas a menos de benefício por ano, e o time evita entregas pequenas, o que aumenta o risco de cada publicação.

A concentração de conhecimento não custa nada até o dia em que custa tudo. É a única linha da tabela em que o valor esperado é baixo e o valor máximo é a operação parada.

Os tipos de dívida, porque o tratamento é diferente

Nem toda dívida é igual, e tratá-las do mesmo jeito desperdiça dinheiro:

Dívida deliberada e registrada. "Vamos entregar sem cache agora para pegar a temporada, e resolver em março." É uso legítimo do instrumento, desde que registrado com prazo. Essa dívida é boa gestão.

Dívida acidental. Ninguém sabia de um jeito melhor na época. Descoberta depois, com o sistema já rodando. Não há culpado e há custo.

Dívida por deterioração. O código estava certo, o negócio mudou. Regras antigas continuam ali "por via das dúvidas", e ninguém tem autoridade para removê-las.

Dívida de infraestrutura. Versões antigas de banco, biblioteca ou sistema operacional sem suporte. É a única categoria com prazo externo: o fornecedor encerra o suporte na data dele, não na sua.

A quarta merece prioridade automática, porque acumula risco de segurança e a janela de correção fecha sozinha.

Quando pagar e quando conviver

Pagar dívida em área que não muda é desperdício. O critério é a frequência de mudança:

Muda com frequência e é difícil de mexer → pague primeiro, é onde o juro é alto
Muda com frequência e é fácil de mexer → mantenha assim
Quase não muda e é difícil → conviva, com monitoramento
Quase não muda e é fácil → não gaste atenção

Uma parte feia do sistema que ninguém toca há três anos não está custando nada. Refatorá-la por incômodo estético é gasto sem retorno.

Como discutir isso com o time técnico

Duas perguntas costumam abrir a conversa de forma produtiva:

"Se pudéssemos parar uma semana, o que vocês arrumariam e quanto isso encurtaria as próximas entregas?" Ela pede a prioridade do time com justificativa de retorno, em vez de uma lista de desejos.

"Quais mudanças você evita fazer por medo de quebrar algo?" O mapa desses lugares é o mapa da dívida crítica, e sai em cinco minutos.

Vale evitar a pergunta "quanto de dívida técnica temos?". Não existe número confiável, e a tentativa de produzir um consome tempo que renderia mais na correção.

Como manter a dívida sob controle

Três práticas de gestão, nenhuma técnica:

Reserve capacidade fixa. Entre 10% e 20% do tempo de cada ciclo para manutenção estrutural, definido antes de o ciclo começar. Sem reserva, essa fila nunca ganha de uma funcionalidade nova.
Registre a dívida quando ela for contraída. Uma linha no documento do projeto: o que foi adiado, por quê, qual o prazo. Dívida invisível é a única que não se administra.
Trate cada incidente como dado. Falha recorrente aponta dívida com precisão maior que qualquer inventário. Vale rodar 5 porquês e registrar a causa estrutural.

Nos sistemas que a Retti Tech mantém em produção, a reserva fixa de capacidade é o que mais diferencia projetos que envelhecem bem dos que travam no terceiro ano. Não é sofisticação técnica: é a decisão de que uma parte do orçamento não vai para tela nova.

O que levar da conversa

Dívida técnica é decisão de negócio, não detalhe de engenharia. Contrair conscientemente é legítimo. Contrair sem registrar é o que produz, anos depois, o sistema que custa caro, quebra com frequência e depende de uma pessoa só, e nesse ponto a discussão já não é sobre código, é sobre risco operacional.