Qué sigue tras el contrato de desarrollo software

Al cerrar el contrato de desarrollo de software tu empresa ya ha dado el primer gran paso hacia la digitalización, pero la verdadera prueba empieza cuando el código está entregado. En este artículo verás qué procesos deben activarse, quién responde ante fallas y cómo evitar que la solución quede atada a un solo proveedor.

Lo que empieza el día de la entrega

Nadie habla mucho de la jornada en que el equipo de desarrollo entrega el producto final. Más allá del aliviado “¡listo!”, aparecen varios puntos críticos que deben quedar claros antes de firmar la última hoja del contrato:

• Checklist de aceptación: no basta con que la aplicación funcione; debe cumplir con los criterios de calidad, pruebas de seguridad y alineación con la normativa peruana (por ejemplo, la facturación electrónica exigida por SUNAT). Un documento firmado por ambas partes con los ítems aprobados evita disputas posteriores.

• Plan de transición: el equipo interno necesita acceso a los entornos de prueba y producción, a las credenciales de bases de datos y a los repositorios de código. Si estos accesos no se entregan el día de la firma, la operación puede quedar paralizada durante semanas.

• Capacitación mínima: aunque la capacitación profunda ya se cubrió en otro artículo, al menos se debe garantizar una sesión de “pase de batón” donde el proveedor explique la arquitectura, los puntos de integración y los procedimientos de despliegue.

• Calendario de soporte inicial: la mayoría de los contratos incluyen un periodo de soporte intensivo (usualmente 4‑6 semanas) para corregir bugs críticos detectados en producción. Ese calendario debe quedar registrado por escrito.

Quién responde cuando algo falla

Una vez el software está en producción, la pregunta más frecuente es: ¿a quién acudo si algo deja de funcionar? La respuesta depende de los niveles de responsabilidad que se hayan pactado.

• Soporte de primer nivel: suele ser gestionado por el propio equipo de TI de tu empresa. El contrato debe especificar un SLA (Service Level Agreement) con tiempos de respuesta claros, por ejemplo: incidencias críticas atendidas en 2 horas, medianas en 8 horas y menores en 24 horas.

• Responsabilidad del proveedor: si la falla está vinculada a un error de desarrollo o a una vulnerabilidad de seguridad, el proveedor debe intervenir sin costo adicional dentro del periodo de garantía. Es fundamental que el contrato incluya una cláusula que describa “cobertura de defectos” y establezca el plazo máximo de resolución (por ejemplo, 10 días hábiles).

• Excepciones: modificaciones no autorizadas, uso fuera del alcance acordado o integración con sistemas no contemplados pueden quedar fuera de la responsabilidad del proveedor. En esos casos, el contrato debe indicar el costo de intervención extra y los tiempos estimados.

• Qué exigir por escrito: además del SLA, solicita un informe de incidentes que detalle la causa, la solución aplicada y las acciones preventivas. Esa documentación es útil para medir el retorno de la digitalización y para futuras auditorías de SUNAT.

Mantenimiento: qué es y qué no

El término “mantenimiento” se usa a menudo como paraguas que cubre tres actividades distintas:

1. Corrección de errores: solución de bugs que impiden el funcionamiento esperado. No debe generar cargos extra durante el periodo de garantía.

2. Mejoras evolutivas: incorporación de nuevas funcionalidades o adaptación a cambios regulatorios (por ejemplo, actualizaciones de la normativa de facturación electrónica de SUNAT). Estas mejoras se negocian como proyectos adicionales.

3. Re‑ingeniería: cuando la arquitectura original ya no soporta la carga o la escalabilidad requerida y se necesita una reescritura parcial o total. Este tipo de trabajo es un nuevo contrato, no parte del mantenimiento rutinario.

Es vital que el contrato diferencie claramente estos conceptos y establezca los porcentajes de tiempo que el proveedor dedicará a cada uno. Un reparto típico en un proyecto de 12 meses podría ser: 40 % corrección, 30 % mejoras evolutivas y 30 % planificación de re‑ingeniería.

Cómo evitar quedar atrapado

El mayor miedo de los gerentes es depender de un solo desarrollador y perder el control sobre la solución. Estas prácticas evitan esa situación:

• Accesos y credenciales: al cerrar el proyecto, el proveedor debe entregar todas las claves, tokens y usuarios con privilegios de administrador. Verifica que los accesos funcionen antes de firmar el acta de cierre.

• Copias de seguridad y repositorios: exige que el código fuente se almacene en un repositorio propio (GitHub, GitLab o Azure DevOps) bajo el control de tu empresa. Además, solicita una copia de la base de datos y de los scripts de despliegue.

• Documentación completa: incluye diagramas de arquitectura, manuales de instalación, guías de operación y un registro de dependencias externas (APIs, servicios en la nube). La documentación debe estar versionada y accesible.

• Propiedad intelectual: el contrato debe especificar que todos los derechos de autor y la propiedad del código pasan a tu empresa al momento del pago final. En Perú, la Ley de Protección de la Propiedad Intelectual reconoce la cesión de derechos mediante contrato escrito, así que asegúrate de que la cláusula sea explícita.

• Plan de salida: define un proceso de transición en caso de que decidas cambiar de proveedor. Esto incluye un plazo de entrega de los artefactos y una lista de tareas pendientes para que el nuevo equipo pueda retomar sin interrupciones.

Conclusión

Después de firmar el contrato de desarrollo de software, la fase crítica es la que sigue a la entrega: validar la aceptación, establecer responsabilidades claras, diferenciar los tipos de mantenimiento y asegurar la propiedad total de la solución. Cumplir con estos pasos garantiza que la digitalización de tu empresa peruana no se quede en una promesa, sino que se convierta en un activo operativo que aporte valor y facilite la medición del retorno de la inversión.