El Priorizador de Deuda Técnica: Convierte una Pila de Problemas Conocidos en un Backlog Clasificado
Por qué importa este prompt
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 qué lo 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.
Todo equipo de ingeniería tiene un backlog de deuda técnica en el que nadie confía del todo. Los elementos se añaden cuando algo molesta a alguien, y se priorizan de la misma forma — por antigüedad de la queja, no por riesgo real. Ese enfoque produce de forma fiable un trimestre entero dedicado a arreglar una molestia menor mientras el sistema más propenso a causar la próxima caída permanece intacto, porque nadie lo puntuó nunca contra nada concreto.
Este prompt obliga a una ronda de puntuación estructurada sobre cada elemento del backlog antes de tomar ninguna decisión de priorización. Usa cuatro dimensiones — radio de impacto, probabilidad de incidente, coste de demora y esfuerzo — precisamente porque esas cuatro juntas capturan lo que “prioridad” significa realmente en un sistema en producción, y ninguna de ellas se corresponde directamente con lo molesto que resulta un problema para el ingeniero que tiene que lidiar con él a diario.
Por qué cuatro dimensiones, no una puntuación
Un simple campo de “prioridad: alta/media/baja” colapsa demasiada información para ser útil, y además es el campo más vulnerable a quien más alto hable en la reunión de planificación. Dividir la puntuación en radio de impacto (cuántos sistemas o usuarios están expuestos), probabilidad de incidente (cuán probable es que este elemento concreto falle realmente, dado lo que se lanzará después), coste de demora (si el problema empeora cuanto más tiempo permanezca) y esfuerzo (lo que realmente cuesta arreglarlo) obliga a que cada argumento de clasificación se plantee en esos términos específicos. “Esto realmente me molesta” no encaja en ninguna de las cuatro casillas, que es justamente el punto.
Por qué importa la vía de escape para lo ineludible
No todos los riesgos deberían clasificarse frente al esfuerzo. Un error de cumplimiento o integridad de datos que ocurre raramente pero causa daño real cada vez que se dispara no debería perder ante un elemento de mayor probabilidad pero menor gravedad solo porque las matemáticas salgan así. El prompt separa explícitamente estos casos en una categoría de arreglo ineludible que se salta la lista clasificada, porque mezclarlos en una puntuación compuesta infla la urgencia aparente de todos los demás elementos o entierra una responsabilidad real bajo un montón de quejas de rendimiento menores.
Por qué la honestidad del esfuerzo es una restricción separada
Las estimaciones de esfuerzo para la deuda técnica son frecuentemente conjeturas disfrazadas de números, y un equipo que trata una estimación conjeturada de tres días igual que una estimación de tres días verificada en el código termina desbordando la capacidad del sprint por razones que nadie puede rastrear. Obligar al modelo a señalar qué estimaciones son fiables frente a aproximadas mantiene la honestidad de la salida sobre lo que realmente sabe.
Cómo usar la salida
Lleva la tabla clasificada y el aviso de arreglos ineludibles directamente a la planificación del sprint. El límite estricto de cinco elementos por trimestre no es arbitrario — está ahí para forzar una decisión de compromiso real en lugar de un backlog que crece cada sprint sin que realmente se arregle nada.