La deuda técnica no es basura acumulada por desarrolladores descuidados. Es el costo diferido de decisiones tomadas bajo presión, con información incompleta o con plazos que no dejaban margen. Es especialmente común en industrias que digitalizaron su operación hace diez o quince años y nunca volvieron a tocar el sistema: un ERP de gestión de stock armado a medida por un proveedor que ya cerró, o una planilla de cálculo que terminó funcionando como sistema de facturación de toda la empresa. El problema no es que esa deuda exista —toda base de código de producción tiene— sino que tiende a invisibilizarse hasta que se vuelve un freno real para el negocio.
¿Por qué le debería importar al negocio?
La deuda técnica tiene consecuencias concretas y medibles: más tiempo para lanzar nuevas funcionalidades, mayor frecuencia de errores en producción, dependencia excesiva de personas específicas del equipo —muchas veces una sola persona que "sabe cómo anda el sistema"— y dificultad para incorporar desarrolladores nuevos. Cada uno de esos síntomas tiene un costo que no aparece en ningún ticket de soporte.
El costo no es anecdótico: en una encuesta de McKinsey a CIOs de empresas de tecnología y servicios financieros con más de US$1.000 millones de facturación, el 30% estimó que más del 20% del presupuesto técnico destinado a productos nuevos termina absorbido por deuda técnica acumulada.
La deuda técnica no se ve en el backlog. Se ve en el tiempo que tarda en hacer algo que debería ser simple.
¿Cuáles son los tres tipos de deuda técnica que importan?
Hay deuda que se acumuló porque era la forma más rápida de avanzar y se devolvería después —y no se devolvió—. Hay deuda que nació de una buena decisión que el tiempo volvió obsoleta. Y hay deuda que vino de no entender bien el problema al principio. Las tres requieren tratamientos distintos.
¿Cómo priorizarla sin paralizarse?
No toda la deuda vale la pena pagar. El criterio no es la elegancia del código sino el impacto operativo: ¿qué tan seguido toca esa parte del sistema?, ¿qué pasa si falla?, ¿cuánto tarda en modificarse? La deuda que toca la operación diaria y frena el crecimiento tiene prioridad sobre la que existe en módulos estables.
La conversación que hay que tener
El equipo técnico necesita poder decirle al negocio: este desarrollo va a tardar el doble de lo esperado porque hay una deuda subyacente que hay que resolver primero. Y el negocio necesita saber si esa conversación vale la pena o si hay una forma de avanzar acumulando menos deuda nueva.