El presupuesto de proyectos nuevos que nunca llega a los proyectos nuevos

McKinsey le preguntó a 50 CIOs de empresas de servicios financieros y tecnología —todas con facturación superior a USD 1.000 millones— cuánto del presupuesto asignado a productos nuevos terminaba resolviendo problemas de deuda técnica. La respuesta fue entre 10% y 20%. Un 30% de los encuestados creía que en su caso superaba el 20%. Y el 60% dijo que la deuda había crecido de forma perceptible en los tres años anteriores.

Es plata que se aprobó para construir y se ejecutó en mantenimiento. No hay una decisión que la desvíe: se desvía sola, distribuida en horas dentro de proyectos que ya estaban aprobados. Por eso nunca aparece como partida, nunca se discute en un comité y nunca compite por presupuesto contra nada.

La encuesta es de 2020 y el universo es de empresas grandes, así que conviene tomarla por lo que es: un orden de magnitud, no un benchmark aplicable a cualquier operación. Lo que sí cambió desde entonces, y cambió mucho, es la velocidad a la que esa deuda se genera. A eso llegamos en un minuto.

El marco que McKinsey usa para explicar la deuda técnica es el más útil que existe para una conversación con finanzas, porque no es una metáfora suelta: separa dos costos que se comportan de forma distinta.

El principal es el trabajo necesario para modernizar el stack: mantenimiento diferido, actualizaciones postergadas, adecuaciones a estándares de datos, software empaquetado tan customizado que el proveedor original ya no puede darle soporte. Es un monto grande y visible cuando se lo busca. Cada tanto se discute como proyecto de modernización.

El interés es el impuesto de complejidad que paga cada proyecto, hoy. Trabajar sobre integraciones frágiles, armonizar datos que no siguen ningún estándar, construir workarounds para llegar a la entrega. No se discute nunca, porque no tiene forma de proyecto. Está repartido en horas adentro de cada entrega.

Ese interés es el que come margen todos los meses. Y es el que casi nadie mide, porque para medirlo habría que poder responder qué porcentaje de las horas de cada proyecto se fue en pelear con lo que ya estaba antes de empezar.

Acá está la particularidad del segmento, y es la razón por la que el contenido genérico sobre deuda técnica no le sirve a una consultora de IT ni a una fábrica de software.

Una empresa de banca o de retail tiene su propia deuda técnica y la paga con su propio presupuesto. Una empresa que vende desarrollo, integración o mantenimiento tiene dos capas:

La deuda que hereda. Cada proyecto de mantenimiento, migración o evolutivo sobre un sistema existente se toma con un pasivo técnico adentro. La empresa lo cotiza con la información que tiene, que casi nunca incluye una medición del estado real del código. Si el modelo es a precio cerrado, ese pasivo pasa directo al margen.

La deuda que genera. Cada atajo tomado para cumplir un deadline, cada componente duplicado en lugar de reutilizado, cada test que no se escribió. Vuelve como rework en el mismo proyecto o en el siguiente, y se factura mezclado con desarrollo nuevo.

Las dos capas terminan en el mismo lugar: en el margen del proyecto. No en el presupuesto de IT.

Este es el dato nuevo, y es el que cambia el timing del tema. La deuda técnica dejó de acumularse al ritmo de las decisiones humanas.

GitClear analizó 623 millones de cambios de código entre 2023 y 2026, siguiendo ocho señales de mantenibilidad a medida que la autoría asistida por AI alcanzaba volúmenes récord. El resultado, en su informe The Maintainability Gap: las señales de reutilización cayeron y las de riesgo subieron, todas al mismo tiempo.

Del lado de la reutilización, los movimientos de refactorización bajaron 70%, el mantenimiento de código legacy bajó 74% contra niveles de 2022, y las llamadas de funciones entre archivos —indicador de que el código se reutiliza en lugar de reescribirse— cayeron 35%.

