Mantenimiento de Software: Lo Que Cuesta y Por Qué No Puedes Saltártelo

Por qué el software necesita mantenimiento en primer lugar

El software no es un puente que queda terminado. Se parece más a un barco en el agua: aun cuando nada en él cambie, el entorno a su alrededor sigue cambiando, y partes que estaban bien el trimestre pasado empiezan a tener fugas. El código que entregaste depende de docenas o cientos de otras piezas, bibliotecas, frameworks, navegadores, sistemas operativos, servicios en la nube, y cada una de esas está siendo actualizada, parcheada, y ocasionalmente retirada por otra persona, en su calendario, no el tuyo.

Dejado solo, el software no se queda quieto. Se desvía. Se descubre una falla de seguridad en una biblioteca de la que dependes, y ahora estás expuesto hasta que alguien la actualice. Un navegador cambia cómo maneja algo y una pantalla se rompe en silencio. Un proveedor de pago da de baja una forma antigua de conectarse y tu pago deja de funcionar en una fecha de la que nadie te avisó. Nada de esto es señal de que la construcción original fuera mala. Es el clima normal en el que vive toda pieza de software funcional.

También está el simple hecho de que el uso real revela cosas que las pruebas nunca revelarán. La gente usa el software de maneras que nadie predijo, afloran casos límite, y pequeñas mejoras se vuelven obvias solo una vez que la cosa está en vivo. El mantenimiento es el trabajo continuo de mantener el software seguro, mantenerlo compatible con el mundo cambiante a su alrededor, arreglar lo que se rompe, y hacer las pequeñas mejoras que lo mantienen genuinamente útil.

Cuánto cuesta típicamente el mantenimiento de software

La regla general que la mayor parte de la industria usa es que el mantenimiento y soporte anual normalmente representa aproximadamente del 15 al 25 por ciento del costo de construcción original por año. Así que si un sistema costó 100,000 dólares construir, típicamente presupuestarías en algún punto del rango de 15,000 a 25,000 dólares al año para mantenerlo sano. Trata eso como una cifra de planificación para calibrar expectativas, no como una cotización, porque el número real depende del software.

Dónde caes dentro de ese rango, o fuera de él, está determinado por unas pocas cosas. El software con muchas integraciones de terceros necesita más cuidado, porque cada conexión es una pieza móvil que otra persona puede cambiar. Cualquier cosa que toque pagos, datos regulados, o requisitos estrictos de disponibilidad conlleva más mantenimiento, porque la seguridad y el cumplimiento no son tareas de una sola vez. Una herramienta interna simple y estable con pocas dependencias puede ubicarse en el extremo bajo o por debajo; una plataforma ocupada, intensiva en integraciones y de cara al cliente se ubicará en el extremo alto.

El encuadre honesto es este: el mantenimiento no es un complemento opcional que un proveedor inventó para seguir facturándote. Es el costo de mantener un activo funcionando. No comprarías una camioneta de reparto y presupuestarías cero para servicio, llantas, y la reparación ocasional. El software es el mismo tipo de compra, y el costo de mantenimiento es el precio de que siga haciendo su trabajo.

Los cuatro tipos de mantenimiento, en lenguaje claro

Cuando la gente en la industria habla de mantenimiento, normalmente se refiere a cuatro cosas distintas, y ayuda saber cuál es cuál, porque no todas se tratan de arreglar lo que está roto. La mayor parte de lo que pagas durante la vida de un sistema es mantenerlo actualizado y prevenir problemas, no parchear fallas.

• ▸Correctivo: arreglar errores y defectos, el trabajo que la mayoría imagina cuando escucha mantenimiento. Algo se comporta mal y se arregla.
• ▸Adaptativo: mantener el software funcionando a medida que el mundo a su alrededor cambia, nuevas versiones de navegador y SO, dependencias actualizadas, cambios de un proveedor de pago o servicio de terceros del que depende.
• ▸Perfectivo: las pequeñas mejoras y refinamientos que revela el uso real, hacer más rápida una pantalla lenta, suavizar un flujo de trabajo torpe, añadir una mejora modesta que la gente sigue pidiendo.
• ▸Preventivo: el trabajo silencioso que detiene los problemas antes de que ocurran, aplicar parches de seguridad, actualizar dependencias antes de que lleguen al fin de su vida útil, y limpiar pequeños problemas antes de que crezcan hasta volverse costosos.

