Hoy vamos a hablar de algo que suena a cosa de ingenieros, pero que en realidad es el fantasma que persigue a cualquier producto digital, la deuda técnica.

Vamos a desgranar qué es de verdad, por qué nos debería quitar el sueño a todos, seamos de producto, de negocio o de ingeniería, y sobre todo, qué podemos hacer para que no se convierta en una bola de nieve que nos aplaste. A ver, para que nos hagamos una idea, lanzo una pregunta. ¿Qué pasaría si cada nueva funcionalidad chulísima que lanzamos en el fondo nos estuviera frenando? Que cada pequeño éxito fuese como echar una palada de tierra más a un agujero del que luego nos va a costar un montón salir. Pues de eso va todo esto, de ese coste oculto que se acumula casi sin que nos demos cuenta. Venga, vamos al lío.

1. El coste oculto del código: más allá del lanzamiento

Normalmente pensamos que cuando una funcionalidad está en producción, fiesta, trabajo hecho. Pero la realidad es justo la contraria. Ahí es cuando empieza el verdadero coste. Un coste que no se ve en el sprint planning, pero que está ahí, corriendo como un taxímetro sin parar. Y a este coste, Eduardo Ferro le puso un nombre muy bueno, el coste basal. La idea es genial, pensadlo como el metabolismo de una persona. Solo por estar vivo, el cuerpo quema calorías, pues con el software pasa igual. Cada trocito de código, cada funcionalidad, consume energía solo por existir. Hay que mantenerlo, vigilarlo, y cada vez que quieres añadir algo nuevo, tienes que pedirle permiso a todo lo que ya está ahí.

Coste basal: el coste continuo para que una funcionalidad exista. La energía que tu sistema gasta en mantenerse.

Y fijaos en este gráfico, porque es que da hasta miedo, es la cruda realidad de lo que pasa. El primer año, guay, el 60% del tiempo, o incluso más, es para cosas nuevas. Pero a medida que el producto crece y ese coste basal se va comiendo todo, mirad lo que pasa. Año 2, pum, la capacidad de innovar cae al 35%. Y al tercer año, ya es solo del 20%.

Esto significa que el equipo pasa el 80% de su tiempo apagando fuegos y manteniendo el chiringuito, en lugar de construir el futuro del producto. Es brutal.

2. La deuda técnica: no es lo que crees

Vale, ya tenemos claro que existe un coste oculto. Ahora vamos a ponerle el nombre que todos hemos oído mil veces, pero que casi nadie sabe explicar bien. Deuda técnica. Y es que, ojo, aquí hay un lío de conceptos tremendo. Si no nos ponemos de acuerdo en qué es, es imposible gestionarla.

"Get things out the door" - Ward Cunningham

La idea original, la de Ward Cunningham, es simplemente brillante y cristalina. Él dijo, mira, esto es como pedir un préstamo al banco. Imagínate que vemos una oportunidad de negocio increíble, pero necesitamos el dinero ya. Pedimos un crédito. Sabemos que vamos a tener que devolverlo y además con intereses. Pues en el desarrollo de software es exactamente lo mismo. A veces, para llegar a tiempo al mercado, tomamos un atajo. Ese atajo es el préstamo. Y los intereses son el dolor que viene después. Tardar más en hacer cambios, que todo sea más frágil, más complicado.

Y aquí, por favor, atención. Tan importante como saber qué es, es saber qué no es deuda técnica. Deuda técnica no es código feo. Que algo sea difícil de leer no es deuda per se. No son bugs. Un error es un error. Punto. Y sobre todo, no es la lista de deseos de producto. No tenemos modo oscuro. No es deuda técnica. Es una funcionalidad que falta. Si metemos todo en el mismo saco, el caos está asegurado.

Y para poner un poco de orden en todo esto, Martin Fowler creó este cuadrante que es una maravilla.

