Ir para o conteúdo 
Para medir dívida técnica, acompanhe cinco métricas: percentual da capacidade de engenharia gasto em manutenção versus evolução, lead time de mudança, taxa de retrabalho, code churn e bus factor. Depois converta em dinheiro: custo anual do time multiplicado pelo excesso de capacidade consumido por manutenção não planejada. O resultado é o juro anual da sua dívida, em reais.
Você já sabe que dívida técnica custa caro. Se ainda não sabe, comece por quanto a dívida técnica custa e por que ela drena orçamento e volte aqui depois. Este artigo assume que você já aceitou o problema e quer o próximo passo: colocar um número na SUA dívida.
Porque "a gente tem bastante dívida técnica" não é informação. É desabafo. CFO não aprova orçamento para desabafo. Aprova para número com método por trás.
Meça o juro, não o principal
Antes das métricas, um ajuste de mira. Você não vai medir o tamanho total da dívida. Isso é quase impossível e, pior, é inútil: ninguém vai pagar o principal inteiro de uma vez.
O que você vai medir é o juro: quanto a dívida cobra do seu time todo mês para simplesmente existir. É a definição clássica de Martin Fowler sobre dívida técnica: cada entrega futura sai mais cara por causa das decisões passadas, como juros compostos sobre um empréstimo.
Juro é mensurável. Juro aparece no fluxo de trabalho do time toda semana. E juro convertido em reais por ano é um argumento que atravessa a sala do CFO sem tradução.
As 5 métricas que colocam número na sua dívida
Nenhuma delas exige ferramenta cara. Todas saem do que você já tem: gestor de tarefas, repositório Git e folha de pagamento. E nenhuma delas é métrica de vaidade: cada uma responde uma pergunta de negócio.
1. Capacidade em manutenção vs evolução
A métrica-mãe. De toda a capacidade do time num mês, quanto foi para criar valor novo (funcionalidade, melhoria de conversão, produto) e quanto foi para manter o que existe funcionando (bugfix, apagar incêndio, contornar limitação de arquitetura, atualização forçada)?
Como coletar: classifique cada tarefa do sprint em "evolução" ou "manutenção". Duas categorias, sem sofisticação. Quatro sprints já dão um retrato honesto.
O que ela revela: a fatia de manutenção é a fatia do seu orçamento de engenharia que a dívida já confiscou. Lembre do teto conhecido do mercado: dívida técnica consome até 40% do orçamento de TI. Essa métrica diz onde VOCÊ está nessa escala.
2. Lead time de mudança
Tempo entre o commit e o código rodando em produção. Métrica popularizada pela pesquisa DORA, e a mais sensível à dívida: código acoplado, sem testes e mal documentado transforma qualquer mudança pequena numa operação de risco.
Como coletar: timestamp do commit até o timestamp do deploy. A maioria das ferramentas de CI/CD entrega isso pronto.
O que ela revela: velocidade de reação do negócio. Se o concorrente lança em dias e você em meses, a diferença não é talento. É dívida.
3. Taxa de retrabalho e bugs
De tudo que o time entrega, quanto volta? Percentual de tarefas reabertas, bugs originados de entregas recentes, hotfixes na semana seguinte ao deploy.
Como coletar: no gestor de tarefas, marque a origem de cada bug. Bug novo em área recém-entregue = retrabalho.
O que ela revela: quanto do seu "avanço" é ilusão. Time que entrega 10 funcionalidades e reabre 4 entregou 6 e pagou por 10.
4. Code churn
Percentual de código reescrito ou apagado pouco tempo depois de ter sido escrito. Churn alto em arquivos recentes indica que o time está escrevendo, descobrindo que não serve e reescrevendo.
Como coletar: análise do histórico Git. Ferramentas de análise de repositório calculam isso automaticamente; um script simples sobre o git log também resolve.
O que ela revela: onde estão os focos da dívida. Os arquivos com maior churn e maior frequência de bugs são o mapa exato do que precisa de refatoração primeiro.
5. Bus factor
Quantas pessoas precisam sair do time para que uma parte crítica do sistema fique órfã de conhecimento? Bus factor 1 significa que um pedido de demissão vira incidente de continuidade de negócio.
Como coletar: cruze os módulos críticos do sistema com os autores dos commits. Módulo crítico com um único autor relevante = bus factor 1.
O que ela revela: risco concentrado. Dívida técnica não mora só no código; mora no conhecimento que nunca foi documentado porque "nunca deu tempo".
| Métrica | Pergunta que responde | Fonte do dado |
|---|---|---|
| Manutenção vs evolução | Quanto do orçamento a dívida já confiscou? | Gestor de tarefas |
| Lead time de mudança | Quão devagar o negócio reage? | CI/CD |
| Taxa de retrabalho | Quanto da entrega é ilusão? | Gestor de tarefas |
| Code churn | Onde estão os focos da dívida? | Histórico Git |
| Bus factor | Qual o risco concentrado em pessoas? | Git + organograma |
A fórmula: convertendo em R$ por ano
Agora o passo que transforma métrica em decisão. A conversão usa a métrica-mãe:
Custo anual da dívida = custo anual do time de engenharia × (% de capacidade em manutenção − % de manutenção aceitável)
Três observações antes de aplicar:
- Custo anual do time é custo cheio: salários, encargos, benefícios, ferramentas. Não é só folha nominal.
- % de manutenção aceitável é uma decisão sua, não um benchmark de mercado. Todo sistema vivo exige alguma manutenção. Defina com o time qual fatia é saudável para o seu contexto e o seu momento de produto. O que passar disso é juro da dívida.
- O resultado é conservador de propósito. Ele mede só o desperdício direto de capacidade. Os Custos Invisíveis ficam de fora, e falamos deles já já.
Aplicando num cenário concreto
Pegue uma operação com 12 pessoas em engenharia e custo cheio médio de R$ 25.000 por pessoa ao mês. Custo anual do time: 12 × 25.000 × 12 = R$ 3,6 milhões.
O time classificou quatro sprints e descobriu que 55% da capacidade vai para manutenção: bugs, incêndios, gambiarras sobre gambiarras. A liderança definiu que, para esse produto, 30% de manutenção seria aceitável.
Custo anual da dívida = 3.600.000 × (0,55 − 0,30) = 3.600.000 × 0,25 = R$ 900.000 por ano.
Novecentos mil reais por ano pagos em juros. Não para evoluir o produto. Não para ganhar mercado. Para manter o sistema no mesmo lugar. Esse é o número que muda a conversa de orçamento: refatorar deixa de ser "pedido da engenharia" e vira investimento com payback calculável contra R$ 900 mil anuais de sangria.
O que a fórmula não captura
O número da fórmula é o piso, não o teto. Fora dele ficam os Custos Invisíveis:
- Receita perdida por experiência ruim. 88% dos usuários abandonam sites após experiências ruins, e sistema endividado degrada a experiência todo dia: lentidão, erro intermitente, fluxo confuso que ninguém consegue arrumar porque mexer ali é perigoso.
- Custo de oportunidade. Cada funcionalidade que não foi lançada porque o time estava apagando incêndio é receita que não aconteceu.
- Risco de decisão errada na correção. Medir errado leva a corrigir errado. Refazer interface sobre fundação podre é o clássico: antes de qualquer reforma, vale ler o que considerar antes de refatorar a UI de um sistema digital e os erros mais comuns no redesign de interface. O número da dívida diz que há problema; ele não diz, sozinho, qual é a correção certa.
Perguntas frequentes
Preciso de ferramenta paga para medir dívida técnica?
Não para começar. As cinco métricas saem de Git, CI/CD e gestor de tarefas que você já usa. Ferramentas de análise estática ajudam a aprofundar depois, mas a conversão em reais depende mais de disciplina de classificação do que de software.
Com que frequência devo medir?
Classificação de manutenção vs evolução: todo sprint, porque o custo de coleta é quase zero. Lead time, retrabalho e churn: leitura mensal. Bus factor: revisão trimestral ou a cada mudança relevante no time. O valor está na tendência, não na foto isolada.
Qual métrica priorizar se eu só puder acompanhar uma?
Capacidade em manutenção vs evolução. É a única que conversa diretamente com a fórmula de custo em reais e a que o CFO entende sem tradução. As outras quatro explicam o porquê e mostram onde atacar.
O número que encontrei justifica parar tudo e refatorar?
Quase nunca. O número serve para dimensionar o investimento em correção, não para justificar uma parada geral. Compare o custo anual da dívida com o custo do plano de correção e priorize pelos focos que o code churn revelou. Pagamento de dívida bem feito é parcelado e cirúrgico.
Conclusão: seu roteiro de medição
O leitor que chegou até aqui não precisa de mais teoria. Precisa de agenda. O roteiro:
- Semana 1: classifique as tarefas do sprint atual em evolução ou manutenção. Só isso.
- Semanas 2 a 4: mantenha a classificação e extraia lead time e taxa de retrabalho das ferramentas que você já tem.
- Semana 4: rode a análise de churn no Git e mapeie o bus factor dos módulos críticos.
- Fim do mês: aplique a fórmula. Custo cheio do time × excesso de manutenção = juro anual da sua dívida, em reais.
- Mês seguinte: leve o número para a conversa de orçamento e priorize a correção pelos focos que o churn apontou.
Um mês de disciplina e a sua dívida deixa de ser sensação e vira linha de planilha. Ativo Digital se gerencia assim: com número, não com opinião. É Eficiência de Capital aplicada à engenharia.
E se o número que aparecer for grande demais para resolver internamente, ou se a dúvida for por onde atacar primeiro sem quebrar o que funciona, esse é exatamente o tipo de decisão que um Discovery estratégico existe para reduzir a risco zero de achismo. Fale com a UX Agency e traga o seu número. A conversa começa dele.
