archivo

Archivo de la etiqueta: win-win

Un modelo de relaciones cliente/proveedor en el que se rompe de manera sensible el equilibrio del todos ganan, afecta al producto de manera directa.

Si la contratación de un proyecto se saca por mucho menos de su valor o un proveedor realiza una oferta muy por debajo de lo que va a costar el desarrollo, habrá problemas.

En los dos casos, el proveedor no va a querer perder dinero (salvo que sea una apuesta para abrir las puertas de un determinado cliente con el objetivo de conseguir nuevos contratos que permitan recuperar la pérdida y obtener beneficios) y por tanto vendrán recortes en la calidad del software y en el alcance del proyecto.

El cliente podrá actuar para minimizar esos recortes pero su control del producto no será suficiente para evitarlos en su totalidad. A lo anterior se le sumará un desgaste importante por parte de las personas implicadas.

En estas circunstancias, el proveedor a veces conseguirá ligeros beneficios, otras se quedará prácticamente a la par y en el resto perderá dinero; mientras que el cliente tendrá un producto probablemente con deuda técnica deficiente, con funcionalidades no implementadas y con incidencias de funcionamiento.

Sin embargo, esta ruptura del equilibrio, no tiene por qué proceder de presupuestos desequilibrados, también se puede producir con presupuestos objetivos a la naturaleza de los trabajos a realizar e incluso con presupuestos holgados.

En estos casos suele estar motivado porque el cliente empiece a realizar cambios sobre el alcance inicial del proyecto o sobre el producto sin consensuar con el proveedor a cambio de qué otras tareas se llevan a cabo (en la mayoría de los casos a cambio de nada) o porque el proveedor quiera paliar la falta de productividad de su equipo y/o maximizar beneficios y reduzca la calidad de los trabajos e intente escamotear todas las funcionalidades que le sean posible.

Por tanto, tanto si se trata de contratación ágil como de otros tipos de contratos entre cliente y proveedor, todo empieza a desviarse cuando se rompe el equilibrio.

Si todo es así de evidente, ¿por qué se rompe el equilibrio? pues porque somos personas y como tales tenemos nuestras debilidades, como por ejemplo nuestra falta de capacidad a la hora de asumir nuestros propios errores. Otro factor es la ambición desmedida.

Y otro factor muy importante es el entorno tanto en el cliente como en el proveedor, que aprietan a las personas implicadas en el proyecto para favorecer sus intereses, por ejemplo, hay que intentar que el proveedor nos haga este módulo aunque no esté contratado o hay que intentar incrementar el margen de beneficio del proyecto un 15%.

¿Es suficiente realizar estos planteamientos al cliente para que acepte el desarrollo de sistema de información aplicando una metodología ágil, teniendo en cuenta que lo mismo está acostumbrado a contratar según un modelo clásico y monolítico y existen otros proveedores que pueden aceptar esas condiciones?.

Si el cliente no conoce los beneficios de la aplicación de los principios ágiles y su instrumentación mediante metodologías podrá ver el enfoque que se plantea alejado de la ortodoxia y ya sabemos todos lo complicado que resulta salir de la zona de seguridad aunque te vaya mal en ella.

Por tanto, si existe la oportunidad de hacer pedagogía con los clientes y mostrarles las ventajas de un enfoque ágil en el desarrollo de software, no solo te estarás ayudando a ti, sino también a toda la profesión y a todo el sector.

No obstante, el desarrollo iterativo incremental ofrece diversas cartas bajo la manga que pueden resultar muy atractivas para el cliente (y también para el proveedor):

– ¿Por qué no incluir en el contrato la posibilidad de que el cliente pueda dar por finalizado el proyecto antes de ejecutar todo el presupuesto?.

Esto se puede plantear de muy diversas formas: Darle la oportunidad a que lo pueda hacer en cualquier momento, a que lo pueda hacer con un mínimo de un % del presupuesto ejecutado, etc… En cualquier caso, el proveedor debería tener como compensación, además de lo ya ejecutado, un % del presupuesto restante (salvo que se haya pactado que un incumplimiento del acuerdo de nivel de servicio pueda suponer que esa compensación se elimine).

En este planteamiento todos ganan:

Si el cliente no está contento puede anular el proyecto, si el proveedor tiene una versión del producto que le parece suficiente no tiene por qué seguir invirtiendo en funcionalidades que lo mismo van a ser innecesarias.

El proveedor en el primer caso, no conseguirá los ingresos inicialmente estimados, pero a cambio se evita el camino a ninguna parte y lleno de desgaste al que iba el proyecto. En el segundo caso, el proveedor obtiene como premio además del beneficio por el trabajo ejecutado, el % extra de la compensación (sería como una prima por hacer las cosas bien).

– ¿Por qué no abordar un modelo relacionado con el esfuerzo necesario para realizar la tarea en el que todos ganen?.