Básicamente nos dice que hay deuda temeraria y deuda prudente. La temeraria es la que acumulamos por ir a lo loco, sin pensar. "No hay tiempo para diseñar, tira millas". Esta es la peor. Pero luego está la prudente. A veces el equipo, de forma consciente, decide tomar un atajo. Sabemos que no es la mejor solución, pero nos permite lanzar en dos semanas. Aceptamos la deuda y pero debemos crear un plan para pagarla. Eso no es una chapuza, eso es una decisión estratégica.

3. ¿Por qué importa y qué impacto tiene en el producto?

Vale, muy bien, todo esto suena muy técnico, pero ¿por qué debería importarle esto a un Product Manager o a un CEO? ¿No es cosa de los programadores? Pues no, rotundamente no. Porque la deuda técnica, al final, no la paga Ingeniería, la paga el negocio y el producto.

Entonces, ¿qué pasa cuando la deuda se descontrola?

1. Que la velocidad se va a pique. Tardamos el triple en sacar cualquier cosa nueva. Adiós a la agilidad.

2. Todo se vuelve súper inestable. Salen bugs de debajo de las piedras. La confianza de los usuarios por los suelos.

3. Los costes se disparan.

4. Esto es súper importante, la moral del equipo se hunde. Y es que a nadie le gusta trabajar en un lodazal.

4. En búsqueda de un lenguaje común

Si buscamos el culpable número uno de que la deuda técnica se convierte en un problema, casi siempre encontramos lo mismo: un muro gigante entre producto e ingeniería. Es la historia de siempre, el día de la marmota. Cuando cada uno se preocupa solo de su mundo, sus objetivos, sus preocupaciones, sus jergas… y sin un lenguaje común, la deuda se convierte en el arma arrojadiza perfecta. ¿Te suena familiar? Es que es un choque de trenes. Pero lo curioso es que ambos trenes quieren llegar al mismo sitio.

Producto piensa, "el tiempo es oro, cada día que no estamos en el mercado es dinero que perdemos". Y tienen razón. Ingeniería piensa, "necesito tiempo para hacer esto bien, porque si no el mes que viene tardaremos el doble". Y también tienen razón. La meta no es que uno gane la batalla, es que ambos ganen la guerra juntos.

5. Construyendo puentes

Entonces, ¿cómo construimos ese puente? Pues hay tres pilares.

A. Contexto: Producto no debe llegar diciendo: "quiero un botón azul aquí". Sino, "necesitamos que los usuarios se fijen hagan click en este botón ya que así aumentarán las ventas". En resumen, debemos de compartir el "porqué" de las cosas y no sólo el "qué"

B. Transparencia total: la conversación tiene que ser: "vale, podemos hacer la versión rápida y salir en dos semanas, pero que sepamos todos que esto nos va a costar una refactorización del componente en el futuro. Lo asumimos". Se hace balance de lo que se gana y se pierde con cada decisión

C. Comunicación bi-direccional: Esto no va de hacer una reunión al mes. Es un diálogo constante, una colaboración real.

6. La caja de herramientas y la gestión con datos

Muy bien, mucha teoría. Muy bonito, pero ¿cómo llevamos esto al día a día? ¿Cómo dejamos de discutir en base a opiniones y empezamos a tomar decisiones con datos? Pues vamos a ver algunas herramientas súper prácticas.

Matriz Impacto / Esfuerzo

La matriz de Impacto / Esfuerzo es un clásico que no falla nunca. Es súper simple, pero potentísima. Permite que todo el equipo, en cinco minutos, ponga cada deuda en su sitio. ¿Qué nos está haciendo mucho daño y es fácil de arreglar? A por ello ya. ¿Qué tiene poco impacto y es un follón? Pues oye, quizá lo dejamos para más adelante y de forma consciente. Nos da un mapa para actuar.

RICE

RICE es genial porque actúa como un traductor universal entre producto e ingeniería. Escoger el método RICE, que se usa para priorizar funcionalidades, y aplicarlo a las tareas técnicas. De repente, ese refactorizar el módulo de pagos que sonaba chino tiene un número, un score, y se puede comparar directamente con una nueva funcionalidad. La conversación sobre qué entra en el sprint cambia por completo. Eso sí, alineado con objetivos de negocio siempre, apoyado en un esfuerzo estimado realista y puntuaciones consensuadas.

