O custo real da dívida técnica: como medir e apresentar para o negócio

1. O que é dívida técnica e por que ela não é apenas "código feio"

Dívida técnica não é sinônimo de código mal escrito. É o acúmulo de decisões subótimas — intencionais ou não — que geram juros na forma de retrabalho, lentidão e bugs. Ward Cunningham, que cunhou o termo, comparou ao débito financeiro: você toma um empréstimo para acelerar uma entrega, mas os juros (esforço extra futuro) precisam ser pagos.

Existem dois tipos principais:
- Dívida intencional (estratégica): quando o time decide conscientemente acelerar uma entrega sabendo que precisará refatorar depois. Exemplo: lançar um MVP com código direto ao ponto, mesmo sabendo que a arquitetura não escala.
- Dívida acidental (técnica): resulta da falta de padrões, testes insuficientes ou ausência de boas práticas. Exemplo: um módulo crítico sem testes unitários, onde qualquer alteração quebra funcionalidades.

A analogia financeira é poderosa: o principal é o esforço inicial economizado; os juros são o custo extra de manutenção. Se o negócio só enxerga o principal, nunca entenderá por que uma simples alteração leva três dias em vez de três horas.

2. Os custos invisíveis que a dívida técnica gera no dia a dia

Três custos frequentemente ignorados:

Custo de onboarding: Um novo desenvolvedor leva o dobro do tempo para entender código com alta dívida técnica. Em um time de 10 pessoas com rotatividade anual de 30%, isso pode significar meses perdidos por ano.

Custo de manutenção: Cada alteração simples exige horas de análise e testes porque o código é frágil. Um bug de produção que deveria ser corrigido em 2 horas pode levar 8 horas — e ainda gerar novos bugs.

Custo de oportunidade: Funcionalidades que deixam de ser entregues porque o time está apagando incêndios. Uma equipe que gasta 40% do sprint corrigindo bugs não está inovando.

3. Como medir a dívida técnica de forma objetiva (métricas e indicadores)

Métricas de código:
- Complexidade ciclomática (ideal < 10 por função)
- Acoplamento entre módulos (número de dependências)
- Duplicação de código (percentual do código-fonte)
- Cobertura de testes (mínimo 70% para código crítico)

Métricas de processo:
- Tempo médio de resolução de bugs (MTTR)
- Lead time de features (da concepção à entrega)
- Taxa de retrabalho (percentual de tarefas que precisam ser refeitas)

Ferramentas práticas:

# Exemplo de comando para análise estática com SonarQube (via CLI)
sonar-scanner \
  -Dsonar.projectKey=meu-projeto \
  -Dsonar.sources=. \
  -Dsonar.host.url=http://localhost:9000 \
  -Dsonar.login=meu-token

# Saída esperada (exemplo):
# Complexidade ciclomática média: 12.4 (meta: < 10)
# Duplicação: 8.3% (meta: < 5%)
# Cobertura de testes: 45% (meta: > 70%)

4. Traduzindo métricas técnicas em linguagem de negócio

A conversão mais direta: horas perdidas × custo médio do time.

# Cálculo do custo financeiro da dívida técnica (exemplo)
Time: 8 desenvolvedores
Salário médio (com encargos): R$ 25.000/mês
Custo por hora (considerando 168h/mês): R$ 148,81

Horas extras por sprint devido à dívida técnica:
- Onboarding extra: 20h/mês
- Manutenção extra: 40h/mês
- Retrabalho: 30h/mês
Total: 90h/mês

Custo mensal da dívida técnica: 90h × R$ 148,81 = R$ 13.392,90
Custo anual: R$ 160.714,80

Tabela comparativa:

| Indicador                     | Sem dívida técnica | Com dívida técnica acumulada |
|-------------------------------|---------------------|------------------------------|
| Lead time de feature          | 2 semanas          | 5 semanas                    |
| Taxa de bugs em produção      | 2/mês              | 12/mês                       |
| Cobertura de testes           | 85%                | 35%                          |
| Tempo de onboarding           | 1 mês              | 3 meses                      |
| Funcionalidades entregues/trim| 12                 | 4                            |

5. Apresentando para stakeholders: o pitch que funciona

Estrutura da apresentação:

  1. Problema: "Estamos gastando R$ 13 mil por mês em retrabalho que poderia ser evitado."
  2. Dados: Mostre as métricas de código e processo traduzidas em horas e dinheiro.
  3. Impacto financeiro: Use a tabela comparativa acima para mostrar o que o negócio está perdendo.
  4. Proposta de ação: "Investir 20% do tempo do time em redução de dívida técnica nos próximos 3 meses trará retorno de 3x em produtividade."

Visualização que convence: um gráfico de "juros compostos" mostrando que a dívida cresce exponencialmente se não for paga. Use o seguinte formato para simular:

Mês 1: 10 horas extras/semana
Mês 3: 25 horas extras/semana
Mês 6: 55 horas extras/semana
Mês 12: 120 horas extras/semana

Evite jargões como "complexidade ciclomática" ou "acoplamento". Use termos como "código frágil que quebra com frequência" e "tempo perdido em retrabalho".

6. Estratégias para reduzir a dívida sem parar a produção

Refatoração incremental: Em vez de reescrever tudo (o que para a produção), priorize módulos com maior frequência de alteração. Um módulo alterado 10 vezes por mês merece mais atenção que um alterado 1 vez por ano.

Orçamento técnico no roadmap: Aloque 20% do sprint para redução de dívida. Isso não para a produção — apenas desacelera novas features temporariamente.

Priorização por custo-benefício: Use a matriz abaixo para decidir o que atacar primeiro:

| Módulo      | Frequência de alteração | Custo de manutenção atual | Prioridade |
|-------------|-------------------------|---------------------------|------------|
| Checkout    | 15/mês                  | 40h/mês                   | Alta       |
| Login       | 2/mês                   | 5h/mês                    | Baixa      |
| Catálogo    | 8/mês                   | 20h/mês                   | Média      |
| Relatórios  | 1/mês                   | 3h/mês                    | Baixa      |

7. Monitoramento contínuo: como evitar que a dívida volte a crescer

Gates de qualidade no pipeline: Configure regras que bloqueiam deploys se as métricas ultrapassarem limites aceitáveis.

# Exemplo de configuração de gate no pipeline (CI/CD)
Regras:
- Complexidade ciclomática máxima: 15 (bloqueia se > 15)
- Cobertura de testes mínima: 70% (bloqueia se < 70%)
- Duplicação máxima: 5% (bloqueia se > 5%)

Rituais de revisão periódica: A dívida técnica deve ser item fixo em retrospectivas. Pergunte: "Quanto tempo gastamos este sprint em retrabalho causado por dívida técnica?"

Cultura de código limpo como padrão: Políticas que funcionam:
- Code review obrigatório com checklist de qualidade
- Pair programming para módulos críticos
- Documentação de decisões arquiteturais (ADRs)

Referências