En este caso al esfuerzo planificado se le aplica un buffer de esfuerzo, de manera que si el esfuerzo es t, nos quedemos con un rango válido de [t-buffer,t+buffer]. Si se consigue terminar la tarea con un tiempo entre [t-buffer,t] el beneficio se reparte entre cliente y proveedor y si la tarea termina con un tiempo entre [t,t+buffer], se reparten los gastos.

En el caso de que se superen los límites, habría que estudiar, antes de aplicar cualquier medida el motivo de tal desviación.

No es mi trabajo, no es mi problema, no es asunto mío, ha sido otro, etc… es otro antipatrón muy frecuente, propio de organizaciones o equipos de trabajo donde no existe una visión del colectivo y donde cada cual vela única y exclusivamente por sus intereses.

De todas formas, es conveniente hacer algunas matizaciones:

– Cuando se hereda un trabajo que proviene de otro o de otros, dentro o fuera de la organización, recomiendo que se realice siempre un análisis objetivo del mismo y se exponga a todos los implicados en el proyecto, de manera que se alineen las expectativas de los stakeholders con la realidad del proyecto (esto no es sencillo porque lo mismo las expectativas que tenían eran muy superiores al estado real de los trabajos (antipatrón “Humo y espejos“) y y tal vez seas un recién llegado al que no conocen).

¿Qué no te creen? Tu ya has hecho lo que tenías que hacer, has establecido un punto de partida y a partir de ahí tienes que seguir trabajando, ¿qué siguen teniendo las expectativas que tenían antes? pues el problema en este caso lo tienen ellos. Por supuesto que te salpicará a ti, pero peor sería no haber avisado y seguir con el mismo discurso hasta al final (antipatrón “El traje nuevo del emperador“).

En conclusión, no estás diciendo que este no sea tu trabajo, sino que estás haciendo ver que este es el estado de lo que me encuentro y a partir de ahí empieza mi labor que pretenderá conseguir los objetivos marcados pero modulados y condicionados por la herencia recibida (estamos para intentar conseguir resultados pero no para hacer milagros).

– Tiene una cierta relación con la matización anterior. Salvo que entiendas que por alguna circunstancia debas hacerlo, no tienes por qué aceptar cargar con responsabilidades que no te corresponden, salvo aquellas que sean motivadas por personas a tu cargo, donde sí que es importante que, salvo actos de evidente negligencia o indisciplina, se de la cara por quienes trabajan contigo, con los que hay que estar para lo bueno y para lo malo y con los que hay que lavar los trapos sucios siempre en casa.

Fuera de estas dos matizaciones, en el ámbito de una organización o de un equipo de proyecto hay que esperar un ambiente colaborativo (en el ámbito organizativo donde se premia la depredación en lugar del win-win entre los empleados, resulta un tanto utópico), a veces podrás echar una mano, en otras ocasiones involucrarte realmente en otra tarea (sería conveniente comunicárselo a tu responsable) y otras veces no podrás, pero por lo menos hay que estar abierto a poder ayudar si es posible, aunque eso suponga hacer tareas que entiendas que no te corresponden, ya sea por encima (siendo programador participando en ciertas tareas de análisis o diseño) o por debajo (siendo programador, colaborando en la carga inicial de datos del sistema).

Diversificar siempre se ha considerado una práctica recomendable si se quiere tener más controlado el riesgo de una inversión. Esta práctica resulta igualmente recomendable en el negocio del desarrollo de software, ya que no solo puedes evitar los males relacionados con la tiranía del cliente o la tiranía del proveedor, sino que también te puedes reponer a pérdidas de clientes o a la pérdida de confianza de un determinado proveedor ya que el edificio se seguirá sosteniendo por el resto de columnas.

La diversificación permite modular situaciones que puedan ser utilizadas para imponer condiciones abusivas, sin embargo se trata de un esquema general de funcionamiento y no asegura, ni de lejos, que esa situación de equilibrio llegue al proyecto de desarrollo de software.

He pasado por muchas etapas en cuanto a cuál debería ser la relación de poder entre clientes y proveedores y he llegado a la conclusión de que el modelo del ganar-ganar resulta el más adecuado, pero no solo entre ellos, sino entre el conjunto de stakeholders de un proyecto.

Ahora bien, las dificultades de alcanzar un funcionamiento basado en el win-win, son importantes, y tiene que ver mucho con la dificultad de alinear objetivos.

Y es que el contexto de partida de muchos proyectos suponen un verdadero muro para conseguir que el enfoque de los objetivos entre stakeholders coincida a nivel de mayor prioridad con el éxito del proyecto: presupuestos insuficientes, plazos muy complicados, metodologías no acertadas, falta de directrices por parte de la alta dirección para que los stakeholders estén implicados de verdad (no solo en los papeles), etc…

Diversificación, equilibrio, buenas condiciones de partida, aseguran unos buenos ingredientes al plato, ahora toca que los cocineros trabajen de manera adecuada y las contingencias que se produzcan en la cocina no afecten al acabado del plato.

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.