archivo

Archivo de la etiqueta: stakeholder

Nos encontraríamos ante una situación concreta del antipatrón “responsable ausente“. En este caso, el gestor a modo de sortilegio establece una líneas generales para el desarrollo del proyecto y desaparece, apareciendo solo cuando existen problemas en el proyecto y generalmente como reacción ante las quejas de uno o más stakeholders (antipatrón “gestión dirigida por disparos“).

Nadie es imprescindible, pero si cada uno desempeña su rol en el proyecto de manera adecuada existirán más posibilidades de que todo salga bien.

Nos encontramos con este antipatrón cuando ante un sistema de información de complejidad y tamaño medio/alto, con una deuda técnica alta, se solicita la realización de tareas de mantenimiento, generalmente evolutivo, de cierta envergadura, las cuáles deberían ejecutarse en un plazo de tiempo muy ajustado y se centran los esfuerzos en intentar conseguir ese objetivo, independientemente de que el producto vea incrementada su deuda técnica y complejidad.

El primer problema que nos encontramos es la existencia de una restricción temporal que condiciona los trabajos, lo que hace que se enfoquen los esfuerzos en “apagar el incendio”, dejando de lado la aplicación de determinadas buenas prácticas y controles de calidad del software si estos pudieran frenar el avance de la ejecución de las tareas.

Esto hace que el plan de proyecto se centre en dar una respuesta a la situación, dejando para el final la realización de tareas que mitiguen la deuda técnica y la simplificación de funcionalidades eliminando funcionalidades o código que no ya no tienen utilidad (ver antipatrones lava seca y ancla de barco). ¿Qué es lo que suele pasar? Pues que al final no haya tiempo para realizar esos ajustes, ya sea porque nos hemos quedado sin presupuesto y/o aparecen nuevos fuegos que ir mitigando.

Esa restricción temporal puede estar justificada ante la necesidad de adaptar un sistema de información a una normativa o para adaptar el sistema a un cambio en procesos o a un nuevo proceso que resultan esenciales para el funcionamiento de la organización y que de no estar en los plazos fijados podría suponer un importante perjuicio económico que podría incluso afectar seriamente no solo a los balances, sino incluso a la propia viabilidad de la compañía.

Otras veces la restricción temporal, pese a que pueda estar sustentada por ciertos criterios objetivos, no deja de ser un capricho de cierto personal directivo a los que un día en un “alarde de creatividad” deciden que es necesario realizar ajustes en un sistema o incluirle nuevos módulos.

El siguiente problema es la realización de cambios de cierta magnitud en un sistema con una deuda técnica elevada, que implican que cualquier tarea de desarrollo sobre el mismo (sobre todo aquellas que supongan modificaciones en módulos ya implementados) cueste muchísimo más esfuerzo (como correr con un vendaval de viento en contra, con carga en una mochila y con pegamento en la suela de las zapatillas), además de incrementarse la probabilidad de errores, tanto por posibles efectos colaterales como por la presión de ejecutar trabajo rápidamente, dejando de lado la realización de determinadas prácticas de aseguramiento de la calidad del software.

Al final, en el caso de que cumplamos el hito temporal (algo que en aquellos casos donde los plazos sean muy ajustados solo será posible priorizando tareas, teniendo a todos los stakeholders muy implicados y acertando mucho), tendremos un producto más complejo, más costoso de mantener (si cabe) y bastante más inestable.

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).

Se llega a este antipatrón cuando en un equipo de proyecto (se puede generalizar a un grupo de personas que han participado o han tenido influencia en una serie de resultados, como puede ser los stakeholders, un grupo de jefes de proyecto o gerentes, etc…) se llega a la conclusión de que la mejor forma de analizar las causas de la no consecución de los objetivos es que se discuta quiénes internamente han tenido la culpa.

Se piensa que de esta forma, diciendo cada cual lo que siente, los problemas salen a relucir.

Es muy posible que entre grito, reproche y ataque salgan a la luz problemas (de hecho, que se grite, reproche o ataque ya resulta suficientemente significativo del ambiente y relación de confianza que se ha vivido en el proyecto) pero entre los participantes (al menos, en la mayoría), lo dicho no quedará en la mesa de reuniones (creando un poso que dependiendo del carácter de cada individuo, tardará más o menos en eliminarse), porque en este tipo de circunstancias se llegan, además, a decir cosas absolutamente fuera de lugar y bastante ofensivas.

