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 1

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 1

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 1

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 1

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 1

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 1