Una explicación del concepto de deuda técnica usando analogías de negocio —sin jerga de programación— y su impacto real en la velocidad y los costos de una empresa.
Si pasaste suficiente tiempo cerca de equipos de desarrollo, escuchaste el término "deuda técnica". Y probablemente notaste que se usa de dos formas muy distintas: a veces como una advertencia —"esto va a generar deuda técnica"— y otras como una excusa —"no podemos entregar esta semana porque estamos pagando deuda técnica"—. Entre esos dos usos, el concepto se vuelve difuso, y para alguien que no programa puede sonar a un problema exclusivamente técnico que no debería preocuparle.
No es así. La deuda técnica es, sobre todo, un problema de negocio. Afecta la velocidad a la que podés sacar funcionalidades nuevas, el costo de mantener lo que ya construiste y el riesgo de que cosas que funcionaban dejen de funcionar cuando tocás algo que no debería estar relacionado.
Este artículo explica qué es la deuda técnica usando analogías de negocio —no de código— para que cualquier fundador o empresario pueda entenderla, evaluarla y tomar decisiones informadas sobre cuándo asumirla y cuándo pagarla.
Imaginá que necesitás abrir una oficina nueva. Tenés dos caminos posibles.
Camino A: contratás a un arquitecto, definís planos, calculás cargas, hacés los cimientos, levantás paredes, pasás la instalación eléctrica por dónde corresponde, dejás documentado dónde está cada caño y cada cable, y después pintás. El proceso lleva seis meses y cuesta lo que cuesta un proyecto bien hecho.
Camino B: empezás a construir sobre la marcha. El primer ambiente lo levantás en tres semanas. Cuando necesitás un segundo ambiente, lo pegás al primero como podés. La instalación eléctrica la pasás por donde queda más fácil, no por donde corresponde. No hay planos de nada. En dos meses tenés la oficina funcionando a la mitad del costo del Camino A.
El Camino B es más rápido y más barato. Por un tiempo. Hasta que un día necesitás agregar un tercer ambiente y descubrís que el cableado pasa justo por donde iría la pared nueva. O hasta que se quema un fusible y el electricista tarda tres días en encontrar el problema porque nadie documentó por dónde pasan los cables. O hasta que un inspector te dice que la instalación no cumple normas y tenés que rehacerla entera.
Eso es la deuda técnica. El Camino B tomó atajos para llegar más rápido. Esos atajos funcionaron en el momento, pero generaron una deuda —en forma de desorden, falta de documentación, decisiones difíciles de revertir— que va a haber que pagar después, con intereses. Los intereses, en este caso, son el tiempo extra que toma cada modificación futura porque nada está donde debería estar ni funciona como debería funcionar.
Aunque el nombre incluya la palabra "técnica", la deuda afecta a todo el negocio. Cada mes que tu equipo dedica a pagar deuda técnica es un mes que no dedica a construir funcionalidades que generan valor para tus clientes o ventaja sobre tus competidores. El costo real no está en las horas de desarrollo: está en la velocidad perdida.
La deuda técnica rara vez se toma de forma deliberada con un cartel que diga "estoy generando deuda". Se acumula de a poco, decisión por decisión, y cada decisión por separado parece razonable en su contexto:
Cada una de estas decisiones, tomada de forma aislada, ahorró unas horas o unos días en su momento. El problema es que el interés compuesto de todas esas decisiones juntas, acumuladas durante meses o años, hace que el costo de construir cualquier cosa nueva se multiplique.
La analogía financiera es precisa: así como una deuda de tarjeta de crédito puede parecer manejable mes a mes hasta que los intereses te comen el flujo de caja, la deuda técnica puede parecer inofensiva sprint a sprint hasta que el equipo pasa más tiempo pagando intereses —arreglando cosas que se rompen, descifrando código que nadie entiende, rehaciendo trabajo mal hecho— que generando valor nuevo.
No hace falta leer código para detectar deuda técnica. Algunas señales visibles desde fuera del equipo técnico:
El verdadero peligro de la deuda técnica no es lo que cuesta pagarla —que al final se paga, de una forma u otra— sino lo que dejás de hacer mientras la arrastrás. Cada funcionalidad que no sale a tiempo, cada bug que tarda en corregirse, cada cliente que se va porque el sistema falla: eso es deuda técnica convertida en pérdida de negocio.
Así como la deuda financiera no es inherentemente negativa —un crédito para comprar una máquina que aumenta la producción puede ser una excelente decisión—, la deuda técnica puede ser una decisión estratégica.
El caso más claro es el de una startup que está validando una idea. En esa etapa, la prioridad no es tener un código impecable: es llegar rápido al mercado con algo que permita saber si el producto resuelve un problema real. Tomar deuda técnica en ese contexto —construir sin pruebas automatizadas, sin documentación exhaustiva, sin una arquitectura pensada para escalar— puede ser la decisión correcta, porque si el producto no funciona en el mercado, la calidad del código es irrelevante.
Lo que hace que la deuda técnica sea buena o mala no es su existencia, sino tres factores:
¿Se tomó de forma consciente? Si el equipo decide explícitamente "vamos por este atajo sabiendo que en tres meses va a haber que pagarlo", es una decisión de negocio. Si el atajo se tomó porque nadie revisó el trabajo o porque hubo presión por entregar sin discutir las consecuencias, es un problema de gestión.
¿Hay un plan para pagarla? La deuda que se documenta, se dimensiona y se agenda para ser saldada en un plazo definido es manejable. La deuda que se acumula sin registro ni plan es la que eventualmente frena todo.
¿El costo de no tomarla es mayor que el costo de pagarla después? Si postergar el lanzamiento tres meses para tener un código perfecto implica que un competidor se quede con el mercado, la deuda técnica es el menor de los males. Si la presión por entregar rápido es autoinfligida —"el CEO quiere mostrar algo en la reunión del lunes"—, la deuda que se genera probablemente no valga la pena.
No necesitás saber programar para gestionar la deuda técnica. Sí necesitás crear las condiciones para que el equipo técnico pueda gestionarla. Algunas prácticas que ayudan:
Pedile al equipo que haga visible la deuda. No hace falta que te expliquen cada detalle técnico. Alcanza con que mantengan una lista de las deudas conocidas, con una estimación de esfuerzo para saldarlas y una explicación en lenguaje de negocio de qué impacto tiene cada una: "este módulo nos va a frenar cuando queramos agregar el método de pago nuevo", "esta parte va a hacer cada vez más lentos los reportes a medida que crezca la base de clientes".
Reservá tiempo para pagar deuda. Si cada sprint se asigna el cien por ciento del tiempo a funcionalidades nuevas, la deuda nunca se paga. Muchos equipos reservan entre un quince y un veinticinco por ciento del tiempo de cada ciclo a reducir deuda técnica. No es tiempo perdido: es inversión en velocidad futura.
Preguntá por el costo de no pagar. Cuando el equipo pide tiempo para ordenar algo, no preguntes solo cuánto va a tardar. Preguntá también qué pasa si no se hace: ¿se frena alguna funcionalidad planeada?, ¿aumenta el riesgo de errores en producción?, ¿se va a volver más caro arreglarlo después? Esa información te permite priorizar con criterio de negocio, no solo técnico.
No trates la deuda técnica como un fracaso del equipo. Si cada vez que el equipo menciona deuda técnica la respuesta es frustración o presión por entregar más rápido, el equipo aprende a no mencionarla. Y la deuda que no se menciona es la que más daño hace, porque se acumula en silencio hasta que explota en producción.
"¿Cuánto de lo que estamos construyendo este sprint va a haber que rehacer en menos de seis meses?" Si la respuesta te incomoda, vale la pena dedicar parte del sprint siguiente a reducir la deuda que está generando ese retrabajo futuro.
La deuda técnica no se genera solo en el código. Muchas veces es consecuencia de decisiones que se toman fuera del equipo técnico:
Relacionado: así como la deuda técnica se acumula cuando no se le da visibilidad ni tiempo, hay riesgos técnicos que nadie revisa hasta que es tarde. Muchos de ellos son consecuencias directas de decisiones de negocio que no consideraron su impacto técnico.
No toda la deuda técnica merece ser saldada. Como en las finanzas, hay deuda barata y deuda cara.
Deuda que conviene pagar pronto: aquella que frena funcionalidades que están en el roadmap de los próximos tres meses, que aumenta el riesgo de errores en partes del sistema que afectan directamente a clientes, o que hace que el equipo pierda horas cada semana en tareas que podrían automatizarse.
Deuda con la que se puede convivir: aquella que está en módulos que no se van a tocar en el futuro previsible, que no genera errores ni lentitud perceptible, o que afecta partes del sistema que eventualmente van a reescribirse por completo y no tiene sentido ordenar algo que se va a tirar.
La decisión de qué deuda pagar y cuándo es una decisión de producto, no solo técnica. Requiere entender el roadmap del negocio, las prioridades de los clientes y los riesgos que el negocio está dispuesto a asumir. El equipo técnico puede dimensionar la deuda y estimar el esfuerzo de saldarla; la decisión de cuándo hacerlo debería tomarla alguien que entienda el negocio.
El artículo sobre qué validar antes de desarrollar una aplicación toca un punto relacionado: si validás las funcionalidades antes de construirlas, reducís la probabilidad de construir cosas que después hay que rehacer. Buena parte de la deuda técnica viene de funcionalidades que se construyeron dos o tres veces porque la primera versión no era lo que el negocio necesitaba. Validar antes de construir es, también, una forma de prevención de deuda técnica.
La deuda técnica no se elimina —como la deuda financiera, es parte de operar—. Se gestiona. Y gestionarla bien requiere que quienes toman decisiones de negocio entiendan qué es, cómo se acumula y cuánto cuesta no pagarla a tiempo.
¿Quieres evaluar cómo aplicar esto a tu proyecto?
Cuéntanos tu caso →