La fuerza de rozamiento o fricción son todas aquellas contingencias que se producen en el proyecto de desarrollo de software que se suma a un valor inicial resultado de la negociación previa a la contratación del mismo (o al decisión de su realización mediante recursos internos).

Ese valor inicial puede ser tan alto que el condicione de manera absoluta el resultado del proyecto pudiéndose llegar al punto de que en la práctica sea casi imposible llegar a buen fin sin que alguna de las variables (calidad del producto, desgaste entre stakeholders, sobrecoste, etc….) se vean afectadas (Death March Project).

Pensar que el valor inicial se va a mantener durante todo el proyecto es suponer que en el desarrollo de software no se van a producir ninguno de los factores que definen su incertidumbre inherente (cambio de prioridades, cambios en los procesos, cambio en los stakeholder, variación de la implicación de los mismos, contingencias en el equipo de proyecto, etc…) y eso es peligroso porque no te hace pensar en los posibles riesgos y gestionarlos.

Conseguir un producto que satisfaga las expectativas del usuario será el resultado de vencer esa resistencia, esa fuerza de rozamiento, esa fricción.

No es sencillo porque el desarrollo de software no lo es, pero será cuestión de asumir que esas dificultades existen y que conformen vayan llegando será necesario superarlas, venciendo la resistencia con más empuje teniendo en cuenta que el mismo no solo es resultado de un mayor esfuerzo, sino también de una buena práctica en el proyecto resultado de la cualificación del equipo que participa en él.

También por el suelo… o en la papelera.

A este antipatrón se llega por la no asunción de sus responsabilidades por parte del área usuaria a la hora de definir las especificaciones del sistema, priorizar trabajos, responder dudas y realizar feedback.

Si se deja que el equipo de proyecto cubra los huecos en los requisitos el sistema solo cumplirá las expectativas del usuario por casualidad (es cierto que si se tiene en el equipo especialistas en el negocio se reduce el margen de error, pero no hay que olvidar que somos desarrolladores y nuestra visión es siempre de desarrollador, no de usuario).

Si el área usuaria no colabora tendremos una serie de requisitos (unos más completos que otros) y probablemente no exista una priorización de los mismos o la misma sea muy generalista, el efecto es como si tuviéramos una serie de requisitos en post-it esparcidos por una pared, sin orden ni concierto.

Cuando el área usuaria deja de colaborar o no lo hace de manera adecuada, hay que levantar la mano y escalar el problema a nivel directivo de los stakeholders ya que no se puede hacer un proyecto de espalda a los usuarios pese a que estos se la den al mismo.

Si no se pone remedio al final liberaremos un producto que rechazarán total o parcialmente los usuarios, que ahora sí, reclamarán aquel requisito que no se realizó, los que no se interpretaron de manera adecuada (algo que es tan malo como el propio hecho de que no harán feedback ni prestarán más atención que la simple advertencia de su no implementación, de aquellas funcionalidades no incorporadas en la versión liberada de la aplicación) y por qué se ha priorizado tal funcionalidad y no tal otra.

Por supuesto, no lo dudéis, todas las miradas se dirigirán a la parte más débil, el equipo de desarrollo.

La falta de confianza siempre resulta un problema porque no te permite trabajar de una manera ágil, ya que tendrás miedo en tomar decisiones y en ejecutar determinadas tareas.

Esa falta de confianza dentro de un equipo de proyecto da lugar a este antipatrón en el cual, antes de dar cualquier paso buscaremos la aceptación del cliente y/o del área usuaria, incluso para tareas que son obvias y/o de trámite y que no requeriría la participación de personal externo al equipo de proyecto.

También es cierto que esa falta de confianza también puede ser provocada desde fuera, ya sea desde el cliente y/o por los gestores de su propia organización por un exceso de control en los trabajos realizados y por medidas desproporcionadas en caso de decisiones o acciones erróneas.

A veces, también se alcanza este antipatrón de manera absolutamente voluntaria, es decir, busco la aprobación de todo lo que hago por lo que traslado la responsabilidad a un tercero.

Además de la falta de agilidad y continuidad en el trabajo que provoca este antipatrón, provoca esfuerzos innecesarios en stakeholders que tendrá como consecuencia, además del tiempo que pierden, interrupciones al no poder contestar siempre en un plazo razonable y pérdida de confianza en la capacidad del equipo de proyecto.

Está claro que hay dos extremos, el antipatrón “los clientes son idiotas” y éste y que por tanto, la solución se encontrará generalmente en un punto medio que no será otro que el más adecuado a la naturaleza del proyecto en el que estemos trabajando y al del grupo de personas que participan en el mismo.