La conversación siempre empieza igual: "Nuestro equipo era ágil. Ahora cada feature lleva el triple de tiempo. ¿Qué pasó?"
Lo que pasó tiene nombre: deuda técnica. Y no aparece de un día para otro, se acumula silenciosamente, sprint a sprint, decisión a decisión, hasta llegar al momento en que el costo de entrega explota y nadie logra señalar exactamente dónde empezó el problema.
Qué es la deuda técnica de verdad
El término fue acuñado por Ward Cunningham en los años 90 para describir una elección consciente: hacer algo de forma más simple ahora, sabiendo que vas a "pagar" después con refactorización. Era una metáfora financiera positiva, deuda estratégica para moverse rápido.
El problema es que la mayor parte de la deuda técnica en el mundo real no es estratégica. Es accidental, invisible, y nunca fue decidida conscientemente por nadie.
Existen tres tipos principales:
- Deuda deliberada: "Vamos a hacer un parche ahora, luego lo arreglamos." A veces tiene sentido. Rara vez se paga.
- Deuda inadvertida: "Solo entendimos el diseño correcto después de terminar." Inevitable. Necesita espacio para ser corregida.
- Deuda entrópica: El sistema funciona, pero nadie más entiende por qué. La documentación desapareció. El autor se fue. Nadie se atreve a tocarlo.
La más peligrosa es la entrópica. No aparece en ningún backlog. Solo aparece cuando algo se rompe, y entonces el costo de investigación + corrección es altísimo.
Cómo la deuda técnica mata la velocidad
El mecanismo es previsible. La deuda crea fricción cognitiva: los ingenieros necesitan entender sistemas complejos antes de modificarlos. Crea acoplamiento oculto: tocar A rompe B de forma inesperada. Crea miedo: nadie quiere ser el responsable de tumbar producción.
¿El resultado práctico? Equipos que deberían entregar una feature en una semana gastan tres semanas solo en entender dónde debe conectarse, y dos más en garantizar que no rompió nada alrededor.
Existe una curva bien conocida: en los primeros meses de un producto, la velocidad es alta. Con el tiempo, sin inversión en calidad, la velocidad cae. Después de 2 a 3 años sin atención, muchos equipos llegan a una situación en la que las nuevas features exigen tanto trabajo de estabilización que el producto efectivamente se detiene.
El error más común: tratar la deuda técnica como problema técnico
Los CTOs frecuentemente cometen un error de encuadre aquí: tratan la deuda técnica como asunto de ingeniería, cuando es un asunto de negocio.
La deuda técnica sin resolver tiene un costo directo mensurable:
- Más horas de ingeniería por feature entregada
- Mayor tasa de bugs en producción (y costo de corrección)
- Rotación de ingenieros, la gente buena no quiere trabajar en sistemas malos
- Menor capacidad de respuesta a oportunidades de mercado
- Riesgo de incidentes de mayor impacto a medida que el sistema se vuelve más frágil
Cuando traduces la deuda técnica en impacto de negocio, la conversación con el liderazgo cambia completamente.
Cómo evaluar tu deuda técnica
Antes de decidir qué pagar, necesitas saber qué debes. Algunos enfoques prácticos:
Mapeo de puntos de dolor
Pregunta directamente al equipo: "¿Qué áreas del sistema te dan más miedo tocar?" Las respuestas apuntan hacia dónde la deuda es más crítica. Las áreas que todo ingeniero evita son áreas que ya están costando caro.
Análisis de tiempo de ciclo por área
Compara el tiempo promedio para entregar una feature en diferentes partes del sistema. Los outliers negativos generalmente coinciden con las áreas de mayor deuda técnica.
Tasa de bugs por módulo
Los módulos con tasa de bugs desproporcionada tienden a ser áreas con alta deuda técnica. La causa es acoplamiento excesivo y cobertura de tests insuficiente.
Qué vale pagar y qué no vale
No toda deuda necesita pagarse. La decisión debe basarse en dos ejes: el impacto en el negocio y el costo de corrección.
¿Deuda en sistemas legados que nadie usa? Ignórala. ¿Deuda en la API principal que procesa el 80% de tu volumen? Prioridad alta, independientemente del costo.
Una regla práctica útil: reserva consistentemente entre 15% y 20% de la capacidad de ingeniería para calidad técnica, refactorización, tests, documentación, modernización de dependencias. No como proyecto puntual, sino como práctica continua.
Los equipos que no reservan ese espacio tienden a llegar, en 18 a 24 meses, al punto en que necesitan un "proyecto de reescritura", que es caro, arriesgado y frecuentemente subestimado en alcance y duración.
La conversación que necesita ocurrir
Si estás en un punto en que la velocidad de entrega del equipo cayó significativamente y la causa parece ser la complejidad acumulada del sistema, necesitas un análisis honesto del estado técnico del producto.
Ese análisis no es un ejercicio de culpa, es un punto de partida para la decisión. ¿Cuánta deuda existe? ¿Dónde está concentrada? ¿Cuál es el costo real de cargarla? ¿Cuál es el costo de abordarla? ¿Y cómo priorizar dentro de la realidad del negocio?
Son preguntas con respuestas. Y responderlas correctamente vale más que cualquier feature nueva en el roadmap.
