Cómo auditar tu deuda técnica antes de iniciar proyectos en 2022
Marzo es típicamente el mes donde los proyectos del año arrancan en serio. Los presupuestos están aprobados, los equipos definidos y las fechas comprometidas. Y es exactamente en este momento donde aparece el riesgo más caro de 2022 para empresas medianas: iniciar proyectos nuevos sobre una base que no aguanta.
La deuda técnica no se manifiesta como problema visible hasta que un proyecto importante se atrasa porque "el sistema viejo no se puede tocar sin romper nada", o un incidente de seguridad escala porque "nadie sabía cómo estaba configurado eso", o un equipo nuevo tarda tres meses en producir porque "la documentación no existe". Este artículo propone un marco para auditarla en dos semanas y, lo más importante, armar un roadmap que el CFO efectivamente apruebe en lugar de archivar.
Qué es deuda técnica (en serio, no en jerga)
La definición popular es "código mal escrito que toca pagar después". Es incompleta. La deuda técnica de una empresa mediana mexicana en 2022 vive en seis dimensiones, no en una:
- Código: legacy sin tests, librerías obsoletas, arquitecturas que ya no aguantan la carga.
- Datos: bases sin documentación, calidad pobre, duplicidad, falta de gobierno.
- Infraestructura: servidores sin parchear, configuraciones manuales sin código, ambientes que no se pueden replicar.
- Procesos: despliegues manuales, falta de CI/CD, ciclos de release largos.
- Conocimiento: dependencia de personas específicas, falta de runbooks, onboarding largo.
- Vendor lock-in y contratos: dependencia a un proveedor, contratos sin cláusulas de salida, sin alternativas evaluadas.
Auditar solo código deja fuera el 70% de la deuda real.
Marco de auditoría en 2 semanas
Recomendamos una auditoría estructurada de dos semanas con una persona o equipo dedicado. No es un proyecto de 6 meses; es un sprint de diagnóstico.
Semana 1: Levantamiento y medición
Día 1-2: Setup
- Definir alcance: ¿qué sistemas y procesos entran? Para una empresa mediana, normalmente entran los 5-10 sistemas core (ERP, CRM, e-commerce, plataformas críticas internas).
- Conseguir buy-in del equipo técnico. Sin ellos no hay auditoría posible y sin honestidad no hay valor.
- Plantilla de levantamiento: una hoja por sistema con las 6 dimensiones.
Día 3-7: Levantamiento por dimensión
Por cada sistema en alcance, recolectar:
- Código: versión de runtime/lenguaje, antigüedad de librerías clave (con SCA si se puede), cobertura de tests, frecuencia de cambios.
- Datos: existe diccionario, calidad documentada, gobierno definido, backups probados.
- Infraestructura: ambientes documentados, parches al día, IaC o configuración manual, monitoreo presente.
- Procesos: CI/CD presente, frecuencia de deploys, tiempo promedio para desplegar un cambio.
- Conocimiento: cuántas personas pueden tocar el sistema, runbooks de incidente, antigüedad de la documentación.
- Contratos: vigencia, costo, cláusulas de salida, alternativas conocidas.
Semana 2: Análisis y entrega
Día 8-9: Scoring
Cada dimensión por sistema en escala 1-5 (1 = sano, 5 = crítico). Esto da una matriz visual que un comité ejecutivo entiende en 30 segundos.
Día 10-11: Priorización
La pregunta clave no es "qué deuda es la peor", sino "qué deuda nos está bloqueando los proyectos del año". Cruza la matriz con el plan de proyectos 2022:
- Si vas a lanzar e-commerce nuevo Q3, la deuda en el ERP que se va a integrar es prioridad 1.
- Si vas a contratar 30 ingenieros nuevos, la deuda en documentación y onboarding es prioridad 1.
- Si vas a expandir geográficamente, la deuda en infraestructura escalable es prioridad 1.
Día 12-13: Roadmap y caso de negocio
Para cada prioridad, propuesta concreta:
- Qué hay que hacer.
- Cuánto cuesta (horas, dinero, oportunidad).
- Qué pasa si no se hace (no en lenguaje técnico, en lenguaje de negocio: "el proyecto X se atrasa 3 meses", "el riesgo de incidente sube de bajo a medio", "no podemos contratar a más de N ingenieros sin perder velocidad").
Día 14: Presentación ejecutiva
Documento corto (10-15 slides), foco en decisiones, no en detalles técnicos.
Cómo vender el roadmap al CFO
Esta es la parte donde la mayoría de los CTOs fallan. Un roadmap de deuda técnica que se presenta como "refactorizar microservicios" se archiva. Uno que se presenta como "reducir tiempo de lanzamiento de productos nuevos de 6 a 3 meses" se aprueba.
Tres reglas:
Regla 1: Lenguaje de negocio, no de código
| Mal | Bien |
|---|---|
| "Migrar de PHP 5 a PHP 8" | "Reducir riesgo de incidente de seguridad y costo de hosting en 30%" |
| "Implementar CI/CD" | "Reducir tiempo de lanzamiento de cambios de 2 semanas a 1 día" |
| "Refactorizar capa de datos" | "Permitir lanzar el nuevo módulo de reportes en Q3" |
Regla 2: Casos cuantificables
Para cada inversión, una métrica concreta esperada. No es exacto, es honesto: "esperamos que esto reduzca incidentes en 40-60%, basado en el patrón de últimos 12 meses".
Regla 3: Empaquetar en quarters, no en años
Un roadmap de 18 meses no se aprueba. Tres iniciativas de 1 trimestre cada una sí. La suma puede ser igual, pero la presentación importa.
Errores comunes en auditoría de deuda técnica
- Auditar todo a la vez. Imposible. Foco en sistemas core.
- Hacer la auditoría sin involucrar al equipo técnico. No hay datos honestos sin ellos.
- Entregar un documento de 80 páginas que nadie lee. Resumen ejecutivo de 2 páginas, anexos con detalle.
- Proponer modernización que no conecta con proyectos del año. Sin conexión a negocio, no se aprueba.
- Esperar que los desarrolladores prioricen "lo correcto". Sin presupuesto y tiempo dedicado, la deuda solo crece.
Qué medir trimestralmente después de la auditoría
Una vez ejecutada la auditoría inicial, el seguimiento debería ser ligero pero constante:
- Tiempo medio para desplegar un cambio.
- Cobertura de runbooks para sistemas críticos.
- Antigüedad media de librerías y runtimes.
- Tickets de "esto está roto y nadie sabe por qué" por trimestre.
- Tiempo de onboarding de un ingeniero nuevo a productividad.
Cuatro métricas, revisadas cada trimestre, ya son más de lo que tienen el 80% de las empresas medianas hoy.
La lectura
La deuda técnica no se paga sola. Cada año que pasa sin auditarla y atenderla, el costo de los proyectos del año siguiente sube. Para empresas mexicanas medianas que están arrancando proyectos importantes en 2022, dedicar dos semanas en marzo a un diagnóstico estructurado es probablemente la mejor inversión del año en términos de riesgo evitado.
No se trata de modernizar todo. Se trata de saber dónde está la deuda, qué tan cara es, y atenderla en orden de impacto en lo que importa al negocio.
¿Quieres apoyo para correr esta auditoría con tu equipo en 2 semanas? En ALCA acompañamos a CTOs y líderes de ingeniería a estructurar diagnóstico y roadmap aprobables por finanzas. Conversemos sin costo.
