8 min leitura • Guide 363 of 877
Priorização de Dívida Técnica
Nem toda dívida técnica é igual. Alguma dívida bloqueia progresso, alguma apenas desacelera coisas, e alguma raramente importa. Boa priorização foca esforço onde cria mais valor. Este guia cobre abordagens práticas para priorizar tech debt.
Matriz de Priorização
| Impacto | Esforço | Prioridade |
|---|---|---|
| Alto | Baixo | Fazer Primeiro |
| Alto | Alto | Planejar Cuidadosamente |
| Baixo | Baixo | Vitórias Rápidas |
| Baixo | Alto | Provavelmente Nunca |
Categorizando Dívida
Tipos de Tech Debt
CATEGORIAS DE DÍVIDA TÉCNICA
════════════════════════════
POR TIPO:
─────────────────────────────────────
Dívida de arquitetura:
├── Problemas de design de sistema
├── Problemas de escalabilidade
├── Complexidade de integração
├── Difícil de refatorar
└── Alto impacto, alto esforço
Dívida de código:
├── Baixa qualidade de código
├── Testes faltando
├── Código duplicado
├── Nomeação confusa
└── Impacto médio, esforço varia
Dívida de infraestrutura:
├── Dependências desatualizadas
├── Ferramentas legadas
├── Processos manuais
├── Preocupações de segurança
└── Prioridade baseada em risco
Dívida de documentação:
├── Docs faltando
├── Informação desatualizada
├── Conhecimento tribal
├── Dor no onboarding
└── Frequentemente negligenciada
POR IMPACTO:
─────────────────────────────────────
Bloqueante:
├── Não consegue entregar features
├── Bugs graves
├── Vulnerabilidades de segurança
└── Deve abordar agora
Desacelerante:
├── Leva mais tempo para desenvolver
├── Bugs frequentes na área
├── Difícil de entender
└── Abordar estrategicamente
Irritante:
├── Frustração do desenvolvedor
├── Ineficiência menor
├── Problemas cosméticos
└── Baixa prioridade
Framework de Avaliação
Avaliando Dívida
AVALIAÇÃO DE DÍVIDA
═══════════════════
CRITÉRIOS DE AVALIAÇÃO:
─────────────────────────────────────
Para cada item de dívida, pontue:
Impacto (1-5):
├── 5: Bloqueia features importantes
├── 4: Desaceleração significativa
├── 3: Fricção perceptível
├── 2: Inconveniência menor
├── 1: Mal percebido
└── Quanto dói?
Frequência (1-5):
├── 5: Toca diariamente
├── 4: Toca semanalmente
├── 3: Toca mensalmente
├── 2: Toca trimestralmente
├── 1: Raramente/nunca
└── Com que frequência encontramos?
Risco (1-5):
├── 5: Vulnerabilidade de segurança
├── 4: Potencial perda de dados
├── 3: Risco de queda de serviço
├── 2: Degradação menor
├── 1: Sem risco
└── O que pode dar errado?
Esforço (1-5):
├── 5: Meses de trabalho
├── 4: Múltiplos sprints
├── 3: Sprint inteiro
├── 2: Poucos dias
├── 1: Horas
└── Quanto vai custar?
PONTUAÇÃO:
─────────────────────────────────────
Score = (Impacto × Frequência × Risco) / Esforço
Maior score = Maior prioridade
Matriz de Decisão
MATRIZ DE PRIORIZAÇÃO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ IMPACTO ALTO IMPACTO BAIXO │
│ ┌────────────────────┬────────────────────┐ │
│ │ │ │ │
│ ESFORÇO│ FAZER AGORA │ QUICK WINS │ │
│ BAIXO │ │ │ │
│ │ - Alto valor │ - Fácil de fazer │ │
│ │ - Fácil │ - Melhora moral │ │
│ │ - Sem desculpas │ - Fazer quando │ │
│ │ │ tiver tempo │ │
│ ├────────────────────┼────────────────────┤ │
│ │ │ │ │
│ ESFORÇO│ PLANEJAR BEM │ NÃO FAZER │ │
│ ALTO │ │ │ │
│ │ - Projeto grande │ - Baixo ROI │ │
│ │ - Precisa buy-in │ - Custo > valor │ │
│ │ - Quebrar em │ - Provavelmente │ │
│ │ partes │ nunca vale │ │
│ │ │ │ │
│ └────────────────────┴────────────────────┘ │
└─────────────────────────────────────────────────────────────┘
Regras de Priorização
O Que Fazer Primeiro
PRIORIZAÇÃO PRÁTICA:
┌─────────────────────────────────────────────────────────────┐
│ │
│ FAZER AGORA (Sprints 1-2): │
│ ───────────────────────── │
│ • Vulnerabilidades de segurança │
│ • Bugs que afetam clientes frequentemente │
│ • Bloqueios para features planejadas │
│ • Dívida em código que será tocado logo │
│ │
│ PLANEJAR (Próximo trimestre): │
│ ───────────────────────────── │
│ • Alto impacto, alto esforço │
│ • Requer coordenação com outras equipes │
│ • Precisa de janela de manutenção │
│ • Benefício de longo prazo │
│ │
│ OPORTUNISTA (Quando conveniente): │
│ ─────────────────────────────── │
│ • Baixo esforço, baixo impacto │
│ • Melhorias "boy scout" durante trabalho relacionado │
│ • Quando já está mexendo no código │
│ │
│ IGNORAR (Provavelmente nunca): │
│ ──────────────────────────── │
│ • Código que nunca muda │
│ • Sistemas sendo substituídos │
│ • Impacto teórico apenas │
│ • Custo muito maior que benefício │
└─────────────────────────────────────────────────────────────┘
Regra do Código Quente
REGRA DO CÓDIGO QUENTE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ "Priorize dívida em código frequentemente modificado" │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ CÓDIGO QUENTE: │
│ Modificado frequentemente │
│ → Dívida aqui tem alto impacto │
│ → Priorizar refatoração │
│ │
│ CÓDIGO FRIO: │
│ Raramente ou nunca modificado │
│ → Dívida aqui raramente importa │
│ → Deixar quieto │
│ │
│ EXEMPLO: │
│ │
│ Módulo A: Modificado 50x/mês, dívida de nível 3 │
│ Módulo B: Modificado 2x/mês, dívida de nível 5 │
│ │
│ → Priorize Módulo A apesar de dívida "menor" │
│ porque impacto é maior no dia-a-dia │
└─────────────────────────────────────────────────────────────┘
Alocando Tempo para Dívida
Estratégias de Alocação
ESTRATÉGIAS DE TEMPO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ OPÇÃO 1: PERCENTUAL FIXO │
│ ──────────────────────── │
│ 15-20% de cada sprint para tech debt │
│ │
│ Sprint de 40 pontos: │
│ • 32-34 pontos para features │
│ • 6-8 pontos para tech debt │
│ │
│ Vantagem: Consistente, previsível │
│ Desafio: Pode ser difícil medir │
│ │
│ OPÇÃO 2: SPRINT DEDICADO │
│ ──────────────────────── │
│ 1 sprint por trimestre dedicado a tech debt │
│ │
│ Vantagem: Foco total, mudanças maiores possíveis │
│ Desafio: 3 meses sem manutenção entre sprints │
│ │
│ OPÇÃO 3: REGRA BOY SCOUT │
│ ───────────────────────── │
│ "Deixe o código melhor do que encontrou" │
│ │
│ Pequenas melhorias durante trabalho normal │
│ Vantagem: Contínuo, sem overhead de planejamento │
│ Desafio: Só pega dívida pequena │
│ │
│ RECOMENDAÇÃO: Combine todas │
│ • 10-15% fixo por sprint │
│ • Sprint de deep clean trimestral │
│ • Boy scout sempre │
└─────────────────────────────────────────────────────────────┘
Priorizando no GitScrum
Gerenciando Backlog de Dívida
| Tag | Significado | Ação |
|---|---|---|
| #debt-critical | Bloqueia progresso | Próximo sprint |
| #debt-high | Impacto significativo | Este trimestre |
| #debt-medium | Impacto moderado | Quando conveniente |
| #debt-low | Baixo impacto | Oportunista |
Dashboard de Dívida
VISUALIZANDO PRIORIDADES NO GITSCRUM:
┌─────────────────────────────────────────────────────────────┐
│ │
│ DÍVIDA TÉCNICA - PRIORIZAÇÃO │
│ │
│ CRÍTICA (fazer agora): │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ DEBT-001 Vulnerabilidade em bcrypt | Score: 48 ││
│ │ DEBT-007 Leak de memória em jobs | Score: 42 ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ ALTA (este trimestre): │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ DEBT-002 Migrar para OAuth | Score: 32 ││
│ │ DEBT-004 Refatorar API pagamentos | Score: 28 ││
│ │ DEBT-009 Atualizar React para v18 | Score: 24 ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ MÉDIA (quando possível): │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ DEBT-003 Aumentar cobertura de testes | Score: 15 ││
│ │ DEBT-005 Documentar API interna | Score: 12 ││
│ │ DEBT-011 Melhorar logs | Score: 10 ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ BAIXA (provavelmente ignorar): │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ DEBT-008 Refatorar módulo legado | Score: 4 ││
│ │ (será substituído em Q3) ││
│ └─────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────┘
Erros Comuns
O Que Evitar
ANTI-PADRÕES DE PRIORIZAÇÃO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ✗ CORRIGIR TUDO │
│ Tentar eliminar toda dívida │
│ → Foque em ROI, não perfeição │
│ │
│ ✗ IGNORAR TUDO │
│ "Não temos tempo para tech debt" │
│ → Dívida só cresce, eventualmente paralisa │
│ │
│ ✗ PRIORIZAR POR BARULHO │
│ Quem reclama mais ganha │
│ → Use dados e frameworks objetivos │
│ │
│ ✗ GOLD PLATING │
│ Refatorar código perfeito │
│ → Foque onde há dor real │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ ✓ BOAS PRÁTICAS: │
│ │
│ • Use dados para priorizar │
│ • Balanceie curto e longo prazo │
│ • Invista consistentemente │
│ • Reavalie regularmente │
│ • Comunique trade-offs │
└─────────────────────────────────────────────────────────────┘