Mantenimiento de software: el coste real tras la entrega

La entrega suele presentarse como el final del proyecto. En realidad, es ahí donde empieza el verdadero coste de un software. El presupuesto de desarrollo acapara la atención en el momento de la decisión de inversión — es la línea visible, la que se aprueba en comité. Lo que rara vez aparece en el business case inicial: los años de funcionamiento que vienen después. El mantenimiento representa, a lo largo de la vida de un software, la parte dominante de su coste total de propiedad. A continuación, los componentes que debe conocer para gestionar ese coste en lugar de sufrirlo.

Tipo de mantenimiento	Qué cubre	Naturaleza
Correctivo	Corrección de errores descubiertos tras la puesta en producción	Reactivo — absorbido
Adaptativo	Actualizaciones por cambios en el entorno (SO, librerías, APIs)	Impuesto — previsible
Perfectivo	Mejoras funcionales solicitadas por los usuarios	Elegido — planificable
Preventivo	Refactoring, reducción de la deuda técnica	Inversión — a programar

Lo esencial

• El presupuesto de desarrollo es la parte visible. El coste total de propiedad (TCO) incluye los años de mantenimiento que siguen — y esta suele ser la parte dominante a cinco años.
• Cuatro tipos de mantenimiento coexisten en todo software vivo: correctivo, adaptativo, perfectivo y preventivo. Confundir su peso respectivo lleva a subestimar la factura.
• La deuda técnica es el multiplicador oculto: cuanto más se acumula, más caro y lento resulta cada cambio.
• Un software sin contrato de mantenimiento explícito no es gratuito: las intervenciones se producen de todos modos — pero en modo urgencia, a un coste unitario superior.
• Anticipar el mantenimiento en el pliego de condiciones reduce el coste total, aunque aumente ligeramente el presupuesto inicial.

Por qué el coste de mantenimiento siempre sorprende

En el momento de tomar la decisión de invertir en un software, la comparación se centra casi siempre en el coste de construcción. Es la línea de presupuesto visible, la que se valida. Lo que rara vez aparece en el business case inicial: los años de explotación que vienen a continuación.

Un software en producción es un software vivo. Los sistemas operativos evolucionan. Los navegadores imponen nuevas restricciones. Las APIs de servicios de terceros cambian. Las normativas fiscales, laborales o sectoriales se modifican. Cada cambio externo exige una adaptación interna — y eso tiene un coste.

A esto se suman las demandas de los usuarios: una herramienta que no mejora es rápidamente sustituida por hojas de cálculo o herramientas SaaS paralelas, lo que fragmenta los datos y diluye la inversión inicial. El mantenimiento no es opcional — es la condición de la vida útil del software. Ignorarlo en el cálculo es como construir la mitad de un puente y decir que ya se verá la otra mitad más adelante.

Los 4 tipos de mantenimiento: naturaleza y peso

Mantenimiento correctivo

Es el más intuitivo: se corrige lo que no funciona. Los errores descubiertos tras la puesta en producción — casos no previstos durante las pruebas, comportamientos inesperados en condiciones reales — deben tratarse rápidamente para no bloquear la actividad.

Su coste depende directamente de la calidad del código inicial y del rigor de las pruebas. Un software bien probado en la entrega genera muchos menos correctivos en los primeros años. Invertir en pruebas en la entrega es también invertir en un menor coste de mantenimiento correctivo.

Mantenimiento adaptativo

Un software no vive aislado. Se apoya en tecnologías subyacentes: sistemas operativos, bases de datos, librerías, frameworks, servicios en la nube. Cuando estos componentes evolucionan, el software debe adaptarse — ya sea una actualización de seguridad obligatoria, un cambio en la API de un socio o una obligación legal.

Es a menudo el tipo de mantenimiento menos visible hasta que se vuelve urgente. Ignorar las actualizaciones durante varios años equivale a acumular una deuda de adaptación que se salda tarde o temprano — habitualmente en modo crisis, bajo presión, a un coste mayor.

Mantenimiento perfectivo

Son las mejoras realizadas a petición de los usuarios: una nueva funcionalidad, un flujo simplificado, una integración con una nueva herramienta. Es el mantenimiento que crea valor visible, pero también el que consume más presupuesto a lo largo del tiempo en un software activo.

