Qué esperar del mantenimiento de tu software tras el lanzamiento

Es habitual que la conversación sobre un proyecto de software se centre casi por completo en el desarrollo y el lanzamiento, dejando el mantenimiento post-lanzamiento como una idea de último momento. Es un error: un producto en producción tiene necesidades que no existían en el papel, y cómo se gestionan esas necesidades determina si el proyecto sigue aportando valor con el tiempo o empieza a degradarse en silencio.

Monitorización activa desde el primer minuto

Un lanzamiento serio incluye monitorización desde el momento en que el sistema sale a producción — no solo para detectar caídas, sino para identificar comportamientos anómalos (tiempos de carga que se degradan, errores que solo aparecen con ciertos datos reales, patrones de uso inesperados) antes de que se conviertan en un problema visible para el usuario final.

Gestión de incidencias con plazos claros

No todas las incidencias tienen la misma urgencia, y un buen acuerdo de mantenimiento lo refleja: un fallo que impide usar el sistema no se trata con el mismo plazo que un ajuste visual menor. Antes de firmar cualquier acuerdo de mantenimiento, conviene tener claro qué tipos de incidencia existen y qué tiempo de respuesta corresponde a cada una — la ambigüedad aquí es la fuente más habitual de frustración post-lanzamiento.

Actualizaciones que no rompen lo que ya funciona

Un sistema en producción convive con un entorno que cambia constantemente: actualizaciones de sistema operativo, cambios en APIs de terceros, nuevas versiones de las herramientas sobre las que está construido. El mantenimiento incluye seguir ese ritmo de cambios externos sin que el negocio tenga que reaccionar a roturas inesperadas — esto es trabajo continuo, no una tarea puntual que se hace una vez y se olvida.

Evolución del producto según el uso real

El uso real siempre revela necesidades que no eran evidentes durante el diseño. Un buen mantenimiento no se limita a corregir errores, incluye espacio para incorporar mejoras basadas en cómo se está usando realmente el producto — esta es la diferencia entre un sistema que mejora con el tiempo y uno que se queda congelado en la versión del día del lanzamiento.

Qué preguntar antes de firmar un acuerdo de mantenimiento

• →¿Qué tiempo de respuesta corresponde a cada tipo de incidencia (crítica, importante, menor)?
• →¿El mantenimiento incluye actualizar dependencias y librerías, o solo corregir errores que yo reporte?
• →¿Cómo se comunican las incidencias y su resolución? ¿Tengo visibilidad del estado en todo momento?
• →¿Qué pasa si necesito una funcionalidad nueva, no solo corregir algo existente? ¿Es parte del mantenimiento o un proyecto aparte?
• →¿Qué documentación queda tras el proyecto por si en el futuro cambio de proveedor?

Tener estas respuestas claras antes del lanzamiento — idealmente, antes incluso de empezar el desarrollo — evita la sensación habitual de que el soporte post-lanzamiento es un terreno ambiguo. Es una de las preguntas que conviene incluir en la evaluación de cualquier proveedor de desarrollo.