Cómo auditar tu deuda técnica antes de iniciar proyectos en 2024
Cada enero recibimos la misma llamada al menos cinco veces: "tenemos un proyecto importante que arranca este trimestre y queremos asegurarnos de que el sistema lo aguante". A veces lo aguanta. Casi siempre, debajo del proyecto nuevo hay deuda técnica acumulada que va a sabotear el plan en los meses 3 a 6, justo cuando ya es tarde para corregir.
En ALCA usamos un marco de auditoría de deuda técnica que se corre en 2 semanas con el equipo interno del cliente. No reemplaza una refactorización profunda; es el paso previo: medir, priorizar y armar el roadmap con números que finanzas pueda aprobar. Aquí lo compartimos completo, paso a paso, para que puedas correrlo tú mismo.
La deuda técnica no es solo código
El error más común es pensar deuda técnica como "código viejo que hay que rescribir". Eso es una parte. En realidad la deuda se acumula en seis dimensiones:
- Código. Funciones largas, duplicación, ausencia de pruebas, dependencias de versiones obsoletas.
- Datos. Esquemas inconsistentes, llaves duplicadas, falta de catálogos maestros, integraciones por archivos planos.
- Infraestructura. Servidores configurados a mano, sin IaC, sin monitoreo, sin política de backups probada.
- Dependencias. Librerías sin actualizar, vulnerabilidades conocidas, soporte vencido.
- Procesos. Despliegues manuales, sin CI/CD, sin code review, sin gestión de incidentes.
- Conocimiento. Sistemas que solo entiende una persona, ausencia de documentación, falta de ADRs (Architecture Decision Records).
Una auditoría seria mide las seis dimensiones por separado, porque las soluciones (y los costos) son distintos.
Semana 1: levantamiento
La primera semana es de captura. Sin priorizar, sin debatir, sin proponer soluciones. Solo medir.
Día 1-2: inventario de sistemas
Lista todos los sistemas en operación, con tres datos por cada uno:
- Criticidad de negocio (alta / media / baja).
- Responsable técnico (persona o equipo).
- Stack tecnológico (lenguaje, framework, base de datos, hosting).
Para una empresa mediana esto suele dar entre 8 y 25 sistemas. Si te dan más de 40, ya hay un problema de gobernanza adicional.
Día 3-4: escaneo automático de código
Herramientas gratuitas que vale la pena correr:
- SonarQube Community o CodeClimate para deuda técnica de código (complejidad ciclomática, duplicación, code smells).
- OWASP Dependency-Check o Snyk (tier gratuito) para vulnerabilidades en dependencias.
- Trivy o Grype para imágenes Docker.
- GitHub / GitLab insights para frecuencia de commits, edad de PRs, contributor concentration.
El output de cada uno se vuelve un anexo del reporte final. No interpretes todavía, solo captura.
Día 5: entrevistas con líderes técnicos
30 minutos con cada líder de equipo, preguntas estructuradas:
- ¿Qué sistema te preocupa más a 12 meses y por qué?
- ¿Qué pasa si el responsable principal renuncia mañana?
- ¿Cuántas veces al mes hay incidentes en producción?
- ¿Hay procesos manuales que deberían estar automatizados pero no lo están?
Documenta literal, no parafrasees. Las palabras exactas de los técnicos son la mejor evidencia para el reporte ejecutivo.
Semana 2: medición y priorización
Con los datos de semana 1, la segunda semana es analítica.
Día 6-7: scoring por dimensión
Califica cada sistema en cada dimensión de 0 (sano) a 5 (crítico). Una matriz simple de sistemas (filas) por dimensiones (columnas) te da el mapa de calor de deuda.
Criterios concretos para cada nivel:
- 0-1 sano: prácticas modernas, monitoreo, pruebas, documentación.
- 2-3 manejable: algunos pendientes, pero sin riesgo crítico.
- 4 elevado: puede romper en cualquier momento bajo carga inusual.
- 5 crítico: ya está rompiendo o está a una semana de hacerlo.
Día 8: estimación de costo de no actuar
Por cada sistema con score 4 o 5, calcula el costo anualizado de no resolver. Variables:
- Horas de operación / firefighting al mes.
- Probabilidad de incidente mayor (estimación, no precisa).
- Costo de la última outage equivalente.
- Costo de oportunidad: features que no se entregan por dedicar tiempo a apagar fuegos.
Para una empresa mediana, este número típicamente cae entre $500,000 y $4,000,000 MXN anuales por sistema con score 5. Es la cifra que abre la conversación con finanzas.
Día 9: propuesta de roadmap
Tres horizontes:
- Trimestre 1: emergencias. Lo que ya está rompiendo o está a punto. Parches, migraciones de versión, backups probados, monitoreo básico.
- Año 1: estructurales. Refactorizaciones grandes, migración de stack, automatización de despliegues, programa de actualización de dependencias.
- Año 2-3: estratégicas. Reescrituras completas, cambio de arquitectura, modernización de plataforma de datos.
Cada item con estimación de esfuerzo (en semanas-persona) y costo (en MXN, incluyendo contratación o consultoría externa si aplica).
Día 10: presentación ejecutiva
El reporte final tiene tres partes para audiencia ejecutiva:
- Mapa de calor (1 página): la matriz de sistemas x dimensiones con colores.
- Top 5 riesgos (1 página): qué puede romper, costo estimado si pasa.
- Roadmap propuesto (1-2 páginas): qué resolver cuándo, costo de cada bloque, ROI implícito vs costo de no actuar.
Ese paquete es lo que se presenta a CEO y CFO. No el reporte técnico de 80 páginas con anexos.
Cómo se vende a finanzas
El error de muchos CTOs al pedir presupuesto para deuda técnica es presentarlo como "necesitamos modernizar". Eso no vende. Lo que sí vende es presentarlo como gestión de riesgo financiero:
- "El sistema X tiene 70% de probabilidad de outage mayor en 2024. Una outage equivalente nos costó $2M en 2022. Resolver cuesta $600k. ROI defensivo: 3.3x."
- "El sistema Y depende de una persona; si renuncia, el riesgo de continuidad operativa es $X al mes. Documentar y construir respaldo cuesta $Y."
Ese marco lo entiende finanzas y lo aprueba. La narrativa de "el código está viejo" no.
Errores comunes que estamos viendo
En las auditorías que corrimos en 2023, los patrones repetidos:
- Dependencias sin actualizar por años, con vulnerabilidades públicas conocidas. Es la deuda más fácil de resolver y la más postergada.
- Servidores en producción configurados a mano, sin IaC. Cuando uno se cae, recuperarlo es arqueología.
- Conocimiento concentrado en una persona sin respaldo. El bus factor 1 es un riesgo de negocio, no técnico.
- Falta de monitoreo proactivo. Los incidentes los reportan los clientes antes que las herramientas internas.
- CI/CD parcial o ausente. Despliegues semanales en vez de continuos porque el riesgo de cada release es alto.
Ninguno de estos requiere tecnología exótica para resolver. Requiere disciplina y prioridad.
Después de la auditoría
El error frecuente es entregar el reporte y volver a las prioridades de siempre. El roadmap funciona solo si se le asignan recursos explícitos:
- 15-25% de capacidad de ingeniería dedicada a deuda técnica como mínimo recurrente.
- Un líder responsable de avanzar el roadmap, con métricas trimestrales.
- Reauditoría cada 12 meses para medir progreso real.
Sin esos tres componentes, la deuda vuelve al mismo nivel en 18 meses.
La lectura larga
La deuda técnica no se elimina; se gestiona. Las empresas medianas que la ignoran terminan en uno de dos escenarios: pagan el costo en outages y rotación de talento, o pagan el costo en proyectos imposibles de completar a tiempo. Las que la auditan, miden y atacan en horizontes definidos, operan con menos sobresaltos y entregan más valor por peso invertido.
2024 es buen año para hacerlo. La presión por reducir costos hace que finanzas sea más receptivo a inversiones que se justifican por riesgo evitado.
¿Quieres apoyo para correr esta auditoría con tu equipo en 2 semanas? En ALCA acompañamos el proceso completo, desde el levantamiento hasta la presentación ejecutiva. Agenda 30 minutos sin costo.
