Cuando una relación con un proveedor de software termina —bien o mal— hay una ventana corta en la que se puede pedir todo. Después, esa ventana se cierra: la gente que sabía se reasigna, los accesos caducan y lo que no se pidió deja de estar disponible.
Esta es la lista de lo que hay que exigir mientras la ventana está abierta.
Código
- El repositorio completo, con historial. No un archivo comprimido con la última versión: el historial cuenta por qué las cosas están como están.
- Las ramas y etiquetas. Especialmente la que corresponde a lo que está en producción ahora mismo.
- Confirmación de que lo entregado es lo que corre. Hay que comprobarlo, no aceptarlo. La diferencia entre el código guardado y el desplegado es una de las sorpresas más comunes.
- Dependencias privadas. Si el sistema usa librerías propias del proveedor, hay que pedirlas también o quedarse con código que no compila.
Infraestructura y accesos
- Servidores, dominios, certificados y en nombre de quién están registrados.
- Credenciales de base de datos, servicios externos y pasarelas de pago.
- Las cuentas de terceros: correo transaccional, almacenamiento, mensajería.
- Quién es el titular de cada cuenta. Es distinto tener la contraseña que ser el dueño. Si la cuenta está a nombre del proveedor, hay que transferirla.
Datos
- Un respaldo completo, y la comprobación de que se restaura de verdad. Un respaldo no probado no es un respaldo.
- El esquema documentado, aunque sea a mano alzada.
- Qué datos hay fuera de la base: archivos, adjuntos, imágenes.
Cómo se pone en marcha
Esto es lo que más se olvida y lo que más duele: cómo se lleva un cambio desde el portátil de alguien hasta producción.
- Los pasos exactos del despliegue, en orden.
- Variables de entorno y valores de configuración, con cuáles son distintas en producción.
- Tareas programadas y procesos en segundo plano.
- Cómo se levanta el sistema en un equipo nuevo, probado por alguien que no lo haya hecho antes.
Conocimiento
La parte que no cabe en un archivo. Vale más una sesión grabada de dos horas con quien lo mantuvo que doscientas páginas de documentación escritas con prisa:
- Qué se rompe con más frecuencia y cómo se arregla.
- Qué partes del código son delicadas y por qué.
- Qué se dejó a medias.
- Qué le pediría el propio proveedor a quien viene detrás.
La prueba que lo valida todo
Hay una sola forma de saber si la entrega está completa: alguien que no ha trabajado nunca en ese sistema lo levanta de cero y despliega un cambio pequeño, usando solo lo entregado.
Si lo consigue, la entrega es real. Si necesita preguntarle algo al proveedor, esa pregunta es un hueco, y conviene descubrirlo mientras todavía hay a quién preguntarle.
Sobre qué hacer cuando esa ventana ya se cerró, escribimos en qué hacer cuando el proveedor desaparece.