Tech Debt: O Que É Dívida Técnica, Quadrante de Fowler e Como Gerenciar no Backlog
Entenda o que é dívida técnica (tech debt), os 4 quadrantes de Martin Fowler, tipos de debt, sinais de acúmulo e estratégias práticas para gerenciar no backlog sem parar o crescimento.
Startups que ignoram tech debt para "ir mais rápido" invariavelmente chegam a um ponto onde ir mais rápido se torna impossível. O paradoxo é cruel: quanto mais você adiou a dívida, mais lenta fica a entrega. Entender os tipos de tech debt e como gerenciá-los é o que separa times de produto sustentáveis de times que ficam apagando incêndio.
O que é?
Tech Debt (dívida técnica) é o custo de manutenção futura gerado por atalhos técnicos tomados no presente. Assim como dívida financeira, a dívida técnica acumula "juros" — quanto mais tempo sem pagar, mais caro fica.
O termo foi cunhado por Ward Cunningham em 1992:
"Shipping first-time code is like going into debt. A little debt speeds development so long as it is paid back promptly with refactoring."
Dívida técnica não é sempre ruim. Às vezes, assumir dívida deliberadamente faz sentido — desde que você saiba que está fazendo e planeje pagar.
Como funciona
Tech Debt Quadrant (Martin Fowler)
Martin Fowler classificou a dívida técnica em 4 quadrantes:
Deliberada Inadvertida
┌──────────────────┬──────────────────┐
Prudente │ "Sabemos que │ "Agora que │
│ não é ideal, │ terminamos, │
│ mas precisamos │ percebemos como │
│ lançar agora" │ deveríamos ter │
│ │ feito" │
├──────────────────┼──────────────────┤
Imprudente │ "Não temos tempo │ "O que são │
│ para design" │ design patterns?"│
│ │ │
└──────────────────┴──────────────────┘
Prudente + Deliberada = Aceitável (pague rápido)
Prudente + Inadvertida = Natural (refatore ao aprender)
Imprudente + Deliberada = Perigosa (corte de corners consciente)
Imprudente + Inadvertida = Tóxica (falta de competência)Tipos comuns de Tech Debt
| Tipo | Descrição | Exemplo |
|---|---|---|
| Code debt | Código mal estruturado, duplicado | Copy-paste de lógica em 5 lugares |
| Architecture debt | Decisões arquiteturais que não escalam | Monolito que precisaria ser microsserviços |
| Test debt | Falta de testes automatizados | 0% de cobertura em módulo crítico |
| Documentation debt | Falta de documentação | Ninguém sabe como o sistema de pagamento funciona |
| Infrastructure debt | Infra defasada | Servidor com Ubuntu 16.04 sem suporte |
| Dependency debt | Libs desatualizadas | React 16 quando o ecossistema migrou para 18+ |
Sinais de Tech Debt acumulada
Sintomas:
├── Features simples demoram semanas para implementar
├── Bugs corrigidos reaparecem em outros lugares
├── Novos devs levam meses para serem produtivos
├── "Só funciona na máquina do João"
├── Medo de mudar código — "não mexe que está funcionando"
├── Deploy manual com checklist de 47 passos
└── Incidents frequentes em produçãoComo gerenciar no backlog
Estratégia 1: Regra dos 20%
├── Reserve 20% da capacidade do sprint para tech debt
├── Exemplo: sprint de 40 pts → 8 pts para tech debt
└── Negociável conforme urgência do negócio
Estratégia 2: Boy Scout Rule
├── "Deixe o código melhor do que encontrou"
├── Pequenas melhorias em cada PR
└── Não precisa de ticket — faz parte da cultura
Estratégia 3: Tech Debt Sprints
├── 1 sprint inteiro dedicado a tech debt a cada 4-6 sprints
├── Útil para refatorações grandes
└── Requer buy-in do Product Owner
Estratégia 4: Tech Debt Score
├── Classifique cada item de tech debt por impacto e esforço
├── Priorize junto com features no backlog
└── Use o mesmo framework RICE/ICEPor que importa?
Gerenciar tech debt é fundamental porque:
- Velocidade de desenvolvimento — tech debt alta torna tudo mais lento
- Qualidade — código frágil gera mais bugs e incidents
- Moral do time — devs se frustram com código legacy
- Custo de contratação — ninguém quer trabalhar em codebase ruim
- Risco de negócio — em casos extremos, tech debt pode inviabilizar o produto
O paradoxo: startups que ignoram tech debt para "ir mais rápido" acabam indo mais devagar a médio prazo.
Exemplo prático
Auditoria de Tech Debt de um SaaS
INVENTÁRIO DE TECH DEBT
ID | Item | Tipo | Impacto | Esforço | Score
-----|-------------------------------|---------------|---------|---------|------
TD-1 | Migrar de REST para GraphQL | Architecture | Alto | 13 pts | 5/10
TD-2 | Adicionar testes no checkout | Test | Crítico | 8 pts | 9/10
TD-3 | Atualizar Node 16 → 20 | Dependency | Médio | 5 pts | 7/10
TD-4 | Remover código morto (40%) | Code | Médio | 3 pts | 6/10
TD-5 | Documentar API interna | Documentation | Baixo | 5 pts | 4/10
TD-6 | CI/CD: pipeline leva 45 min | Infrastructure| Alto | 8 pts | 8/10
Priorização:
1. TD-2 (score 9) → Checkout sem testes = risco de receita
2. TD-6 (score 8) → Pipeline lenta = devs improdutivos
3. TD-3 (score 7) → Node 16 perde suporte em 3 meses
4. TD-4 (score 6) → Código morto confunde novos devs
5. TD-1 (score 5) → Válido, mas grande — planejar para Q3
6. TD-5 (score 4) → Importante, mas não urgente
Plano: TD-2 e TD-6 entram no próximo sprint (16 pts).
Restante no backlog com revisão mensal.Tech Debt e o contexto de negócio
A decisão de assumir ou pagar tech debt precisa estar conectada ao contexto do negócio:
- Startup em validação de PMF: assumir mais dívida deliberada faz sentido — velocidade de iteração é mais importante que perfeição técnica.
- Startup pós-PMF em escala: pagar a dívida sistematicamente é crítico — tech debt alta limita a velocidade de crescimento justamente quando a empresa mais precisa escalar.
- Startup buscando captação: investidores fazem due diligence técnica. Tech debt visível afeta valuation e pode travar uma rodada.
A relação com OKRs é direta: incluir "redução de tech debt" como Key Result em OKRs técnicos — com métricas mensuráveis como "reduzir tempo de deploy de 40min para 10min" — é o que garante que a dívida seja paga de forma sistemática, não esquecida.
Modernize sua stack e reduza tech debt com experts full-stack
A RedBlock realiza auditorias técnicas, refatorações e modernizações de codebase — de monolitos para arquiteturas escaláveis, CI/CD, testes automatizados e infraestrutura como código.