Cómo identificar deuda técnica que ya afecta al negocio

«Ese cambio es pequeño, ¿por qué tarda tres semanas?»

Es una pregunta que muchas gerencias le hacen a su equipo técnico o a su proveedor. A veces la respuesta es mala estimación. Muchas otras, la respuesta es deuda técnica: decisiones del pasado que hicieron el sistema más difícil de cambiar, y que ahora cobran intereses en cada modificación.

Martin Fowler describe la deuda técnica con esa metáfora: el atajo de hoy es un préstamo, y el esfuerzo adicional que exige cada cambio futuro son los intereses. No toda deuda es mala; a veces conviene tomarla para llegar a tiempo. El problema es no saber cuánta tienes.

Síntomas que puedes ver sin leer código

Un síntoma no es un diagnóstico. Dos sistemas con el mismo síntoma pueden tener causas distintas, y la única forma de saberlo es inspeccionar.

Reunir evidencia

• Tiempos: cuánto tardaron los últimos cambios frente a lo estimado.
• Incidentes: qué errores se repitieron y cuánto costó resolverlos.
• Versiones: qué lenguaje, framework o plugins usas y si siguen con soporte. PHP, por ejemplo, publica qué versiones tienen soporte activo y de seguridad.
• Despliegues: con qué frecuencia y con cuántos fallos. Las métricas DORA ofrecen un marco para medir frecuencia, tiempo de entrega, tasa de fallos y tiempo de recuperación.
• Seguridad: si hay revisiones pendientes frente a riesgos conocidos, como los que lista OWASP.

Consecuencias y riesgo

Para cada deuda identificada, escribe su consecuencia en lenguaje de negocio: «cada cambio en el cotizador cuesta el doble», «una versión sin parches de seguridad expone los datos de clientes». Luego estima la probabilidad y el impacto. Esto convierte una conversación técnica en una decisión de inversión.

Priorizar

1. Primero, lo que es riesgo de seguridad o de continuidad.
2. Luego, lo que frena las iniciativas de tu hoja de ruta.
3. Después, lo que genera errores repetidos.
4. Por último, lo que solo incomoda.

No hace falta pagar toda la deuda. A menudo basta con reducirla en las zonas que más cambias.

Ejemplo aplicado

Límites

Esta guía ayuda a reconocer señales y ordenar la conversación. No reemplaza una inspección técnica del sistema, y ningún diagnóstico serio debería emitirse sin ella.

Cómo usar el registro descargable

1. Registra cada síntoma con su evidencia.
2. Indica si fue inspeccionado.
3. Escribe la consecuencia de negocio.
4. Califica probabilidad e impacto.
5. Lleva las prioridades altas a tu hoja de ruta.

Criterios para priorizar

Ejemplo sintético completo

Ejemplo sintético. En una empresa ficticia, cada cambio al módulo de facturación tarda semanas y suele romper otra cosa. El gerente registra tres síntomas con evidencia: los últimos cuatro cambios generaron errores en producción, solo una persona entiende el módulo y la librería de generación de PDF no se actualiza desde hace años.

Pide una inspección técnica acotada. El informe confirma que el módulo no tiene pruebas automáticas y que la librería ya no recibe actualizaciones de seguridad. Traducido a negocio: cada cambio arriesga errores en facturas a clientes y la empresa depende de una sola persona.

Prioriza: alta probabilidad y alto impacto. Agrega a la hoja de ruta dos acciones: pruebas básicas sobre los flujos de facturación más usados y reemplazo de la librería. Documenta el conocimiento de la persona clave en paralelo. Ejemplo inventado.

Preguntas para tu equipo técnico o proveedor

• ¿Qué partes del sistema da miedo tocar y por qué?
• ¿Qué componentes ya no reciben actualizaciones?
• ¿Cuánto del sistema tiene pruebas automáticas?
• ¿Qué conocimiento está solo en la cabeza de una persona?
• ¿Qué costaría no hacer nada durante seis meses?

Cómo saber si funcionó

• Cada síntoma tiene evidencia y consecuencia de negocio.
• Las prioridades altas están en la hoja de ruta.
• El conocimiento crítico está documentado.

Plan para las primeras cuatro semanas

1. Semana 1: registra síntomas con evidencia.
2. Semana 2: pide una inspección acotada.
3. Semana 3: traduce hallazgos a consecuencias y prioriza.
4. Semana 4: lleva acciones a la hoja de ruta.

Diagnóstico antes de empezar

• Lista los cambios que tardaron más de lo esperado en el último semestre.
• Pregunta qué partes del sistema evitan tocar los desarrolladores.
• Revisa cuándo se actualizaron por última vez los componentes principales.

Un segundo ejemplo, en contraste

Ejemplo sintético. Una empresa ficticia sospecha deuda técnica porque los cambios son lentos. La inspección muestra un sistema razonablemente sano: la lentitud venía de requerimientos poco claros. En lugar de reescribir código, mejora cómo pide los cambios. A diferencia del primer ejemplo, el síntoma no era deuda técnica. Ejemplo inventado.

Qué hacer cuando algo falla

• Si la inspección no es concluyente, pide evidencia concreta por cada hallazgo.
• Si una corrección rompe otra cosa, agrega pruebas antes de seguir.
• Si no hay presupuesto, prioriza solo lo de alto riesgo.

Cómo medirlo con tus propios datos

• Registra el tiempo entre pedir un cambio y tenerlo en producción.
• Cuenta los errores en producción que aparecen después de cada cambio.
• Anota cuántas veces se necesita a la persona clave para resolver algo.
• Revisa cuántos componentes siguen sin actualizaciones.

Toma estos datos antes de atacar la deuda y repítelos tres meses después. Si los cambios tardan menos y generan menos errores, la inversión está dando resultado. Si no cambian, revisa si la acción elegida atacaba la causa real o solo un síntoma.

Errores frecuentes

• Diagnosticar por síntomas sin inspeccionar.
• Querer reescribir todo de cero.
• Ignorar la deuda hasta que hay un incidente.
• Describir la deuda solo en términos técnicos.
• No registrar la deuda que se toma a propósito.

Checklist

• Síntomas con evidencia.
• Inspección antes de diagnosticar.
• Consecuencias en lenguaje de negocio.
• Prioridad por riesgo.
• Acciones en la hoja de ruta.