Recomendaciones para la implementación de una solución

La fase de implementación o de transicición puede ser más complicada de lo que
aparenta en la planificación. Pero hay recomedaciones que pueden ayudar y que
los gerentes deben tomar en cuenta

Durante todo el año hemos descrito el ciclo de vida de las aplicaciones desarrolladas con buenas prácticas de calidad y  una correcta Arquitectura de información como un espiral que transita cinco fases: Definición, Diseño, Desarrollo, Implementación y Producción. La semana pasada entramos en los problemas que se originan al intentar implementar una solución previamente desarrollada y vimos que, con independencia de la completitud, lo ingenioso y lo bien realizado que estén el trabajo de diseño y la labor de desarrollo de una solución, siempre habrá posibilidades de que se presenten problemas en la implementación porque los ambientes de desarrollo y producción son diferentes, incluso cuando aparentan no serlos en sus indicadores nominales y en las planificaciones.

Siendo así de incierta, la fase de implementación tiene una particular relevancia de la que es conveniente estar conscientes: hasta que no logre su cometido los usuarios no sentirán (y con razón desde su perspectiva) que el trabajo de desarrollo fue realizado, porque, para todo efecto práctico, una solución que no está operativa es una solución que no existe.

Ante esta complejidad podemos preguntarnos si se puede hacer algo para disminuir los riesgos de tener sorpresas durante la fase de transición. La respuesta es que si, que si bien nunca se pueden eliminar totalmente los riesgos, si se pueden minimizar si se realizan cinco cosas que un gerente debe recordar siempre al momento de planificar la implementación dentro de un proyecto.

Se trata de cinco recomendaciones básicas que podemos hacer para la fase de transición. En esta oportunidad las enumeraremos e introduciremos muy brevemente y dejaremos para siguientes ocasiones la ampliación con más detalles. Las recomendaciones son:

1. Establecer explicitamente los criterios de validación
2. Validar la aplicación en el servidor de desarrollo
3. Comenzar la transición en forma temprana, antes de concluir la construcción.
4. Hacer la transición en dos etapas: primero a un servidor de preproducción y luego al servidor de producción
5. Considerar que algunos ajustes pueden ser hechos durante la etapa de producción

Establecer explicitamente los criterios de validación
Tener claro los criterios que debe cumplir la solución construida para poder considerar la tarea realizada elimina subjetividad en las decisiones y una peligrosa fuente de malos entendidos entre las personas involucradas.

Validar la aplicación en el servidor de desarrollo:
Cada cambio de ambiente operativo introduce nuevos posibles puntos de falla e involucra otras personas por lo que es importante tener los criterios de aceptación bien definidos antes de pasar de un ambiente de trabajo a otros.

Comenzar la transición en forma temprana, antes de concluir la construcción:
Hay tareas de transición que pueden hacerse cuando aún se está construyendo y resulta recomendable realizarlas así, cada vez que sea posible.

Hacer la transición en dos etapas: primero a un servidor de preproducción y luego al servidor de producción:
Cuando no hay ambientes de preproducción en las instituciones hay más riesgos. Cuando los hay, se debe usarlos sistemáticamente.

Considerar que algunos ajustes pueden ser hechos durante la etapa de producción:
No se debe jugar al todo o nada. Es importante siempre un poco de flexibilidad en el camino que conduce a una transición plena al ambiente de operaciones final.

Estas cuatro recomendaciones básicas merecen comentarios adicionales. En siguientes oportunidades ampliaremos los detalles…