Distinguirlo claramente de los otros tipos es importante: es una decisión de inversión, no un mantenimiento rutinario. Debe someterse a una priorización — y gestionarse como parte de una hoja de ruta de producto, no como una corriente permanente de solicitudes ad hoc.

Mantenimiento preventivo

Es el menos valorado y el más útil a largo plazo. Consiste en reestructurar el código (refactoring), reducir la deuda técnica y modernizar los componentes antes de que causen problemas.

Un software cuyo mantenimiento preventivo ha sido descuidado durante varios años se vuelve difícil y costoso de evolucionar. Cada nueva funcionalidad tarda más de lo previsto y genera efectos secundarios inesperados. Es la deuda técnica trabajando — silenciosamente, pero sin descanso.

La deuda técnica: el coste que no vio venir

La deuda técnica es el atajo tomado durante el desarrollo para entregar más rápido, que se paga con intereses más adelante. No es un concepto abstracto: es el módulo que nunca se refactorizó, la librería obsoleta que nunca se actualizó, el código duplicado que nadie racionalizó.

La deuda se acumula silenciosamente. Sus efectos se hacen visibles cuando una solicitud aparentemente simple — «añadir una columna a este informe» — tarda de repente dos semanas en lugar de dos días. Es la deuda trabajando: cada cambio debe ahora sortear la estructura existente, multiplicando el tiempo y el riesgo de errores.

Gestionar la deuda técnica significa integrar una línea de mantenimiento preventivo en el plan de evolución del software. Los equipos que lo hacen sistemáticamente mantienen una velocidad de desarrollo estable. Los que no lo hacen ven cómo su software se vuelve progresivamente imposible de mantener — hasta que resulta necesario reescribirlo por completo, a un coste muy superior al que habría supuesto el mantenimiento regular.

Cómo gestionar el coste de mantenimiento

1. Definir el mantenimiento desde el contrato inicial

Un software entregado sin un acuerdo de mantenimiento no se mantiene gratuitamente: las intervenciones se realizan de forma puntual, en modo time-and-materials, a menudo en urgencia — el modo más caro de operar. Un contrato de mantenimiento fija el marco: alcance cubierto, tiempos de respuesta garantizados, horas incluidas, condiciones de facturación de los trabajos fuera de contrato.

Hay que negociarlo en el momento de la entrega, cuando el proveedor conoce el código — no seis meses después. Es también en este momento cuando hay que negociar la cesión del código fuente (art. L113-9 del Código de la Propiedad Intelectual francés), condición indispensable para poder cambiar de proveedor si fuera necesario.

2. Presupuestar por tipo de mantenimiento y por periodo

Los cuatro tipos no tienen el mismo peso según la madurez del software:

• Primer año: el mantenimiento correctivo domina. Los errores post-lanzamiento absorben la mayor parte de las intervenciones.
• Años 2-4: el mantenimiento adaptativo y perfectivo toma el relevo. El software se integra mejor en el entorno técnico; los usuarios formulan solicitudes de mejora.
• A partir de ahí: la deuda técnica empieza a pesar si no se ha gestionado. El mantenimiento preventivo se vuelve prioritario para evitar una reescritura total.

Esta lectura temporal permite presupuestar con más precisión en lugar de tratar el mantenimiento como una línea fija idéntica cada año.

3. Medir para anticipar

Algunos indicadores permiten evaluar objetivamente la situación sin ser desarrollador:

• Tasa de errores recurrentes: si los mismos fallos aparecen cada mes, la causa raíz no está siendo tratada.
• Tiempo medio de un cambio: si se alarga trimestre tras trimestre, suele ser señal de deuda técnica creciente.
• Frecuencia de actualización de dependencias: un software cuyas librerías no se han actualizado en varios años acumula una deuda de seguridad y adaptación.

Estos indicadores deben solicitarse a su equipo técnico o proveedor en las reuniones de seguimiento — deben estar disponibles, no ocultos. Si no se están midiendo, eso ya es una señal.

Externalizar el mantenimiento: qué cambia realmente

