Resposta rápida
Dívida técnica é o custo futuro de decisões “rápidas” ou subótimas. O problema não é ter dívida — é não ter plano de pagamento. (ibm.com)
Como identificar dívida técnica (sinais objetivos)
1) Os “juros” aparecem no dia a dia
Procure por:
- Mudanças simples que viram “projeto”
- Releases com medo (sem rollback, sem teste)
- Bugs recorrentes na mesma área
- Crescente MTTR (tempo para restaurar)
Regra prática
Se o time evita mexer em um módulo porque “quebra tudo”, isso já é dívida.
2) Classifique a dívida (pra parar de discutir no grito)
O quadrante do Fowler ajuda a separar dívida prudente vs. imprudente e deliberada vs. inadvertida. (martinfowler.com)
A metáfora existe porque o custo aparece depois, como juros. (martinfowler.com)
Como priorizar (o que pagar primeiro)
Use três notas (1–5) e some
- Risco (segurança, indisponibilidade, dados)
- Impacto no delivery (quantas squads/módulos bloqueia)
- Frequência (quantas vezes você “paga juros” por mês)
Critério de desempate
Se tem risco de incidente, vira P0. Se só atrasa, entra no topo do próximo ciclo.
Como reduzir sem parar (método que funciona)
1) Reserve capacidade fixa
Separe 10–20% do sprint para dívida (refactor, testes, observabilidade). Práticas ágeis e “definição de pronto” ajudam a conter dívida continuamente. (atlassian.com)
2) Crie um “registro de dívida” (Debt Register)
Cada item precisa ter:
- sintoma e “juros” (tempo extra, bugs, instabilidade)
- risco (baixo/médio/alto)
- saída objetiva (ex.: “cobertura mínima 70% nesse módulo”)
3) Use SLO e error budget como freio automático
O Google mostra uma política: se o serviço excede o error budget, congela mudanças (exceto correções críticas) até voltar ao SLO. (sre.google)
4) Pague a dívida no fluxo (sem “projetão de refactor”)
- refatore ao tocar no código (boy scout rule)
- crie tickets pequenos (1–3 dias)
- fortaleça CI e testes para impedir que a dívida volte
Próximo passo: na growtech™, a gente transforma esse modelo em uma matriz de priorização + rotina mensal de pagamento (com métricas e evidências).
Notas e trade-offs (riscos, alternativas, dependências)
- Risco: atacar dívida “por feeling” vira briga com produto; por isso o quadrante e a pontuação (risco/impacto/frequência) são úteis. (martinfowler.com)
- Trade-off: reservar 10–20% reduz velocidade “no curto prazo”, mas evita juros que travam o time depois. A Atlassian reforça práticas como DoD, testes e CI para controlar dívida. (atlassian.com)
- Dependência: para usar error budget, você precisa de SLO e monitoramento minimamente confiável. (sre.google)
