archivo

Archivo de la etiqueta: stakeholder

Es muy importante saber dónde se encuentra cada uno y cuál es su rol. Pero partiendo de esa base, los proyectos funcionan mejor cuanto menos muros existen entre los diferentes stakeholders en el proyecto (en el título del artículo he puesto unos cuantos, en la medida en que sean más los que decidan aplicar esta filosofía, las cosas funcionarán mucho mejor).

Venimos de una cultura formalista, en la que los mecanismos de comunicación se centraban en el intercambio de papel. Una cultura en la que todas las partes trataban de cubrirse las espaldas, para que cuando hubiera problemas, que los había, por mucho papel que hubiera por medio, todos tuvieran argumentos de defensa o de ataque.

El problema no era que quedasen cosas registradas en papel, en sí no es malo siempre y cuando no se abuse de él, sino la orientación que se le dio. En lugar de crear espacios comunes se creaban muros de defensa para lo que después podría venir.

Y es que al final nadie solía quedar satisfecho. La crisis del software (totalmente vigente hoy día) daba como resultado productos que no satisfacían las necesidades del cliente y encima el proveedor obtenía, en el mejor de los casos, beneficios muy escasos. Además, generalmente cuando más satisfecha quedaba una parte, menos quedaba la otra.

Eso necesariamente no lo arregla un simple cambio de mentalidad, porque en un proyecto siempre hay muchos intereses en juego e intervienen personas ajenas a los mismos pero que tienen influencia directa sobre los equipos (los responsables de los departamentos implicados o de las propias organizaciones).

Para que esto termine calando dentro de una determinada organización o departamento se requiere su tiempo, pero alguien tiene que dar el primer paso, y verás como te alegras de ser tú el que lo ha dado.

Para Jim Highsmith (traducción libre): “La gestión de proyectos ágil abarca tanto “hacer” y “ser” ágiles, siendo lo segundo lo más difícil”.

Gestionar proyectos siguiendo metodologías ágiles no hace necesariamente ágil ni a quien gestiona, ni al equipo de proyecto, ni al proyecto, porque la agilidad no se consigue solo con metodologías porque la agilidad está por encima de ellas.

¿Qué pasa si tu contexto de trabajo no te permite aplicar metodologías ágiles?, ¿desenchufas y ya no aplicas un enfoque ágil? Incluso en las circunstancias más adversas para ser ágil existirán resquicios que te permitirán serlo (con mayor o menor trascendencia).

La gestión ágil debe empezar desde el mismo proceso de definición del proyecto, realizando las tareas que sean necesarias para evitar que desde su inicio sea considerado un Death March Project (en este tipo de contextos los árboles siempre impedirán ver el bosque y la presión y el exceso de carga de trabajo dificultará la creación de un clima donde el equipo de proyecto sea colaborativo y esté motivado) y para asegurarse que los stakeholders, sobre todo el área usuaria, tienen la implicación que requiere el proyecto (ellos tienen que definir la línea de desarrollo del producto, especificar los requisitos, indicar sus expectativas).

Si no se logran esos objetivos (y es posible que así sea porque generalmente podremos intentar influir pero el poder de decisión estará lejos de nosotros) seguimos teniendo el proyecto bajo nuestra responsabilidad y aunque las restricciones establecidas hagan daño al modelo de funcionamiento que nos gustaría implantar, no hay que tirar la toalla para la aplicación de enfoques ágiles, es más, nunca hay que tirarla.

Después la gestión ágil debe contextualizar los métodos de trabajo a la naturaleza del proyecto y del equipo de personas que van a participar en él y estar dispuesto a hacer los cambios necesarios para mejorar si fuera preciso y/o para adaptarse al cambio (para esto es fundamental que la estrategia de desarrollo utilizada y la calidad del software creen la menor resistencia posible).