Confiar el mantenimiento a un proveedor externo — el equipo que construyó el software u otro — desplaza el riesgo en lugar de eliminarlo. Lo que cambia en la práctica:

• La curva de aprendizaje: un nuevo proveedor necesita tiempo para entender el código. Si la documentación es escasa y la base de código es compleja, esa curva de aprendizaje se factura.
• La continuidad: un contrato de mantenimiento estructurado con un socio a largo plazo es más predecible que una sucesión de intervenciones puntuales.
• El coste por jornada: para las pymes cuyo software es crítico pero no tienen masa crítica para un equipo interno, externalizar a un socio francófono bien formado ofrece una reactividad sostenida a costes de estructura inferiores a los del mercado europeo. Es el modelo que NEXARA despliega desde Madagascar — equipos francófonos, diferencia horaria reducida (UTC+3), experiencia técnica.

El mantenimiento externalizado suele ser menos costoso que el interno para un sistema de tamaño medio — siempre que el contrato esté bien definido y el código esté documentado.

Preguntas frecuentes (FAQ)

¿Cuánto representa el mantenimiento frente al coste de desarrollo inicial?

No existe un ratio universal, pero el mantenimiento representa habitualmente la parte dominante del TCO a cinco años — a menudo muy por encima del coste de construcción inicial. Depende de la calidad del código entregado, la complejidad del entorno técnico y el volumen de cambios solicitados. Un software bien encuadrado desde el principio, con pruebas rigurosas, cuesta mucho menos de mantener. Nuestra guía de costes de software a medida detalla los rangos de coste de construcción — intégrelos en su cálculo de TCO.

¿Cuál es la diferencia entre mantenimiento correctivo y evolutivo?

El mantenimiento correctivo arregla lo que no funciona (errores, anomalías). El mantenimiento evolutivo (o perfectivo) añade funcionalidades o mejora las existentes. Son dos tipos de intervención radicalmente diferentes: el primero se absorbe, el segundo se elige. Confundirlos lleva a gestionar mal el presupuesto y a tratar las mejoras como correcciones, lo que distorsiona las prioridades y diluye el presupuesto disponible.

¿Cómo evitar una reescritura total costosa?

Gestionando la deuda técnica de forma regular, en lugar de dejarla acumularse. Un plan de mantenimiento preventivo — incluso modesto — que reserve tiempo para el refactoring en cada ciclo de desarrollo preserva la mantenibilidad del software a largo plazo. Una reescritura total es casi siempre el resultado de años de deuda no tratada. Si se encuentra en esa situación, nuestra guía sobre cómo llevar un proyecto de software sin pasarse de presupuesto establece los fundamentos para retomar el buen camino.

¿Un SaaS (suscripción) escapa a los costes de mantenimiento?

Parcialmente. Los costes de infraestructura, seguridad y actualización de funcionalidades genéricas están incluidos en la suscripción. Pero las integraciones a medida, las adaptaciones a sus procesos y la formación de usuarios siguen siendo su responsabilidad. Y si el SaaS se descontinúa o cambia su modelo de precios, migrar sus datos puede ser costoso. La elección entre software a medida y solución de mercado aborda este criterio explícitamente en la cuadrícula de decisión.

¿Qué ocurre si el proveedor que desarrolló el software ya no está disponible?

Es el escenario crítico que la cláusula de cesión del código (art. L113-9 del CPI francés) pretende prevenir: usted debe ser propietario del código fuente. Con ese derecho, otro proveedor puede retomar el proyecto. Sin documentación ni pruebas, la transición sigue siendo difícil y costosa — otra razón para exigir estos entregables en la recepción del proyecto, antes de liquidar la factura final.

¿Cómo medir el ROI del mantenimiento preventivo?

El mantenimiento preventivo es difícil de valorar a priori — no se ve lo que no ocurre. La medición viene después: compare el tiempo medio para implementar un cambio antes y después de una fase de reducción de deuda. Un cambio que tarda 3 días menos en ejecutarse, sobre 20 cambios al año, representa 60 días de ahorro — menos tiempo facturable. Para encuadrar esto en el ROI global de su software, nuestra guía de cálculo del ROI de un software de gestión proporciona una metodología completa.