Las 5 fases de la deuda técnica empresarial
Un framework práctico para que gerentes, CTOs y dueños de PyME identifiquen en qué fase de deuda técnica está su empresa, qué corresponde hacer en cada una, y cuándo el costo de no actuar supera al de actuar.
Un gerente nos llamó hace meses. Su empresa factura sobre USD 2M al año, tiene un sistema interno construido durante una década, y siente que algo no funciona. “Cada cambio cuesta el doble que el anterior. Mi equipo de TI me dice que está todo bien, pero los plazos nunca se cumplen. ¿Qué le pregunto a mi gente?” Esa pregunta no se responde con jerga. Se responde con un mapa.
Este artículo es ese mapa. Cinco fases de deuda técnica, con síntomas verificables, costos estimables, y qué decisión corresponde en cada una. Es para gerentes, CTOs de PyME, dueños y encargados de operaciones que necesitan diagnosticar antes de invertir.
Por qué un framework con fases
La deuda técnica no es binaria. No es “tienes deuda” o “no tienes”. Es un continuo, y el continuo importa porque la decisión correcta cambia. Tratar fase 2 como fase 5 lleva a reescribir cuando bastaba refactorizar: meses perdidos y un sistema nuevo con los mismos errores. Tratar fase 4 como fase 2 lleva a parchar lo que ya no se puede parchar: dinero quemado y el sistema empeora.
El framework de 5 fases que sigue se sustenta en patrones que Ward Cunningham describió como metáfora financiera en 1992, en datos del Developer Coefficient de Stripe (2018) y del estudio de McKinsey (2020), y en lo que hemos visto trabajando con clientes en cada una de las fases.
El mapa: cinco fases
Identifica dónde está tu empresa hoy.
Sano
Stack moderno, tests, deploys automáticos. Estimaciones se cumplen.
Tensión silenciosa
Parches localizados. Estimaciones se desvían 50-100%.
Dependencia operativa
Una o dos personas son irreemplazables. Áreas que nadie quiere tocar.
Frágil
Cada cambio rompe algo. Deploys los viernes (no broma).
Crítico
Equipo original se fue. Nadie modifica con confianza. Reconstruir es la única salida.
Síntomas verificables por fase
Síntoma típico vs. realidad detrás.
Fase 1 — Sano
Stack moderno y documentado. Tests automatizados que cubren rutas críticas. Despliegues con un click. El equipo entiende qué hace cada parte del sistema, y nuevas funciones se construyen en días o semanas. Las dependencias y versiones se actualizan en ventanas planificadas, no por urgencia.
Síntomas verificables: las estimaciones se cumplen ±20%. Un desarrollador nuevo puede ser productivo en menos de dos semanas. El último incidente serio fue hace meses.
Decisión correcta: invertir 10-15% del tiempo del equipo en mantenimiento preventivo. Actualizar dependencias en cadencia trimestral. Documentar mientras se construye, no después. Costo de no hacerlo: caer a fase 2 en 12 a 24 meses.
Fase 2 — Tensión silenciosa
Aparecen los primeros parches. Hay “esa cosa que nadie quiere tocar”. Algunas dependencias quedaron rezagadas porque actualizar implica probar y nadie tiene tiempo. Los tests pasan pero no cubren ramas críticas. Las estimaciones empiezan a desviarse 50% a 100%.
Síntomas verificables: el equipo dice “déjame ver” antes de comprometerse a un plazo. Hay procesos manuales que “deberían automatizarse algún día”. El backlog tiene tickets de “refactor” que nunca se priorizan.
Decisión correcta: bloquear 20% del esfuerzo en deuda. Documentar las áreas problemáticas. Actualizar dependencias críticas. Costo de no actuar: caer a fase 3 en 6 a 12 meses.
Muchas empresas en fase 2 contratan más desarrolladores creyendo que el problema es de capacidad. No es. Sumar gente a un sistema con deuda no resuelta acelera el deterioro: cada nuevo dev agrega su forma de parchar. Brooks lo dijo en 1975 y sigue siendo cierto.
Fase 3 — Dependencia operativa
Hay una o dos personas en el equipo que son irreemplazables. Solo ellas entienden módulos críticos. Hay áreas del sistema que se evitan tocar conscientemente. Producción y staging divergen, y nadie documentó las diferencias. Aparecen incidentes recurrentes con “root cause conocida pero no se ha podido arreglar”.
Síntomas verificables: las vacaciones del dev senior se vuelven motivo de ansiedad. Hay un Excel maestro que solo una persona actualiza. El día que renuncia el dev clave, la operación queda comprometida.
Decisión correcta: documentación obligatoria, pair programming para distribuir conocimiento, auditoría externa para mapear deuda. Empezar plan de modernización por módulos. Costo de no actuar: caer a fase 4 en 3 a 6 meses. Perder al dev clave es colapso operativo.
Un sistema en fase 3 está sostenido por personas, no por arquitectura. Eso es exactamente lo que cambia en fase 4.
Fase 4 — Frágil
Cualquier cambio significativo rompe algo más. Las dependencias están tan desactualizadas que actualizarlas implica reescribir partes del sistema. El código fuente coincide solo parcialmente con lo que corre en producción: hay parches manuales que nadie volcó al repositorio. Hay miedo real de tocar ciertas áreas. El equipo nuevo no puede operar sin supervisión constante.
Síntomas verificables: los deploys se hacen los viernes (no es broma). Hay un canal de Slack llamado “#alarmas” que está siempre activo. Una funcionalidad que se prometió en dos semanas lleva tres meses.
Decisión correcta: plan de migración por módulos, con sistema antiguo en paralelo. Congelar features no críticas. Auditoría profunda. Esta fase requiere decisión gerencial, no técnica: hay que aceptar 6 a 12 meses de inversión sin ROI directo. Costo de no actuar: caer a fase 5, donde el costo de salida se duplica.
Fase 5 — Crítico
El equipo original se fue total o parcialmente. Nadie puede modificar el sistema con confianza. Cada incidente se resuelve con un parche que aumenta la deuda. La operación depende del sistema, pero el sistema depende de plegarias. Contratan consultores que miran, dicen “esto hay que migrar”, y se van porque no quieren tocarlo.
Síntomas verificables: hay servicios que solo se reinician, no se modifican. La documentación está en cabezas que ya no están en la empresa. Los proveedores SaaS te avisan que las versiones que usas dejarán de tener soporte.
Única salida: reconstrucción planificada con el sistema antiguo en paralelo. Plazo realista: 12 a 24 meses. Costo: alto, pero menor que la pérdida operativa esperada de no actuar. Esta no es decisión técnica: es decisión de continuidad del negocio.
Qué hacer en cada fase
Si tu empresa está en fase X, esto es lo que corresponde.
- 01 Fase 1 — Sano. Mantener disciplina. 10-15% del tiempo en deuda preventiva. Documentación viva.
- 02 Fase 2 — Tensión. Bloquear 20% en deuda. Priorizar áreas problemáticas identificadas. No contratar más sin antes documentar.
- 03 Fase 3 — Dependencia. Auditoría externa. Distribuir conocimiento. Empezar plan modular de modernización.
- 04 Fase 4 — Frágil. Migración por módulos con sistema viejo en paralelo. Congelar features. Aceptar 6-12 meses sin ROI directo.
- 05 Fase 5 — Crítico. Reconstrucción. 12-24 meses. Decisión de continuidad del negocio, no técnica.
Los tres errores más caros
Error 1: tratar fase 2 como fase 5. Reescribir cuando bastaba con disciplina. Resultado: dos años perdidos para volver al mismo lugar con otra tecnología.
Error 2: tratar fase 4 como fase 2. Parchar lo que ya no admite parche. Resultado: deterioro acelerado, equipo agotado, sistema peor cada mes.
Error 3: contratar gente en fase 3 sin documentar primero. El conocimiento sigue en la misma cabeza, ahora con tres personas que parchan a su manera. Acelera la llegada a fase 4.
Ejemplos en sistemas que conocemos
En Bioaudita, una plataforma de certificación orgánica, la decisión desde el día uno fue construir en fase 1 explícita: 40+ modelos Django documentados, tests sobre rutas críticas, despliegues automatizados con GitHub Actions. Trabajamos para que la disciplina de mantenimiento esté incorporada al ciclo de desarrollo, no como tarea separada.
En Sign DataNubi, el diseño consideró que módulos críticos (PKI, firma criptográfica) tienen que estar aislados arquitectónicamente para que la deuda en otras zonas no contamine la parte que necesita ser confiable a largo plazo. Es separación que reduce el riesgo de pasar de fase 1 a fase 2.
En TCultura, tres aplicaciones Flutter, un backend Django, integraciones con SII y medios de pago. Mantenerlo en fase 1 después de dos años en producción requiere lo mismo de siempre: actualizar dependencias en cadencia, no acumular features sin refactor, no contratar para acelerar sin antes documentar.
La deuda técnica no es un problema de código. Es un problema de cadencia: cuántas decisiones de mantenimiento postergas antes de que se acumulen.
Cuándo pedir ayuda externa
- 01 No sabes en qué fase está tu empresa. Una auditoría externa te lo dice en 2-4 semanas.
- 02 Sabes que estás en fase 3+ pero el equipo interno minimiza el problema.
- 03 Tu equipo TI te pide presupuesto para reescribir todo. Tercera opinión antes de firmar.
- 04 Un dev clave anunció que se va. Plan de transferencia con auditoría externa, no solo onboarding.
- 05 Un incidente reciente expuso fragilidad que no se ve cuando todo va bien.
Cierre
Identificar la fase es el primer ejercicio honesto que puede hacer una empresa con su software. No es una herramienta de venta de servicios. Es un mapa para decidir con criterio, en vez de decidir por intuición o por la última conversación con el vendor de turno.
Si después de leer esto crees que tu empresa está en fase 3 o superior y quieres una segunda opinión, conversemos. Veinte minutos, sin compromiso. No te vamos a vender una reescritura: te vamos a decir en qué fase estás y qué corresponde hacer.
Preguntas frecuentes
¿Qué es la deuda técnica en una empresa?
Es el costo acumulado de decisiones técnicas tomadas por velocidad, falta de tiempo o desconocimiento, que se pagan después con mantenimiento más lento, fragilidad operacional y rigidez para cambiar. El término lo acuñó Ward Cunningham en 1992 como metáfora financiera: como una deuda monetaria, devenga intereses.
¿Cómo sé en qué fase está mi empresa?
Mira las estimaciones: si los proyectos terminan en ±20% del plazo prometido estás en fase 1 sana. Si se desvían 50-100% estás en fase 2 de tensión silenciosa. Si dependes de una sola persona para mantener el sistema, estás en fase 3. Si los deploys dan miedo, estás en fase 4. Si nadie se atreve a tocar el sistema, estás en fase 5.
¿Cuánto cuesta reconstruir un sistema en fase 5?
Entre 12 y 24 meses de trabajo en paralelo con el sistema antiguo, y costos que suelen exceder lo que habría costado modernizar desde fase 3. La buena noticia es que el costo de seguir operando en fase 5 también es alto: caídas, fuga de talento, oportunidades perdidas, riesgo regulatorio. La cuenta tarde o temprano se paga.
¿Cuánto tiempo demora pasar de una fase a la siguiente?
Sin disciplina, una empresa pasa de fase 1 a fase 2 en 12-24 meses. De fase 2 a fase 3 en 6-12 meses. De fase 3 a fase 4 en 3-6 meses. De fase 4 a fase 5 puede pasar en semanas tras un evento gatillante (incidente grave, pérdida de un dev clave). El deterioro se acelera.
¿Es deuda técnica algo que solo aplica a empresas grandes?
No. Una PyME con un sistema interno crítico (ERP custom, plataforma de operaciones, e-commerce a medida) puede entrar en fase 4-5 con un equipo de tres personas. El tamaño no protege. Lo que protege es la disciplina de mantenimiento.
¿Cuándo conviene reescribir vs. refactorizar?
Reescribir conviene en fase 5 (sistema irrecuperable) o cuando el negocio cambió tanto que el modelo de datos ya no representa la realidad. Refactorizar conviene en fase 2-3. En fase 4 la decisión es caso a caso, generalmente con migración por módulos. Reescribir en fase 1-2 suele ser un error caro.