La deuda técnica se invoca a menudo para explicar un retraso, un incidente o una solicitud de rediseño. El término se convierte entonces en un contenedor vago donde se mezclan código antiguo, arquitectura, documentación, seguridad, datos e irritantes de los desarrolladores. Mientras siga formulada así, es difícil de financiar y casi imposible de gestionar.
Una deuda descrita de manera útil conecta un hecho técnico con una consecuencia observable: una evolución toma tres veces más tiempo, una actualización no puede aplicarse, un incidente puede borrar datos o cada despliegue requiere una manipulación manual. Esta traducción permite comparar la deuda con otras inversiones de producto.
La deuda técnica no es necesariamente un error
Un compromiso puede ser racional. Un equipo puede aceptar una solución simple para validar un mercado, posponer una automatización o mantener una tecnología estable para cumplir un plazo. La deuda aparece cuando este compromiso aumenta el costo futuro. Se vuelve peligrosa cuando nadie conoce su existencia, su propietario o su fecha de reevaluación.
Por lo tanto, hay que distinguir:
- la deuda deliberada, elegida y documentada;
- la deuda accidental, nacida de una falta de conocimiento o de un efecto inesperado ;
- la deuda de obsolescencia, creada por la evolución de las dependencias e infraestructuras;
- la deuda funcional, cuando se siguen manteniendo reglas o pantallas innecesarias;
- la deuda operativa, relacionada con los despliegues, copias de seguridad, alertas y procedimientos manuales.
No todas se tratan con el mismo presupuesto ni por el mismo equipo.
Por qué una estimación en días de corrección no es suficiente
Evaluar únicamente el esfuerzo produce una lista de trabajos, no una prioridad. Un elemento costoso puede no tener impacto inmediato, mientras que una corrección de dos horas puede eliminar un riesgo crítico. Por el contrario, el número de anomalías detectadas por una herramienta no refleja ni la criticidad de los procesos ni la frecuencia de las modificaciones.
Una medida útil combina al menos cuatro dimensiones:
- probabilidad de que se manifieste un problema ;
- impacto en el trabajo, los datos, la seguridad o la reputación;
- frecuencia de exposición, es decir, cuántos cambios o usuarios afectan la zona;
- coste del retraso, que aumenta si la deuda sigue extendiéndose.
El esfuerzo de corrección interviene después para elegir el orden y agrupar los trabajos.
Una unidad de deuda explotable
Cada elemento del registro debe seguir una estructura común:
- constat: lo que se observa objetivamente ;
- prueba: medida, incidente, versión, test o ejemplo;
- consecuencia: lo que esto impide o debilita;
- perímetro: módulos, datos y usuarios involucrados;
- acción: corrección, aislamiento, reemplazo o aceptación;
- esfuerzo: orden de magnitud y dependencias;
- fecha de revisión: momento en que el compromiso debe ser reconsiderado.
Por ejemplo, «el código está mal diseñado» no es útil. «Cualquier modificación en el cálculo de la prima obliga a duplicar la regla en cuatro módulos, lo que provocó dos discrepancias de resultados en seis meses» permite tomar decisiones.
El esquema es un cuadrante de dos ejes. La urgencia del negocio aumenta de abajo hacia arriba y el esfuerzo de corrección aumenta de izquierda a derecha. La zona 1, en la parte superior izquierda, recomienda corregir rápidamente los elementos urgentes y poco costosos. La zona 2, en la parte superior derecha, pide iniciar un proyecto estructurado para los elementos urgentes y costosos. La zona 3, en la parte inferior izquierda, propone agrupar los elementos poco urgentes y poco costosos con una evolución próxima. La zona 4, en la parte inferior derecha, conduce a aceptar temporalmente, supervisar o eliminar los elementos poco urgentes y costosos. Cada zona lleva un número y una acción explícita para que el color nunca sea la única información. La siguiente tabla constituye una representación textual equivalente.
| Zona | Urgencia profesional | Esfuerzo de corrección | Acción propuesta |
|---|---|---|---|
| 1 — Corrección rápida | fuerte | débil | corregir rápidamente |
| 2 — Obra estructurada | fuerte | fortaleza | planificar y financiar un proyecto de construcción |
| 3 — Agrupamiento | débil | débil | tratar con una evolución cercana |
| 4 — Vigilancia | débil | fortaleza | aceptar temporalmente, supervisar o eliminar la función |
Clasificar la deuda por área
Arquitectura
Acoplamiento excesivo, fronteras de negocio ausentes, dependencias circulares, puntos únicos de fallo o servicios fragmentados sin beneficio. La respuesta no siempre es una nueva arquitectura: puede comenzar por una fachada, un contrato de API o una división de responsabilidades.
Código y dependencias
Complejidad, duplicación, convenciones incoherentes, componentes no soportados o bibliotecas difíciles de actualizar. Los análisis automáticos identifican tendencias; la prioridad depende de la exposición y de la frecuencia de cambio.
Datos
Esquemas incoherentes, ausencia de restricciones, migraciones no reproducibles, duplicados, tratamientos manuales o retención no controlada. La deuda de datos a menudo es más costosa de corregir tarde que la deuda de código.
Pruebas
Recorridos críticos no protegidos, pruebas inestables, suites demasiado lentas o dependientes de entornos externos. El objetivo no es un porcentaje máximo, sino una confianza proporcional al riesgo.
Seguridad
Secretos, derechos, diarios, dependencias vulnerables o ausencia de procedimiento de corrección. Una deuda de seguridad puede requerir un tratamiento inmediato, independientemente de su rendimiento aparente.
Explotación
Despliegues manuales, copias de seguridad no probadas, alertas ausentes, configuraciones divergentes o dependencia de una persona. Esta deuda a menudo se revela durante un incidente, cuando el tiempo cuesta más.
Documentación y conocimiento
Decisiones no explicadas, procedimientos obsoletos, ausencia de glosario profesional o de propietario. La documentación debe enfocarse en lo que sería difícil de reconstruir, no en describir cada línea.
Usar una matriz, sin creer en una fórmula mágica
Una matriz de urgencia/esfuerzo ayuda a visualizar:
- fuerte urgencia, bajo esfuerzo : corregir rápidamente ;
- urgencia fuerte, gran esfuerzo: lanzar un proyecto estructurado;
- baja urgencia, bajo esfuerzo: agrupar con una evolución cercana;
- baja urgencia, gran esfuerzo: aceptar temporalmente, supervisar o eliminar la función.
La puntuación no reemplaza el juicio. Un riesgo de seguridad o de integridad puede exigir una acción incluso si su probabilidad parece baja. Las ponderaciones deben ser visibles y revisables.
Reservar una capacidad recurrente
Tratar la deuda únicamente « cuando queda tiempo » equivale a no tratarla nunca. Una estrategia más eficaz combina tres mecanismos:
- un porcentaje de capacidad recurrente dedicado a las mejoras ;
- criterios de calidad integrados en cada nueva funcionalidad;
- proyectos específicos cuando la causa supera un módulo.
El porcentaje no es universal. Depende del riesgo, del ritmo producido y del estado de la plataforma. Lo que importa es la visibilidad: la deuda se arbitra con las evoluciones, no se oculta en sus estimaciones.
Reducir la deuda sin iniciar una gran limpieza
La primera técnica es la regla del vecindario: cuando se modifica una zona, mejorar lo necesario para hacer que el cambio sea seguro, sin ampliar indefinidamente el perímetro. La segunda es la adición de pruebas de caracterización antes de cualquier transformación. La tercera consiste en crear fronteras estables para impedir la propagación.
Algunas deudas deben ser eliminadas por el producto: retirar una función no utilizada, reducir una variante o armonizar un proceso puede ahorrar más que una refactorización. Otras requieren una actualización de versión o un reemplazo de componente planificado.
Medir la reducción, no la actividad
Contar los tickets cerrados anima a dividir artificialmente. Indicadores más útiles siguen el resultado:
- plazo medio de una evolución en las zonas concernidas;
- tasa de fracaso de los despliegues ;
- incidentes y tiempos de recuperación;
- nombre de dependencias fuera de soporte;
- parte de los recorridos críticos protegidos;
- número de operaciones manuales;
- tiempo necesario para que una nueva persona intervenga.
Una deuda puede considerarse controlada cuando es conocida, circunscrita, supervisada y compatible con la estrategia, aunque no esté totalmente eliminada.
Presentar la deuda a los responsables de la toma de decisiones
El lenguaje debe centrarse en la elección. «Invertir diez días permite reducir el tiempo de entrega de las reglas tarifarias y evitar cuatro implementaciones divergentes» es más útil que «refactorizar el módulo». El registro debe mostrar la opción de no hacer nada y su costo probable.
Un cuadro trimestral puede presentar los riesgos mayores, las acciones terminadas, los nuevos elementos, la capacidad consumida y la evolución de los indicadores. Esta transparencia evita que la deuda se descubra en ocasión de una solicitud urgente.
Hacer de la deuda una herramienta de estrategia
No existe una plataforma sin ninguna deuda. La calidad proviene de la capacidad de elegir los compromisos, de hacerlos visibles y de pagarlos antes de que bloqueen el valor. La deuda se convierte entonces en una cartera de riesgos e inversiones, no en un reproche dirigido al pasado.
Partitech puede auditar una aplicación existente, construir un registro priorizado e integrar la reducción de deuda en una hoja de ruta de mantenimiento o modernización. El objetivo es asegurar el producto mientras se mantiene un ritmo de evolución útil para el negocio.
Para prolongar este enfoque, comience por un auditoría técnica completa de la aplicación, defina una trayectoria para modernizar una aplicación heredada, encuádrelo mantenimiento de aplicaciones y sus niveles de servicio y descubran los prestaciones Partitech.
Referencias oficiales
Referencias verificadas el 17 de agosto de 2026 :