Garantía en software: qué ocurre tras la entrega

La entrega del proyecto marca el inicio de una nueva fase: la resistencia del equipo a un sistema nuevo se vuelve real y la garantía en el desarrollo de software pasa de papel a práctica. En este artículo verás qué sucede después de la firma, quién debe responder cuando algo falla y cómo proteger a tu empresa de sorpresas.

Lo que empieza el día de la entrega

Ese mismo día en que recibes los accesos, la documentación y el código, el proyecto ya está bajo tu responsabilidad operativa. Lo que nadie cuenta antes de firmar es que la garantía no cubre todo por igual:

• Alcance limitado: la garantía suele cubrir errores que impiden que el sistema cumpla con los requisitos pactados, no mejoras o adaptaciones posteriores.
• Plazo concreto: en Perú, la práctica estándar es entre 8 y 12 semanas de garantía técnica, tiempo en el que el proveedor debe corregir defectos sin costo adicional.
• Entregables de transición: manuales de usuario, diagramas de arquitectura y credenciales de acceso deben estar completos antes de que el reloj de la garantía empiece a correr.

Si tu equipo no está preparado, la resistencia al cambio se traduce en tickets de soporte que se acumulan rápidamente y pueden erosionar la confianza en la solución.

Quién responde cuando algo falla

Una vez que el sistema está en producción, la línea de responsabilidad se vuelve crítica. Define por escrito:

1. Nivel de servicio (SLA): tiempo máximo de respuesta (por ejemplo, 24 h para incidentes críticos) y tiempo de resolución (48 h para errores que bloquean procesos clave como la facturación electrónica de SUNAT).
2. Canales de comunicación: correo dedicado, ticketing system y, si procede, un número de emergencia 24/7.
3. Procedimiento de escalamiento: quién firma la autorización para recursos adicionales y bajo qué condiciones se aplican cargos fuera de garantía.

Exigir un anexo al contrato que detalle estos puntos evita discusiones posteriores y permite a tu equipo planificar sus recursos de soporte interno.

Mantenimiento: qué es y qué no

El término “mantenimiento” genera confusión porque abarca tres actividades distintas:

• Corrección: solución de defectos dentro del alcance de la garantía. No genera costo extra.
• Mejora: incorporación de nuevas funcionalidades o ajustes que no estaban en el alcance original. Requiere un nuevo presupuesto y, por lo general, un nuevo contrato de mantenimiento.
• Re‑desarrollo: cambios estructurales que implican rehacer partes del código. Se trata de un proyecto nuevo, no de mantenimiento.

Para que tu empresa no se quede atrapada, solicita un plan de mantenimiento que indique claramente qué incluye cada categoría y qué procesos seguir para solicitar cada tipo de intervención.

Cómo evitar quedar atrapado

Los siguientes cuatro puntos son esenciales para mantener la soberanía sobre el software:

1. Accesos y credenciales: antes de que finalice la garantía, verifica que tu equipo tenga acceso total a servidores, bases de datos y repositorios de código (Git, Bitbucket, etc.).
2. Copias de seguridad: exige entregas de backups completos y la documentación de los procesos de restauración. Guarda al menos dos copias en ubicaciones distintas.
3. Documentación técnica: incluye diagramas de arquitectura, APIs, dependencias y scripts de despliegue. Sin esta información, cualquier intento de migrar o actualizar será costoso.
4. Propiedad intelectual: el contrato debe dejar claro que el código fuente y los derechos de uso pertenecen a tu empresa una vez finalizada la garantía. Evita cláusulas de “licencia no exclusiva” que limiten tu capacidad de trabajar con otro proveedor.

• El equipo no encuentra la documentación. Los usuarios pierden tiempo buscando información y el soporte interno se vuelve ineficiente.
• Los accesos están bajo control del proveedor. Cada cambio requiere su intervención, generando dependencia y costos ocultos.
• Los tickets se acumulan por errores no cubiertos. La resistencia del personal aumenta y la adopción del sistema se estanca.

Una garantía bien definida y una transferencia de conocimientos clara son la base para que tu inversión digital sea sostenible.

Conclusión

Después de la entrega, la garantía en el desarrollo de software deja de ser una promesa y se convierte en el marco que regula errores, tiempos de respuesta y responsabilidades. Si estableces SLA claros, separas corrección de mejora y aseguras la plena propiedad del código, tu empresa evitará quedar atrapada y podrá superar la resistencia del personal con confianza. El resultado es un sistema que realmente aporta valor y que tu equipo puede gestionar sin depender eternamente del proveedor.