Cómo auditar tu deuda técnica antes de iniciar proyectos en 2021
El primer trimestre del año es momento típico para arrancar proyectos nuevos: nuevas funcionalidades, nuevas integraciones, nuevos módulos del sistema interno. Lo que vemos en empresas medianas mexicanas es que esos proyectos arrancan con entusiasmo y, a las pocas semanas, se topan con una pared invisible: deuda técnica acumulada que nadie midió, nadie documentó y, hasta ese momento, nadie quiso ver.
En ALCA hemos pasado los últimos años acompañando equipos de ingeniería en este momento incómodo. La buena noticia es que existe una forma estructurada de auditar deuda técnica en dos semanas, sin paralizar la operación, y de armar un reporte que el CFO va a entender y aprobar. Compartimos el marco aquí.
Qué es deuda técnica, de verdad
La definición popular ("código mal escrito que hay que rehacer") es estrecha y por eso engañosa. La deuda técnica abarca seis dimensiones, no una sola, y la mayoría de empresas tiene problemas serios en al menos tres de ellas.
Código. Funciones largas, lógica duplicada, tests insuficientes, dependencias desactualizadas, frameworks obsoletos.
Arquitectura. Acoplamientos fuertes que impiden cambiar una parte sin afectar otras, módulos que crecieron más allá de su alcance, decisiones tomadas hace años para problemas que ya no existen.
Infraestructura. Configuraciones manuales no reproducibles, servidores sin automatización de despliegue, ambientes que no se parecen entre sí, falta de monitoreo o monitoreo que nadie revisa.
Datos. Esquemas de base de datos que crecieron orgánicamente sin mantenimiento, datos duplicados entre sistemas, falta de calidad mínima en campos críticos, ausencia de respaldos verificados.
Conocimiento. Información clave que solo está en la cabeza de una o dos personas, documentación inexistente o desactualizada, decisiones de diseño que nadie recuerda por qué se tomaron así.
Procesos. Falta de revisión de código sistemática, despliegues manuales y arriesgados, ausencia de runbooks para incidentes comunes, dependencia de heroísmo individual para resolver problemas recurrentes.
Sin un mapa claro de las seis dimensiones, "modernizar" se vuelve una conversación abstracta que cada quien interpreta distinto. El primer paso del marco es hacer ese mapa explícito.
El marco de dos semanas
Recomendamos un proceso estructurado en cuatro fases, ejecutable por un equipo pequeño (un líder técnico y dos o tres colaboradores) en aproximadamente diez días hábiles.
Fase 1: levantamiento (3 días)
El objetivo es recolectar evidencia de cada dimensión. Para código, usar herramientas de análisis estático (SonarQube, CodeClimate o equivalentes) que generan métricas objetivas. Para arquitectura, hacer entrevistas con dos o tres ingenieros senior que conozcan la historia del sistema. Para infraestructura, inventariar servidores, configuraciones y procesos de despliegue. Para datos, ejecutar consultas de calidad sobre las tablas más importantes. Para conocimiento, mapear quién sabe qué y dónde están los puntos únicos de falla. Para procesos, observar un ciclo completo de desarrollo, desde el ticket hasta producción.
El producto de esta fase es un documento crudo con hallazgos, no recomendaciones. La distinción importa: separar observación de juicio reduce la resistencia interna.
Fase 2: medición (3 días)
Para cada hallazgo, asignar dos atributos: impacto en operación actual e impacto en proyectos futuros. Usamos una escala simple: alto, medio, bajo. La pregunta detrás de cada atributo es concreta. Para impacto operativo: ¿este problema genera incidentes, retrabajo, fricciones medibles hoy? Para impacto futuro: ¿este problema va a hacer que los proyectos planeados para los próximos doce meses tomen más tiempo o sean imposibles?
Algunos elementos serán alto-alto: están sangrando hoy y bloquean futuro. Esos son las prioridades. Otros serán bajo-bajo: existen pero no estorban. Esos pueden quedarse. La mayor parte estará en el medio, y ahí es donde la conversación se vuelve útil.
Fase 3: priorización (2 días)
Con los hallazgos clasificados, armar tres listas. La primera, "estabilizar antes de lanzar nada nuevo": elementos críticos que deben atenderse en el siguiente mes. La segunda, "remediar en paralelo a roadmap normal": deuda que se aborda mientras avanzan los proyectos del año. La tercera, "aceptar y documentar como deuda conocida": elementos que reconocemos como deuda pero decidimos no atender este año por costo-beneficio.
El acto de poner cosas en la tercera lista es valioso. Reconocer deuda que se acepta es distinto de ignorarla; quedan documentadas como decisiones explícitas, no olvidos.
Fase 4: reporte ejecutivo (2 días)
Aquí está la parte que muchas auditorías técnicas hacen mal. El reporte para el CFO no debe contener listas de funciones con baja cobertura de tests; debe contener costos, riesgos y opciones en lenguaje de negocio.
Estructura recomendada del reporte. Primero, una página de resumen con tres números: cuánto tiempo del equipo se está perdiendo hoy en lidiar con la deuda existente, cuánto va a aumentar ese desperdicio en los próximos doce meses si no se hace nada, qué proyectos planeados están en riesgo. Segundo, las tres opciones (estabilizar, paralelo, aceptar) con presupuesto estimado para cada una. Tercero, una recomendación clara del líder técnico sobre cuál se debe elegir y por qué.
Lo que vemos funcionando es que este reporte se discute en una sesión de una hora con dirección general y CFO, donde se toma una decisión informada. Sin ese reporte, la conversación se vuelve abstracta y termina en pospones.
El error más común: confundir deuda técnica con renacer todo
Cuando los equipos técnicos identifican deuda, la tentación natural es proponer una "rearquitectura completa" o un "rewrite del sistema". Eso es casi siempre un error. Los rewrites tardan más de lo planeado, casi nunca terminan exactamente como se proyectaron, y mientras tanto la operación sigue dependiendo del sistema viejo.
La mejor práctica es lo que se llama strangler pattern: ir reemplazando partes del sistema gradualmente, mientras el sistema viejo sigue operando, hasta que el viejo eventualmente queda sin uso y se puede apagar. Esto requiere disciplina y tiempo, pero reduce dramáticamente el riesgo y permite que el equipo siga entregando valor durante el proceso.
Quién debe liderar este ejercicio
Para empresas medianas con un equipo técnico interno de cinco a treinta personas, la auditoría puede ser liderada por un líder técnico interno con apoyo del CTO o gerente de TI. Lo importante es que sea alguien con autoridad técnica y disposición para entregar malas noticias con datos.
Para equipos pequeños donde no hay esta figura disponible, o donde el liderazgo técnico está demasiado cerca del código y le cuesta tomar distancia, vale la pena traer apoyo externo. Una mirada de afuera tiende a hacer preguntas que internamente se han dejado de hacer.
Lo que no recomendamos es saltarse este ejercicio. Empezar proyectos nuevos sobre una base que no se ha medido es la receta para sorpresas costosas a la mitad del año, cuando ya estén comprometidos presupuestos y plazos.
Dos semanas de trabajo deliberado pueden ahorrar meses de improvisación reactiva. La inversión vale.
¿Quieres apoyo para correr esta auditoría con tu equipo en 2 semanas? En ALCA acompañamos auditorías de deuda técnica con una metodología probada y entregables ejecutivos accionables. Agenda una sesión inicial sin costo.