TDIR

Y esta, que conocí hace poco, se ha vuelto mi favorita. Se llama TDIR (Technical Debt Interest Rate). Es potentísima porque hace algo que parece magia. Convierte el dolor de la deuda en un número que todo el mundo entiende. Calcula el porcentaje de esfuerzo extra que nos cuesta hacer algo por culpa de la deuda que arrastramos. Es literalmente el interés que estamos pagando por ese préstamo que pedimos. Mirad el ejemplo, se ve clarísimo.

Una tarea que idealmente debería llevar 5 horas nos lleva 8. Pues eso es un interés del 60%. Ya duele. Pero, ¿y el despliegue manual? algo que podría hacerse en una hora, nos lleva cuatro. Estamos pagando un 300% de interés cada vez que lo hacemos. Hay que poner ese número encima de la mesa. Se acabaron las discusiones. La urgencia para automatizar eso se vuelve obvia.

Incorporar DORA y otras métricas de salud técnica

Además de estas herramientas para priorizar y cuantificar la deuda, merece la pena apoyarse en métricas reconocidas de la industria para entender la salud real del delivery. Un buen punto de partida es DORA.dev (DevOps Research and Assessment), el proyecto de referencia detrás del informe “State of DevOps” y adquirido por Google en 2018, que define cuatro indicadores clave que correlacionan directamente con la eficiencia técnica y la estabilidad operativa:

• Lead time for changes: cuánto tardamos en llevar una idea a producción.

• Deployment frequency: con qué frecuencia somos capaces de desplegar nuevas versiones.

• Change failure rate: qué porcentaje de cambios provoca incidentes o fallos.

• Mean time to restore: cuánto tiempo tardamos en recuperarnos cuando algo falla.

Medir estos aspectos de forma continua permite detectar cuándo la deuda técnica empieza a frenar el flujo de entrega mucho antes de que se convierta en crisis.

Además, herramientas como SonarSource o Teamscale ayudan a monitorizar la calidad del código, analizar la complejidad y visualizar tendencias de deterioro o mejora en el tiempo. En conjunto, estos datos convierten la conversación sobre deuda técnica en algo tangible y comparable, no una cuestión de opiniones.

7. Responsabilidad compartida

Por tanto vemos que se produce un cambio de chip total. Tenemos que dejar de pensar en la deuda técnica como limpiar el código o arreglar cosas viejas. Tenemos que empezar a verlo como lo que es, una inversión estratégica. El mensaje es este: pagar deuda técnica no es frenar, es coger carrerilla. No es perder el tiempo, es invertir en velocidad futura. Es como la famosa historia del leñador que no tiene tiempo para afilar la sierra. Pues gestionar la deuda es afilar la sierra. Es una inversión para asegurarnos de que mañana, y pasado mañana, podemos seguir entregando valor de forma rápida y sostenible.

Y creo que esta cita de Ramón Montero (Global Director - Digital Product Engineering en IKEA) lo clava. Lo resume todo a la perfección.

"La deuda no es mala por naturaleza. no es el enemigo, es una herramienta, es una decisión con un costes asociado y una responsabilidad compartida."

La clave está en el concepto responsabilidad compartida. Esto no va de culpar a nadie, va de que todos juntos seamos dueños de las decisiones y de sus consecuencias.

Así que, para terminar, lanzo una pregunta para la próxima vez que en una reunión aparezca la tentación de tomar un atajo. La pregunta no es solo ¿nos dará tiempo a lanzar? La pregunta es ¿estamos pidiendo un préstamo carísimo que nos ahogará en seis meses? ¿O estamos haciendo una inversión inteligente en la velocidad y la salud de nuestro producto a largo plazo? Porque esa, y no otra, es la decisión que de verdad importa.