A Matriz de Priorização de Technical Debt

Os backlogs de technical debt costumam morrer de duas formas: ou cada item é marcado como "crítico" pelo engenheiro mais irritado com ele, ou a lista é ignorada por completo porque ninguém consegue traduzir "esse módulo não tem cobertura de testes" em algo que um gerente de produto ou um CFO vá financiar. Este prompt força uma etapa de pontuação por impacto nos negócios antes de qualquer sequenciamento de remediação, de modo que o plano resultante sobrevive a uma conversa de roadmap com pessoas que não são da área técnica na sala.

Por que cada seção do prompt existe

Papel: O prompt atribui à AI a perspectiva de um líder de engenharia que precisa defender um roadmap de remediação para um CFO e um VP de Produto na mesma reunião — e não apenas de um engenheiro sênior revisando qualidade de código. Esse enquadramento importa porque um revisor puramente técnico vai classificar os itens por elegância e correção; já um líder responsável tanto pelo orçamento quanto pela entrega os classifica pelo que de fato prejudica o negócio.

Contexto: O prompt solicita a capacidade atual do sprint do seu time e as prioridades atuais do negócio (crescimento, estabilidade, redução de custos) porque o mesmo item de technical debt tem classificações diferentes dependendo do que a organização está otimizando no momento. Uma startup em fase de escala e uma empresa em um trimestre de estabilidade não deveriam receber o mesmo resultado de priorização a partir da mesma lista de débitos.

Tarefa: Cada item de technical debt é pontuado em quatro dimensões — arrasto na entrega (o quanto ele atrasa trabalhos futuros de funcionalidades), risco de incidente (com que frequência ele está implicado em problemas em produção), exposição de receita/clientes e custo de remediação — em vez de uma única avaliação vaga de "severidade", porque uma pontuação única colapsa tradeoffs distintos em um número com o qual ninguém consegue concordar ou discordar.

Restrições: O prompt proíbe explicitamente "é só fazer refactor em tudo" como resultado e exige que o plano respeite a capacidade de sprint declarada, porque um exercício de priorização que recomenda mais trabalho do que o time consegue absorver não é um plano — é uma lista de desejos.

Formato de saída: O resultado é uma tabela ranqueada (e não texto corrido), especificamente para que possa ser inserida em um deck de revisão de roadmap sem trabalho adicional de formatação, seguida de uma justificativa em linguagem simples, em um único parágrafo, para os 3 itens principais — algo que um stakeholder não técnico consiga de fato ler e aprovar.

O prompt

Act as an engineering leader who needs to defend a technical debt remediation roadmap to a CFO and a VP of Product in the same meeting.

CONTEXT:
- Our team's available capacity for debt remediation next quarter: [E.G. "1 engineer, 20% time" OR "2 sprints total"]
- Current business priority: [GROWTH / STABILITY / COST-CUTTING]
- Raw list of known technical debt items: [PASTE YOUR LIST — one item per line, however informal]

TASK:
For each debt item, score it 1-5 on each of these four dimensions:
1. Delivery drag — how much does this slow down future feature work in the affected area?
2. Incident risk — how often is this implicated in production issues, outages, or urgent fixes?
3. Revenue/customer exposure — does this affect paying customers, SLAs, or revenue-generating flows directly?
4. Remediation cost — how much effort would fixing this actually take (5 = very cheap, 1 = very expensive)?

Then compute a priority score and rank all items.

CONSTRAINTS:
- Do not recommend more remediation work than the stated capacity allows — sequence items into what actually fits.
- Do not treat all debt as equally urgent — explicitly deprioritize items that score low on both delivery drag and incident risk, even if they're technically embarrassing.
- Justify the top 3 items in plain English a non-engineer could read and approve without a glossary.

OUTPUT FORMAT:
1. Scored Table: Item | Delivery Drag | Incident Risk | Revenue Exposure | Remediation Cost | Priority Score
2. Recommended Sequence: which items fit in the stated capacity, in order
3. Plain-English Justification: 1 paragraph per top-3 item, written for a non-technical stakeholder

Como o resultado realmente se parece

Para um time com capacidade de "1 engenheiro, 20% do tempo" em um trimestre de CRESCIMENTO, dada uma lista bruta que inclui "sem cobertura de testes no serviço de checkout", "tokens de autenticação não expiram", "o dashboard de relatórios consulta diretamente o banco de dados primário" e "nosso script de deploy tem três etapas manuais que alguém sempre esquece", um resultado típico seria:

Conclusões práticas

• Execute este prompt antes do seu próximo ciclo de planejamento, não durante ele — a conversa de pontuação traz à tona divergências sobre prioridade de negócio que são mais bem resolvidas antes de a capacidade ser alocada, e não no meio de uma reunião acalorada de roadmap.
• Use as justificativas em linguagem simples literalmente ao solicitar orçamento ou headcount — elas foram construídas especificamente para sobreviver a um público não técnico sem que você precise traduzir na hora.
• Reexecute o prompt sempre que a prioridade declarada do negócio mudar (de crescimento para estabilidade, por exemplo) — a mesma lista de débitos deve produzir uma sequência significativamente diferente; se não produzir, os parâmetros de pontuação precisam ser revisados.
• Não pule a etapa de despriorização explícita — uma lista de débitos em que tudo é "importante" é a razão mais comum pela qual os roadmaps de remediação nunca sobrevivem ao contato com um sprint real.