Deuda técnica en TI: cómo evaluarla antes de que te evalúe a ti
La deuda técnica no es un problema de programadores. Es un riesgo de negocio que el Gerente TI necesita poder medir, comunicar y priorizar.
En algún punto de tu carrera como Gerente TI ya habrás escuchado la frase: "ese sistema tiene mucha deuda técnica". Quizás la hayas dicho tú mismo. El problema es que la mayoría de las veces se dice como explicación — y no como diagnóstico.
Una deuda técnica sin diagnóstico es ruido. Con diagnóstico, es información con la que puedes tomar decisiones.
Qué es deuda técnica y qué no es
Deuda técnica es la diferencia entre cómo está hecho un sistema hoy y cómo debería estar hecho para funcionar bien a mediano plazo. Esa diferencia tiene un costo: el tiempo y el esfuerzo adicional que toma cada cambio, cada integración nueva, cada corrección.
Lo que no es deuda técnica: un sistema viejo que funciona bien, está documentado, y no bloquea nada. La antigüedad no es el criterio. El criterio es si la deuda frena al equipo o al negocio.
Lo que sí es deuda técnica:
- Código que nadie quiere tocar porque no hay tests, ni documentación, ni nadie que lo entienda del todo
- Integraciones que funcionan "de milagro" y que se rompen cada vez que algo cambia en un extremo
- Sistemas que dependen de una versión de software desactualizada sin soporte
- Procesos que requieren trabajo manual porque el sistema no puede automatizarlos
- Arquitectura que no escala: lo que funciona para el volumen actual no funcionará para el doble
Por qué no se evalúa bien
La deuda técnica es difícil de evaluar porque vive en el código, y la mayoría de los reportes que llegan a la dirección no incluyen el código.
Los equipos TI suelen conocerla de cerca — saben dónde está el sistema frágil, quién es el único que puede tocarlo, qué integración está colgando de un hilo. Lo que falta con frecuencia es el paso siguiente: convertir eso en un diagnóstico estructurado que pueda priorizarse y presentarse.
El resultado es que la deuda técnica existe, el equipo la conoce, pero no está inventariada ni valorizada. Y lo que no está valorizado no entra en el presupuesto.
Cómo evaluarla: un marco práctico
No necesitas una auditoría de 200 páginas para tener un diagnóstico útil. Necesitas responder cuatro preguntas por cada sistema crítico de tu empresa:
1. ¿Qué tan frágil es?
Frágil significa que puede romperse si alguien lo toca. Los indicadores:
- ¿Hay tests automatizados? ¿Cuántos pasan cuando alguien hace un cambio?
- ¿Cuánto tarda en entender el sistema alguien que no lo conoce?
- ¿Ha habido incidentes en los últimos 12 meses causados por cambios que "no deberían haber afectado nada"?
- ¿Cuántas personas pueden hacer un cambio de producción sin riesgo alto?
2. ¿Qué tan opaco es?
Opaco significa que el conocimiento de cómo funciona vive en personas, no en documentación. Los indicadores:
- ¿Existe documentación técnica actualizada?
- ¿Cuántas personas entienden el sistema de principio a fin?
- Si esa persona o personas se van, ¿cuánto tiempo tomaría que alguien nuevo lo entienda?
- ¿Se puede auditar lo que hace el sistema — logs, trazas, historial de cambios?
3. ¿Qué tan bloqueante es?
Bloqueante significa que limita lo que el negocio puede hacer. Los indicadores:
- En los últimos 12 meses, ¿cuántas iniciativas del negocio se frenaron porque el sistema no las soportaba?
- ¿Cuánto trabajo manual se hace porque el sistema no puede automatizarlo?
- ¿Hay procesos críticos que dependen de pasos manuales porque el sistema falla o es insuficiente?
4. ¿Qué tan urgente es?
Urgencia no es lo mismo que importancia. Urgente es lo que tiene probabilidad de fallar pronto con consecuencias graves. Los indicadores:
- ¿Tiene dependencias de software sin soporte activo (sistemas operativos, bases de datos, frameworks)?
- ¿El proveedor del sistema está activo o desapareció?
- ¿Ha habido señales de deterioro — lentitud creciente, errores intermitentes, correcciones que no duran?
El mapa de riesgo
Con esas cuatro dimensiones, puedes construir algo útil: un mapa de riesgo técnico por sistema.
No es una matriz compleja. Puede ser tan simple como esto:
| Sistema | Fragilidad | Opacidad | Bloqueo | Urgencia | Prioridad |
|---|---|---|---|---|---|
| Sistema de despacho | Alta | Alta | Alta | Media | Crítica |
| ERP propio | Media | Baja | Media | Baja | Controlada |
| Integración con carrier | Alta | Alta | Alta | Alta | Crítica inmediata |
| Sistema de RR.HH. | Baja | Baja | Baja | Baja | Monitorear |
Este mapa tiene tres usos concretos:
Priorización interna: saber en qué trabajar primero sin depender solo de la urgencia percibida.
Comunicación hacia arriba: presentar el estado del sistema TI en términos de riesgo operacional, no de tecnicismo. "La integración con el carrier tiene fragilidad y opacidad altas, y si falla, los despachos se detienen por al menos medio día" es una frase que el Gerente General entiende.
Base para presupuesto: una deuda técnica valorizada es un argumento de inversión. Una deuda técnica invisible es un riesgo que nadie quiere financiar porque nadie sabe que existe.
El error más común: tratar toda la deuda igual
No toda la deuda técnica es urgente. No toda requiere intervención inmediata.
El error es tratar el catálogo de deuda como una lista de cosas que hay que arreglar todas al mismo tiempo, lo que lleva a no arreglar ninguna porque el esfuerzo parece abrumador.
La distinción que importa:
Deuda técnica con la que se puede convivir: el sistema tiene quince años, nadie lo toca, funciona para lo que hace, y no bloquea nada nuevo. Ese sistema puede seguir así mientras el negocio no lo necesite diferente.
Deuda técnica que hay que contener: el sistema tiene problemas, pero con documentación y un plan de contingencia, el riesgo es manejable. Se trabaja en ella con tiempo y sin urgencia.
Deuda técnica que hay que resolver ahora: el sistema es frágil, opaco, y está bloqueando algo que el negocio necesita o tiene alta probabilidad de fallar con consecuencias graves. Eso no espera.
El diagnóstico sirve para poner cada sistema en la categoría correcta.
Cuándo conviene manos externas
El equipo interno tiene un problema estructural para evaluar deuda técnica: todos trabajan en el sistema desde adentro. Lo que parece normal desde adentro puede ser una señal de riesgo alta para alguien que lo ve desde afuera.
Además, hay una carga política. Si el equipo TI generó parte de esa deuda, pedirles que la evalúen objetivamente es difícil. No por deshonestidad — por sesgo natural.
Un equipo externo puede hacer ese diagnóstico sin historia ni compromiso con cómo se llegó ahí. Solo con el mapa de lo que hay y lo que significa.
Si quieres hacer ese ejercicio en tu organización y no sabes por dónde empezar, la conversación de diagnóstico sirve exactamente para eso: mapear lo que hay, identificar dónde están los riesgos reales, y construir un plan que el equipo TI pueda ejecutar — solo o con apoyo externo.
Preguntas frecuentes
Lo que la gente pregunta sobre este tema
¿Cómo le explico la deuda técnica a un Gerente General o Gerente de Finanzas?
Traduciendo cada problema técnico a riesgo operacional o costo concreto. No 'el código está desactualizado', sino 'si esta integración falla, los despachos se detienen entre 4 y 8 horas'. No 'la base de datos no escala', sino 'si el volumen crece un 30% el próximo año, el sistema actual no lo soporta y necesitaremos parar para migrar'. El lenguaje que importa arriba es el de riesgo y continuidad, no el de tecnología.
¿Cuánta deuda técnica es aceptable?
Toda empresa tiene deuda técnica. La pregunta no es si existe, sino si está controlada. Deuda técnica con la que se puede convivir: sistemas legacy que funcionan, están documentados, y no bloquean iniciativas nuevas. Deuda técnica crítica: sistemas sin documentación que dependen de una persona, integraciones rotas que se compensan manualmente, código que nadie quiere tocar por miedo a que se rompa todo.
¿Por dónde empiezo si tengo deuda técnica en varios sistemas al mismo tiempo?
Por impacto operacional, no por antigüedad del sistema. El criterio correcto es: si esto falla mañana, ¿qué parte del negocio se detiene, por cuánto tiempo, y a qué costo? El sistema más viejo no es necesariamente el más urgente. El más urgente es el que tiene más probabilidad de fallar y más consecuencias si falla.
¿La deuda técnica se puede eliminar completamente?
No, y no es el objetivo. El objetivo es que la deuda esté inventariada, valorizada y controlada — que no crezca sin decisión consciente. En proyectos de ritmo alto siempre se acumula algo de deuda. Lo que distingue a un equipo TI en control de uno en modo apagafuegos es si esa deuda está documentada o si vive solo en la cabeza de alguien.
¿Cuándo conviene traer ayuda externa para evaluar deuda técnica?
Cuando el equipo interno no puede ser objetivo porque todos trabajan en el sistema desde adentro. O cuando hace falta un lenguaje técnico-financiero para presentar el problema a la dirección. O cuando el equipo ya sabe dónde está el problema pero nadie quiere ser el que proponga tocarlo.
Antes de contratar, revisa este checklist
15 preguntas para evaluar si el proyecto necesita apoyo externo o puede resolverse internamente. PDF, 2 páginas.
¿Prefieres conversar directo? Agenda 45 min sin costo