Cómo identificar y gestionar la deuda técnica en proyectos de software

¿Quieres que tu equipo deje de temer los viernes por la noche? Entonces presta atención: la deuda técnica no es un problema técnico, es un problema comercial disfrazado de código.

Tiempo estimado de lectura: 6 min

Introducción

Poca gente habla claro sobre esto. Todos hablan de “refactorizar” como si fuera una pócima mágica. Nadie te dice que hay que pagar esas facturas en cuotas, con interés, y con plan.

Voy a contarte cómo identificarla, cuándo pagarla, cómo priorizarla y, sobre todo, cómo evitar que se convierta en una morgue de proyectos. No es teoría: es un manual de supervivencia para equipos que quieren seguir entregando valor sin enterrarse en yeso.

Resumen rápido (lectores con prisa)

Deuda técnica: decisión que acelera hoy y encadena mañana. Mide impacto en negocio, reserva presupuesto en cada sprint, prioriza por ROI y aplica mejoras incrementales (Boy Scout + Strangler).

¿Qué es la deuda técnica, de verdad?

No es solo código feo o tests faltantes. Es cualquier decisión que acelera hoy y te encadena mañana.

Pedir velocidad a cambio de calidad es pedir un préstamo. Si sabes que lo pides, es deuda deliberada. Si lo hiciste por ignorancia, es otra cosa — y merece formación, no romántica metáfora.

La deuda tiene un interés: cada cambio posterior será más lento. Cada bug será más caro. Cada onboarding tomará más tiempo. Y cuando llegue la crisis, el interés se come tu ritmo de entrega.

Cómo suena la deuda en la sala de engineering

Frases que delatan deuda

• “No lo toques, no vaya a romper algo” — frase clásica.
• “Los rollouts se hacen los lunes por la mañana” — signo de miedo.
• “Necesitamos 3 semanas para entender esto” — onboarding fallando.

Si tu equipo dice estas frases, tienes deuda. Si además las frases salen con cara de resignación, tienes un problema estratégico.

Tipos que importan (y cómo tratarlos)

No todas las deudas se pagan igual.

1) Deuda deliberada y prudente

• Lo haces con los ojos abiertos.
• Ejemplo: lanzar un MVP sin caché óptimo para validar mercado.
• Cómo pagarlo: ticket en backlog, plazo definido, regla de “no crecer la superficie sin pagar”.

2) Deuda deliberada y temeraria

• Se hace por presión sin plan.
• Ejemplo: copiar-pegar soluciones, no tests, no CI.
• Cómo pagarlo: es urgente. Priorizar mitigación, pruebas, y quizá revertir la decisión de negocio si falla.

3) Deuda inadvertida

• Por falta de conocimiento o negligencia.
• Ejemplo: código espagueti porque nadie revisa PRs.
• Cómo pagarlo: formación, pair programming, código con owners claros.

4) Deuda evolución/tecnológica

• Dependencias sin actualizar, plataformas obsoletas.
• Cómo pagarlo: calendarizar upgrades por riesgo, no por fecha bonita.

Síntomas que deberían encender una alarma

No lo adivines: mide. Estos son síntomas que indican bancarrota técnica:

• Deployments con sudor frío y rollback semanal.
• PRs que duran semanas por complejidad.
• Reducción dramática de la velocidad del equipo sin razón aparente.
• Regresiones frecuentes donde arreglas una cosa y rompes tres.
• Tests que mienten o tardan horas en ejecutarse.

Si ves dos o más, levanta la bandera y para la próxima feature hasta tener plan de pago.

Estrategias que funcionan (no cuentos)

Olvídate de “vamos a parar todo y reescribir”. Eso solo suena bien en presentaciones.

La estrategia que funciona es incremental y política. Aquí las más efectivas:

Regla del Boy Scout

Deja el campamento un poco más limpio. Si tocas un archivo, arréglalo: renombra, añade un test, extrae funciones. Pequeñas mejoras constantes suman.

Presupuesto técnico en cada sprint

Reserva un % fijo del capacity (10–25%). Lo ideal depende de tu contexto. Si estás en hypergrowth, sube al 20%. Si estás estable, 10% puede bastar.

Tickets visibles y priorizados

La deuda que no está en el backlog no existe. Traduce deuda en tickets claros con impacto de negocio (tiempo de dev, riesgo, seguridad). Prioriza igual que features.

El patrón Strangler (reconstrucción por partes)

No reescribas el monolito. Construye nuevo alrededor y estrangula lo viejo. Migración por capas, desvío de tráfico y pruebas A/B hasta que lo antiguo deje de respirar.

Writer único para datos críticos

Si la deuda viene de concurrencia en escritura (bases, archivos), centraliza el writer. Evita múltiples procesos escribiendo el mismo artefacto.

Tests donde duela

No necesitas 100% coverage. Necesitas tests donde duele: integración crítica, pagos, seguridad y puntos con historial de fallos.

Checklist para Tech Leads (haz que te obedezcan)

Un listado que puedes imponer como política sin sermones:

1. Cada PR > 200 LOC exige refactor simple o tests.
2. Problema no documentado → no merge.
3. Sprint: 15% de capacidad para deuda técnica.
4. Métricas públicas: tiempo de build, tiempo de despliegue, tasa de rollback.
5. Owners claros: cada módulo con responsable técnico.
6. Registro de decisiones técnicas (ADR) obligatorio.

