archivo

Archivo de la etiqueta: Larry Bernstein

Querer automatizar el caso, “flujos de trabajo indisciplinados” como indica Larry Bernsteian, es perder tiempo, dinero y requiere un importante desgaste personal para llevarlo a cabo.

Tal vez se consiga poner en producción un producto pero el coste posterior que tiene su explotación y mantenimiento será muy importante porque llegado el momento las diferentes áreas usuarias afectadas querrán que el sistema funcione como ellos entienden que debe hacerlo, con una visión localista y no con una visión global, necesaria para un sistema que pretende ofrecer una solución de carácter horizontal.

Dado que en este tipo de circunstancias los responsables funcionales no impondrán un criterio, se ejecutarán muchos cambios en el sistema sin haber pasado un filtro que determine si realmente la modificación era necesaria y si llevarla a cabo afecta al funcionamiento de algún área usuaria que, cuando descubra que se han hecho esos cambios, entrará en rebeldía, solicitando que se vuelva a la situación anterior, que se le de una solución local o dejarán de utilizar la aplicación.

El sistema, cada vez tendrá más hilos y tuberías, estará lleno de excepciones y casos particulares, será mucho más grande y complejo y por tanto, su evolución y capacidad de adaptación al cambio será costosa y lenta.

Sabiendo que todo eso va a pasar, lo mejor es no abordar el desarrollo del sistema hasta que los procesos que se pretenden informatizar hayan quedado definidos adecuadamente y existan unos mecanismos que velen por su cumplimiento y mejora continua.

Podemos discutir el porcentaje pero no el fondo de la siguiente reflexión de Larry Bernstein: “Sólo entre el 40 y 60% de los requisitos de un sistema se conoce al comienzo del proyecto. El resto emerge con el uso. Barry Boehm acuñó el término requisitos emergentes para describirlos”.

Y no se trata de requisitos que aparecen por arte de magia sino que son consecuencia de la evolución que existe entre lo que el usuario cree que quiere y lo que realmente necesita y de la separación que existe entre la visión abstracta de un producto y su implementación real.

De ese porcentaje inicial de requisitos previsibles, una parte importante de los mismos tiene a su vez que ser perfilada también con la utilización del sistema.

Esto al final nos hace ver que los desarrollos llave en mano y/o los ciclos de vida en cascada no se adaptan a esta realidad y por ese motivo no suelen ofrecer buenos resultados y si lo consiguen es porque todas las partes en alguna parte del proceso de desarrollo se dan cuenta de que es necesario llegar a un acuerdo para que el producto se dirija hacia lo que realmente se necesita y no hacia lo que inicialmente era previsible.

Larry Bernstein en la siguiente reflexión hace referencia a una máxima que tenemos que tener en cuenta todos los que nos dedicamos a este negocio (traducción libre): “No automatices procesos de negocio o workflows donde no existe una disciplina. Los ordenadores no pueden resolver lo que los gestores del cliente no pueden”.

Si se intenta desarrollar un sistema de información que automatice algo que procedimentalmente no se está respetando en la actualidad se está tirando el dinero y no porque no se pueda implementar la aplicación, sino porque existe mucho riesgo de que el retorno de la inversión nunca llegue o tarde mucho.

Esto es así porque en la mayoría de los casos será necesario mucho esfuerzo poner la aplicación en marcha, ya que al no existir previamente un procedimiento que se siga con rigor, muchos de los usuarios no sentirán reflejadas sus expectativas en el sistema, ya que habrá cosas que antes hacían de otra forma y con otras herramientas y eso provocará un rechazo por parte de los mismos que, salvo que existan instrucciones muy precisas de los niveles más altos de la organización, hará que pongan muchos obstáculos a la hora de utilizar la aplicación.

Se tendrá una mayor probabilidad de éxito al automatizar procesos de negocio consolidados. Si lo que se quiere es aprovechar el desarrollo del sistema para consolidar un método de trabajo, el riesgo solo disminuye (pero a costa de un mayor coste de desarrollo ya que serán necesarias una mayor cantidad de iteraciones para conseguir una versión del producto satisfactoria) si existe un compromiso por parte de la dirección de la organización en hacer que los usuarios trabajen de la manera en como se va a definir el sistema y eso se debe hacerse cuanto antes.

El prototipado es una técnica aplicable a prácticamente cualquier metodología de desarrollo ya que no es más que concretar en un entregable, que puede ir desde una serie de imágenes (para mostrar como sería el diseño de un formulario) hasta un producto software, las ideas que el usuario va lanzando sobre lo que quiere que la aplicación haga.

En ciertos tipos de ciclos de vida como el clásico o en cascada este tipo de técnica tiene mucho interés porque independientemente de que estas metodologías sean predictivas y no adaptativas, sí que resulta conveniente que por lo menos, de inicio, la diferencia entre lo que el usuario espera y lo que el analista interpreta sea la menor posible.

En metodologías evolutivas como lo son, por ejemplo, RUP o el conjunto de metodologías ágiles, cuando las iteraciones son cortas, la importancia del prototipado disminuye, si bien sigue resultando un instrumento muy útil cuando se trata de abstraer a un programa de ordenador un aspecto de negocio complejo o para intentar obtener la información más precisa posible del usuario, cuando este no tiene muy claro lo que quiere o no lo sabe explicar de manera adecuada.

Sobre el prototipado Larry Bernstein realiza la siguiente reflexión: “El prototipado reduce el tiempo de desarrollo y el coste en un 40%”.