Error! Use the Home tab to apply Título 1 to the text that you want to appear here. PUESTA EN MARCHA La reforma que es grande para un país puede ser minúscula para otro. Esta diferente evaluación que a una misma reforma atribuiríamos en dos naciones distintas no sería, sin embargo, caprichosa. Una misma y única razón nos llevará a llamar aquí pequeño lo que allí llamamos grande. En ambos casos medimos el tamaño de la reforma con la misma unidad de medida. ¿Cuál? Muy sencillo: la cantidad de cosas que en cada país necesiten ser reformadas. Donde casi todo está bien, una pequeña modificación será de gran importancia. Donde casi todo está mal, esa misma modificación resultará imperceptible. José Ortega y Gasset, ”La Redención de las Provincias II”, Reforma del Estado o Reforma de la Sociedad Una vez que se logra la satisfacción de parte del usuario, y ya superadas todas las consideraciones políticas 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 producción, conocido en la teoría como puesta en marcha. Evidentemente, dentro de la ingenuidad o más bien candor propio de un principiante, se espera que esta parte del proyecto sea prácticamente transparente, ágil, dinámica y dentro de todo lo planificado. De nuevo, nada más alejado de la realidad. El ciclo de vida de los proyectos TI: una visión empírica Marco Antonio Rossel Página 1 de 6 Error! Use the Home tab to apply Título 1 to the text that you want to appear here. El primer considerando erróneo en este punto se refiere precisamente a la ausencia de una planificación específicamente diseñada para la implantación 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 pérdida de tiempo y desazón de parte de los usuarios, que dados los atrasos generados durante las etapas previas del desarrollo, ya hace bastante tiempo que tienen su paciencia más que agotada. I.1. MARCHA BLANCA ("PRUEBA EN PRODUCCIÓN") Los modelos teóricos son majaderos en indicar que los elementos de software desarrollados deben ser sometidos a pruebas exhaustivas antes de ser puestos en producción, de tal forma de determinar con antelación si el sistema/producto funcionará cumpliendo con lo esperado, no fallará durante su operación normal y además no afectará el correcto desempeño de otros sistemas con los que se relacione (contabilidad, gestión, facturación, etc.). No obstante esta exigencia de las metodologías teóricas, bastante razonable por lo demás, la realidad suele situarse bastante alejada. Varios son los factores que inciden en que la teoría 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 diseño: pocas son las organizaciones que se preocupan de las pruebas a realizar sobre un sistema al momento de diseñarlo, y al momento de realizar las pruebas los tiempos comprometidos son tales que solo es posible realizar una prueba mínima, casi siempre tendiente a demostrar que el sistema opera en forma aislada. El ciclo de vida de los proyectos TI: una visión empírica Marco Antonio Rossel Página 2 de 6 Error! Use the Home tab to apply Título 1 to the text that you want to appear here. Inexistencia de ambientes de prueba símiles de producción: es altamente complicado levantar ambientes de prueba con esta característica, ya que implica una gran cantidad de recursos. Estos esquemas, denominados ambientes Q&A, permitirían a los usuarios (ojo, no al desarrollador) realizar todas las pruebas necesarias sobre un sistema, de tal forma de determinar no sólo que el producto cumple con lo esperado, sino además que el mismo no afecte negativamente otros sistemas (típicamente centralizadores como los sistemas contables). La omisión de la etapa de pruebas de la planificación del proyecto: por costumbre, mal hábito o simple método personal de trabajo, suele lisa y llanamente omitirse la etapa de pruebas de software del proceso de planificación. 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 típico). Si actúa con honestidad en la elaboración de su respuesta, es decir de su estimación, podrá percatarse de que en su primera aproximación no tomó en cuenta realizar pruebas de su mantenedor. Extrapolando este simple ejercicio se demuestra este punto. La sub-estimación 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 más 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 visión empírica Marco Antonio Rossel Página 3 de 6 Error! Use the Home tab to apply Título 1 to the text that you want to appear here. 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 círculo 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 especificación original, etcétera. Sin embargo, es imprescindible en aras del trabajo en equipo y del logro de los objetivos estratégicos de la institución en la cual se está trabajando, que la actitud del profesional de la informática sea esencialmente proactiva en este punto, ya que el usuario, al sentirse inculpado, podría caer en un ostracismo defensivo, el cual finalmente se nos tornaría en un problema para nuestro desempeño ya que, y esto nunca lo debemos olvidar quienes trabajamos en unidades de servicio, el usuario es imprescindible para nuestro desempeño y una buena relación 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 especificación para asegurarnos que ambos entendimos lo mismo. Esto no fue parte de la especificación inicial, pero podemos estudiarlo para la siguiente versión del sistema. El ciclo de vida de los proyectos TI: una visión empírica Marco Antonio Rossel Página 4 de 6 Error! Use the Home tab to apply Título 1 to the text that you want to appear here. Ese problema le corresponde resolverlo a otras personas del equipo, pero déjame tomar nota para contactarlos y preocuparme de que se resuelva. Y un largo etcétera... En términos más concretos y resumidos, se trata de demostrar una permanente disposición al trabajo en equipo y a resolver los problemas, no a soslayarlos o a derivar la responsabilidad. I.3. ACEPTACIÓN DEL CLIENTE INTERNO (RESPONSABILIDADES COMPARTIDAS) Una vez completado el proceso de definición, desarrollo, pruebas y marcha blanca (vale decir, la fabricación) del producto de software, se procede, a través de un mecanismo formal previamente definido, a cerrar el ciclo mediante una recepción de parte del usuario. En general, en el documento de entrega (acta de término) se dejan explícitos 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 especificación de requerimientos hecha en las fases más tempranas del ciclo de vida. Si se logró una buena definición de requerimientos en el comienzo del trabajo entonces el nivel de satisfacción del cliente será mayor. Ahora bien, como se mencionó durante el transcurso de este trabajo, la definición 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 visión empírica Marco Antonio Rossel Página 5 de 6 Error! Use the Home tab to apply Título 1 to the text that you want to appear here. Por el cliente en este caso entendemos a los usuarios reales de un producto de software, ya que lo acostumbrado es que los niveles jerárquicos 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 informática debe cumplir con el rol de defender lo construido como lo solicitado. Para ello se debe tener un conocimiento cabal de la especificación de requerimientos y sus modificaciones posteriores, procurando siempre tener respaldo escrito (grabado) de las solicitudes. El ciclo de vida de los proyectos TI: una visión empírica Marco Antonio Rossel Página 6 de 6