El paso a producción

Curiosamente, una de las tareas que debería ser de las más simples en el proceso de desarrollo de software se convierte en un autentico muro en muchos proyectos, tan alto que, en ocasiones, superarlo lleva muchísimo tiempo y en consecuencia esfuerzo y dinero.
¿Por qué debería ser simple? El trabajo duro de obtener los requisitos, realizar el resto del análisis, el diseño y la construcción ya está hecho, por lo que sólo quedaría el proceso final de revisión del producto y la instalación en los servidores del cliente.
Sin embargo, algo que teóricamente debería ser ejecutado de manera sencilla no lo es en la práctica por una serie de factores, algunos de los cuales paso a enumerar (en un proyecto concreto puede que no se de ninguno, uno, una combinación de ellos u otros que provoquen que el paso a producción sea una tarea compleja):
1) Miedo al cambio: Si el cliente no termina de ver clara la sustitución de la aplicación que venía utilizando por otra nueva o bien la informatización de un proceso de negocio que hasta ahora no lo estaba, pondrá muchas trabas a que el producto se ponga en producción, ya que una vez que pase dicha barrera, la posibilidad de que puedan evitar su utilización se reducirá considerablemente, ya que se ha realizado una inversión que será necesario amortizarla de alguna manera.
2) Miedo al resultado: Si el cliente tiene dudas sobre el producto (ya sea por culpa suya, del desarrollador o de ambos) y además tiene responsabilidad sobre el resultado final del mismo, tratará de retrasar el paso a producción hasta que tenga una mayor seguridad de que el producto responderá a las expectativas existentes. Como puede darse el caso de que modificar el producto, puede provocar prácticamente rehacerlo, este factor puede convertirse en una de las principales fuentes de problemas con el cliente que querrá hacer en la mayoría de los casos nuevas versiones sin rascarse el bolsillo.
3) Desinterés por el producto: Si el producto no ha sido solicitado por el usuario final que lo va a utilizar, su participación en el proyecto ha sido nula y el proceso de negocio lo tiene resuelto con las herramientas que viniera utilizando hasta ahora, puede dar lugar a circunstancias de miedo al cambio o simplemente de falta de interés en que el producto termine por implantarse, lo que dará lugar a que el producto no se revise, tarde en revisarse o se pongan impedimentos para su puesta en marcha. Otra variante del desinterés es el denominado “se me pasó el arroz”: en ocasiones, los retrasos en el proyecto son tales, que un producto que resultaba interesante, importante o fundamental en un momento dado, más tarde ya no lo es, ya sea porque las prioridades han variado, se han buscado soluciones alternativas o el equipo de personas que mostró interés en su momento o que han participado en su desarrollo ya no están.
4) Búsqueda de la perfección: Nada es perfecto y un producto software tampoco lo es y por más vueltas que se le dé nunca será perfecto, por tanto, si se trata de que el producto pase a producción con un grado de cumplimiento funcional, calidad, seguridad, etc… que se aproxime al 10, no lo conseguirá, producirá retrasos importantes que vendrán acompañados de costes (generalmente para el proveedor) y será una fuente de innumerables conflictos.
5) Mala ejecución de los trabajos: Una cosa es conseguir la perfección y otra permitir que el producto que se pase a producción sea deficiente, por tanto, si el producto no cumple unos mínimos exigibles no pasará el listón del paso a producción y deberán tomarse las medidas correspondientes para que el mismo mejore. Como es lógico, habrá que evaluar las causas que han dado lugar a que la aplicación no haya alcanzado el nivel exigible y en función de las mismas actuar en consecuencia.
6) Entornos de desarrollo distintos a los entornos de prueba y producción: La instalación se puede complicar cuanto mayor sea la divergencia entre los entornos de desarrollo utilizados y los entornos de prueba, preproducción y producción del cliente y mayor sea la complejidad tecnológica de la aplicación y mayor uso de componentes distribuidos tenga. El proceso de instalación puede ser una auténtica pesadilla y requerir un esfuerzo muy importante, con importantes retrasos en la puesta en producción. Para mejorar estos tiempos es conveniente, como es lógico adaptar lo máximo posible el entorno de desarrollo al que tenga el cliente y tener muy bien documentado las características físicas, lógicas y de arquitectura de los mismos, así como los principales problemas que han surgido en las instalaciones y cómo se han arreglado (esto que puede suponer un esfuerzo extra lo agraderán en un futuro tus compañeros y tú, por lo que te recomiendo que documentes y que pongas esa documentación accesible a tus compañeros).

http://jummp.wordpress.com/2010/01/30/el-paso-a-produccion/