Del lado del riesgo, el copy/paste dentro de un mismo commit subió 41%, la duplicación de bloques de código 81%, las construcciones que enmascaran errores 47%, y el churn a dos semanas —código que se reescribe o se borra a los pocos días de haberse escrito— 15%.

Un bloque duplicado no es un problema estético: es un lugar donde cada corrección futura hay que aplicarla otra vez. La investigación académica asocia el código clonado a tasas de defectos entre 15% y 50% más altas. Y el informe DORA de Google ya había medido en 2024 que cada 25% de uso adicional de AI venía acompañado de 7,2% más de inestabilidad en la entrega.

El output sube. La estructura que mantiene el código sostenible se degrada. La diferencia entre las dos cosas es deuda, y se está generando adentro de proyectos facturables, ahora.

No es por falta de herramientas. Hay análisis estático, métricas de cobertura, indicadores de acoplamiento, dashboards de calidad. El problema es de traducción.

La deuda técnica se discute en el lenguaje de ingeniería: duplicación, complejidad ciclomática, cobertura de tests, acoplamiento. El presupuesto se discute en el lenguaje financiero: costo, margen, retorno. Nadie hace la conversión, y sin conversión el tema no compite por presupuesto contra nada. Un CFO no puede aprobar una partida para "reducir el acoplamiento".

La conversión existe y es simple de enunciar, aunque no de implementar: la deuda técnica se mide en horas dedicadas a resolver problemas heredados, imputadas a un proyecto y a un cliente. Eso es un número que finanzas entiende, que se puede comparar entre proyectos y que se puede proyectar.

El obstáculo es que casi ninguna empresa del segmento tiene esa categoría abierta. El rework se carga dentro de horas facturables, mezclado con desarrollo nuevo. Y la Developer Survey 2025 de Stack Overflow —más de 49.000 desarrolladores en 177 países— da una idea del volumen que se está mezclando ahí: 66% dedica más tiempo del previsto a corregir código generado que queda "casi bien".

Si eso no está separado, el costo de la deuda técnica es literalmente incalculable. No porque sea enorme: porque el dato no existe.

McKinsey midió también el otro lado. Las empresas que gestionan activamente su deuda técnica liberan hasta 50% más del tiempo de sus ingenieros para trabajo que sostiene objetivos de negocio. En su análisis de 220 organizaciones, las del percentil 80 de su índice de deuda técnica crecieron en facturación 20% más que las del percentil 20. Y las del percentil inferior de severidad resultaron 40% más propensas a terminar con modernizaciones incompletas o canceladas.

Ese último dato es el más relevante para una empresa que vende modernizaciones: el estado del sistema no solo afecta el margen del proyecto, afecta la probabilidad de que el proyecto llegue a cerrarse.

Y hay un factor propio de 2026 que suma urgencia. La deuda técnica se convirtió en un bloqueador de adopción de AI: los sistemas legacy sin APIs limpias, sin datos estandarizados y sin documentación no son terreno donde un agente pueda operar. La agenda de CIO 2026 de Gartner empuja en la dirección complementaria: cada plataforma tiene que justificar su costo con retorno financiero demostrable, no con argumentos técnicos, y la consolidación de proveedores aparece como palanca central para eliminar sobrecostos ocultos.

Es el mismo criterio aplicado a la deuda. No se paga porque el código esté sucio. Se paga cuando se puede mostrar qué margen libera.

Abrir "trabajo sobre deuda heredada" como categoría de carga. Separada de desarrollo nuevo y de soporte. Es el paso que habilita todos los demás y el único que no requiere comprar nada. Sin esa categoría, el resto de la lista es imposible.

Calcular la tasa de interés de cada proyecto. Qué porcentaje de las horas ejecutadas se fue en resolver problemas que ya estaban antes de empezar. Ese porcentaje, comparado entre proyectos y entre clientes, es el mapa de dónde está el pasivo. Suele haber sorpresas: proyectos que parecían rentables por facturación y no lo eran por composición de horas.

