Un sistema puede funcionar al entregarse y necesitar atención después: cambian los dispositivos, las dependencias, los procesos y las personas que lo utilizan. «Mantenimiento» no significa lo mismo en todas las propuestas. La conversación útil empieza al separar qué se hará, quién decide y cómo se atenderán las interrupciones.

Cuatro trabajos que suelen confundirse

El mantenimiento correctivo aborda fallos frente al comportamiento acordado. El evolutivo modifica o añade capacidades. El preventivo incluye actividades acordadas para reducir riesgos, como revisar dependencias y realizar pruebas. La operación de infraestructura comprende tareas como alojamiento, monitoreo y copias, si forman parte del contrato.

Un servicio puede incluir algunas de estas actividades y excluir otras. No supongas que una suscripción de alojamiento cubre cambios funcionales, ni que corregir un defecto incluye migrar a una versión mayor. Pregunta también quién paga y administra servicios externos.

Define alcance y forma de atención

Prepara una lista de componentes: aplicación, base de datos, dominio, integraciones, cuentas de proveedores y dispositivos compatibles. Para cada uno indica responsable, acceso, horario de atención, canal de reporte y procedimiento ante un incidente. Un acuerdo puede definir prioridades por impacto y objetivos de respuesta; respuesta no siempre significa resolución.

Pregunta cómo se autoriza trabajo adicional, cómo se documentan los cambios y si existe un límite de esfuerzo o una tarifa separada. Los términos concretos dependen de la propuesta y conviene revisarlos con quien administra el presupuesto.

Actualizaciones con control

Aplicar una actualización sin revisar dependencias o probar el recorrido principal puede introducir un problema nuevo. Conviene acordar cómo se identifican cambios, dónde se ensayan, quién valida y qué plan existe si no funcionan. La guía de OWASP sobre integración y entrega trata el manejo controlado de cambios y componentes; úsala como referencia técnica, no como promesa de seguridad absoluta.

Un ejemplo y una lista de decisión

Imagina una empresa con un portal de solicitudes. Un error impide guardar el formulario; también quiere añadir una nueva etapa de aprobación. El primer caso podría evaluarse como corrección y el segundo como evolución. Si el portal usa un proveedor externo que cambió su servicio, habría que revisar en qué alcance cae la adaptación.

  • ¿Qué componentes están cubiertos y cuáles no?
  • ¿Cómo se clasifican y priorizan los reportes?
  • ¿Quién aprueba actualizaciones y funcionalidades adicionales?
  • ¿Qué pasa con infraestructura, copias, accesos y proveedores externos?
  • ¿Cómo se entregan documentación y credenciales al terminar?

Un buen alcance no elimina todas las incidencias. Hace visibles las expectativas, las dependencias y el siguiente paso cuando aparece una necesidad nueva.

Separa urgencia de prioridad

Un inconveniente puede ser molesto para una persona o impedir que todo el equipo trabaje. Acuerda ejemplos de impacto para clasificar reportes y evitar que cada solicitud se gestione como una emergencia. También define qué información debe acompañar el reporte: la acción intentada, el resultado observado, el momento aproximado y un identificador que no exponga datos sensibles.

Cuando el proveedor corrige un problema, conviene registrar qué cambió y pedir una validación en un caso representativo. Si la mejora requiere alterar el proceso o una integración, trátala como trabajo de alcance propio. Así la conversación se centra en responsabilidades verificables y no en palabras amplias como «soporte ilimitado».

Fuentes consultadas

Hablemos de lo que necesitas mantener

Cuéntanos qué sistema utilizas y qué tipo de acompañamiento estás buscando.

Cuéntanos sobre tu sistema