El problema de entrega del que nadie habla en el lanzamiento
El escenario es familiar y se desarrolla meses después de cerrar un proyecto. Una construcción se completó. El cliente aceptó la entrega y pagó la factura. Luego algo necesita cambiar — una configuración de hosting, una credencial de despliegue, una variable de entorno. El cliente contacta al equipo original. El equipo siguió adelante. Nadie puede encontrar las credenciales. El cliente no puede acceder a su propia infraestructura. Esto no es un caso extremo inusual. Es el resultado predecible de un proceso de entrega que trató la entrega como una transferencia de archivos en lugar de una transferencia de propiedad.
Qué transfiere realmente una entrega completa
Una entrega completa tiene cuatro componentes. Los entregables de producción según el alcance de trabajo firmado — esto es lo que la mayoría de los equipos trata como toda la entrega, cuando en realidad es solo el primer componente. La documentación de transferencia de acceso: credenciales, cuentas de plataforma, registros DNS, configuraciones de despliegue, todo documentado con recibo confirmado del cliente antes de que cierre el compromiso. La documentación técnica: la Lista de Materiales de Software que registra cada dependencia en la entrega, la lista de variables de entorno, el procedimiento de despliegue. Y los términos de soporte post-lanzamiento, delimitados como un retainer de mantenimiento.
La documentación no es para quien lo construyó
La documentación técnica no es un registro para el desarrollador que construyó el sistema. Es un registro para quien lo opere o mantenga después — ya sea una agencia futura, un equipo interno o el cliente mismo. La Lista de Materiales de Software registra el inventario de dependencias en el momento de la entrega: cada paquete, su versión, su licencia. La lista de variables de entorno documenta cada valor de configuración que el sistema requiere para funcionar. El procedimiento de despliegue documenta cómo se lanza una nueva versión sin conocimiento institucional de la construcción. Sin estos tres documentos, la continuidad operacional depende de una llamada telefónica a alguien que puede no estar disponible.
Lo que requiere realmente el cierre de un proyecto
Cada cierre de proyecto de NoDrftSystems sigue una secuencia definida antes de que cualquier elemento sea transferido. La aprobación de calidad debe estar archivada: todas las categorías de revisión completadas, con autorización humana confirmada por escrito — no asumida a partir de la aceptación verbal. La revisión legal se registra para cualquier elemento de contrato, asignación de IP o regulatorio en el entregable. Un barrido del paquete de entrega confirma que no hay activos propietarios internos — documentos de gobernanza, arquitectura del sistema, metodologías internas — presentes en lo que recibe el cliente. Cada credencial de acceso, cuenta de plataforma, registro DNS y configuración de despliegue está documentada con recibo confirmado del cliente antes de que cierre el compromiso. La autorización del Fundador es requerida antes de que cualquier paquete sea transferido: es una aprobación directa, no una delegación, y no ocurre hasta que cada paso previo esté completo. El paquete se ensambla al final — conteniendo solo lo que el alcance de trabajo firmado promete, revisado antes de salir. Ninguna presión de plazo justifica omitir o comprimir esta secuencia. Un paso omitido para cumplir un plazo de entrega se convierte en un defecto que emerge después de que el plazo ha pasado — momento en el que el costo de corrección incluye no solo la corrección técnica sino la confianza necesaria para pedirle al cliente que acepte una segunda entrega.