Dívida técnica: como medir, priorizar e reduzir com dados (não com opinião)
“Dívida técnica” virou a desculpa mais confortável do mercado de TI. Todo sistema tem, todo CTO reconhece, e quase nenhuma empresa consegue dizer, em número, o quanto ela custa hoje. Isso é um problema — porque o que não é medido não entra em orçamento, e o que não entra em orçamento nunca é priorizado de verdade.
A McKinsey desenvolveu um índice para resolver exatamente essa lacuna: o Tech Debt Score (TDS). O achado mais importante não é técnico, é financeiro — empresas no percentil 80 desse índice crescem receita 20% a mais do que empresas no percentil abaixo de 20. Dívida técnica não é assunto de engenharia. É assunto de crescimento.
Este é o último conteúdo do nosso hub de modernização de legado — e o mais fundamental. Porque toda decisão que já discutimos aqui (os 7Rs, IA generativa, Strangler Fig Pattern, OutSystems) depende de uma coisa: saber medir, com dado, o tamanho real do problema antes de decidir o que fazer com ele.
O que é dívida técnica (e por que nem sempre é um erro)
Dívida técnica é o custo futuro de retrabalho gerado por uma decisão de desenvolvimento que priorizou velocidade sobre robustez. O termo foi cunhado por Ward Cunningham em 1992, usando a metáfora financeira de propósito: assim como uma dívida financeira, ela pode ser estratégica — assumida conscientemente para ganhar velocidade em um momento de negócio que exigia isso — ou não intencional, resultado de prazo apertado, falta de conhecimento técnico ou ausência de revisão.
O problema não é ter dívida técnica. É não saber quanto ela custa, e por isso nunca priorizá-la contra outras decisões de investimento.
As 5 dimensões de dívida técnica
Já introduzimos esse framework no artigo sobre IA generativa na modernização de código. Vale detalhar cada dimensão aqui, porque a forma de medir muda de acordo com qual delas está mais crítica:
- Manutenibilidade: quão difícil é entender e alterar o código sem introduzir erros.
- Compatibilidade: capacidade do sistema de se integrar com tecnologias e padrões atuais.
- Portabilidade: facilidade de mover o sistema entre ambientes, plataformas ou provedores.
- Segurança: exposição a vulnerabilidades conhecidas e ausência de práticas modernas de proteção.
- Eficiência de performance: capacidade de responder à carga real de uso sem degradar.
As 5 dimensões fundamentais da dívida técnica (Manutenibilidade, Compatibilidade, Portabilidade, Segurança e Eficiência de Performance). Mapear com dados em qual dessas frentes o sistema sofre gargalos é o primeiro passo para aplicar o método SQALE, calcular o Technical Debt Ratio (TDR) e direcionar investimentos de modernização para os módulos que realmente impactam o crescimento e a receita da empresa.
Como medir dívida técnica com dados — não com opinião
Existem três métodos consolidados para colocar um número em cima da dívida técnica. Nenhum é perfeito sozinho — a maioria das empresas maduras usa os três em conjunto, dependendo de para quem está reportando.
SQALE e o Technical Debt Ratio (TDR)
O método SQALE, criado por Jean-Louis Letouzey em 2010 e implementado por ferramentas como o SonarQube, converte problemas encontrados por análise estática em horas de remediação. A fórmula é direta:
Ferramentas como o SonarQube classificam o resultado em notas de A a E — nota A abaixo de 5%, nota E acima de 50%.
A vantagem: é reproduzível e já vem com suporte de ferramenta. A limitação: mede principalmente o que a análise estática enxerga — ou seja, dívida de código, não necessariamente dívida de arquitetura ou de decisão de negócio.
Método baseado em tempo
Acompanha, por trimestre, quantas horas de desenvolvedor são consumidas por trabalho relacionado a dívida — reverts, hotfixes, deploys manuais, correções rápidas, resposta a incidentes conhecidos. Multiplicado pelo custo-hora carregado do time, converte tempo perdido em valor monetário direto.
Custo de oportunidade
Compara a velocidade de entrega de funcionalidades entre serviços com alta e baixa dívida técnica, e traduz essa diferença em receita não entregue. É o método mais persuasivo para conversas com o financeiro — porque fala a língua de receita perdida, não de qualidade de código.
Como priorizar: a regra 80/20 aplicada à dívida técnica
Um erro comum é tratar dívida técnica como um problema uniforme, espalhado igualmente pelo sistema. Na prática, um pequeno número de módulos costuma concentrar a maior parte do custo — muitas vezes o módulo de pagamento ou financeiro, em sistemas enterprise, domina o custo total de “juros” pago pela organização.
Priorizar com essa lente significa medir onde a dívida técnica realmente dói — não tratar o sistema inteiro como se tivesse o mesmo nível de urgência.
Checklist de priorização por dado
- Qual módulo concentra a maior parte dos incidentes de produção nos últimos 2 trimestres?
- Qual módulo tem o TDR mais alto segundo a análise estática?
- Qual módulo consome mais horas de manutenção não planejada por sprint?
- Qual módulo está bloqueando lançamento de funcionalidades novas de maior valor de negócio?
O custo real de não medir
Os números do mercado deixam claro o tamanho do problema quando ele não é gerido com dado:
| Dado | Fonte |
|---|---|
| 30% dos CIOs reportam mais de 20% do orçamento de novos produtos desviado para dívida técnica | McKinsey |
| Dívida técnica representa 20% a 40% do valor total do ativo tecnológico de uma empresa | McKinsey |
| Projeção de US$ 5 trilhões em perda de produtividade global até 2030 | McKinsey |
| 45% do código mundial é frágil; 32% inchado; 31% rígido demais para mudar com segurança | CAST (“Coding in the Red”, 2025) |
| Desenvolvedores gastam 33% do tempo lidando com dívida técnica em vez de construir funcionalidade nova | Stripe |
Framework de decisão: quando pagar a dívida x quando ela é aceitável
| Cenário | Recomendação |
|---|---|
| Módulo de alto TDR, mas baixo impacto no negócio | Monitorar, não priorizar — dívida aceitável no momento |
| Módulo de TDR moderado, mas concentra incidentes recorrentes | Priorizar remediação incremental (ver 7Rs: Refactor) |
| Módulo crítico, alto TDR, alto custo de oportunidade | Priorização máxima — avaliar Rearchitect ou Rebuild via Strangler Fig Pattern |
| Dívida concentrada em plataforma low-code por falta de governança | Ver critério específico em modernização em OutSystems |
Fechando o hub: como esses 5 conteúdos se conectam
Medir dívida técnica é o ponto de partida — não o fim da conversa. A partir daqui, a decisão se conecta diretamente ao resto deste hub: os 7Rs da modernização ajudam a escolher a estratégia certa para cada sistema identificado aqui como prioritário; a IA generativa pode acelerar a remediação, desde que com a governança certa; o Strangler Fig Pattern é como executar a migração sem parar a operação; e a decisão sobre evoluir ou sair do OutSystems segue exatamente a mesma lógica de dado, não de opinião.
Como a Framework mede antes de agir
No projeto com a Unimed-BH, o sistema CIH não tinha documentação nem testes — ou seja, nenhuma forma prévia de medir dívida técnica com dado. O primeiro passo não foi migrar. Foi medir: cobertura de testes E2E implementada antes de qualquer refatoração, para que a decisão de modernização seguisse dado real de comportamento do sistema, não suposição.
A virada
Dívida técnica não medida não desaparece — ela só fica invisível até aparecer como incidente, atraso de lançamento ou vulnerabilidade explorada. As empresas que crescem receita mais rápido, segundo o próprio índice da McKinsey, não são as que têm menos dívida técnica. São as que sabem exatamente quanto ela custa.
Se isso faz sentido para o momento que sua empresa está vivendo, a nossa AI Session é o próximo passo.
Perguntas frequentes sobre dívida técnica
O que é dívida técnica?
É o custo futuro de retrabalho gerado por uma decisão de desenvolvimento que priorizou velocidade sobre robustez — podendo ser uma escolha estratégica consciente ou resultado não intencional de prazo apertado e falta de revisão.
Como medir dívida técnica em números?
Três métodos principais: o Technical Debt Ratio (SQALE), que converte problemas de código em horas de remediação; o método baseado em tempo, que mede horas de retrabalho por trimestre; e o custo de oportunidade, que traduz a diferença de velocidade de entrega em receita não gerada.
Qual o Technical Debt Ratio (TDR) considerado bom?
Ferramentas como o SonarQube, que implementam o método SQALE, classificam TDR abaixo de 5% como nota A e acima de 50% como nota E — mas o valor aceitável depende da criticidade do sistema.
Como priorizar qual dívida técnica resolver primeiro?
Seguindo a lógica 80/20: identificar o pequeno número de módulos que concentra a maior parte do custo — geralmente medido por incidentes de produção, TDR e impacto em funcionalidades de maior valor de negócio.
Dívida técnica é sempre um problema?
Não. Pode ser uma decisão estratégica válida para ganhar velocidade em um momento de negócio específico. O problema surge quando ela não é medida nem monitorada, e cresce além da capacidade de gestão da empresa.
Quanto a dívida técnica custa para uma empresa?
Segundo a McKinsey, pode representar de 20% a 40% do valor total do ativo tecnológico de uma empresa, com até 20% do orçamento de novos produtos desviado para lidar com problemas relacionados.
