Cómo auditar tu deuda técnica antes de iniciar proyectos en 2023
Marzo es el mes en que la mayoría de empresas medianas mexicanas terminan de aterrizar el plan operativo del año y empiezan a ejecutar proyectos serios. Es también el momento donde, año tras año, vemos repetirse la misma historia: el proyecto nuevo arranca con expectativas claras, choca contra problemas heredados que nadie había mapeado, se atrasa entre 30% y 80% del plan original y termina costando entre 1.5 y 3 veces el estimado. La culpable casi siempre es la misma: deuda técnica acumulada que nadie auditó antes de empezar.
En ALCA proponemos un marco sencillo: dedicar dos semanas, antes de iniciar cualquier proyecto serio del año, a hacer una auditoría disciplinada de deuda técnica. Sale más barato y más rápido enfrentar lo que está mal antes de construir encima. Aquí va el método que usamos con clientes.
Qué es deuda técnica (y qué no)
Deuda técnica no es "código viejo". Es cualquier decisión técnica pasada que hoy te impide moverte rápido o seguro. Eso incluye seis dimensiones que típicamente se pasan por alto:
- Código: arquitectura monolítica que ya no escala, lenguajes/frameworks fuera de soporte, falta de tests, cobertura baja, código duplicado, módulos sin owner claro.
- Datos: esquemas inconsistentes, duplicación entre sistemas, calidad pobre (campos vacíos, formatos mixtos), pipelines frágiles, falta de catálogo o data lineage.
- Infraestructura: servidores sin actualizar, configuraciones drifteadas, ausencia de IaC, dependencias sin patches de seguridad, escalamiento manual, sin observabilidad.
- Dependencias: librerías y SDKs versiones viejas, integraciones con APIs deprecadas, vendors descontinuados, contratos sin revisar.
- Procesos: deploys manuales, ausencia de CI/CD, gestión de cambios informal, plan de continuidad inexistente, control de accesos ad-hoc.
- Conocimiento: documentación desactualizada o inexistente, conocimiento crítico en una sola persona ("el ingeniero que sabe cómo funciona el sistema X"), runbooks que nadie ha revisado en años.
Lo que NO es deuda técnica: el código que funciona pero "no es lo que harías hoy". Si el sistema sigue cumpliendo su función, no requiere cambios urgentes y no bloquea la siguiente fase, no es deuda; es legacy estable. Confundir estas categorías cuesta proyectos.
El marco de 2 semanas
Para empresas medianas (50-500 empleados, equipos técnicos de 5-30 personas) este timing funciona. Más corto pierde profundidad; más largo pierde momentum.
Semana 1: levantamiento
Día 1-2: Inventario. Listar sistemas, servicios, bases de datos, integraciones. Si no existe un mapa, este es el momento de hacerlo (puede ser un diagrama simple en Miro/Lucid). Para cada componente: owner, criticidad, fecha de último cambio significativo, tecnologías.
Día 3-4: Entrevistas técnicas. Sesiones de 60-90 minutos con cada owner técnico. Tres preguntas clave:
- ¿Qué te frustra de operar este sistema hoy?
- ¿Qué te despertaría a las 3 AM si pasara?
- ¿Si tuvieras 2 semanas para mejorar algo, qué harías?
Día 5: Análisis estático. Correr herramientas que dan datos objetivos: SonarQube o similar para código, Snyk/Dependabot para vulnerabilidades, Datadog/New Relic para performance, AWS Trusted Advisor o equivalente para infra. Si nada de esto está instalado, el levantamiento toma más; vale la pena el esfuerzo.
Semana 2: medición y priorización
Día 6-7: Cuantificación. Por cada hallazgo de la semana 1, intentar ponerle número:
- ¿Cuánto tiempo de equipo consume al mes? (mantener, parchar, "apagar fuegos")
- ¿Qué riesgo concreto representa? (downtime, brecha de seguridad, compliance)
- ¿Qué bloquea? (proyectos que no podemos iniciar mientras esto exista)
Día 8-9: Priorización con matriz impacto/esfuerzo. Cuatro cuadrantes:
- Alto impacto / bajo esfuerzo: quick wins. Empieza por aquí.
- Alto impacto / alto esfuerzo: proyectos del año. Entran al roadmap formal.
- Bajo impacto / bajo esfuerzo: background. Asignar a tiempos de holgura.
- Bajo impacto / alto esfuerzo: ignorar conscientemente. Documentar la decisión.
Día 10: Roadmap y presentación. Documento ejecutivo de 5-8 páginas: hallazgos por dimensión, top 10 prioridades, propuesta de roadmap a 6-12 meses, requerimiento de inversión, riesgos de no actuar. Esto es lo que se presenta al CFO o a la dirección general.
Cómo "vender" el roadmap a finanzas
La trampa clásica del CTO: presentar el roadmap de deuda técnica con vocabulario técnico ("necesitamos refactorizar el módulo de pagos a una arquitectura hexagonal"). Predeciblemente, al CFO no le mueve nada.
Tres reglas para que el roadmap se apruebe:
Regla 1: traducir cada item a impacto de negocio
No: "actualizar Java 8 a Java 17". Sí: "Java 8 sale de soporte oficial este año; sin actualización, próxima vulnerabilidad crítica nos deja expuestos sin parche, riesgo de incidente de seguridad y de no pasar auditoría ISO/PCI". El componente técnico es el mismo; el lenguaje es de riesgo.
Regla 2: presentar costo de NO hacerlo
Por cada hallazgo prioritario, calcular costo anualizado de mantenerlo así: horas-persona apagando fuegos, downtime estimado, riesgo de compliance, oportunidad bloqueada. Cuando el costo de no hacer supera el costo de hacer, la decisión se vuelve obvia.
Regla 3: empaquetar en proyectos con resultado medible
No "modernización de plataforma" (proyecto eterno, sin ROI claro). Sí "reducir tiempo de deploy de 3 horas a 15 minutos en Q2" o "automatizar 80% de generación de reportes regulatorios en Q3". Cada proyecto con métrica clara, plazo y dueño.
Errores típicos en auditorías de deuda técnica
Tres patrones recurrentes que invalidan el ejercicio:
Error 1: hacerlo solo con la lente del CTO
Si la auditoría la hace una persona en una oficina, va a quedar sesgada por sus puntos ciegos. La señal real está en las entrevistas con quienes operan los sistemas día a día.
Error 2: no cuantificar y quedarse en lista narrativa
"Hay mucha deuda en el módulo X" no es accionable. "El módulo X consume 12 horas-persona al mes en mantenimiento, ha tenido 3 incidentes de severidad alta en los últimos 6 meses, bloquea 2 proyectos del roadmap" sí lo es.
Error 3: priorizar por preferencia técnica, no por impacto
Es muy tentador atacar primero "lo que más nos molesta como ingenieros" en lugar de "lo que más cuesta al negocio". Disciplina la priorización con la matriz impacto/esfuerzo y mantente fiel a ella.
Cuándo correr esta auditoría
Recomendamos hacerla en estos momentos:
- Inicio de año fiscal, antes de comprometer el plan de proyectos.
- Antes de un proyecto grande (migración, lanzamiento de producto nuevo, M&A).
- Después de un incidente serio (post-mortem extendido).
- Cambio de CTO o líder técnico (parte del onboarding).
Para empresas medianas que nunca han hecho una auditoría formal, el primer ejercicio típicamente revela 15-30 hallazgos significativos. Los siguientes (anuales) descubren 5-15. La cadencia anual es razonable.
Lectura final
La deuda técnica es como la deuda financiera: si la dejas crecer en silencio, llega un punto donde los intereses consumen tu capacidad operativa. Si la mides, priorizas y atacas con disciplina, es una palanca de productividad real. Dos semanas en marzo evitan tres meses de retraso en el Q3.
Las empresas mexicanas medianas que entran a 2023 con un mapa claro de su deuda técnica y un roadmap aprobado tienen ventaja sobre las que descubren los problemas en medio del proyecto. La diferencia se cuenta en utilidad, no solo en código.
¿Quieres apoyo para correr esta auditoría con tu equipo en 2 semanas? En ALCA acompañamos a equipos técnicos a estructurar auditorías de deuda y a presentar roadmaps que finanzas aprueba. Conversemos en una sesión sin costo.
