Qué es la deuda técnica explicada para founders

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.

La analogía de la construcción sin planos

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.

Cómo se acumula la deuda técnica sin que te des cuenta

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:

• "Hacemos esta integración rápido, total después la mejoramos." La mejora nunca llega porque siempre hay algo más urgente.
• "Dejamos este valor fijo en el código, después lo pasamos a una configuración." El valor fijo queda ahí durante dos años, y cuando finalmente hay que cambiarlo, nadie recuerda dónde estaba ni qué más depende de él.
• "No documentamos esta parte ahora, está fresca en la cabeza del equipo." Tres meses después, la persona que lo construyó se fue de la empresa y nadie más sabe cómo funciona.
• "No escribimos pruebas automatizadas para este módulo, lo probamos manualmente." Cada vez que se modifica algo relacionado, alguien tiene que probar todo a mano. Con el tiempo, las pruebas manuales toman más tiempo que el desarrollo mismo.

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.

Señales de que la deuda técnica ya está afectando al negocio

No hace falta leer código para detectar deuda técnica. Algunas señales visibles desde fuera del equipo técnico:

• Funcionalidades que antes tomaban una semana ahora toman tres. El alcance es similar, el equipo es el mismo, pero cada cosa nueva tarda más. El código se volvió tan frágil que cualquier cambio requiere entender —y muchas veces reescribir— partes que no deberían estar relacionadas.
• Cada corrección de un bug genera uno nuevo. El sistema es una red de dependencias invisibles: modificás algo en el módulo de facturación y se rompe el envío de notificaciones. El equipo empieza a tener miedo de tocar cosas que funcionan, y con razón.
• Solo una o dos personas saben cómo funciona cada parte del sistema. Si la persona que construyó el módulo de pagos se toma vacaciones, cualquier incidencia en pagos queda sin resolver hasta que vuelva. Esto no es un problema de personas: es un problema de deuda técnica en forma de conocimiento no compartido.
• Las estimaciones del equipo son cada vez más imprecisas. Cuando el código está ordenado, estimar cuánto va a tardar una funcionalidad nueva es razonablemente predecible. Cuando el código es un campo minado, cualquier estimación es una apuesta porque nadie sabe qué va a romperse en el camino.
• El equipo técnico habla constantemente de "refactorizar" o "limpiar". Si cada planning incluye una discusión sobre si este sprint por fin van a poder ordenar algo, y esa discusión lleva meses repitiéndose sin que nunca llegue a hacerse, la deuda técnica ya se volvió un lastre que el equipo arrastra pero no puede soltar.

No toda deuda técnica es mala

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:

1. ¿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.

2. ¿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.

3. ¿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.

Cómo gestionar la deuda técnica sin ser técnico

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.

La relación entre deuda técnica y decisiones de negocio

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:

• Vender funcionalidades que no existen obliga al equipo a construir contra reloj, sin tiempo para diseñar ni probar adecuadamente.
• Cambiar prioridades cada semana impide que el equipo termine lo que empieza con la calidad necesaria; cada cambio de contexto deja código a medio hacer que después nadie retoma.
• No definir criterios de calidad —o definirlos pero no asignar tiempo para cumplirlos— manda la señal de que lo único que importa es la velocidad de entrega. El equipo responde entregando rápido, y la deuda se acumula.

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.

Cuándo conviene pagar la deuda y cuándo conviene vivir con ella

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.