Puesta en marcha

PUESTA EN MARCHA
La reforma que es grande para un pas puede ser minscula para otro. Esta diferente evaluacin que a una misma reforma atribuiramos en dos naciones distintas no sera, sin embargo, caprichosa. Una misma y nica razn nos llevar a llamar aqu pequeo lo que all llamamos grande. En ambos casos medimos el tamao de la reforma con la misma unidad de medida. Cul? Muy sencillo: la cantidad de cosas que en cada pas necesiten ser reformadas. Donde casi todo est bien, una pequea modificacin ser de gran importancia. Donde casi todo est mal, esa misma modificacin resultar imperceptible. Jos Ortega y Gasset, La Redencin de las Provincias II, Reforma del Estado o Reforma de la Sociedad

Una vez que se logra la satisfaccin de parte del usuario, y ya superadas todas las consideraciones polticas de las aprobaciones, las presiones ejercidas desde las diferentes esferas relacionadas con el proyecto y estando convenientemente ocultos los errores y deficiencias que se acord mantener, llega la tan esperada etapa de poner el sistema en produccin, conocido en la teora como puesta en marcha. Evidentemente, dentro de la ingenuidad o ms bien candor propio de un principiante, se espera que esta parte del proyecto sea prcticamente transparente, gil, dinmica y dentro de todo lo planificado. De nuevo, nada ms alejado de la realidad.

El ciclo de vida de los proyectos TI: una visin emprica Marco Antonio Rossel

Pgina 1 de 6

Puesta en marcha

El primer considerando errneo en este punto se refiere precisamente a la ausencia de una planificacin especficamente diseada para la implantacin del sistema/producto. Al no considerar la necesidad de planificar esta etapa se suceden una seguidilla de errores que en numerosas ocasiones obligan a rehacer el camino andado en numerosas oportunidades, con la evidente prdida de tiempo y desazn de parte de los usuarios, que dados los atrasos generados durante las etapas previas del desarrollo, ya hace bastante tiempo que tienen su paciencia ms que agotada.

I.1. MARCHA BLANCA ("PRUEBA EN PRODUCCIN") Los modelos tericos son majaderos en indicar que los elementos de software desarrollados deben ser sometidos a pruebas exhaustivas antes de ser puestos en produccin, de tal forma de determinar con antelacin si el sistema/producto funcionar cumpliendo con lo esperado, no fallar durante su operacin normal y adems no afectar el correcto desempeo de otros sistemas con los que se relacione (contabilidad, gestin, facturacin, etc.). No obstante esta exigencia de las metodologas tericas, bastante razonable por lo dems, la realidad suele situarse bastante alejada. Varios son los factores que inciden en que la teora no pueda ser aplicada a cabalidad en este aspecto, a saber: La no-exigencia de planes de prueba a los desarrolladores al momento de realizar el diseo: pocas son las organizaciones que se preocupan de las pruebas a realizar sobre un sistema al momento de disearlo, y al momento de realizar las pruebas los tiempos comprometidos son tales que solo es posible realizar una prueba mnima, casi siempre tendiente a demostrar que el sistema opera en forma aislada.

El ciclo de vida de los proyectos TI: una visin emprica Marco Antonio Rossel

Pgina 2 de 6

Puesta en marcha

Inexistencia de ambientes de prueba smiles de produccin: es altamente complicado levantar ambientes de prueba con esta caracterstica, ya que implica una gran cantidad de recursos. Estos esquemas, denominados ambientes Q&A, permitiran a los usuarios (ojo, no al desarrollador) realizar todas las pruebas necesarias sobre un sistema, de tal forma de determinar no slo que el producto cumple con lo esperado, sino adems que el mismo no afecte negativamente otros sistemas (tpicamente centralizadores como los sistemas contables).

La omisin de la etapa de pruebas de la planificacin del proyecto : por costumbre, mal hbito o simple mtodo personal de trabajo, suele lisa y llanamente omitirse la etapa de pruebas de software del proceso de planificacin. Esto es tan evidente que basta con un simple ejercicio mental para tomar conciencia de este hecho. Imagine el lector que debe desarrollar un programa que sea capaz de leer, insertar, modificar y eliminar elementos de una tabla Oracle (un mantenedor tpico). Si acta con honestidad en la elaboracin de su respuesta, es decir de su estimacin, podr percatarse de que en su primera aproximacin no tom en cuenta realizar pruebas de su mantenedor. Extrapolando este simple ejercicio se demuestra este punto.

