Documentos del Proyecto · Serie 15 · Semana Cierre · Tema 590
Este documento traspasa el resultado del proyecto a quien va a convivir con él durante los próximos años. Y se juzga por una cosa: cuántas veces tiene que llamarte el área de operaciones durante el primer mes.
Para qué sirve, en una línea
Entregar el resultado con todo lo que hace falta para operarlo sin preguntarle nada a quien lo construyó.
Qué se entrega, además del producto
- Documentación de operación. Cómo se arranca, cómo se para, qué se vigila, qué hacer cuando falla lo que suele fallar.
- Accesos y credenciales, transferidos a nombre del área que opera, no prestados.
- Contratos vinculados: licencias, garantías, mantenimientos, con sus fechas de renovación.
- Configuración y dónde vive cada entorno.
- La lista de defectos conocidos.
- Formación impartida: a quién y sobre qué. Y a quién faltaba.
- Acuerdo de acompañamiento: quién queda disponible, con qué dedicación y hasta cuándo.
- Los tres primeros meses del calendario: qué hay que hacer y cuándo, si hay tareas periódicas.
La lista de defectos conocidos
Es el apartado que más cuesta escribir y el que más cambia la experiencia del primer mes.
Todo sistema se entrega con cosas que no funcionan del todo: un proceso que hay que relanzar a mano cuando falla, un informe que tarda si se pide con mucho rango, un caso raro que da error y se resuelve de otra forma. El equipo que lo construyó las conoce todas y las tiene interiorizadas hasta el punto de no percibirlas como defectos.
Si no se escriben, operaciones las descubre una por una, cada una como una incidencia urgente, cada una con su investigación desde cero. Lo que para el equipo original era «ah, sí, eso se relanza», para operaciones son cuatro horas y una llamada.
Escribir esa lista se vive como reconocer defectos y es exactamente lo contrario: es la diferencia entre entregar un sistema y abandonarlo.
Cada defecto conocido con tres datos: qué pasa, cómo se detecta, qué hacer mientras tanto.
El acompañamiento tiene fecha de fin
Dejar a alguien del proyecto disponible unas semanas es sensato y casi siempre necesario. Lo que no puede faltar es la fecha en que eso termina, y qué pasa después.
Sin fecha, el acompañamiento no se acaba nunca: se degrada en un goteo de llamadas que duran años, que nadie contabiliza y que impiden que el área de operaciones aprenda de verdad el sistema, porque siempre tiene a quién preguntar.
Una fórmula que funciona: dedicación decreciente y explícita. Cuatro semanas al 30 %, cuatro más al 10 %, y a partir de ahí por el canal normal de soporte como cualquier otro sistema.
Qué la vuelve papel mojado
- Sin defectos conocidos. Operaciones los redescubre como incidencias.
- Documentación escrita para quien ya sabe. La prueba: que alguien de operaciones la siga delante de ti, sin ayuda.
- Accesos prestados. Con las credenciales de alguien del proyecto que un día se va.
- Sin fecha de fin del acompañamiento.
- Sin contratos ni renovaciones. La licencia caduca y nadie lo sabía.
- Se firma sin que operaciones haya operado nada. La entrega se acepta antes de la primera prueba real.
- Nadie del área receptora participó antes. Y entonces recibe un sistema decidido sin ella.
Y si me falta lo que pide
Operaciones no quiere recibirlo. Suele ser señal de que no participó en el proyecto. Se arregla mal a última hora y bien si se invita pronto; en cualquier caso, escribe qué condiciones pone y llévalo a la decisión de quien manda sobre ambos.
No hay tiempo para documentar. Prioriza: qué se vigila, qué falla y cómo se arregla. Eso cubre la mayor parte de las llamadas del primer mes. El resto puede esperar.
No me dejan dejar gente acompañando. Cuantifica lo que costó la última entrega sin acompañamiento. Casi siempre existe el dato, en forma de incidencias del primer trimestre.
Caso práctico: el proceso nocturno que había que relanzar
Escenario construido con patrones habituales; las cifras son ilustrativas.
Un sistema de gestión de pedidos se entregó a operaciones con documentación completa: manual de usuario, manual técnico, diagramas de arquitectura y procedimientos de arranque y parada. Ciento cuarenta páginas.
No había lista de defectos conocidos. No se omitió a propósito: no estaba en la plantilla y a nadie se le ocurrió.
El sistema tenía un proceso nocturno de consolidación que fallaba aproximadamente una vez cada diez noches, cuando coincidía con el respaldo de otro sistema. El equipo de proyecto lo sabía desde las pruebas. La solución era relanzarlo por la mañana y tardaba dos minutos.
La primera vez que falló en producción, operaciones abrió una incidencia crítica a las siete de la mañana: los pedidos del día anterior no estaban consolidados y el área comercial no podía trabajar.
Dos personas de operaciones dedicaron la mañana a investigar. A mediodía localizaron al que había sido responsable técnico, que contestó en treinta segundos: «ah, sí, eso pasa a veces; se relanza».
Volvió a ocurrir once veces en cuatro meses. Las tres primeras generaron incidencia crítica. A partir de la cuarta, alguien de operaciones lo apuntó en una nota adhesiva.
Tres líneas en un documento de ciento cuarenta páginas habrían ahorrado tres mañanas de dos personas y, sobre todo, la sensación de haber recibido algo que no funcionaba.
Porque ese fue el daño real: durante meses, operaciones describió aquel sistema como «el que falla», cuando fallaba una noche de cada diez de forma conocida y prevista.
Checklist
- ¿Hay lista de defectos conocidos, con qué hacer en cada caso?
- ¿Alguien de operaciones ha seguido la documentación sin ayuda?
- ¿Los accesos están a nombre del área, no de personas del proyecto?
- ¿Están los contratos con sus fechas de renovación?
- ¿El acompañamiento tiene dedicación y fecha de fin?
- ¿Operaciones participó antes de la entrega?
- ¿Se firma después de que hayan operado algo de verdad?
Para cerrar
La entrega a operaciones es el momento en que el proyecto deja de ser un proyecto y pasa a ser algo que alguien tiene que mantener durante años. Todo lo que no se escriba aquí lo va a averiguar otra persona, más despacio y con una incidencia abierta.
Te leo en los comentarios: del último sistema que entregaste, ¿había lista de defectos conocidos?
Referencias
- Project Management Institute, Guía del PMBOK, sobre la transferencia del producto, servicio o resultado final.
- ISO 21502:2020, sobre transición del proyecto a operaciones y sostenibilidad de los beneficios.
- Office of Government Commerce, PRINCE2, sobre la entrega del producto y la confirmación de que está operativo.
← Anterior en la serie: Métricas del proyecto: medir y deformar
Siguiente en la serie: Lecciones aprendidas: tres, no treinta →
Este artículo forma parte de Documentos del Proyecto, una serie de 73 artículos. Ver todos los de esta serie · Índice completo por materia.