¿Cómo decides cuánto tiempo dedicar a deuda técnica frente a nuevas funcionalidades?

Trata la deuda como un coste de negocio y no como una cuestión moral. Cuantifícala: cuánto ralentiza la entrega, cuántos incidentes causa, qué pasa si falla. Luego finánciala en la misma conversación que las funcionalidades, ya sea como una asignación fija (a menudo del quince al veinte por ciento) o pegada al trabajo de roadmap que toca esa zona. Paga la deuda que de verdad está cobrando intereses, no el código que te desagrada.

Me niego a plantearlo como un argumento moral aparte, porque ingeniería siempre pierde ese. Lo convierto en una conversación de costes. Mantenemos un registro de deuda con una estimación de lo que nos cuesta cada punto: este servicio añade dos días a cada funcionalidad que lo toca, aquel causó cuatro de los últimos diez incidentes, esta dependencia deja de tener soporte en nueve meses y bloquea una renovación de cumplimiento. Luego priorizo por tipo de interés y no por lo feo que sea el código, porque hay montones de código horrible que está estable, nadie lo toca y puede seguir así para siempre. Sobre la financiación, mi opción por defecto es un veinte por ciento fijo más limpieza pegada al trabajo de roadmap, así que si ya estamos en esa zona lo arreglamos de paso. El argumento que cala con producto siempre es el de la entrega. En mi último equipo pude demostrar que dos tercios de nuestro tiempo de incidentes venían de una única ruta legacy, y una vez planteado como perdemos una semana al mes por esto, el arreglo de seis semanas se vendió solo en vez de ser una pelea.