Qué documentos debes exigir al final de un proyecto de software
Cuando un proyecto termina, los entregables técnicos son tan importantes como el software en sí. Sin esta documentación, dependes del proveedor para siempre.
El software terminó, el proveedor te entregó el acceso y todos están contentos. Hasta que seis meses después necesitas hacer un cambio, el proveedor no está disponible y nadie en tu empresa sabe cómo funciona el sistema por dentro.
Esto se evita si al cerrar el proyecto tienes los entregables correctos.
Los entregables que debes pedir al cierre
1. Código fuente en un repositorio de tu propiedad
No es suficiente que “el proveedor tenga el código”. El repositorio (GitHub, GitLab, Bitbucket) debe estar en una cuenta que controles tú. Al terminar el proyecto, el proveedor hace entrega del acceso transferido a tu cuenta, no solo te invita como colaborador al suyo.
Esto garantiza que si la relación termina, el código no se va con ellos.
2. Documentación del sistema
No necesita ser un libro. Debe incluir:
- Qué hace cada parte del sistema en términos funcionales.
- Cómo están organizadas las principales secciones del código (para que otro desarrollador pueda orientarse).
- Qué servicios externos usa (APIs, bases de datos, servicios de correo, etc.) y cómo están configurados.
- Cómo instalar y correr el sistema en un entorno nuevo.
Sin esto, cualquier desarrollador nuevo que tome el proyecto tiene que adivinar cómo funciona todo.
3. Credenciales y accesos
Una lista ordenada de todos los servicios usados en el proyecto con sus accesos: servidor, base de datos, correo transaccional, servicios de pago, APIs de terceros. Todos bajo cuentas que controles tú, no el proveedor.
Si el proveedor tiene acceso por comodidad, que sea acceso otorgado por ti, no al revés.
4. Manual de operación básico
¿Cómo se hacen las tareas más frecuentes en el sistema? ¿Cómo se agrega un usuario administrador? ¿Cómo se hace un backup? ¿Qué pasa si cae el servidor?
Esto no tiene que ser extenso. Un documento de cinco a diez páginas con los procedimientos más comunes es suficiente para que alguien de tu equipo pueda operar el sistema sin depender del proveedor para todo.
5. Resumen del período de garantía
Qué errores cubre, por cuánto tiempo y cómo reportarlos. La garantía no cubre nuevas funciones ni cambios de requerimiento: solo errores en lo que se acordó construir.
Tenerlo por escrito evita discusiones futuras sobre si algo es un bug o una mejora.
Por qué muchas empresas no tienen esto
Porque no lo pidieron en el contrato inicial. Es mucho más fácil que el proveedor entregue estos elementos si estaban especificados como parte del alcance desde el principio.
Si ya terminaste un proyecto y no tienes estos documentos, todavía puedes pedirlos. Un proveedor serio los tiene aunque no los haya entregado. Si no puede o no quiere, eso también es información útil sobre con quién estás trabajando.
La regla más simple
Al terminar un proyecto de software, deberías poder pasárselo a otro proveedor sin necesitar llamar al anterior para que explique cómo funciona. Si no puedes, faltan entregables.