Y tras eso, mucho más, porque la gestión ágil es un día a día con tu equipo (o equipos) de trabajo y el resto de personas o grupos de personas que intervienen de alguna u otra forma en el proyecto, de manera que se consolide una relación de confianza entre todos ellos (y dentro del equipo de proyecto), que el nivel de implicación de todas las partes se mantenga acorde a las necesidades del proyecto, que la comunicación entre todos sea fluida y que todos se sientan importantes.

La comunicación es básica en los proyectos de desarrollo de software y no solo entre los miembros de un equipo (algo que es esencial) sino también entre los stakeholders.

Una vez que se consigue que la comunicación sea fluida (no es tan fácil ya que no solo depende de uno mismo) o por lo menos que exista cuando sea necesario es importante que de vez en cuando haya encuentros cara a cara (cuanto mayor sea la relación que se tenga que tener más frecuentes deberían ser esos encuentros).

Es cierto que el contexto en el que se desarrolla el proyecto condiciona mucho y si tu cliente está a 500 kilómetros o en otro país no es tan sencillo conseguir esa cercanía, lo cual no quita que se busque el mecanismo de comunicación que permita una mayor proximidad dentro de esas condiciones y en el que ambas partes se sientan cómodos.

Y es que la comunicación previene de muchos problemas y también permite resolver otros tantos. Cuando hay un malentendido, un conflicto o un desencuentro lo mejor es hablarlo y hacerlo cuanto antes. A veces, en función del carácter que tenga cada uno es interesante esperar un poco ya que a veces es mejor dar tiempo a reflexionar y ver las cosas desde otras perspectiva. Esperar un poco no es aguardar a que el problema desaparezca porque en este tipo de circunstancias suele quedar un poso que tarde o temprano termina saliendo afuera, sino hablar unas horas o unos días después.

Pero no es solo útil en este tipo de circunstancias, ya que permite armonizar las visión del conjunto sobre el proyecto, resolver dudas y lo más importante desarrollar y consolidar paulatinamente la relación de confianza.

Generalmente muchos problemas en los proyectos no vienen por un exceso en la comunicación sino por su defecto.

En la confianza se cimentan las relaciones personales, laborales y mercantiles.

Cuando un equipo de proyecto y los stakeholders construyen un ambiente de confianza disminuye la resistencia para conseguir el éxito, es la diferencia entre ir todos a una o encontrar personas o equipos que empujan en direcciones direcciones o sentidos.

Si dos principios del Manifiesto Ágil indican que se valora:

– A los individuos y su interacción, por encima de los procesos y las herramientas.
– La colaboración con el cliente, por encima de la negociación contractual.

La confianza resulta un ingrediente esencial para poder satisfacerlos.

No es condición suficiente la confianza para el éxito del proyecto pero es importante, tampoco es condición necesaria pero resulta poco probable que en este contexto el proyecto tenga un fin acorde a las expectativas.

La confianza no se gana de un día para otro, se requiere tiempo y mucho más que palabras. La confianza se basa en los hechos.

Sin embargo, la confianza se puede perder en un momento. Cuesta mucho ganarla, casi nada perderla.

Brad Appleton, director de ingeniería del software de Motorola, realiza una reflexión con la que estoy de acuerdo: “Lo primero que hay que construir es la confianza”. O por lo menos empezar a construirla ya que, como decía, requerirá tiempo.

Un sistema con problemas tiene consigo a toda una multitud de personas (usuarios, directores usuarios, etc…) quejándose de manera sistemática y en muchos casos creando un ruido y una presión difíciles de soportar.

Trabajar de esta forma es complicado y todavía puede ser peor si las relaciones entre diferentes stakeholders se han deteriorado ya que alcanzar soluciones de consenso requerirán de mucho diálogo, debiéndose aceptar que no siempre se podrá conseguir ese consenso y que si la decisión o la solución que se ha ejecutado resulta poco acertada tocará soportar de nuevo una fuerte marejada aunque la decisión no la hayas tomado tú

