5 min read
Le decís a tu gerente de producto: “Necesitamos dos sprints para refactorizar el módulo de facturación, tiene mucha deuda técnica”.
Y la respuesta es siempre la misma: “¿Y qué gana el negocio con eso? Tenemos cuatro funcionalidades comprometidas con clientes para este trimestre”.
La conversación termina con la refactorización al fondo del backlog, otra vez.
El problema rara vez es que el negocio no valore la calidad. El problema es el idioma.
Cuando decís “deuda técnica”, la otra persona escucha “los programadores quieren limpiar su código”.
Para conseguir apoyo hay que traducir el problema a lo que el negocio mide: dinero, riesgo y velocidad.
¿Qué es la deuda técnica (y qué no es)?
Ward Cunningham, quien acuñó el término, lo explicó con una metáfora financiera: tomar un atajo en el código es como pedir un préstamo.
Te permite entregar más rápido hoy, pero pagás intereses cada vez que tenés que trabajar sobre ese código. Si pagás la deuda (refactorizás), los intereses desaparecen. Si no, los intereses se acumulan hasta que cada cambio cuesta el doble de lo que debería.
Ojo con lo que no es deuda técnica: el código feo que nadie toca no genera intereses, y por lo tanto no es una prioridad.
La deuda importa cuando está en una zona del sistema que cambia seguido, o que falla en producción.
Cómo traducirla al lenguaje del negocio
| Lo que dice el equipo técnico | Lo que escucha el negocio |
|---|---|
| “El módulo de facturación está muy acoplado” | “Agregar un nuevo método de pago nos tomaría 6 semanas en lugar de 1” |
| “No tenemos pruebas automáticas ahí” | “Cada cambio en facturación requiere 3 días de pruebas manuales y aun así se nos escapan errores” |
| “La arquitectura no escala” | “En el próximo pico de ventas, el sistema podría caerse y perderíamos ingresos” |
| “El código es difícil de entender” | “Un desarrollador nuevo tarda 2 meses en poder tocar esta parte sin riesgo” |
Guía paso a paso
Paso 1 — Identificá el costo concreto
Buscá evidencia en datos que el negocio respete: tiempo que toma un cambio típico en esa zona, cantidad de incidentes en producción, horas de soporte consumidas, funcionalidades que no se pudieron entregar. Tu historial de tickets y de despliegues tiene mucho de esto.
Paso 2 — Convertilo a unidades de negocio
“Cada funcionalidad de facturación tarda un promedio de 12 días; en el resto del sistema son 4. Eso significa 8 días extra por cada una, con 6 funcionalidades al trimestre: 48 días de equipo.” Dinero, tiempo, riesgo de ingresos o riesgo regulatorio.
Paso 3 — Presentá opciones, no un ultimátum
En lugar de “necesitamos dos sprints”, ofrecé alternativas con sus compromisos:
- Opción A: no hacer nada. Costo: se mantiene el sobrecosto de 8 días por funcionalidad, y el riesgo de incidentes.
- Opción B: refactorizar de forma incremental, dedicando 20% de cada sprint durante un trimestre mientras se entregan las funcionalidades.
- Opción C: pausar funcionalidades dos sprints y resolverlo de una vez. Más rápido, pero con costo de oportunidad.
Paso 4 — Atalo a un objetivo del negocio
Conectalo con algo que ya importa: “Esto nos permite lanzar el nuevo plan de suscripciones en enero sin riesgo” es más persuasivo que “esto mejora la calidad”.
Paso 5 — Medí el resultado después
Si prometiste que los cambios en facturación pasarían de 12 a 5 días, mostrá el resultado. Esa evidencia es lo que hace que la próxima conversación sea más fácil.
Para tener en cuenta
- Hacé visible la deuda de forma continua: mantené un registro de deuda técnica (en el mismo backlog) con el impacto estimado de cada ítem, así la conversación no empieza de cero cada vez.
- Distinguí tipos de deuda: la deuda deliberada y prudente (“entregamos rápido y lo arreglamos después”) es una herramienta legítima; la deuda imprudente por descuido no lo es. El cuadrante de deuda técnica de Martin Fowler ayuda a explicarlo.
- Usá métricas reconocidas: el informe Accelerate y las métricas DORA (DevOps Research and Assessment — Investigación y Evaluación de DevOps), como tiempo de entrega y tasa de fallos en cambios, conectan la calidad técnica con resultados de negocio.
- No exageres: si todo es “crítico”, nada lo es. Pedí lo que realmente tiene impacto y perderás menos credibilidad.
- Pagá deuda mientras trabajás: la regla del boy scout (dejar el código un poco mejor de como lo encontraste) evita que las deudas pequeñas se acumulen sin necesitar un proyecto aparte.
Conclusión
Cuando explicás la deuda técnica como un problema de código, competís con funcionalidades que tienen clientes esperando.
Cuando la explicás como un costo medible en dinero, tiempo y riesgo, dejás de pedir un favor y pasás a presentar una decisión de inversión.
Esa traducción es una de las habilidades que más rápido te acercan a roles de liderazgo técnico.
Recordá suscribirte aquí para recibir los próximos posts directamente en tu correo.
Referencias:
Martin Fowler — Technical Debt: https://martinfowler.com/bliki/TechnicalDebt.html
Accelerate — Nicole Forsgren, Jez Humble, Gene Kim
Ward Cunningham — The WyCash Portfolio Management System (1992)