Los criterios de aceptación son tu carta de garantía para cerrar tu proyecto y para saber cuándo es necesario hacer rollback al sistema. Aquí se debe identificar los indicadores mínimos o máximos que el usuario va a validar/probar del sistema, esos que le van a indicar si andamos por el camino correcto o si nos estamos desviando. Estos indicadores pueden ser: Tiempo de respuesta, número mínimo de registros, porcentaje de errores, entre otros, todos por cada proceso.

2. Selección de los Keyuser

Los Keyuser son aquellas personas que conocen la operación al revés y al derecho. Son los que van a aportar mayor información y son los primeros en ser capacitados. Ellos serán los usuarios expertos en el dominio del sistema implementado. La relación con ellos debe ser la mejor, sus dudas deben ser tus dudas por tal motivo necesitas resolverlas

3. Capacitación a los Usuarios Finales

Cuando vamos a implementar un sistema que tiene muchos usuarios, son los Keyuser quienes necesitan capacitar a escala, es decir llegar hasta los usuarios finales. Esto no significa que el área de Sistemas como responsable del desarrollo del sistema no participe o no esté al tanto de cuándo, a quiénes y cómo se está realizando estas capacitaciones. Recuerda que si el Keyuser dicta una mala capacitación, los usuarios finales aprenden mal y esto impactará en la Salida en vivo del proyecto y durante la estabilización, dado que ellos en ese momento van a preguntar mucho sobre el funcionamiento del sistema o harán los procesos de modo incorrecto, de tal manera que causaran confusión en datos o procesos. Por eso, busca al Keyuser, valida como da la capacitación, apóyalo a que ésta sea dinámica y sencilla, y sobre todo apóyalo a despejar todas las dudas de los usuarios finales.

4. Homologación de Servidor de QA y Producción 

Para contar con unas pruebas lo más reales posibles, es necesario que el servidor que usamos para pruebas o QA esté homologado en Datos e Infraestructura, como el de Producción. Si QA es lento, no sabremos cuál será la performance del sistema en Producción; si la data no es la misma que Producción, simplemente no tendremos casos reales para probar.

5. Creación de los Planes de Contingencia

Aunque tengamos el optimismo y positivismo al tope, necesitamos contar con los planes de contingencia necesarios para evitar las sorpresas de última hora como: se va la conexión a Internet (si tu sistema es trabajado en la nube tendrás problemas), se va la luz, problemas con el servidor de Producción, etc.

6. Creación del Plan de Rollback 

A pesar de que sabes que la implementación que estás realizando va viento en popa, es mejor prevenir el riesgo, no vaya a ser que “Murphy” se aparezca. Para eso es necesario hacer un checklist de todas las actividades que necesitas realizar para “cancelar” el sistema actual y volver al sistema anterior, además de los procesos manuales que esto involucraría. Hacer el Plan de Rollback es parte de la gestión de riesgo y no debe ser tomado como una “preocupación” por que exista algo mal en el proyecto, es simplemente que se ha identificado el riesgo y se previene.

7. Planificación y Ejecución de “Pruebas en Producción”

Pese a que las pruebas en QA hayan sido excelentes y optimistas, es necesario recrear un flujo completo en el ambiente de Producción una vez realizado el Pase. No necesariamente se tiene que hacer con data de prueba, sino que se puede usar aquellas tareas que se han realizado manualmente debido al Pase a Producción y que deben regularizarse en el nuevo sistema. Lo que se busca es validar que el Pase se he realizado de forma correcta y que los flujos están trabajando con normalidad. Estas “pruebas” deben realizarse de forma controlada y con todo el equipo monitoreando, de modo que si surge algún incidente pueda ser corregido en el momento y se pueda continuar, quedando el ambiente Productivo preparado para el Go-Live.