Dos presupuestos de mantenimiento pueden incluir servicios diferentes. Compare las tareas incluidas, el horario de soporte, el proceso de incidentes y las exclusiones antes de comparar el precio. La palabra «mantenimiento» por sí sola no define el acuerdo.
Las cuatro cosas que se venden bajo una sola palabra
Correctivo — diagnosticar y solucionar defectos. Especifique si se incluyen la investigación, la reparación, las pruebas de regresión y el despliegue, y cómo se tratan los defectos existentes.
Adaptativo — mantener la aplicación operativa mientras cambia el entorno que la rodea. Actualizaciones del sistema operativo, cambios en los navegadores, versiones de API de terceros, parches de seguridad de bibliotecas y renovaciones de certificados. Esta es la parte que los clientes no esperan y la que hace que una aplicación sin modificaciones deje de funcionar.
Preventivo — trabajos para evitar problemas futuros. Actualizaciones de dependencias, refactorización, optimización del rendimiento y mejora de los registros.
Perfectivo — pequeñas mejoras y nuevas funciones. Con frecuencia se mezcla con un contrato de mantenimiento, y es la principal razón por la que los presupuestos difieren tanto.
Un presupuesto que cubre solo el trabajo correctivo es un producto diferente de otro que cubre las cuatro categorías. Preguntar cuáles de las cuatro están incluidas convierte dos cifras incomparables en una comparación.
Por qué una aplicación sin modificaciones sigue fallando
Los clientes preguntan razonablemente por qué un software que no se está modificando necesita un gasto continuo. La respuesta honesta es que el entorno cambia por debajo de él:
- Los sistemas operativos móviles pueden cambiar su comportamiento u obsolescer API. Defina los dispositivos y las versiones compatibles, así como las pruebas necesarias para una actualización.
- Las tiendas de aplicaciones pueden cambiar los requisitos de envío y disponibilidad. Compruebe las normas actuales de la plataforma y los plazos pertinentes para la aplicación específica; determine quién supervisa y realiza el trabajo necesario.
- Las API de terceros evolucionan y se retiran. Si un proveedor de pagos o mapas deja obsoleta una versión antigua, se debe realizar una actualización según su calendario, no el suyo.
- Las vulnerabilidades de seguridad se descubren constantemente en las bibliotecas, y algunas son lo bastante graves como para requerir parches inmediatos.
- Los certificados caducan, en una fecha conocida, y hacen que el sitio deje de estar disponible cuando eso ocurre.
Ninguna de estas situaciones es causada por la aplicación. Todas requieren trabajar en ella.
Tiempo de respuesta y tiempo de resolución
Son conceptos diferentes y los presupuestos suelen indicar solo el primero.
El tiempo de respuesta mide la confirmación de recepción o el inicio de la investigación, según el contrato. Defina qué evento detiene el contador de respuesta y cómo recibe las actualizaciones el cliente.
El tiempo de resolución mide la finalización de la solución. Defina también el tiempo de restauración para devolver un flujo de trabajo principal a su uso, posiblemente mediante una reversión o una solución temporal. Un servicio puede restaurarse antes de que la causa raíz se resuelva de forma permanente.
Una estructura viable vincula ambos tiempos a la gravedad:
La siguiente es una plantilla para definir el alcance, no un SLA de Manboo ni un tiempo de recuperación prometido. Incluya en el acuerdo real objetivos medibles de confirmación, actualización y restauración, horarios de soporte y contactos de escalamiento. Distinga un objetivo de una resolución garantizada.
| Gravedad | Significado | Controles de respuesta que se deben acordar | Planificación de la restauración |
|---|---|---|---|
| Crítica | Aplicación no disponible o datos en riesgo | Cobertura designada, objetivo de confirmación y ruta de escalamiento | Contención, reversión o solución temporal; registre un objetivo de recuperación y un calendario de actualizaciones |
| Alta | Flujo de trabajo principal interrumpido sin una solución temporal | Prioridad acordada y frecuencia de las actualizaciones de progreso | Evalúe las dependencias y el esfuerzo de reparación; confirme una estimación específica para el incidente |
| Media | Funcionalidad afectada con una solución temporal | Ventana de respuesta acordada durante el horario laboral | Planifique la solución después de revisar el impacto y la versión |
| Baja | Problema cosmético o menor | Confirmación de registro pendiente y proceso de priorización | Programe el trabajo mediante el plan de versiones acordado |
Indique la zona horaria, el horario laboral, los días festivos y cualquier cobertura fuera de horario. Confirme el precio y las condiciones de escalamiento para una cobertura adicional en lugar de asumir un estándar del sector.
Modelos comerciales habituales
- Cuota mensual con una asignación de horas. Es predecible para ambas partes. Pregunte qué sucede con las horas no utilizadas y cómo se cobran las horas excedentes.
- Pago por uso. Autorice el trabajo conforme a una estimación definida a medida que surjan las necesidades. Confirme por separado la disponibilidad y cualquier compromiso de respuesta; este modelo no garantiza por sí mismo el coste más bajo ni una posición concreta en la cola.
- Presupuesto anual. Estime el esfuerzo incluido, la cobertura de soporte, la asignación para incidentes y el trabajo programado de plataforma y seguridad. Identifique por separado los costes de alojamiento y de terceros. Un porcentaje del coste de desarrollo original puede ser una métrica de comparación, pero no demuestra el trabajo necesario y no existe una tarifa universal del 15–25%.
Preguntas que hacen comparables los presupuestos
- ¿Cuáles de los cuatro tipos de mantenimiento están incluidos?
- ¿Cuáles son los compromisos de respuesta y resolución según la gravedad?
- ¿Qué horario cubre el compromiso?
- ¿Están incluidos los costes de alojamiento y de terceros o se facturan por separado?
- ¿Están incluidas las actualizaciones de cumplimiento del sistema operativo y de las tiendas, o se presupuestan cuando surgen?
- ¿Cuántas horas de cambios pequeños están incluidas y qué ocurre cuando se agotan?
- ¿Cuál es el plazo de preaviso para finalizar el acuerdo?
Utilice esas respuestas para comparar el servicio real y el presupuesto total. Registre las exclusiones y los cargos por exceso; un precio anunciado más bajo por sí solo no demuestra un mejor valor ni un alcance más reducido.
Servicios relacionados de Manboo
- Desarrollo de aplicaciones Flutter para MVP de iOS y Android.
- Desarrollo de software empresarial para sistemas de CRM, reservas, inventario y flujos de trabajo.
- Desarrollo de paneles de administración para paneles operativos y gestión del backend.
- Integración de API de IA cuando su producto esté listo para búsquedas inteligentes, chat o automatización.
- Solicite una revisión del alcance y un presupuesto del proyecto cuando esté listo para planificar la primera versión.