La sub-estimacin de las pruebas necesarias: relacionado con los puntos anteriores est ste, en el cual al estimar las pruebas necesarias para un producto de software normalmente no se piensa en ms de un 2% 3% del tiempo de desarrollo, mientras que todo ciclo de pruebas debiera abarcar al menos un 30%.

El ciclo de vida de los proyectos TI: una visin emprica Marco Antonio Rossel

Pgina 3 de 6

Puesta en marcha

I.2. MANEJO DE ERRORES Ahora bien, si ya se est embarcado en esto es evidente que se deber hacer frente a numerosos errores en el producto que se est entregando. Al momento de presentarse un error es imprescindible mostrar una actitud comprensiva hacia el usuario. Es usual pretender ocultar la falla intentando buscar el problema fuera de nuestro crculo de influencia. Dicho de otra forma, es una costumbre tratar de culpar al usuario de la falla, aduciendo desconocimiento en el uso del sistema, problemas en la especificacin original, etctera. Sin embargo, es imprescindible en aras del trabajo en equipo y del logro de los objetivos estratgicos de la institucin en la cual se est trabajando, que la actitud del profesional de la informtica sea esencialmente proactiva en este punto, ya que el usuario, al sentirse inculpado, podra caer en un ostracismo defensivo, el cual finalmente se nos tornara en un problema para nuestro desempeo ya que, y esto nunca lo debemos olvidar quienes trabajamos en unidades de servicio, el usuario es imprescindible para nuestro desempeo y una buena relacin con ellos ser, sin lugar a dudas, un factor determinante en el xito de nuestras empresas profesionales. La actitud proactiva se demuestra con frases como las siguientes: Por favor toma registro detallado del error para poder revisarlo. Yo te dir qu es lo que me hace falta. Te invito a que revisemos los documentos de especificacin para asegurarnos que ambos entendimos lo mismo. Esto no fue parte de la especificacin inicial, pero podemos estudiarlo para la siguiente versin del sistema.

El ciclo de vida de los proyectos TI: una visin emprica Marco Antonio Rossel

Pgina 4 de 6

Puesta en marcha

Ese problema le corresponde resolverlo a otras personas del equipo, pero djame tomar nota para contactarlos y preocuparme de que se resuelva.

Y un largo etctera...

En trminos ms concretos y resumidos, se trata de demostrar una permanente disposicin al trabajo en equipo y a resolver los problemas, no a soslayarlos o a derivar la responsabilidad.

I.3. ACEPTACIN DEL CLIENTE INTERNO (RESPONSABILIDADES COMPARTIDAS) Una vez completado el proceso de definicin, desarrollo, pruebas y marcha blanca (vale decir, la fabricacin) del producto de software, se procede, a travs de un mecanismo formal previamente definido, a cerrar el ciclo mediante una recepcin de parte del usuario. En general, en el documento de entrega (acta de trmino) se dejan explcitos aquellos puntos pendientes del desarrollo. Lo que corresponde es, como en todo orden de cosas, tener una base predefinida exigible. Esta base corresponder a la especificacin de requerimientos hecha en las fases ms tempranas del ciclo de vida. Si se logr una buena definicin de requerimientos en el comienzo del trabajo entonces el nivel de satisfaccin del cliente ser mayor. Ahora bien, como se mencion durante el transcurso de este trabajo, la definicin de requerimientos suele presentar numerosas deficiencias, en particular respecto a la completitud de las mismas. Si a esto incorporamos las otras variables, como las reducciones en las estimaciones de plazo, aceleraciones del trabajo producto de presiones, etc., entonces es poco probable que el cliente se manifieste satisfecho con el producto final.

El ciclo de vida de los proyectos TI: una visin emprica Marco Antonio Rossel

Pgina 5 de 6

Puesta en marcha

Por el cliente en este caso entendemos a los usuarios reales de un producto de software, ya que lo acostumbrado es que los niveles jerrquicos superiores concuerden (entre ellos) que el sistema es justamente lo que uno esperaba recibir y el otro esperaba entregar. En este caso el profesional de informtica debe cumplir con el rol de defender lo construido como lo solicitado. Para ello se debe tener un conocimiento cabal de la especificacin de requerimientos y sus modificaciones posteriores, procurando siempre tener respaldo escrito (grabado) de las solicitudes.

El ciclo de vida de los proyectos TI: una visin emprica Marco Antonio Rossel

Pgina 6 de 6