--- name: mohitagw15856/technical-debt-register source: https://app.decimal.ai/s/mohitagw15856-technical-debt-register@3/SKILL.md source_sha256: e6b41d77cf1f --- # Skill de Registro de Deuda Técnica Produce un registro completo de deuda técnica para un equipo o servicio. Un registro de deuda no es una lista de quejas — es un inventario priorizado y consciente del impacto empresarial que permite a un equipo de ingeniería tomar decisiones deliberadas sobre qué deuda pagar, en qué orden y con qué retorno esperado. Una buena gestión de deuda no es eliminar toda la deuda. Es asegurar que la deuda sea visible, asignada y resuelta cuando el costo de los intereses supera el costo de arreglarlo. ## Entradas Requeridas Solicita estas si aún no se han proporcionado: - **Nombre del equipo o servicio** — qué equipo y/o servicio cubre este registro - **Elementos de deuda conocidos** — lista de deuda técnica conocida, o solicita a Claude que los extraiga preguntando sobre: código heredado, pruebas faltantes, dependencias desactualizadas, atajos arquitectónicos, procesos manuales, brechas de observabilidad, backlogs de seguridad - **Stack técnico** — lenguaje, frameworks, infraestructura (ayuda a Claude a categorizar y calificar elementos correctamente) - **Tamaño del equipo y velocidad** — número de ingenieros y aproximadamente story points o días por sprint (necesario para estimar esfuerzos) - **Trimestre actual / período de planificación** — para que la hoja de ruta se enfoque en el marco de tiempo correcto ## Formato de Salida --- # Registro de Deuda Técnica: [Nombre del Equipo / Servicio] **Equipo:** [Nombre] | **Servicio(s):** [Nombre(s)] **Autor:** [Nombre] | **Última actualización:** [Fecha] **Período de planificación:** [Q[X] [Año]] | **Cadencia de revisión:** [Mensual / Trimestral] --- ## Descripción General [2–3 oraciones describiendo la situación actual de deuda del equipo, las categorías principales de deuda y el contexto empresarial — ej. ¿están en una fase de crecimiento donde la velocidad es importante, o acercándose a una fecha límite de cumplimiento donde la deuda de seguridad es crítica?] **Total de elementos en el registro:** [X] **Elementos sin resolver:** [X] **Elementos críticos/Alta prioridad:** [X] **Esfuerzo total estimado de resolución:** [X story points / X semanas de ingeniero] --- ## Definiciones de Categoría de Deuda | Categoría | Descripción | Ejemplos | |---|---|---| | **Calidad del código** | Código que funciona pero es difícil de cambiar de forma segura | Lógica duplicada, condicionales profundamente anidados, manejo de errores inconsistente, abstracción faltante | | **Arquitectura** | Decisiones estructurales que limitan la escalabilidad o aumentan el acoplamiento | Monolito que debería descomponerse, llamadas síncronas que deberían ser asincrónicas, límites de dominio faltantes | | **Pruebas** | Brechas en cobertura de pruebas que aumentan el riesgo de regresión | Pruebas unitarias faltantes, sin pruebas de integración, suite de pruebas inestable, sin gestión de datos de prueba | | **Seguridad** | Vulnerabilidades conocidas o controles de seguridad faltantes | Dependencias desactualizadas con CVEs, limitación de tasas faltante, secretos codificados, autenticación insuficiente | | **Dependencias** | Dependencias externas desactualizadas o riesgosas | Librerías de fin de vida, retraso de versión principal, paquetes abandonados | | **Infraestructura** | Infraestructura que limita la confiabilidad o productividad del desarrollador | Pasos de implementación manual, sin IaC, zona única de disponibilidad, escalado automático faltante | | **Observabilidad** | Brechas en visibilidad que ralentizan la respuesta ante incidentes | Métricas faltantes, sin trazado distribuido, estructura de registros pobre, sin alertas en SLIs clave | | **Proceso** | Procesos operacionales manuales o propensos a errores | Migraciones de BD manuales, sin runbooks, conocimiento tribal no documentado | --- ## Registro de Deuda Técnica ### Método de Puntuación **Impacto empresarial (1–5):** - 5 — Bloqueando crecimiento, causando incidentes en producción o creando riesgo de cumplimiento - 4 — Ralentizando significativamente la entrega o aumentando la probabilidad de incidentes - 3 — Desaceleración notable; manejable pero acumulándose - 2 — Fricción menor; bajo riesgo inmediato - 1 — Cosmético o aspiracional; sin impacto empresarial actual **Esfuerzo para resolver (1–5, menor = más fácil):** - 1 — <0.5 día; ingeniero único - 2 — 0.5–2 días; ingeniero único - 3 — 3–5 días; ingeniero único o par pequeño - 4 — 1–2 semanas; colaboración de equipo requerida - 5 — >2 semanas; planificación y coordinación significativa **Puntuación de prioridad = Impacto empresarial × (6 − Esfuerzo)** *(recompensa a elementos de alto impacto y bajo esfuerzo)* --- | ID | Elemento | Categoría | Impacto empresarial (1–5) | Esfuerzo (1–5) | Puntuación de prioridad | Estado | Propietario | |---|---|---|---|---|---|---|---| | TD-001 | [ej. Sin pruebas de integración para flujo de pago] | Pruebas | 5 | 3 | 15 | Abierto | [Nombre] | | TD-002 | [ej. Biblioteca de autenticación 3 versiones principales atrás] | Seguridad | 5 | 2 | 20 | Abierto | [Nombre] | | TD-003 | [ej. Consultas de base de datos sin usar agrupación de conexiones] | Arquitectura | 4 | 2 | 16 | Abierto | [Nombre] | | TD-004 | [ej. Proceso de implementación manual para [servicio]] | Infraestructura | 4 | 3 | 12 | En progreso | [Nombre] | | TD-005 | [ej. Función Dios de 200 líneas en procesamiento de pedidos] | Calidad del código | 3 | 3 | 9 | Abierto | [Nombre] | | TD-006 | [ej. Sin registros estructurados — solo texto plano] | Observabilidad | 3 | 2 | 12 | Abierto | [Nombre] | | TD-007 | [ej. Versión de ORM tiene problema de consulta N+1 conocido] | Dependencias | 3 | 3 | 9 | Abierto | [Nombre] | | TD-008 | [ej. Sin runbook para [operación crítica]] | Proceso | 3 | 1 | 15 | Abierto | [Nombre] | | TD-009 | [ej. Cobertura de pruebas al 34% — sin red de seguridad significativa] | Pruebas | 4 | 4 | 8 | Abierto | [Nombre] | | TD-010 | [ej. Valores de configuración codificados en el código de aplicación] | Calidad del código | 2 | 1 | 10 | Abierto | [Nombre] | | TD-011 | [ej. Servicio implementado en zona única de disponibilidad sin conmutación] | Infraestructura | 5 | 4 | 10 | Abierto | [Nombre] | | TD-012 | [ej. Sin alertas en latencia P95 para [endpoint]] | Observabilidad | 4 | 1 | 20 | Abierto | [Nombre] | --- ## Desglose por Categoría ``` Distribución de categorías (por número de elementos): ───────────────────────────────────────────── Calidad del código ████████░░ [X elementos] ([X]%) Arquitectura ██████░░░░ [X elementos] ([X]%) Pruebas █████████░ [X elementos] ([X]%) Seguridad ████░░░░░░ [X elementos] ([X]%) Dependencias ███░░░░░░░ [X elementos] ([X]%) Infraestructura ████░░░░░░ [X elementos] ([X]%) Observabilidad ████░░░░░░ [X elementos] ([X]%) Proceso ██░░░░░░░░ [X elementos] ([X]%) ───────────────────────────────────────────── Distribución de prioridad: Crítico (puntuación 20–25): [X elementos] Alto (puntuación 12–19): [X elementos] Medio (puntuación 6–11): [X elementos] Bajo (puntuación 1–5): [X elementos] ``` --- ## Top 5 Elementos Prioritarios — Planes de Resolución ### TD-XXX: [Nombre del elemento de máxima prioridad] **Puntuación de prioridad:** [Puntuación] | **Categoría:** [Categoría] | **Propietario:** [Nombre] **Problema:** [2–3 oraciones describiendo cuál es la deuda, cómo se manifiesta y qué dolor causa actualmente. Sé específico — haz referencia a incidentes reales, desaceleraciones o riesgos.] **Impacto empresarial:** [Qué sucede si esto no se resuelve? Haz referencia a incidentes, casi-fallos o bloqueadores de crecimiento. Ej. "Esto causó 2 incidentes en producción en el último trimestre y añade ~30 minutos de depuración a cualquier cambio en esta área."] **Enfoque de resolución:** [Descripción clara de la solución. No "mejorar el código" — describe el trabajo real: "Extrae la lógica de procesamiento de pagos en una clase `PaymentService` dedicada, escribe pruebas unitarias al 80% de cobertura y actualiza los 3 sitios de llamada."] **Pasos:** 1. [Paso específico y asignable] 2. [Paso específico y asignable] 3. [Paso específico y asignable] **Criterios de aceptación:** - [ ] [Criterio medible — ej. "Cero valores de configuración codificados permanecen en el código de aplicación"] - [ ] [Criterio medible — ej. "El pipeline de CI pasa con nuevas pruebas"] - [ ] [Criterio medible] **Estimación de esfuerzo:** [X story points / X días] **Sprint sugerido:** [Q[X] Sprint [Y] / Cuando [dependencia] esté completa] --- ### TD-XXX: [Nombre del segundo elemento prioritario] **Puntuación de prioridad:** [Puntuación] | **Categoría:** [Categoría] | **Propietario:** [Nombre] **Problema:** [Descripción] **Impacto empresarial:** [Descripción de impacto] **Enfoque de resolución:** [Descripción de enfoque] **Pasos:** 1. [Paso] 2. [Paso] 3. [Paso] **Criterios de aceptación:** - [ ] [Criterio] - [ ] [Criterio] **Estimación de esfuerzo:** [X story points / X días] **Sprint sugerido:** [Sprint o marco de tiempo] --- ### TD-XXX: [Tercer elemento prioritario] *(Sigue el mismo formato que arriba)* --- ### TD-XXX: [Cuarto elemento prioritario] *(Sigue el mismo formato que arriba)* --- ### TD-XXX: [Quinto elemento prioritario] *(Sigue el mismo formato que arriba)* --- ## Hoja de Ruta de Reducción de Deuda ### Principios Orientadores - Asigna [X%] de la capacidad de cada sprint a resolución de deuda — recomendado 15–20% para equipos saludables - La deuda de seguridad y dependencias se aborda en cadencia fija independientemente de la puntuación de prioridad - Sin nuevo trabajo de características en módulos con deuda Crítica a menos que la deuda esté programada para el sprint actual - Los elementos de deuda cerrados sin resolución (aceptados/diferidos) deben tener un propietario designado y una fecha de revisión ### Plan trimestral | Trimestre | Área de enfoque | Elementos objetivo | Capacidad estimada | Resultado esperado | |---|---|---|---|---| | **[Q1 Año]** (actual) | Seguridad + observabilidad | TD-002, TD-012, TD-006 | [X] points / [Y] días-ing | Biblioteca de autenticación actual; alertas de latencia en vivo; registros estructurados entregados | | **[Q2 Año]** | Arquitectura + confiabilidad | TD-003, TD-011, TD-004 | [X] points / [Y] días-ing | Agrupación de conexiones corregida; multi-AZ implementado; automatización de implementación completa | | **[Q3 Año]** | Cobertura de pruebas | TD-001, TD-009 | [X] points / [Y] días-ing | Pruebas de integración de flujo de pago en vivo; cobertura general ≥60% | | **[Q4 Año]** | Calidad del código + proceso | TD-005, TD-008, TD-010 | [X] points / [Y] días-ing | Funciones Dios refactorizadas; runbooks completos; cero configuración codificada | ### Modelo de asignación de sprint ``` Capacidad de sprint: [X] story points Asignación: ├── Trabajo de características: [X * 0.75 = ~Y] points (75%) ├── Resolución de deuda: [X * 0.15 = ~Y] points (15%) └── No planificado/bugs: [X * 0.10 = ~Y] points (10%) Elementos de deuda que caben en un sprint ([≤Y] points cada uno): ✓ TD-002 ([X] points) ✓ TD-012 ([X] points) ✓ TD-006 ([X] points) ✓ TD-008 ([X] points) Elementos de deuda de múltiples sprints (dividir en fases): ~ TD-001: Fase 1 ([X] pts) → Fase 2 ([X] pts) ~ TD-009: Requiere sprint dedicado de deuda o pareado ``` --- ## Deuda Aceptada / Diferida Elementos donde el costo de remediación actualmente supera el valor empresarial, aceptados con fechas de revisión explícitas. | ID | Elemento | Razón del aplazamiento | Fecha de revisión | Propietario | |---|---|---|---|---| | TD-XXX | [Elemento] | [ej. "La reescritura requeriría 3 semanas sin valor visible al usuario a escala actual; revisar a 10× tráfico"] | [Fecha] | [Nombre] | | TD-XXX | [Elemento] | [ej. "La dependencia tiene CVE pero no existe ruta de actualización hasta Q3; mitigado por regla WAF"] | [Fecha] | [Nombre] | **Política:** Ningún elemento puede aplazarse más de dos veces sin escalación al gerente de ingeniería. --- ## Verificaciones de Calidad - [ ] Cada elemento tiene un propietario designado — sin deuda sin propietario - [ ] Las puntuaciones de prioridad se calculan usando la fórmula, no se asignan arbitrariamente - [ ] Los elementos de seguridad y dependencias no se califican por debajo de su impacto empresarial real porque parecen "técnicos" - [ ] Los planes de resolución de los 5 principales incluyen pasos específicos y asignables — no descripciones vagas como "mejorar cobertura de pruebas" - [ ] La hoja de ruta trimestral asigna capacidad realista — la asignación de deuda no excede el presupuesto real del sprint - [ ] Los elementos aceptados/diferidos tienen una fecha de revisión y un propietario designado — sin elementos permanentemente diferidos - [ ] El registro distingue entre deuda (atajos deliberados o acumulados) y bugs (defectos involuntarios) - [ ] Los elementos se cierran como resueltos solo cuando se cumplen los criterios de aceptación — no cuando se fusiona el PR ## Antipatrones - [ ] No califiques elementos de deuda arbitrariamente — las puntuaciones de prioridad deben calcularse usando la fórmula documentada - [ ] No confundas deuda técnica (atajos deliberados) con bugs (defectos involuntarios) — requieren estrategias de remediación diferentes - [ ] No subestimes elementos de seguridad y dependencias porque parecen abstractos — califica en función del impacto empresarial real - [ ] No crees elementos "permanentemente diferidos" — cada elemento aceptado debe tener una fecha de revisión y propietario designado - [ ] No incluyas planes de resolución que sean descripciones vagas — cada plan debe tener pasos específicos y asignables