Revisando antiguos post, pero no obsoletos :), nuevamente he recaído en el post de Nicolás Osuna, Pesadillas del desarrollador, la verdad es que es una buena fuente de inspiración...De estas “pesadillas” del desarrollador, hoy me voy a centrar en “La implantación y puesta en marcha: si todo funciona realmente bien, la importancia de los datos antiguos, que todos los procesos complicados funcionen, que no haya bugs, gazapos…”Por experiencia y debido a compartir estas pesadillas, una forma de minimizar los problemas que puedan surgir (por no estar correctos todos los datos importados, por no funcionar procesos complicados pero a la vez críticos en la actividad del cliente, que no haya grandes bugs, etc... ) es poniendo en un nuevo directorio diferente al de los datos reales una copia de los datos reales en pruebas. Vamos a hacer un arranque beta, previo al real.El objetivo es conseguir un compromiso por parte del cliente de que durante x días, trabaje de forma dual, por un lado con su actual software y haciendo exactamente lo mismo con el nuevo software. Ésto supone un esfuerzo por parte del cliente, pero es la mejor prueba de fuego de todo el desarrollo y datos. Aunque nosotros probemos los datos, incluyendo los procesos complicados, nunca conseguiremos llegar a donde los usuarios llegan una vez que se ponen a trabajar con la aplicación. Y si no, quién no se ha encontrado alguna vez con la pregunta de ¿cómo lo habrá hecho?Por tanto, si conseguimos este compromiso del cliente y si, además, finalizado el periodo de pruebas, comprobamos que los datos y el funcionamiento de todos los procesos es el correcto, sin duda alguna será un seguro que evitará problemas en el arranque real.Para ello, debemos incluir en el procedimiento de implantación y puesta en marcha un documento de validación previo al arranque, que el cliente debe responsabilizarse a cumplir, algo que no tendremos difícil si nuestro cliente se encuentra implicado en el proyecto y apoya el cambio.Con todo ésto conseguiremos:- corregir errores de importación de datos- detectar errores en procesos críticos- localizar bugs y gazaposEsto nos permitirá antes del arranque en real:- solucionar los problemas anteriores- minimizar el impacto de cambio de softwareAunque este modo de proceder no va a solucionar todos nuestros problemas, los que permanezcan serán menores y se podrán solucionar sin suponer un mayor impacto al cliente y por supuesto dejará de ser una pesadilla... aunque, posiblemente, ¡tendremos otras!Saludos a todos!!