Qué pasa de verdad cuando te lo saltas

Saltarse el mantenimiento se siente gratis por un tiempo, que es exactamente lo que lo hace peligroso. Nada se rompe el primer día. Los costos se acumulan en silencio y luego llegan todos de golpe, normalmente en el peor momento posible. El primer riesgo y el más serio es la seguridad. Las dependencias sin parchear son una de las formas más comunes en que el software se ve comprometido, y la brecha entre que un arreglo esté disponible y que tú lo apliques es la ventana que usa un atacante. Mientras más tiempo pasa el software desatendido, más amplia permanece esa ventana abierta.

El segundo costo es la putrefacción. Cada actualización omitida hace la siguiente más difícil. Las dependencias se quedan más atrás, hasta que ponerse al día ya no es una actualización rutinaria sino un proyecto grande y riesgoso, porque todo se ha movido a la vez y el camino seguro de actualización se ha cerrado. Software que pudo haberse mantenido en pasos pequeños y baratos se convierte en un sistema que necesita una renovación costosa solo para volver a estar al día. Así es como una herramienta que funcionaba bien lentamente se convierte en una que nadie quiere tocar.

El tercer costo es la emergencia en sí. Cuando el mantenimiento se aplaza, no estás evitando el trabajo, estás cambiando un cuidado planificado por crisis no planificadas. En lugar de una pequeña actualización programada, obtienes un pago caído en tu día más ocupado, un incidente de seguridad que exige un arreglo de emergencia, o una pantalla crítica que se rompe tras la actualización de un navegador. El trabajo de emergencia es la forma más cara de comprar tiempo para el software, porque es urgente, es reactivo, y arrastra a la gente con esfuerzo premium para apagar un incendio que el mantenimiento planificado habría prevenido.

El modelo de retención: mantenimiento sin el pánico

Hay dos formas de manejar el mantenimiento, y producen experiencias muy distintas. La primera es romper/arreglar: no haces nada hasta que algo se rompe, y entonces corres a buscar a alguien que lo arregle, a menudo un desconocido para tu código, bajo presión de tiempo, a tarifas de emergencia. Se siente más barato porque no estás pagando entre incendios, pero es la forma más cara y más estresante de mantener el software funcionando, y te deja expuesto mientras tanto.

La alternativa más tranquila es un contrato de retención de mantenimiento: un arreglo mensual estable y predecible donde alguien que conoce tu sistema lo mantiene parcheado, actualizado, monitoreado y mejorado de forma continua. Las actualizaciones de seguridad ocurren antes de que se conviertan en incidentes. Las dependencias se mantienen al día en lugar de pudrirse. Las pequeñas mejoras se hacen a medida que surgen en lugar de amontonarse en un proyecto para algún día. Cambias un costo pequeño y predecible por la eliminación de unos grandes e impredecibles, que es exactamente el intercambio que la mayoría de los dueños quiere una vez que han vivido la alternativa.

Un contrato de retención funciona mejor cuando es genuinamente mes a mes y la persona a cargo ya conoce tu sistema, porque la continuidad es la mayor parte del valor. Alguien que construyó o ha convivido con tu software puede mantenerlo en una fracción del tiempo que le toma a un recién llegado siquiera entenderlo. Esa continuidad es también la razón por la que poseer tu código fuente importa: el mantenimiento debería ser algo que puedas llevar a cualquier parte, nunca una palanca que un proveedor tenga sobre ti. El punto de un contrato de retención no es atarte. Es mantener el sistema en pie, con calma, durante todo el tiempo que dependas de él.