AXENTED — Blog Article
Slug: /blog-posts/software-maintenance-cost |
Meta description: La mayoría de los presupuestos de software terminan en el lanzamiento. El costo real de propiedad incluye infraestructura, seguridad, mantenimiento y soporte — típicamente el 15–25% del costo de construcción por año. |
Target keywords: costo mantenimiento software, costo software post lanzamiento, costo total de propiedad software, presupuesto soporte software |
La factura de desarrollo de software se paga. El proyecto se lanza. Todos celebran. Seis meses después, la misma empresa está gastando el 40% de lo que gastó construyendo el sistema solo para mantenerlo funcionando, y nadie lo presupuestó.
Esta es la conversación sobre el costo post-lanzamiento que debería ocurrir antes de que el proyecto comience.
La mayoría de los presupuestos de software cubren descubrimiento, diseño, desarrollo y lanzamiento. No cubren lo que viene después: alojamiento continuo, actualizaciones de seguridad, mantenimiento de dependencias, corrección de bugs, pequeñas adiciones de funcionalidades, optimización de rendimiento y el trabajo acumulado de mantener un sistema de producción funcionando de forma confiable con el tiempo.
El punto de referencia de la industria para el costo de mantenimiento de software es del 15–25% del costo de desarrollo inicial por año. Un sistema que costó $200,000 USD construir típicamente requerirá $30,000–$50,000 USD por año para mantener. Ese número sorprende a los clientes que presupuestaron para el desarrollo pero no para la vida del sistema.
La infraestructura en la nube es el costo de mantenimiento más fácil de cuantificar. Cómputo, almacenamiento, base de datos, redes, CDN, herramientas de monitoreo — estos aparecen como facturas mensuales y son sencillos de proyectar a partir de los patrones de uso inicial. Error común: proyectar costos de infraestructura basados en el uso del entorno de desarrollo en lugar de los patrones de tráfico de producción. Los sistemas en producción manejan más solicitudes, almacenan más datos y necesitan más redundancia que los entornos de desarrollo. Presupuesta de dos a cinco veces el costo de tu entorno de desarrollo para la infraestructura de producción, dependiendo de las expectativas de tráfico.
Cada aplicación tiene dependencias — librerías, frameworks y paquetes de terceros que otros equipos mantienen. Esas dependencias tienen vulnerabilidades. Constantemente se descubren nuevas vulnerabilidades. No actualizar las dependencias significa ejecutar vulnerabilidades conocidas en producción, que es cómo ocurre la mayoría de las brechas.
El mantenimiento de dependencias es trabajo recurrente, no opcional. Para una aplicación web típica, espera gastar cuatro a ocho horas al mes en actualizaciones de dependencias, probando que las actualizaciones no rompieron nada y desplegando los cambios. Eso es tiempo de ingeniería con un costo real. Agrega a eso el costo de abordar cualquier hallazgo de seguridad a nivel de aplicación de pruebas de penetración periódicas, que deberían ocurrir al menos anualmente para cualquier sistema que maneje datos de usuarios.
Hay una distinción que la mayoría de los presupuestos de software difuminan: el costo de mantener las funcionalidades existentes funcionando versus el costo de agregar nuevas. Las funcionalidades existentes se rompen. No catastróficamente, generalmente — la ruptura es sutil. Una API de terceros cambia su formato de respuesta. Una actualización del navegador cambia un comportamiento de CSS. Una base de datos crece lo suficiente como para que una consulta que corría en 50ms ahora corra en 500ms. Mantenerse al día con esta degradación ambiental requiere una asignación constante de capacidad de ingeniería incluso cuando no estás agregando nuevas funcionalidades.
Presupuesta el 10–15% de tu capacidad de ingeniería para el mantenimiento de funcionalidades existentes. Si tienes un ingeniero de tiempo completo, eso son aproximadamente dos a tres horas por semana. Si tienes cinco ingenieros, eso es la mitad del tiempo de un ingeniero. Esta capacidad no debería competir con el desarrollo de funcionalidades en la planificación del sprint — debería reservarse antes de que se asigne el sprint.
Cada aplicación desplegada genera preguntas de soporte. Los usuarios encuentran errores, no pueden encontrar funcionalidades o se topan con casos borde que el equipo no anticipó. Para las herramientas internas, ese soporte recae en el equipo de ingeniería. Para los productos dirigidos a clientes, generalmente hay una función de soporte — pero los bugs que surgen a través del soporte todavía requieren tiempo de ingeniería para diagnosticar y corregir.
Rastrea el tiempo de ingeniería gastado respondiendo a bugs y preguntas impulsados por el soporte durante un mes. El número generalmente es más alto de lo que los equipos esperan, y proporciona una línea base real para presupuestar.
Un presupuesto anual realista post-lanzamiento para una aplicación web de mediana complejidad: infraestructura ($12,000–$24,000 USD), seguridad y mantenimiento de dependencias ($8,000–$15,000 USD), corrección de bugs continua y funcionalidades menores ($20,000–$40,000 USD) e ingeniería de soporte ($5,000–$10,000 USD). Total: $45,000–$89,000 USD por año.
Ese presupuesto es el costo de propiedad. Debería discutirse antes de que se firme el contrato de desarrollo, porque cambia la economía de si tiene sentido construir el sistema.
%20(1)-2.svg)
