La deuda técnica visible: mapear y priorizar con evidencia
La deuda técnica solo aparece cuando explota, en un incidente o en una feature que debía tomar días y toma semanas. La IA mapea esa deuda con evidencia verificable; priorizar qué pagar ahora sigue siendo criterio de negocio tuyo.
Hace meses el equipo repite la misma frase en las retros: "ese módulo de facturación es un desastre, un día va a explotar". Nadie señala dónde exactamente, cuánto cuesta mantenerlo, o qué va a estallar primero. Es opinión compartida, no un mapa. Entonces alguien le pide a la IA que escanee el repositorio entero y liste dónde la lógica se repite, qué dependencias están desactualizadas con vulnerabilidad conocida, y qué módulo tiene la peor cobertura de test. El informe sale con archivo, línea y número. La pregunta que queda ya no es "qué está mal", es "qué de esa lista cuesta caro ahora, y qué puede esperar".
El estudio jurídico convive con la leyenda de que "el sistema de gestión de plazos procesales falla a veces", sin saber cuándo ni por qué. La IA escanea los registros de error de la herramienta y señala que las fallas se concentran exactamente en los procesos que tienen más de una instancia, porque la lógica de cálculo de plazo nunca se actualizó para manejar correctamente el plazo recursal. La suposición se convirtió en una categoría específica de proceso con una causa técnica nombrada. Priorizar el arreglo antes o después de otra entrega del proveedor de la herramienta sigue siendo decisión de quien responde por los plazos, no del escaneo.
Todos en el equipo de gente y gestión comentan que "el sistema de evaluación de desempeño se traba en cada temporada de ciclo", pero nadie había medido el tamaño del problema. La IA escanea los tickets de soporte interno de la herramienta y señala que 40% de ellos se concentran en una única funcionalidad, la de calibración cruzada entre gerentes, siempre en la misma semana del ciclo. La suposición se convirtió en un patrón fechado y localizado. Pero decidir si vale invertir en un arreglo ahora o esperar a que se evalúe el próximo proveedor de RRHH es decisión de negocio, no del escaneo.
El equipo de producto siempre supo que "el onboarding de la app tiene una tasa de error rara", sin saber dónde. La IA escanea los logs de error del flujo de onboarding y señala que 22% de las fallas se concentran en una única pantalla de verificación de documento, asociada a una librería de terceros que cambió el formato de respuesta hace dos meses sin aviso. La suposición se convirtió en una pantalla específica y una causa probable. Solo que decidir si se arregla ahora o se espera la migración de proveedor ya planificada para el próximo trimestre depende del impacto real en la conversión, no del escaneo en sí.
El equipo comercial se queja de que "el CRM está lento y se traba todo el tiempo", sin saber señalar dónde. La IA escanea los informes de performance del sistema y señala que una consulta específica, usada cada vez que alguien abre el historial de un cliente, demora doce veces más que el promedio, porque busca en una tabla sin índice adecuado desde una migración de hace dos años. La suposición se convirtió en un punto exacto, con el tiempo de respuesta medido. Decidir si esta corrección entra en este sprint o espera depende de cuánto tiempo pierde comercial por día con esto, un cálculo que es tuyo, no de la IA.
La operación convive hace meses con la fama de que "el sistema de ruteo de entregas es inestable al final del día", sin saber la causa. La IA escanea los logs de error y señala que el problema se concentra en una función que recalcula rutas, cuya complejidad creció tanto a lo largo de los años que hoy evalúa más de 40 condiciones distintas en una única llamada, una señal clásica de complejidad acumulada sin refactorización. La suposición se convirtió en una función nombrada, con el número de condiciones que evalúa. La decisión de parar la operación para refactorizar esto, o postergarlo al próximo trimestre, es decisión de negocio.
El área de riesgo convive con el rumor de que "el sistema de consentimiento de datos tiene un agujero", sin ningún detalle. La IA escanea el código y señala que existe una ruta de API antigua, sin uso documentado en el flujo actual, que todavía acepta requests sin verificar el consentimiento del titular, un remanente de una versión anterior del producto. La suposición se convirtió en una ruta específica, con el archivo y la ausencia exacta de verificación. Decidir si esto es lo bastante crítico para frenar otra entrega esta semana es criterio del responsable de riesgo, no del escaneo.
El equipo de diseño convive con la impresión de que "la app se vuelve pesada después de un tiempo de uso", sin saber señalar dónde. La IA escanea el código de la pantalla principal y señala que un componente de lista carga todos los ítems de una vez, sin paginación, desde que la base de usuarios era diez veces más chica, y hoy eso derrumba el rendimiento en dispositivos más antiguos. La suposición se convirtió en un componente específico con la causa exacta. Pero decidir si esta corrección entra antes o después del rediseño ya planificado de la pantalla es una decisión de prioridad que le corresponde al equipo, no al escaneo que solo señaló el síntoma.
El directorio siempre escuchó decir que "la plataforma de análisis de mercado está desactualizada" sin ningún número que sostenga eso en una decisión de inversión. La IA escanea el historial de mantenimiento de la plataforma y señala que 60% de los informes generados en el último trimestre necesitaron corrección manual antes de ir al directorio, un retrabajo que nunca había sido medido. La suposición se convirtió en un número que justifica, o no, invertir en un rediseño antes del próximo ciclo de planificación. La decisión de priorizar esa inversión, mirando el retorno contra otras apuestas del trimestre, sigue siendo del directorio, no de la IA.
Oye, todo equipo de tecnología tiene ese módulo del que todos hablan mal en los pasillos y nadie logra explicar bien el tamaño del problema. "Esto es una bomba de tiempo" es la frase, y es opinión, no diagnóstico. Piensa conmigo: ¿cuánto tiempo perdió ya tu equipo discutiendo si vale la pena tocar una deuda que nadie sabe medir? La deuda técnica no es un misterio, solo es invisible hasta que la miras con la herramienta correcta.
La idea central de esta lección. La deuda técnica queda invisible hasta estallar, en un incidente o en una entrega que debía tomar días y toma semanas, porque nadie la rastrea de forma sistemática. La IA cambia ese juego: escanea el sistema y devuelve evidencia verificable, archivo y línea de lógica duplicada, número de CVE de una dependencia vieja, porcentaje de cobertura de test de un módulo crítico. Eso cambia la suposición por mapa. Pero el mapa no decide solo qué pagar primero. No toda deuda pesa igual, y priorizar con criterio de negocio, mirando el riesgo real de cada ítem, sigue siendo tuyo.
01Por qué la deuda queda invisible hasta estallar
La deuda técnica tiene una característica cruel: no manda aviso. Nadie abre un ticket diciendo "hoy la deuda técnica del módulo X aumentó 3%". Solo aparece de dos formas, y ambas cuestan caro. La primera es el incidente: el sistema se rompe en un mal momento y, al investigar, se descubre que la causa era una fragilidad conocida desde hacía meses, solo que nadie la había priorizado. La segunda es más sutil: una feature que debía tomar tres días toma tres semanas, porque el código alrededor de ella es un campo minado que nadie quiere tocar sin cuidado redoblado.
Recuerda la salvedad mortal que abrió este módulo: velocidad sin revisión se convierte en deuda e incidente. Es exactamente aquí donde aparece en la práctica. Cada atajo, cada corrección apresurada, cada código generado rápido y aceptado sin revisión profunda, va apilándose en una cuenta que nadie está mirando, hasta que vence de golpe, en el peor momento posible.
El problema no es que exista la deuda, toda operación real tiene alguna. El problema es que sea invisible. Sin visibilidad, el equipo solo reacciona después de que ya cobró el precio.
02Lo que la IA hace bien: escanear y señalar evidencia
Aquí la IA es excelente, porque el trabajo es justamente del tipo que ella cubre bien: escanear un volumen de código que ninguna persona releería entero, y señalar patrones concretos, con referencia que se puede verificar. Nota la palabra: evidencia, no opinión.
- Duplicación de lógica, con archivo y línea. La misma regla de negocio escrita de formas ligeramente distintas en lugares distintos, cada copia un riesgo de divergir de la otra en la próxima corrección.
- Dependencia desactualizada, con CVE. Una librería atascada en una versión antigua, con una vulnerabilidad catalogada públicamente, algunas con nivel de gravedad documentado.
- Cobertura de test baja, con porcentaje. Un módulo crítico (el que calcula dinero, el que autentica gente, el que procesa dato sensible) corriendo con poco o ningún test automatizado protegiéndolo.
- Complejidad acumulada, con el punto exacto. Una función que, a lo largo de los años, fue ganando condición sobre condición hasta convertirse en un enredo difícil de entender y más fácil de romper que de arreglar.
Lo que cambia con eso no es solo la claridad. Es la posibilidad de decidir. Con suposición, toda conversación sobre deuda se vuelve debate de opinión. Con evidencia, la conversación se vuelve sobre prioridad, que es donde debía estar.
Sabe más: por qué la "evidencia" necesita ser verificable, no solo detallada
Una lista larga y detallada no es lo mismo que una lista con evidencia. La IA puede devolver un informe extenso, lleno de adjetivos técnicos, sobre por qué un módulo "presenta señales de complejidad elevada y potencial acoplamiento excesivo". Eso suena riguroso y puede no valer nada, si nadie logra abrir el archivo y ver el problema descrito. La prueba correcta para cualquier ítem del mapa de deuda es simple: ¿se puede señalar con el dedo (el archivo, la línea, el nombre de la CVE, el número exacto de cobertura) y otra persona puede confirmarlo mirando la misma fuente? Si la respuesta es sí, es evidencia. Si la respuesta es "confía en mí, ella dijo que es grave", sigue siendo suposición, solo que con apariencia de informe.
03Lo que sigue siendo del equipo: priorizar con criterio de negocio
El mapa no termina el trabajo, empieza la parte que importa. La pregunta correcta ante cualquier ítem de la lista nunca es "qué está más feo". Es otra, más dura: ¿esta deuda específica va a causar un incidente, o está trabando una entrega que importa ahora?
Piensa en los cuatro hallazgos del inicio de la lección. La duplicación de regla de impuesto en cuatro archivos es fea, pero si el impuesto rara vez cambia, el riesgo de divergencia es bajo, puede esperar. En cambio la CVE crítica en una librería de procesamiento de imagen expuesta públicamente es un riesgo concreto y fechado, compite por atención inmediata. El 8% de cobertura en el módulo de comisión solo se vuelve urgencia real si ese módulo está por ser modificado; si nadie lo va a tocar tan pronto, el riesgo es menor de lo que parece a primera vista. La complejidad acumulada en la función de ruteo se vuelve prioridad si ya está causando inestabilidad medida, no solo porque es fea de leer.
Nota que ninguna de esas cuatro decisiones vino del escaneo. Vinieron de cruzar el hallazgo técnico con lo que el negocio necesita en las próximas semanas: qué va a cambiar, qué está expuesto, qué ya está doliendo. Eso es lectura de contexto, y el contexto es tuyo.
04El peligro de tratar toda deuda igual
Aquí vive el error más común después de que el mapa llega listo: tratar la lista como si cada ítem pesara lo mismo. Es tentador tomar los ítems más fáciles de resolver, un sprint entero arreglando la deuda barata y visible (renombrar variable, ordenar import, refactorizar un fragmento pequeño), porque da la sensación buena de "progreso visible" y encaja bien en una retro.
El problema es que, mientras tanto, la deuda cara y escondida (la CVE crítica, el módulo sin test que va a ser modificado la semana que viene) sigue acumulando, sin que nadie la toque, porque es más difícil, más riesgosa de tocar, y menos visible en el día a día. Un sprint de limpieza cosmética puede hasta mejorar la sensación del equipo, y no cambiar nada en el riesgo real de la operación.
La regla correcta no es el tamaño del esfuerzo ni cuánto incomoda el ítem visualmente. Es el riesgo de negocio que cada ítem carga si nadie lo toca en las próximas semanas. Gastar energía limitada en la deuda equivocada es desperdicio disfrazado de productividad.
05Cierre: el mapa se convierte en fuente para el resto del sistema
El mapa de deuda no vive aislado. Es el antídoto directo de la salvedad mortal que abrió este módulo: vuelve visible exactamente lo que la velocidad sin revisión esconde. Antes, la deuda se acumulaba en la oscuridad. Ahora, tiene dirección.
Y también alimenta la coreografía de la lección anterior: cuando un incidente aparece en el triage de backlog, el mapa de deuda es una fuente más que ayuda al equipo a confirmar la severidad real, porque ahora existe una lista de fragilidades conocidas para cruzar contra el ticket nuevo. La suposición se vuelve mapa, el mapa se vuelve prioridad, y la prioridad se vuelve menos incidente de madrugada. ¿Vamos?
Hazlo ahora
Toma un sistema o módulo real de tu entorno, tu tarea real o aquel del que todos se han quejado informalmente. Pídele a la IA que escanee y liste 3 evidencias concretas de deuda técnica, cada una con referencia: archivo y línea, número de CVE, o porcentaje de cobertura de test.
Ahora haz la parte que es tuya: para cada una de las 3 evidencias, clasifica en "cuesta caro ahora" o "puede esperar", y escribe en una frase el motivo de negocio de la clasificación (qué va a cambiar pronto, qué está expuesto, qué ya está doliendo).
Si las 3 evidencias llegaron sin nada verificable (sin archivo, sin CVE, sin número), retrocede un paso: eso sigue siendo suposición con apariencia de informe, pide la evidencia de nuevo antes de priorizar cualquier cosa.
Practica
1. ¿Cuál es la diferencia entre la suposición de deuda técnica ('ese módulo es un desastre') y el mapa que produce la IA?
2. El escaneo señala dos deudas: una CVE crítica en una librería expuesta públicamente, y una regla de cálculo duplicada en código rara vez modificado. ¿Cuál es la lectura correcta?
3. ¿Cómo se conecta el mapa de deuda técnica con el resto del módulo de Tecnología de esta trilla?
Para la pizarra
Sobre la suposiciónesto es una bomba de tiempo es una opinión, no un diagnóstico.
Sobre la prueba de evidenciapuedes apuntar el dedo a una fuente que otra persona abre y confirma. Sin eso, sigue siendo suposición.
Sobre la prioridadla pregunta no es qué está más feo. Es qué causa un incidente o traba algo que importa ahora.
Gracias por el feedback. Esto ayuda a afinar la próxima lección.