Una checklist verificable para entregar un producto software

Define al responsable receptor y la evidencia de aceptación

Empieza por nombrar la organización y las personas que operarán el producto después de la entrega. Registra quién aprueba lanzamientos, administra producción, responde a incidentes, modifica facturación, revisa hallazgos de seguridad y puede detener un cambio arriesgado. Describe los recorridos de usuario que deben mantenerse, los entornos incluidos y los servicios excluidos de forma deliberada. Una entrega sin responsable receptor puede mover archivos y dejar sin dueño todas las decisiones importantes.

Convierte la finalización en evidencia observable. Exige registro de activos, registro de accesos, mapa de arquitectura, inventario de entornos, procedimiento de despliegue, procedimiento de recuperación, lista de riesgos y backlog de mantenimiento. Indica si cada elemento fue entregado, inspeccionado y ejercitado por el equipo receptor. El contrato puede resolver por separado propiedad, licencias, garantías y obligaciones. Esta checklist registra hechos operativos, pero no determina derechos ni sustituye asesoramiento profesional.

Mueve código y proveedores a organizaciones responsables

Sitúa los repositorios bajo la organización que debe conservar el producto, conforme al acuerdo aplicable. Preserva historial, ramas, etiquetas, releases, issues, pull requests, paquetes, submódulos, archivos grandes y automatizaciones. Revisa los roles en lugar de conceder administración general. Confirma que al menos dos propietarios autorizados pueden recuperar el acceso y que ninguna compilación crítica depende de un fork personal, una clave desconocida o una cuenta que la organización receptora no puede administrar.

Inventaría registrador, DNS, nube, bases, autenticación, almacenamiento, correo, analítica, pagos, tiendas móviles, CI, monitorización, soporte y facturación. Para cada proveedor, registra organización propietaria, responsable de cobros, contacto de recuperación, MFA, entornos, datos tratados y administradores. Invita a personas mediante roles nominales en lugar de compartir contraseñas. Verifica que la empresa controla los canales de recuperación antes de retirar al equipo saliente, porque un traspaso aparente puede fallar en el siguiente acceso o cobro.

Demuestra que construcción y despliegue son reproducibles

Pide a una persona que no preparó la entrega que clone el repositorio en un equipo limpio y siga las instrucciones. Fija versiones de runtimes y herramientas, conserva archivos de bloqueo y enumera SDK nativos, certificados y utilidades externas. Documenta comprobaciones locales, pruebas, comandos de compilación y el camino desde un commit aprobado hasta cada artefacto distribuible. Usa fixtures o datos de ejemplo seguros, nunca secretos ni copias de producción, para que el ejercicio pueda repetirse.

Documenta cada variable y secreto por nombre, finalidad, entorno, ubicación segura, equipo responsable y proceso de rotación, sin guardar el valor. Revisa identidades de CI, claves de despliegue, webhooks, certificados de firma, tokens y cuentas de máquina. Cuando el equipo receptor tenga acceso funcional, rota las credenciales conocidas por personas salientes y elimina permisos obsoletos. Ejecuta un despliegue controlado fuera de producción y una reversión siguiendo únicamente el procedimiento entregado.

Transfiere datos, monitorización y recuperación

Mapea los datos desde su recogida hasta el borrado. Identifica bases principales, objetos, colas, índices, destinos analíticos, exportaciones y procesadores externos. Documenta esquemas, migraciones, retención, eliminación y reconciliaciones manuales. Registra la frecuencia y propiedad de las copias, pero no confundas una tarea correcta con una recuperación demostrada. Restaura datos representativos en un entorno controlado, verifica su integridad y anota tiempo, accesos y dependencias necesarios para utilizarlos.

Enumera paneles, registros, sondas externas, rutas de alerta, canales de incidente y estados de proveedores. Toda alerta urgente necesita una persona receptora y una acción posible. Entrega runbooks para fallos que puedan afectar un recorrido crítico, como proveedor caído, cuota agotada, trabajo fallido, release rechazada o procesamiento parcial. Realiza una simulación con diagnóstico, comunicación, mitigación, reversión y seguimiento, y convierte cada paso confuso en un riesgo abierto con responsable.

Ejecuta el relevo antes de cerrar accesos

Usa una sesión práctica como revisión final. El mantenedor receptor debe explicar la arquitectura, realizar un cambio pequeño, ejecutar pruebas, producir un artefacto, desplegar fuera de producción, inspeccionar telemetría, revertir y completar una recuperación. El equipo saliente puede responder preguntas, pero no operar el proceso de forma oculta. Cada ayuda no documentada se convierte en una tarea explícita de entrega, con evidencia de cierre.

Cierra con elementos aceptados, riesgos pendientes, responsables y fechas de revisión. Separa la entrega de cualquier garantía, soporte o mantenimiento posterior, cuyas condiciones deben revisarse por la vía adecuada. Retira accesos antiguos solo después de verificar reemplazos y recuperación. IVRYN se presenta públicamente como un estudio de producto independiente en París que diseña, desarrolla y opera productos propios y algunos para terceros. Ese contexto no demuestra una entrega concreta sin superar esta checklist.

Criterios de decisión

Aplica las mismas preguntas a cada opción antes de elegir.