O Priorizador de Dívida Técnica: Transforme uma Pilha de Problemas Conhecidos em um Backlog Classificado
Porque é que este prompt importa
Teams that prioritize tech debt by gut feeling or by whoever complained most recently routinely spend a full quarter fixing a low-impact annoyance while the actual system most likely to cause the next outage sits untouched for another two quarters, because nobody scored it against anything concrete.
Para que o usamos
A tech lead has 40 open technical debt tickets accumulated over a year, a sprint planning meeting in two hours, and no agreed-upon method for deciding which 5 items the team will actually commit to fixing this quarter instead of just the ones the loudest engineer complained about last.
Prompt
Act as a staff engineer who specializes in technical debt triage and has to defend every prioritization decision to both engineering leadership and the business side, not just to other engineers. Context: - Team size and sprint capacity: [TEAM SIZE AND STORY POINTS OR HOURS AVAILABLE PER SPRINT] - Known tech debt items: [PASTE YOUR LIST OF TECH DEBT ITEMS, ONE PER LINE, WITH A ONE-SENTENCE DESCRIPTION OF EACH] - Roadmap context: [WHAT THE TEAM IS SHIPPING IN THE NEXT 1-2 QUARTERS, SO WE KNOW WHICH SYSTEMS WILL SEE THE MOST CHANGE OR LOAD] - Incident history: [ANY OUTAGES, SEV1/SEV2 INCIDENTS, OR CUSTOMER ESCALATIONS THAT TRACE BACK TO ANY OF THESE ITEMS, IF KNOWN] Task: For each tech debt item, score it on four dimensions using a 1-5 scale and produce a single composite score: 1. Blast radius - how many systems, teams, or customers would be affected if this item causes a failure 2. Incident probability - how likely this item is to cause a production incident in the next two quarters, given the roadmap context above 3. Cost of delay - how much more expensive or risky this item becomes the longer it's left unaddressed (interest accrual, not just current pain) 4. Effort to fix - estimated engineering time, flagged clearly as either a confident estimate (based on reading the actual code or system) or a rough guess Then rank all items by composite score and draw a clear line recommending the top items that fit within the stated sprint capacity for this quarter. Constraints: - Recommend no more than 5 items for this quarter's commitment, regardless of how many items are on the list - Any item with a safety, data-integrity, or compliance dimension must be flagged as a must-fix regardless of its composite score, and called out separately from the ranked list - Do not let "this annoys me as an engineer" stand in for blast radius or incident probability - every score needs a one-sentence justification tied to actual system behavior or business impact - If effort estimates are guesses rather than informed by code inspection, say so explicitly rather than presenting false precision Output format: A markdown table with columns: Item | Blast Radius (1-5) | Incident Probability (1-5) | Cost of Delay (1-5) | Effort (1-5, lower is less effort) | Composite Score | Recommendation (Fix this quarter / Defer / Must-fix regardless of score) Followed by a short narrative (3-4 sentences per item) explaining the reasoning for the top 3 recommended items, and a separate callout box listing any must-fix safety/compliance items that bypass the ranking entirely.
Resultado
| Item | Blast Radius | Incident Probability | Cost of Delay | Effort | Composite | Recommendation |
|---|---|---|---|---|---|---|
| Auth service still on sync HTTP calls to 3 downstream services, no circuit breaker | 5 | 4 | 5 | 3 | 17 | Fix this quarter |
| Legacy billing cron job has no idempotency key, double-charges on retry | 4 | 3 | 4 | 2 | 13 | Must-fix regardless (compliance/financial risk) |
| Admin dashboard still uses deprecated internal API v1, scheduled for shutdown in 5 months | 2 | 5 | 3 | 3 | 13 | Fix this quarter |
| Test suite takes 47 minutes, no parallelization | 2 | 1 | 2 | 4 | 9 | Defer |
| Inconsistent error logging format across 6 microservices | 2 | 1 | 2 | 2 | 7 | Defer |
Why the top 3
Auth service sync calls (score 17): This is the clearest must-fix for pure risk reasons. With three downstream dependencies and no circuit breaker, a single slow dependency degrades login for the entire platform, and the roadmap shows two new services calling into auth next quarter, which only raises the odds of a cascading timeout. Effort is a confident estimate at 3 because the team already scoped this during the Q2 reliability review.
Billing cron double-charge bug: This bypasses the ranking entirely and goes in the must-fix box. A double-charge is a compliance and trust issue regardless of how rarely the retry path triggers; probability of occurrence doesn't matter when the downside is a refund process and a support escalation every time it fires.
Admin dashboard on deprecated API v1: Incident probability is scored a 5 specifically because the shutdown date is fixed and known — this isn't a maybe, it's a scheduled failure if untouched. Blast radius is lower than the auth item because only internal admin users are affected, which is why it ranks third despite the certain failure date.
Must-fix callout: Billing cron idempotency bug — financial and compliance exposure independent of composite score. Recommend assigning to this sprint even if it displaces one of the ranked items above.
Toda equipe de engenharia tem um backlog de dívida técnica em que ninguém confia totalmente. Itens são adicionados quando algo incomoda alguém, e são priorizados da mesma forma — pela recência da reclamação, não pelo risco real. Essa abordagem produz de forma confiável um trimestre inteiro gasto corrigindo um incômodo menor enquanto o sistema mais propenso a causar a próxima queda permanece intocado, porque ninguém nunca o pontuou contra nada concreto.
Este prompt força uma rodada de pontuação estruturada em cada item do backlog antes de qualquer decisão de priorização. Ele usa quatro dimensões — raio de impacto, probabilidade de incidente, custo de atraso e esforço — precisamente porque essas quatro juntas capturam o que “prioridade” realmente significa em um sistema de produção, e nenhuma delas se mapeia diretamente para o quão incômodo um problema parece para o engenheiro que precisa contorná-lo diariamente.
Por que quatro dimensões, não uma pontuação única
Um simples campo “prioridade: alta/média/baixa” colapsa informação demais para ser útil, e também é o campo mais vulnerável a quem fala mais alto na reunião de planejamento. Dividir a pontuação em raio de impacto (quantos sistemas ou usuários estão expostos), probabilidade de incidente (quão provável é que este item específico realmente falhe, dado o que será lançado a seguir), custo de atraso (se o problema piora quanto mais tempo permanece) e esforço (o que realmente custa corrigi-lo) força cada argumento de classificação a ser feito nesses termos específicos. “Isso realmente me incomoda” não se encaixa em nenhuma das quatro caixas, que é exatamente o objetivo.
Por que a válvula de escape para correções obrigatórias importa
Nem todo risco deveria ser classificado contra o esforço. Um bug de conformidade ou integridade de dados que ocorre raramente mas causa dano real sempre que acionado não deveria perder para um item de maior probabilidade mas menor gravidade só porque a matemática funciona assim. O prompt separa explicitamente esses casos em uma categoria de correção obrigatória que ignora a lista classificada, porque misturá-los em uma pontuação composta infla a urgência aparente de todos os outros itens ou enterra uma responsabilidade real sob uma pilha de reclamações de desempenho menores.
Por que a honestidade sobre esforço é uma restrição separada
Estimativas de esforço para dívida técnica são frequentemente suposições disfarçadas de números, e uma equipe que trata uma estimativa de três dias baseada em suposição como uma estimativa de três dias verificada no código acaba excedendo a capacidade do sprint por razões que ninguém consegue rastrear. Forçar o modelo a sinalizar quais estimativas são confiáveis versus aproximadas mantém a saída honesta sobre o que ela realmente sabe.
Como usar a saída
Leve a tabela classificada e o aviso de correções obrigatórias diretamente para o planejamento do sprint. O limite rígido de cinco itens por trimestre não é arbitrário — ele existe para forçar uma decisão de compromisso real em vez de um backlog que cresce a cada sprint sem que nada seja realmente corrigido.