En estas circunstancias siempre estarás en medio y ahí se vive y se trabaja mucho peor.

Si hay problemas incluso cuando has estado detrás del sistema desde el principio, los mismos se multiplican cuando el sistema que gestionas lo has heredado así.

¿Por qué? Pues porque tendrás que asumir un contexto que han creado otros y eso resulta complicado de digerir, es decir, nos sentimos motivados para arreglar problemas en los que hemos estado involucrados (independientemente de nuestro grado de responsabilidad en la deriva final del sistema) pero mucho menos cuando estos directamente se nos han puesto encima de la mesa.

El principal motivo es que tendremos que trabajar con restricciones técnicas en las que probablemente no creemos y generalmente nuestros recursos presupuestarios serán muy inferiores a los invertidos en el proceso de desarrollo.

Es cierto que no es plato de buen gusto trabajar en estas circunstancias pero os puedo asegurar que como contraprestación a lo mal que se pasa y a la cantidad de horas que hay que echarle, está lo que se aprende en este tipo de proyectos.

La experiencia no es lineal en relación al tiempo que llevas trabajado, este tipo de proyectos es un claro ejemplo de ello.

No se pueden entender desarrollos ágiles si no se disminuye la resistencia hasta unos umbrales mínimos aceptables.

¿Qué es la resistencia? Toda aquella actividad que dificulta el progreso del proyecto y esto se extiende desde el propio proceso de desarrollo (incluida la implantación del sistema en sus diversas iteraciones) hasta el conjunto de stakeholders que intervienen en el mismo, pudiendo incluso trascender a lo que es el propio proyecto: tanto en aspectos de políticas y normas como en aspectos de infraestructura (estabilidad de la aplicación, del CPD en el que se encuentra, etc…).

No entiendo como resistencia actividades propias del proceso de desarrollo independientemente de que no tengan influencia directa sobre el producto. Habrá quienes piensen que lo que no tenga influencia directa en el desarrollo se considere resistencia en todos los casos y lo respeto y hasta puedo llegar a estar de acuerdo, no obstante hay que entender que habrá tareas que son necesarias de realizar con el objeto, por ejemplo, de cumplir con los procesos establecidos en la organización, pero, ¿dónde está la frontera entre lo que es resistencia y no lo es? cuando se pierde la visión de los principios ágiles.

Es muy difícil encontrar un contexto de trabajo sin resistencia, por lo que será algo con lo que tendremos que convivir. Ahora bien, No se puede hacer un desarrollo ágil si se superan unos ciertos límites. Claro que podrás aplicar metodologías, tácticas o actitudes ágiles pero otra es que las puedas aplicar en condiciones y sean realmente efectivas.

Nos encontramos ante un antipatrón que también se suele producir con frecuencia y que provoca retrasos y otro tipo de problemas en los proyectos.

El interbloqueo ya sea directo o indirecto es consecuencia principalmente de una mala comunicación en el proyecto, también lo puede ser de una mala planificación (pero no necesariamente una planificación inadecuada tiene por qué provocar interbloqueos, pudiéndose producir también este tipo de situaciones sin que existan este tipo de problemas).

Eso de que yo no puedo continuar porque estoy esperando a que tú hagas algo, mientras que tú no puedes hacerlo porque estás esperando a que yo haga otra cosa, desgraciadamente está a la orden del día y lo peor de todo es que la solución en la mayoría de los casos, es sencilla: comunicación.

Cuántos problemas se ahorrarían muchísimos proyectos si la comunicación dentro del equipo de proyecto o entre stakeholders fuera fluida.

No es casualidad que el primer principio del manifiesto ágil indique que se valore “a los individuos y su interacción, por encima de los procesos y las herramientas.”

Lo que suele pasar es que cuando en un proyecto empieza a existir desgaste uno de los primeros elementos en resentirse es la comunicación, lo cual generará más problemas y más desgaste, haciendo la bola de nieve cada vez más grande.