Un contrato de mantenimiento de software debería dejar claro qué pasa cuando aparece un error, quién atiende una consulta, cómo se priorizan los incidentes y qué trabajo se cotiza aparte. La clave no está en prometer que todo se resolverá de inmediato, sino en acordar un marco visible para sostener el sistema sin convertir cada pedido en una discusión de presupuesto.
Un buen acuerdo distingue cuatro tipos de trabajo: correcciones de errores, soporte operativo, cambios sobre funciones existentes y nuevas funcionalidades. También define canales de atención, horarios, tiempos de respuesta, información necesaria para analizar un caso y criterios para decidir qué se hace primero. Sin esas definiciones, incluso un equipo responsable puede terminar trabajando de manera reactiva y con expectativas difíciles de cumplir.
Respuesta corta
Un contrato de mantenimiento de software suele incluir la atención de incidentes, el análisis de errores, la corrección de fallas, consultas de uso, tareas preventivas y, según el acuerdo, pequeños ajustes sobre funciones existentes. No debería incluir automáticamente nuevas funcionalidades, rediseños completos, migraciones grandes, cambios de alcance indefinido ni trabajos originados por sistemas de terceros fuera del control del proveedor.
Para evitar conflictos, el contrato tiene que explicar qué se considera incidente, qué significa una respuesta, cómo se mide una solución, qué nivel de prioridad corresponde a cada caso y cuándo un pedido pasa a ser una mejora o un proyecto separado.
Qué puede incluir el mantenimiento
Corrección de errores
La corrección de errores busca que el software vuelva a comportarse según lo acordado. Por ejemplo, una pantalla que antes permitía registrar una operación y dejó de hacerlo después de un cambio. El criterio importante es comparar el comportamiento observado con una especificación, una regla de negocio o una función que ya estaba disponible.
No todo resultado incómodo es un error. Si una persona solicita que el sistema haga algo que nunca hizo, probablemente se trate de una mejora o una nueva funcionalidad. Esa diferencia conviene documentarla desde el inicio.
Soporte operativo
El soporte puede abarcar dudas sobre el uso, orientación para reproducir un problema, revisión de registros, explicación de mensajes y acompañamiento ante situaciones conocidas. También puede incluir ayuda para identificar si la causa está en la aplicación, en la infraestructura, en los permisos o en una integración.
El soporte no debería confundirse con capacitación ilimitada. Si una organización incorpora muchas personas nuevas o necesita rediseñar sus procesos, puede ser razonable acordar una instancia específica de formación.
Mantenimiento preventivo
Las tareas preventivas apuntan a reducir riesgos antes de que aparezca un incidente. Pueden incluir revisión de registros, actualización planificada de componentes, controles básicos de rendimiento, limpieza de datos temporales o verificación de copias de respaldo cuando esa responsabilidad forma parte del acuerdo.
Conviene describir cada tarea con suficiente precisión. La frase mantenimiento general es demasiado amplia si no se aclara qué se revisa, con qué frecuencia y qué resultado se entrega.
Cambios pequeños
Algunos contratos contemplan una cantidad limitada de ajustes menores. Puede tratarse de modificar un texto, cambiar una validación simple o adaptar un reporte existente. En estos casos, el contrato debería establecer un criterio para determinar qué es pequeño: horas estimadas, cantidad de pantallas afectadas, riesgo técnico o ausencia de cambios en la arquitectura.
La etiqueta pequeño no debería utilizarse para ocultar proyectos grandes. Un pedido aparentemente sencillo puede requerir cambios en datos, permisos, integraciones y pruebas. Si el análisis muestra ese impacto, corresponde reclasificarlo.
Qué suele quedar afuera
Las nuevas funcionalidades normalmente requieren definición funcional, diseño, desarrollo, pruebas y aceptación. Aunque se construyan sobre el mismo sistema, no son necesariamente mantenimiento. Lo mismo ocurre con una aplicación móvil nueva, una migración completa, un cambio de proveedor de infraestructura o una integración que no existía.
También pueden quedar fuera los incidentes causados por configuraciones modificadas por terceros, servicios externos caídos, equipos no administrados por el proveedor o información incompleta entregada para investigar el caso. Esto no significa que el proveedor no pueda ayudar. Significa que el contrato debe explicar cómo se coordina esa ayuda y cómo se estiman sus costos.
| Tipo de pedido | Tratamiento habitual | Pregunta para decidir |
|---|---|---|
| Error reproducible en una función existente | Mantenimiento correctivo | ¿El sistema dejó de cumplir una conducta acordada? |
| Consulta sobre una función disponible | Soporte | ¿Hace falta explicar o verificar el uso? |
| Ajuste acotado sobre una función | Mantenimiento o bolsa de horas | ¿El cambio tiene bajo impacto y alcance claro? |
| Nueva pantalla o nuevo flujo | Mejora o proyecto | ¿Se agrega una capacidad que no existía? |
| Cambio en un servicio externo | Análisis coordinado | ¿La causa depende de un tercero? |
| Revisión periódica de componentes | Mantenimiento preventivo | ¿Está definida la tarea y su frecuencia? |
Cómo fijar prioridades sin discutir cada mes
Priorizar no significa atender al cliente más insistente. Significa ordenar los pedidos según impacto, urgencia, cantidad de personas afectadas y existencia de alternativas temporales. El contrato puede usar categorías simples para que la decisión sea entendible.
Una prioridad crítica podría corresponder a una caída general que impide una operación central y no tiene alternativa disponible. Una prioridad alta puede describir una función importante afectada para un grupo relevante, aunque exista una forma manual de continuar. Una prioridad media puede aplicarse a un inconveniente con impacto acotado. Una prioridad baja suele abarcar consultas, ajustes menores o problemas que no bloquean la operación.
El tiempo de respuesta no es lo mismo que el tiempo de resolución. Responder significa confirmar recepción, pedir datos o informar que el análisis comenzó. Resolver implica corregir, aplicar una alternativa o comunicar una conclusión aceptada. Separar ambos conceptos evita promesas confusas.
También conviene acordar qué información debe acompañar cada pedido: usuario afectado, momento del problema, pasos para reproducirlo, mensaje observado, capturas cuando sean necesarias y nivel de impacto. Un reporte claro reduce idas y vueltas, aunque no garantiza que la causa sea simple.
Cómo separar correcciones de nuevas funcionalidades
La pregunta más útil es: ¿el sistema incumple una conducta existente o se espera que haga algo nuevo? Si incumple una conducta conocida, hay indicios de error. Si se busca una capacidad adicional, hay indicios de mejora.
Hay casos intermedios. Por ejemplo, una regla de negocio pudo cambiar después de que se implementó el sistema. Desde la perspectiva actual, el resultado puede parecer incorrecto, pero técnicamente podría ser un cambio de alcance. El contrato debería prever un proceso para analizar estos casos, registrar el criterio usado y evitar decisiones improvisadas.
Una buena práctica es crear una ficha breve para cada pedido. Debe incluir descripción, impacto, prioridad propuesta, clasificación inicial, dependencias, estimación y decisión final. Esa ficha no tiene que ser burocrática. Puede vivir en una herramienta de seguimiento o en un documento compartido, siempre que las partes puedan consultar el estado.
Checklist antes de firmar
- ¿El contrato define qué se entiende por mantenimiento?
- ¿Distingue errores, soporte, cambios y nuevas funcionalidades?
- ¿Indica los canales válidos para informar incidentes?
- ¿Aclara horarios de atención y períodos no cubiertos?
- ¿Separa tiempo de respuesta de tiempo de resolución?
- ¿Define prioridades con criterios observables?
- ¿Explica qué información debe aportar quien reporta un problema?
- ¿Indica cómo se tratan los servicios de terceros?
- ¿Aclara si existe una bolsa de horas o un límite mensual?
- ¿Describe cómo se cotizan los trabajos fuera de alcance?
- ¿Incluye un proceso de aprobación para mejoras?
- ¿Establece cómo se valida una corrección?
- ¿Indica qué ocurre cuando no se puede reproducir el problema?
- ¿Define responsables de contacto de cada organización?
- ¿Prevé revisiones periódicas del servicio?
Ejemplo trabajado
Una empresa usa un sistema interno para registrar pedidos. Un lunes, varias personas informan que pueden cargar productos, pero al confirmar la operación aparece un error y el pedido no queda guardado.
El primer paso es registrar el incidente con horario, usuarios afectados, pasos realizados y mensaje visible. Como la operación central está bloqueada para varias personas, el caso podría proponerse como prioridad alta o crítica, según exista o no una alternativa operativa.
El proveedor analiza los registros y detecta que una actualización reciente modificó una validación. Si el flujo funcionaba antes y la actualización introdujo la falla, el caso encaja como mantenimiento correctivo. La respuesta inicial puede confirmar la recepción y comunicar una alternativa temporal. La solución puede consistir en revertir el cambio, aplicar una corrección y realizar pruebas antes de informar el cierre.
Ahora supongamos que la empresa pide que, además, el sistema sugiera automáticamente productos relacionados y envíe una notificación a cada cliente. Esos pedidos agregan capacidades nuevas. Pueden ser valiosos, pero deberían analizarse como mejoras, con alcance, estimación y aprobación independientes.
El ejemplo muestra por qué conviene separar urgencia de alcance. Un error urgente puede requerir atención inmediata sin que eso convierta en urgente cualquier mejora solicitada durante el mismo intercambio.
Cómo evaluar niveles de servicio razonables
Un nivel de servicio útil debe ser comprensible y posible de cumplir. No alcanza con escribir atención prioritaria o respuesta rápida. Hay que definir qué sucede, durante qué horario, por qué canal y con qué dependencia de la información entregada por el cliente.
También es importante revisar si el compromiso considera la complejidad técnica. Un incidente puede recibir una respuesta rápida y, sin embargo, necesitar más tiempo para una solución segura. Forzar una corrección apresurada puede producir nuevos problemas, especialmente cuando se modifican datos, permisos o integraciones.
El contrato debería explicar cómo se suspenden o ajustan los plazos cuando falta acceso, no se entrega información suficiente o depende de un tercero. Esta precisión no busca quitar responsabilidad, sino hacer visible qué parte del proceso está bloqueada.
Limitaciones y supuestos
Esta guía usa criterios generales para ordenar un contrato de mantenimiento. No reemplaza la revisión del acuerdo concreto ni contempla todas las particularidades técnicas, comerciales o regulatorias de una organización. Las responsabilidades sobre infraestructura, datos, seguridad, copias de respaldo y proveedores externos deben definirse expresamente cuando sean relevantes.
Los ejemplos son ilustrativos y no establecen una clasificación obligatoria. La misma situación puede tratarse de manera diferente si el contrato original define otra conducta, si hubo cambios aprobados o si la infraestructura está bajo otra responsabilidad. Tampoco se asumen niveles de servicio, horarios, costos ni resultados que no hayan sido acordados.
Preguntas frecuentes
¿El mantenimiento incluye todas las mejoras que pida el cliente?
No necesariamente. Las mejoras agregan o modifican capacidades y suelen requerir análisis, estimación y aprobación. Pueden incluirse dentro de una bolsa de horas si el contrato lo prevé, pero aun así conviene registrar el alcance.
¿Una corrección urgente siempre se resuelve el mismo día?
No. La prioridad puede establecer una respuesta rápida, pero el tiempo de solución depende de la causa, la complejidad, la disponibilidad de información y las dependencias técnicas. El contrato debe diferenciar esos compromisos.
¿Qué pasa si el proveedor no logra reproducir el error?
Debería informar qué revisó, pedir datos adicionales y acordar los próximos pasos. Si el problema no vuelve a ocurrir, puede mantenerse abierto durante un período definido o cerrarse con una explicación documentada.
¿Conviene contratar una cantidad fija de horas?
Puede ser útil cuando el volumen de pedidos es relativamente estable y se necesita previsibilidad. No elimina la necesidad de priorizar ni convierte cualquier pedido en mantenimiento. El contrato debe explicar cómo se consumen y reportan esas horas.
¿Quién decide si algo es error o mejora?
Lo más conveniente es usar criterios acordados y documentar la decisión. Si existe desacuerdo, puede realizarse un análisis breve antes de aprobar el trabajo, separando la atención de un incidente operativo de la discusión sobre un cambio futuro.
¿Hace falta revisar el contrato periódicamente?
Sí, especialmente cuando cambian el sistema, los responsables, las integraciones o el volumen de uso. Una revisión permite ajustar categorías, canales y prioridades sin esperar a que aparezca un conflicto.
Cierre y próximos pasos
Un contrato de mantenimiento de software funciona mejor cuando transforma expectativas difusas en reglas simples: qué se atiende, cómo se informa, quién prioriza y qué se cotiza aparte. La separación entre errores, soporte, mejoras y nuevas funcionalidades protege a ambas partes y permite discutir decisiones concretas en lugar de discutir percepciones.
Para ordenar criterios y preparar una conversación interna, podés consultar los recursos de /guias, revisar alternativas en /catalogo o enviar una consulta desde /contacto.
