archivo

Archivo de la etiqueta: ciclo de vida en espiral Win Win

Barry Boehm evolucionó su modelo en espiral hacia el modelo en espiral win & win, probablemente inspirado en sus convicciones de que las personas son las que condicionan el éxito o el fracaso de un proyecto.

Desde esta perspectiva, Boehm defiende que el equilibrio entre todas las partes implicadas se consigue a través de unas condiciones de trabajo y resultados en el que todos ganan ya que de esta forma todos enfocan sus tareas al cumplimiento de los objetivos.

La visión de Boehm, resulta racional, todos luchan por el éxito del proyecto si a través de él ganan.

Sin embargo, ¿qué sucede en la realidad? pues que resulta complicado alcanzar ese equilibrio ya que depende de dónde cada parte ponga el listón de lo que considera ganar ya que lo mismo se coloca a un nivel donde no es posible que los otros ganen.

Hay autores como Jim Camp que no creen en el ganar-ganar (su conocido libro “De entrada diga no” muestra con ejemplos, basado en su experiencia, que no es posible ganar sin que otro pierda o visto de otra manera, siempre habrá alguien que en una negociación gane más que otro) y el fundamento está en que los intereses individuales nublan o incluso anulan la empatía.

Basado en mi experiencia os comentaré que este negocio es una selva y que en ella cada cual intenta sobrevivir como puede. Este contexto no resulta el más adecuado para buscar soluciones basadas en el ganar-ganar, sin embargo, dentro de él, hay que intentar ir hacia una gestión de proyectos en la cual se intente alcanzar el equilibrio del ganar-ganar (el equilibrio difícilmente se conseguirá, pero en su búsqueda se podría llegar a alcanzar una situación en la que cada parte supere el mínimo válido para cumplir sus expectativas).

Para llegar a esto es necesario que cada parte cumpla con su cometido, con lo que ha acordado y que si las condiciones cambian por el propio devenir del proyecto, se llegue a un nuevo contexto que trate de alcanzar de nuevo el modelo del ganar-ganar.

Para que cada parte cumpla, es necesario que de manera individual funcione de forma adecuada, ya que su propio desequilibrio provocará un desequilibrio entre todas las partes y la ruptura del objetivo del ganar-ganar.

Un ejemplo de esto lo podemos tener en el caso de que el proveedor no cumpla sus objetivos de productividad y empiece a poner en riesgo sus expectativas de beneficio, en ese momento probablemente, para mitigar este efecto se empiece a ver afectado la calidad del producto y/o se solicite una ampliación del presupuesto del proyecto.

Otro ejemplo lo podemos tener desde el punto de vista del cliente, cuando se encuentra próximo a consumir el presupuesto o intentar recortarlo y sin embargo todavía no tiene listo el sistema de información (por continuos cambios en el proceso de desarrollo) o quiere mantener su alcance.

Barry Boehm, años después realizó una variante o actualización del ciclo de vida en espiral que definió en 1988.

Con la variante trata de ajustarse más a la realidad de lo que es un proyecto de desarrollo de software, en el cual el resultado final no es exactamente la implementación del catálogo de requisitos, sino que una vez definido se renegocia el alcance del mismo, incluso en diversas partes del proyecto, entre cliente y proveedor con el objetivo de intentar que ambas partes queden satisfechas (aunque en la mayoría de los casos, cada parte solo se mire su ombligo).

La variante se basa en la inclusión de tres etapas o regiones al principio:

1.- Identificar las partes interesadas (stakeholders) para esta nueva iteración del producto: Es necesario definir los interlocutores que serán de áreas que se verán afectadas por el resultado final de la nueva versión. Estos interlocutores serán del área del cliente (puede haber más de uno) y del proveedor.

2.- Identificar las condiciones de victoria de las partes interesadas en el proyecto: Se concreta cuáles son las condiciones que requiere cada parte para que se sienta satisfecha una vez realizada esta versión.

3a.- Reunir las condiciones de victoria: Con las etapas anteriores se han definido unos objetivos generales para la versión y se obtiene conocimiento de los objetivos particulares de cada parte. Ahora toca negociar hasta dónde realmente se va a llegar y cómo, intentando llegar a una solución en la que todos ganen (cliente y proveedor).

Las siguientes etapas tienen una correspondencia con algunas variantes, con la versión inicial del ciclo de vida en espiral:

3b.- Establecer los objetivos, restricciones y alternativas del siguiente nivel: Teniendo en cuenta los objetivos y acuerdos de las fases anteriores, se definirían los requisitos de esta versión, además de especificarse diversas alternativas en el caso de que existan.

4.- Evaluar las alternativas del producto y del proceso y resolución de riesgos: Se realizaría el análisis del riesgo típico de los modelos en espiral.

5.- Definir el siguiente nivel del producto y del proceso, incluyendo particiones: Esta etapa completaría el proceso de análisis y realizaría el diseño y la construcción.

6.- Validar las definiciones del producto y del proceso: Comprendería la implantación y aceptación de la versión, verificándose si el resultado de la iteración satisface el alcance indicado.

7.- Revisión y comentarios: Tocaría hacer inventario, medir el nivel de satisfacción de las partes, el nivel de cumplimiento de objetivos con el objetivo sobre todo de intentar aprender de los errores para mejorar en versiones sucesivas y de detectar correcciones y mejoras a realizar en el producto.

Desde mi punto de vista, lo más interesante del modelo es que se especifique de forma explícita la necesidad de que las partes negocien para llegar a un acuerdo satisfactorio para todos, por eso esta variante recibe el nombre de Win Win. Aunque es complicado alcanzar un equilibrio en el que ambas partes ganen a un 50%, sí que es fundamental que independientemente de si uno es un poco más ganador que el otro, todas las partes estén convencidas en que el acuerdo es bueno.

En cualquier caso sigue sin ser absolutamente realista con respecto al transcurso normal de un proyecto de desarrollo de software, donde la negociación se extiende en muchos proyectos hasta el mismo proceso de construcción del sistema de información, no obstante, si los incrementos no son muy grandes no tendría por qué extenderse tanto la negociación, no obstante, como en este tipo de modelos de ciclo de vida, en cada iteración (incluida la primera) se intenta tener un producto funcionando, salvo que éste sea trivial, las primera etapa por lo menos tendrá tamaño suficiente para que en muchos casos nos encontremos con casos donde se estén negociando aspectos del proyecto hasta el final.