Medir el estado del código antes de cotizar, no después. Un evolutivo sobre un sistema desconocido cotizado a precio cerrado es una apuesta, no una estimación. Una auditoría técnica previa, facturada aparte como entregable propio, convierte esa apuesta en información. Y en varios casos, en una línea de servicio nueva.

Estimar con histórico real y no con memoria. Estimar ya lo domina la industria. Lo que falla es comparar el estimado contra lo ejecutado a tiempo para corregir mientras el proyecto sigue abierto. Un desvío detectado en el cierre de mes es un dato histórico; el mismo desvío detectado cuando el proyecto consumió buena parte de sus horas asignadas y todavía queda scope por entregar es una decisión que se puede tomar.

Llevar la deuda a la conversación de scope con el cliente. Cuando existe el número, deja de ser una discusión técnica que el cliente no entiende y pasa a ser una línea de propuesta. La deuda técnica sin medir se absorbe como costo propio. Medida, se puede cotizar.

La deuda técnica se discute casi siempre en foros de ingeniería, y por eso se queda en el diagnóstico correcto con la conclusión incompleta: hay que refactorizar. Puede ser. Pero la decisión de cuánto refactorizar, cuándo y en qué proyecto no es técnica: es de asignación de capital.

Y no se puede tomar sin el dato de cuánto está costando hoy, proyecto por proyecto, cliente por cliente. Ese dato no está en el análisis estático del repositorio. Está en las horas que el equipo ya carga todos los días, mal categorizadas.

Es la misma historia del segmento entero: se mide mal lo que ya se registra. Empresas que le venden a otras el software para ordenar su operación y puertas adentro no pueden responder si cada proyecto les dejó plata.

Los tableros de gestión —Jira, Azure DevOps, Linear, GitHub— resuelven bien tickets, sprints y asignación, y nadie los va a cambiar por esto. Ninguno responde la pregunta financiera. El board dice si la tarea avanza. El margen dice otra cosa.

• McKinsey, Tech debt: Reclaiming tech equity (octubre 2020, sobre encuesta de julio 2020 a 50 CIOs de servicios financieros y tecnología con facturación superior a USD 1.000 M): 10–20% del presupuesto dedicado a productos nuevos se desvía a resolver deuda técnica; 60% de los CIOs reportó crecimiento perceptible de la deuda en tres años. Marco de principal e interés.
• McKinsey, Demystifying digital dark matter (junio 2022): 30% de los CIOs cree que más de 20% de su presupuesto de productos nuevos se desvía a deuda técnica.
• McKinsey, Breaking technical debt's vicious cycle to modernize your business (abril 2023): hasta 50% más de tiempo de ingeniería liberado al gestionar la deuda activamente; empresas en el percentil inferior de severidad, 40% más propensas a modernizaciones incompletas o canceladas.
• McKinsey, análisis de Tech Debt Score sobre 220 organizaciones: las del percentil 80 crecen en facturación 20% más que las del percentil 20.
• GitClear, The Maintainability Gap (2026, 623 millones de cambios de código, 2023–2026): refactorización −70%, mantenimiento de legacy −74% vs. 2022, llamadas entre archivos −35%; copy/paste intra-commit +41%, duplicación de bloques +81%, construcciones que enmascaran errores +47%, churn a dos semanas +15%.
• Google, informe DORA 2024: cada 25% de uso adicional de AI se asocia a 7,2% más de inestabilidad en la entrega.
• Stack Overflow, Developer Survey 2025 (49.000+ desarrolladores, 177 países): 66% dedica más tiempo del previsto a corregir código generado que queda "casi bien".
• Gartner, agenda de CIO 2026: cada plataforma debe justificar su costo con retorno financiero demostrable; consolidación de proveedores como palanca para eliminar sobrecostos ocultos.
• COR, Reporte de industria 2026: 1.632 conversaciones con líderes de empresas de tecnología, IT y desarrollo de software.

Volver al Blog