Cómo auditar tu deuda técnica antes de iniciar proyectos en 2025

Cada enero pasa lo mismo: el equipo de tecnología presenta su roadmap del año, el comité lo aprueba, arrancan los proyectos. Tres meses después, dos cosas explotan al mismo tiempo. Una integración vieja se rompe porque un proveedor actualizó su API, y el módulo nuevo no avanza porque depende de un servicio que está amarrado a una versión de PHP que nadie quiere tocar.

La causa casi siempre es la misma: no se hizo una auditoría honesta de la deuda técnica antes de planear el año. Los proyectos nuevos se construyen sobre una base que ya estaba pidiendo mantenimiento desde hace dos años.

Esta guía es el marco que usamos en ALCA para auditar deuda técnica en cualquier organización mediana en aproximadamente dos semanas, y traducirla en un roadmap que se puede defender frente a un CFO sin entrar en jerga.

Qué cuenta como deuda técnica (y qué no)

El primer error es pensar que deuda técnica es solo "código legacy". Es más amplio. Para nosotros, deuda técnica es cualquier decisión técnica pasada que hoy te cobra interés: te frena, te cuesta más, te expone a riesgo o te quita opciones.

Eso incluye seis dimensiones:

• Código: funciones gigantes, ausencia de pruebas, frameworks descontinuados, dependencias sin actualizar.
• Datos: modelos inconsistentes, falta de master data, duplicidad entre sistemas, calidad pobre que envenena reportes.
• Infraestructura: servidores sin parches, configuraciones manuales no documentadas, falta de respaldos, monitoreo inexistente.
• Dependencias externas: APIs de proveedores en deprecación, contratos con un único proveedor crítico, software que ya no recibe soporte.
• Procesos: despliegues manuales, ambientes que no se parecen a producción, ausencia de pruebas automatizadas.
• Conocimiento: una sola persona que entiende cómo funciona un módulo crítico, documentación obsoleta o inexistente.

Si tu auditoría solo mira las primeras dos dimensiones, vas a tener una foto a medias.

El marco de auditoría en 2 semanas

Una auditoría de deuda técnica no necesita 6 meses ni un consultor con 14 hojas de spec. Con método, se hace en 10 días hábiles y queda lo suficientemente accionable.

Semana 1: levantamiento

Día 1-2. Inventario. Lista de aplicaciones, servicios, integraciones y bases de datos. Para cada uno: lenguaje, versión, fecha de último cambio, dueño actual, criticidad para el negocio.

Día 3-4. Entrevistas técnicas. 45 minutos por persona clave del equipo de ingeniería. Las preguntas que mejor sacan información:

• "Si te dijera que tienes que dejar de mantener tres cosas hoy, ¿cuáles serían?"
• "¿Qué parte del sistema te da miedo tocar?"
• "¿Dónde sentiste que la calidad bajó en los últimos 12 meses?"

Día 5. Entrevistas de negocio. 30 minutos con responsables comerciales, operativos y de finanzas. Preguntas:

• "¿Qué reporte o proceso te frustra constantemente?"
• "¿Qué pediste que no se haya podido entregar y por qué te dijeron que no?"
• "¿Qué tan rápido podemos lanzar algo nuevo cuando lo pides?"

Semana 2: medición y priorización

Día 6-7. Indicadores cuantitativos. Para cada aplicación del inventario, medir:

• Antigüedad del framework (versiones detrás de la actual estable).
• Cobertura de pruebas (si hay).
• Tiempo medio entre despliegues (deployment frequency).
• Tiempo medio de recuperación ante falla (MTTR).
• Número de incidentes abiertos en el último trimestre.
• Costo mensual de infraestructura asociada.
• Número de personas que pueden hacer cambios sin supervisión.

Estos números son crudos pero son objetivos. Te quitan la conversación del "yo creo" y la llevan al "esto es lo que está pasando".

Día 8-9. Matriz impacto / esfuerzo. Cada ítem de deuda detectado se ubica en una matriz simple:

• Alto impacto, bajo esfuerzo: quick wins, hazlos en este trimestre.
• Alto impacto, alto esfuerzo: proyectos grandes, planéalos con presupuesto y fechas reales.
• Bajo impacto, bajo esfuerzo: llénalos cuando haya ventana, no son prioridad.
• Bajo impacto, alto esfuerzo: no los toques este año (o nunca).

Día 10. Reporte ejecutivo. Una sola página con: top 5 riesgos, top 5 oportunidades de ahorro, propuesta de inversión (en horas o dinero) y resultados esperados.

Cómo véndelo a finanzas y al CEO

Aquí es donde fallan la mayoría de los líderes técnicos. Llegan con una lista de 47 ítems técnicos, mezclan urgente con importante, y pierden la conversación. La forma de ganarla:

Habla en su idioma. No "tenemos que migrar de Node 12 a Node 20". Sí "tenemos un componente crítico que pierde soporte oficial en marzo; si no actuamos, el riesgo de un incidente sin parche disponible se vuelve real, con un costo estimado de X horas de operación afectada".

Atribuye número. Cada ítem del top 5 debe tener: costo de no hacer nada, costo de hacerlo, ahorro o riesgo evitado. Aunque sean estimados, te da una conversación real.

Conecta con prioridades del año. Si el negocio quiere lanzar un nuevo producto, muestra qué ítems de deuda son bloqueadores de ese lanzamiento y cuáles no. La deuda que bloquea estrategia se aprueba sola.

Propón ventanas, no proyectos enormes. "Reservar el 20% de la capacidad del equipo durante Q1 para deuda crítica" es más digerible que "necesitamos un proyecto de 4 meses dedicado a esto".

Errores comunes que vemos cada año

Algunos patrones que se repiten en las primeras auditorías:

• Sobrevalorar la deuda de código y subvalorar la de datos. El código se reescribe; los datos sucios contaminan decisiones por años.
• No entrevistar al área de negocio. La deuda más costosa muchas veces es la que el negocio percibe como "lentitud para entregar", no como problema técnico.
• Confundir refactor con modernización. Refactorizar código viejo no soluciona que el modelo de datos no soporta las nuevas necesidades del negocio.
• No documentar el inventario. Si la auditoría vive en la cabeza de quien la hizo, en seis meses se perdió.

Qué sigue después de la auditoría

La auditoría es solo el primer paso. El siguiente, igual de crítico, es definir el ritmo continuo: revisar la deuda al inicio de cada trimestre, asignar entre 15% y 25% de la capacidad del equipo a pagarla, y medir trimestre contra trimestre si está bajando o subiendo.

Las empresas que tratan deuda técnica como un evento anual nunca avanzan. Las que la tratan como una línea de producto continua llegan a 2026 con una base sobre la cual sí se puede construir el siguiente nivel de IA, automatización y compliance que el año va a exigir.

---

Si quieres apoyo para correr esta auditoría con tu equipo en 2 semanas, en ALCA tenemos un formato probado. Solicita una llamada de 30 minutos y te compartimos el checklist completo.