Cómo priorizar: regla del ROI técnico

No pagues lo que no frena tu negocio. Pregunta: ¿esta deuda impide ventas, seguridad o escalabilidad inmediata?

Prioriza por:

• Impacto en cliente (bugs críticos).
• Riesgo de seguridad o cumplimiento.
• Tiempo que retrasa nuevas features.
• Coste de mantenimiento actual (horas/semana).

Haz una matriz rápida: impacto vs esfuerzo. Ataca primero lo alto-impacto/bajo-esfuerzo.

Evolución de personajes: el equipo, la feature y el legacy

Imagina una escena: la feature (entusiasmada) quiere salir al mercado. El legacy (cansado) susurra “no me toques”. El equipo (dividido) corre para lanzar.

Con el plan correcto, la feature sale, el equipo aprende y el legacy muere por asfixia controlada. Sin plan, la feature se convierte en otro parche que alimenta más deuda. La clave es dirigir la narrativa: que la feature evolucione, no que se enrede.

Casos prácticos: qué hacer hoy mismo

No necesitas permiso del CEO para estas acciones:

1. Haz un sprint de diagnóstico (1 semana).
   • Recolecta métricas: tiempo CI, fallos, PR cycle.
   • Lista top 10 hotspots (archivos o módulos más cambiados/rotos).
2. Empieza con 3 quick wins.
   • Añade tests en módulos críticos.
   • Elimina imports duplicados y variables globales peligrosas.
   • Automatiza un job de lint/format en CI.
3. Define owner por módulo.
   • Asigna y documenta quien manda sobre cada componente.
4. Programa un mes de mejoras
   • Plan de 4 semanas: cada semana 1 objetivo de deuda con entregable claro.

Herramientas y métricas que realmente importan

No más dashboards bonitos que no sirven.

• MTTR (Mean Time To Recovery): si sube, hay deuda.
• Tiempo medio de PR (days): cuando sube, complejidad.
• Tasa de rollback: fricción operativa.
• Coverage en paths críticos: no porcentaje general.
• Tiempo de build y test: si CI crece, la velocidad muere.

Cómo vender el pago de deuda al negocio (el argumento que funciona)

No hables en técnico. Habla en riesgo, dinero y velocidad.

• “Invertir X horas reduce tiempo de entrega de features en Y% y fallos en Z%”.
• Muestra casos: “Reducimos rollbacks en 70% y ganamos N horas de dev/mes”.
• Propón un plan con milestones y rollback: “Si no vemos mejora en 3 sprints, revertimos la política”.

Cuándo sí reescribir (y cuándo no)

Reescribir es una opción legítima. Pero sólo cuando:

• La base de código es inentendible y ralentiza todo por encima del 50%.
• Hay problemas legales o de seguridad que no se pueden parchear.
• La plataforma actual impide crear valor competitivo.

Si no, aplica strangler. Reescribir por ego o miedo es receta de desastre.

Errores comunes que deberías evitar

• No documentar la deuda: desaparece y vuelve peor.
• Pay only when there are fires. (Pagar sólo cuando hay incendios.)
• Pensar que QA soluciona deuda: QA encuentra errores, no reestructura código.
• Ignorar la deuda cultural: sin code reviews, la deuda vuelve.

Metáfora que pega: la deuda como jardín

La deuda es jardín salvaje. Si lo ignoras, crece maleza y come el césped bonito. Podés dejarlo crecer por un tiempo si sólo querés probar el terreno (MVP). Pero a la larga, o contratas jardineros o el jardín se vuelve intransitable.

Urgencia y plan de 90 días (si quieres resultados reales)

Si te sientes valiente, este es el plan que recomiendo:

• Día 0–7: Diagnóstico y métricas.
• Día 8–30: Quick wins + políticas (Boy Scout + Sprint budget).
• Día 31–60: Migraciones pequeñas (Strangler) y tests críticos.
• Día 61–90: Medir impacto, ajustar presupuesto, presentar resultados al negocio.

CTA directo (haz algo ahora)

Haz esto ahora: abre tu tablero de issues, crea un epic llamado “Deuda Técnica — Sprint 0” y añade:

• 3 métricas que vas a medir.
• 3 hotspots para arreglar esta sprint.
• Asignación del 15% de la capacidad.

Respóndeme con “DEUDA YA” y te mando una plantilla de epic + checklist de 90 días que puedes pegar en tu Jira/Linear. Además te daré el mail corto y convincente para que envíes a Product/CEO y consigas el presupuesto técnico.

Cierre — por qué esto no acaba aquí

La deuda técnica no es un monstruo que se elimina de una vez. Es una economía: cobran intereses y cambia con el mercado. La idea no es purismo, es sostenibilidad.

Si haces lo básico —visibilidad, presupuesto y pequeños pagos constantes— recuperarás velocidad y reducirás noches de pánico. Si no, la deuda comprará una hipoteca sobre tu tiempo de desarrollo.

No te estoy pidiendo que seas perfecto. Te pido que seas estratégico. ¿Quieres la plantilla? Di “DEUDA YA”. Esto no acaba aquí: esto es el inicio de que tu equipo vuelva a confiar en sus despliegues.

FAQ