Deuda técnica sin discursos
Casi toda discusión de deuda técnica se pierde por cómo está planteada: «el código está feo» contra «hay que entregar». La salida no es convencer a nadie de que la calidad importa, es medir el interés que esa deuda cobra por mes.
La metáfora de la deuda es buena y casi siempre se usa a medias. Se habla del capital —lo mal que quedó eso que hicimos apurados— y no del interés, que es lo único que le importa a quien decide: cuánto está costando por mes convivir con eso.
Un préstamo con interés cero no se cancela con urgencia. Uno que cobra el 20 % mensual se cancela ya. La misma deuda técnica puede ser cualquiera de las dos, y no se distinguen mirando el código.
No toda deuda es la misma deuda
Antes de priorizar hay que clasificar, porque cada tipo se paga distinto:
| Tipo | De dónde sale | Qué hacer |
|---|---|---|
| Deliberada y de corto plazo | Sabíamos la forma correcta y elegimos una rápida para llegar a una fecha | Anotarla al tomarla, con la fecha en que se paga. Es la única sana |
| Deliberada y de largo plazo | Una decisión de arquitectura que sirve hoy y no a futuro | Revisarla cuando cambien los supuestos, no antes |
| Accidental | Aprendimos algo después: hoy lo haríamos distinto | Pagarla cuando toque tocar esa zona, no como proyecto aparte |
| Por deterioro | El código no cambió, el mundo sí: versiones sin soporte, dependencias vencidas | Tiene fecha de vencimiento externa. Es la que se convierte en urgencia sola |
Medir el interés
Cuatro preguntas convierten una queja en un número que se puede comparar con cualquier otra cosa del plan:
El interés de una deuda
- ¿A cuánta gente y con qué frecuencia le pasa? Dos personas por sprint no es lo mismo que todo el equipo, todos los días.
- ¿Cuánto cuesta cada vez? Horas de trabajo extra, tiempo de despliegue, un incidente al mes con su tiempo de recuperación.
- ¿Está creciendo? Una deuda estable puede esperar. Una que empeora con cada funcionalidad nueva tiene interés compuesto y hay que atacarla antes.
- ¿Qué está bloqueando? Lo más caro casi nunca es la hora perdida: es la funcionalidad que no se intenta porque «ahí no se puede tocar».
Antes de seguir, predecí
La conversación, en vivo
Escenario · 1 decisión como mínimo
Producto quiere tres funcionalidades este trimestre y vos venís arrastrando una base de datos que aguanta poco
Reunión de planificación. Producto presenta tres funcionalidades para el trimestre. Vos sabés que el esquema actual va a dar problemas serios con cualquiera de las tres, y que arreglarlo son unas cuatro semanas. ¿Con qué abrís?
La respuesta es previsible: «entendemos, pero el trimestre ya está comprometido con los clientes». Quedás en el lugar del que frena. ¿Qué hacés?
La reunión termina con las tres funcionalidades comprometidas y sin tiempo asignado para la base.
DesenlaceSe hace igual, con menos información de la que tenías al empezar. La deuda sigue creciendo y la próxima vez que pidas tiempo vas a arrancar con menos crédito. La conversación técnica se perdió por cómo se planteó, no por lo que decía.
Se comprometen las tres. A la sexta semana, la primera se atrasa por el esquema y hay que explicar por qué.
DesenlaceTermina saliendo una de las tres, tarde, y la deuda quedó peor que al principio: ahora tiene tres funcionalidades encima. Avisar «va a salir lento» sin números no es avisar: nadie puede tomar una decisión con eso.
Producto dice que la primera es la que compromete con dos clientes grandes; las otras dos pueden moverse. ¿Qué proponés?
Proponés: la funcionalidad prioritaria sale en seis semanas en vez de dos, con el esquema arreglado; las otras dos se mueven al trimestre siguiente y salen más rápido porque ya no pelean con la base. Traés el costo de cada opción escrito.
DesenlaceEs la conversación que querías tener, y ahora es una decisión de negocio con números de los dos lados. Puede que digan que no, pero se decide con la información completa y vos conservás el crédito para la próxima. La deuda se paga mejor pegada a algo que la empresa ya quiere.
Se acuerda hacerla sobre el esquema viejo. ¿Qué dejás por escrito?
Pasan cuatro meses y tres funcionalidades más sobre el mismo esquema.
DesenlaceLa conversación hay que volver a darla desde cero, ahora con más capital y más interés, y sin ningún registro de que alguna vez fue una decisión deliberada. Es el camino por el que casi toda deuda deliberada se vuelve accidental.
Queda una nota corta: qué se hizo rápido, qué cuesta por mes, qué lo destraba y cuándo se revisa.
DesenlaceEs un final razonable. No pagaste la deuda, pero dejó de ser invisible: tiene interés medido y fecha de revisión, y la próxima conversación arranca con evidencia en vez de con una sensación.
Podés recorrerlo varias veces. Los caminos que terminan mal no son trampas: son las dos formas en que esta conversación se pierde de verdad.
Cómo se paga en la práctica
Casi nunca conviene el «proyecto de refactor» de tres meses: es lo más difícil de defender, lo más fácil de cancelar a la mitad y lo que más riesgo acumula antes de dar algún beneficio. Tres formas que sí funcionan:
- Pegada a la funcionalidad que la necesita. Es el argumento más fuerte que existe, porque ya no compite con producto: es parte del costo de algo que producto quiere.
- Regla del campamento, con límite. Cada vez que se toca una zona, se deja un poco mejor que como estaba. Sirve para la deuda dispersa; no sirve para la estructural, y conviene ponerle un techo para que no se convierta en cambios enormes en cada revisión.
- Un porcentaje fijo del tiempo, acordado y visible. Entre un 10 % y un 20 % declarado, con lo que se hizo contado igual que cualquier otra entrega. Lo que se hace a escondidas nunca cuenta como resultado.
Más a fondo · nivel seniorEl registro de deuda que no se vuelve un cementerio
Casi todos los equipos intentan una vez una lista de deuda técnica, y casi todas terminan con ochenta ítems que nadie lee. Lo que la mantiene viva son tres reglas: cada entrada incluye el interés medido —no la descripción del problema—; se revisa en la misma reunión donde se planifica, no en una aparte; y lo que lleva dos revisiones sin que a nadie le importe se borra.
Borrar es la regla incómoda y la más importante. Una deuda que hace seis meses que nadie prioriza está diciendo que su interés es más bajo de lo que se creyó al anotarla. Dejarla ahí no la hace más probable: hace menos creíble a toda la lista.
Lo que preguntan sobre esto
Cierre
Autoevaluación
¿Lo entendiste?
Práctica