Mantención y evolución de software

Lo que pasa después del lanzamiento

El día que un sistema entra en producción empieza la parte larga. Aparecen los casos que nadie previó, los usuarios encuentran maneras de usarlo que no estaban pensadas, cambian las reglas del negocio, se vencen certificados, un proveedor cambia su API y las dependencias acumulan vulnerabilidades conocidas.

Ninguna de esas cosas es un error del desarrollo. Son la consecuencia normal de tener software funcionando. El problema aparece cuando no hay nadie a cargo de atenderlas, y el sistema se degrada progresivamente hasta que falla en el peor momento.

Este servicio es lo que en otros países se llama mantenimiento de software: alguien responsable de que el sistema siga operando y siga avanzando, con horas comprometidas cada mes.

Qué incluye el plan mensual

• Correcciones. Errores reportados por tu equipo o detectados por el monitoreo, con prioridad según cuánto afectan la operación.
• Nuevas funciones y mejoras. Un bloque de horas mensuales para hacer avanzar el producto según lo que vaya pidiendo el uso real.
• Actualizaciones de seguridad. Dependencias, parches y revisión de accesos. Es la tarea menos vistosa y la que resulta más costosa de omitir.
• Respaldos verificados. Tener respaldos no sirve de nada si nunca se probó restaurarlos. Se prueban.
• Monitoreo. Alertas de caída, de errores y de rendimiento, para enterarme antes de que te llame un cliente.
• Informe mensual. Qué se hizo, qué se detectó y qué conviene priorizar el mes siguiente. En una página, sin relleno.

Cómo se define el tamaño del plan

No hay un precio único porque no cuesta lo mismo sostener un sistema interno que usan diez personas en horario de oficina que una plataforma con pagos en línea que atiende público las veinticuatro horas.

Lo que define el plan:

• Cuántas personas dependen del sistema y qué pasa si se cae una hora.
• Si maneja pagos, datos personales sensibles o información regulada.
• Cuánta evolución esperas: solo mantenerlo funcionando, o hacerlo crecer.
• El estado en que está el código y la infraestructura hoy.

Si el sistema lo hizo otro

Es un escenario frecuente: el proveedor original ya no está, el equipo que lo construyó se fue, o simplemente la relación se terminó. Antes de tomarlo hago una revisión que cubre el código, la infraestructura, los accesos, los respaldos y las dependencias vencidas.

De ahí sale un informe con el estado real, los riesgos inmediatos y qué habría que ordenar antes de operar tranquilo. Ese informe es tuyo aunque después decidas trabajar con otra persona.

El antecedente

Hemos sostenido plataformas en producción durante años, no meses: sistemas con pago en línea, integraciones con terceros y requisitos normativos, funcionando sin interrupciones mientras se les incorporaban funciones nuevas.

Esa es la clase de continuidad que este servicio busca reproducir: que el sistema siga disponible mientras cambia, no que se congele para no romperlo.

Si lo que tienes todavía no está construido, el punto de partida es desarrollo a medida. Si no sabes en qué estado está lo que tienes, empieza por una consultoría.