archivo

Archivo de la etiqueta: gestor de proyectos

Una objetivo fundamental de un jefe o gestor de proyectos, Scrum Master o cualquiera que sea el nombre que queramos darle, es la de tratar de conseguir un contexto lo más estable posible que permita que todas las partes involucradas en el proyecto desempeñen su función de la manera más eficiente posible.

Además del trabajo sobre el contexto que va más sobre líneas generales del proyecto: relación de confianza, gestión adecuada de expectativas, del valor ganado y de la inversión realizada hasta el momento, etc…, en el día a día del proyecto existen contingencias que pueden afectar al rendimiento del equipo de proyecto y que conviene solucionar cuanto antes para que el impacto sobre la productividad y los resultados sea el menor posible.

Está claro que un facilitador eficiente hace mucho bien al proyecto, parece un trabajo fácil pero no lo es en absoluto porque tiene mucho de inteligencia emocional, ya que para resolver esos problemas del día a día o para tratar de mantener un equilibrio en el proyecto se requiere mucha interacción y comunicación con otras personas que probablemente tengan unas prioridades y objetivos diferentes a los del equipo de proyecto.

Cuando el facilitador lo hace bien, las personas que trabajan con él tienden a despreocuparse de la resolución de determinadas contingencias que perfectamente podrían resolver ellos y/o el propio facilitador con el objetivo de que el equipo esté centrado en su trabajo decide asumir que toda la intendencia del proyecto pase por él.

Esto puede llegar a convertirse en un antipatrón por varios motivos: el facilitador se puede terminar convirtiendo en un cuello de botella, si el facilitador por el motivo que sea no puede dedicar tanto tiempo al proyecto se necesitará que los desarrolladores den un paso al frente para resolver estos problemas y/o para tratar de que el equipo siga gestionándose de manera adecuada pudiendo darse el caso de que no se encuentren preparados para realizar esas tareas o no las consideren de la suficiente importancia, degradándose paulatinamente el rendimiento y productividad del equipo impactando directamente en los resultados.

Una de las labores más complicadas de un gestor de proyectos en aquellos casos en los que existen múltiples equipos de trabajo que pueden pertenecer incluso a proveedores diferentes (tampoco resulta sencillo hasta en aquellos casos en los que existe un solo equipo formado por pocos desarrolladores) es que todos comprendan cuáles son los objetivos y las restricciones que existen para alcanzarlos.

Resulta especialmente complicado sobre todo en aquellos equipos que están desarrollando funcionalidades o herramientas complementarias al núcleo el sistema, en primer lugar porque la atención del gestor estará más orientada a la línea principal de desarrollo del producto así como a eliminar o paliar las posibles resistencias que puedan existir en cualquiera de las distintas líneas y en segundo lugar porque, por el mismo motivo, se encontrarán a distancia del product owner y de los directores usuarios y contemplarán desde más lejos sus expectativas y su presión.

Hay proyectos donde el trabajo de estos equipos secundarios es igualmente secundario pero en otros casos el resultado de su trabajo puede ser esencial para el funcionamiento y/o para la puesta en marcha del sistema. Tanto en un caso como en otro (aunque por supuesto mucho más en el segundo) es necesario que esos equipos mantengan el enfoque y la tensión en el proyecto, de la misma forma que lo hacen aquellos equipos que están peleando con las partes más críticas del sistema.

Como decía, esto no es fácil, ya que resultaría fundamental que el product owner y los directores usuarios les expresasen directamente y de forma constante (continua) sus expectativas y eso es algo que resulta complicado en proyectos con una cierta envergadura. Ahora bien, si no es posible llegar a eso cualquier aproximación ya supone un avance. Si el equipo no termina de asimilar la situación, el gestor de proyectos debe actuar y en estos casos es mejor un falso positivo (pensar que el equipo no es consciente de la situación e insistir) que creer que se ha asimilado y no actuar.

Cuantas más personas se suban al barco más posibilidades hay de sacar el proyecto adelante, sin olvidar que hay que procurar que quien suba no vuelva a bajar (de ahí la importancia de las actividades necesarias para que los equipos y los desarrolladores mantengan el enfoque en el proyecto).

Decía Milt Bryce que: “Si viviéramos en un mundo perfecto, no sería necesario la existencia de gestores; los proyectos se ejecutarían en tiempo y coste. Sin embargo, la realidad es que vivimos en un mundo imperfecto”.

Para mi el objetivo principal de un gestor es que el equipo tenga claro que el objetivo es que como consecuencia del proyecto el cliente y/o el usuario estén satisfechos con él de manera que se hayan satisfecho sus expectativas, respetando que nos encontramos dentro del ámbito de una organización cuyo objetivo es obtener beneficios a través de los servicios que ofrece.

Ahora bien, este objetivo resulta utópico de conseguir cuando las condiciones de partida de un proyecto no se adaptan a las exigencias del mismo (proyecto infravalorado en esfuerzo y/o en tiempo y/o no compatible con las expectativas de calidad). Si se parte de un Death March Project o de una situación próxima a él, el gestor tendrá muy complicado mantener un discurso coherente porque cuando la manta es demasiado pequeña solo da para taparse la cabeza o los pies.

De la misma forma, si aún comenzando el proyecto con unas condiciones favorables, a lo largo de su desarrollo se producen contingencias que afectan sensiblemente a su ritmo, de manera que se requiere invertir un mayor esfuerzo en tareas que no lo requerían (cambios en procesos, sucesivas vueltas a atrás de funcionalidades por problemas en la especificación por parte del área usuaria, etc…), nos podemos encontrar en una situación parecida a la de si las condiciones de partida hubieran sido desfavorables.

¿Cómo mantener entonces ese discurso en el equipo? Soy de la opinión de que ese discurso debe mantenerse inmutable pero sin obviar la realidad en la que nos encontramos. El objetivo del equipo debe ser el mismo pero modulado a través de los discursos disponibles.

Es decir, el equipo tiene que ser productivo (acorde a sus posibilidades) e intentar minimizar errores evitables, por otro lado hay que intentar consensuar con el usuario una solución que sea lo más simple posible sin que éste vea perjudicada sus expectativas, además de tener muy cerrados los compromisos del usuario con respecto al proyecto, así como las medidas a tomar en el caso de que los errores o cambios sean debidos como consecuencia de los usuarios (estas dos últimas características deben estar bien resueltas en la fase de negociación, de lo contrario lo que puede ser una venta mala o muy mala se puede convertir en una venta nefasta).

Lo anterior no funciona siempre, es más, no funcionará en muchos casos, porque el cliente se aferrará con fuerza al contrato. Cuando no sea posible llegar a un acuerdo, cuando el cliente no entienda que puede ser más beneficioso tener un producto con las funcionalidades esenciales bien implementadas que un producto final donde casi nada funcione como debería, poco podemos hacer más allá de intentar llegar lo más lejos posible con los recursos disponibles (en el fondo hemos intentado alcanzar las expectativas del usuario aunque nos hayamos quedado a medio camino, respetando también en segundo término las expectativas de nuestra organización respecto al proyecto).

Cuanto más confíe el cliente en nuestro trabajo más entenderá lo que le estamos pidiendo y más dispuesto estará a hacer concesiones. La confianza es también resultado de la coherencia, es decir, no podemos pedirle al usuario que corra con sus errores si nosotros no corremos con los nuestros (y en este caso quien suele mirar por el ancho del embudo suele ser el proveedor).

Por tanto, el objetivo principal del gestor es mantener en el equipo el compromiso de entregar un trabajo de calidad y realizar las actuaciones oportunas para que el contexto del proyecto sea el más favorable posible para conseguir ese objetivo.

El gestor por tanto, es un facilitador, un dinamizador, es alguien que debe estar a disposición del equipo para que éste puede desempeñar su trabajo de la mejor forma posible, para ello debe ser alguien próximo al equipo, alguien dispuesto a sacrificarse y a ayudar, alguien quien dentro de sus posibilidades pueda echar una mano extra al equipo si hiciera falta.

El gestor también debe tomar decisiones y algunas de ellas tendrán un importante desgaste personal. A nadie le resulta cómodo reprender actitudes y a nadie le resulta agradable tener que prescindir de personal, pero si se quiere mantener un equilibrio y solidaridad entre los miembros del equipo de proyecto, será necesario realizar ese tipo de actuaciones.

Entiendo que quien no esté acostumbrado a una gestión de proyectos de este tipo, se cuestione en muchas ocasiones el valor que aporta un jefe de proyectos. También incluso en aquellos casos donde el gestor esté más alejado del proyecto sería conveniente analizar si lo está realmente por una cuestión de actitud del mismo, por una política de su organización o por imposibilidad material al estar participando en demasiados proyectos a la vez.

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.

Todo gestor quiere contar con el mejor equipo posible para realizar sus proyectos. Cada gestor tiene una idea de equipo ideal, ya que la escala de valores de cada persona suele ser distinta, no obstante, hay “jugadores” que tienen cabida en más de un equipo (cuando no en todos) y ahí es donde se pueden producir conflictos.

Lo más habitual en las organizaciones es que cada gestor tenga un equipo de personas a su cargo más o menos fijo (su personal de confianza) y otro grupo de técnicos que colaboran en proyectos que se estén ejecutando pero que su adscripción al gestor es coyuntural, salvo que de alguna u otra forma destaque en una o más variables valoradas por el gestor y éste decida la inclusión en su equipo (si hay hueco).

Los gestores suelen pelear por mantener a su equipo fijo como sea, para lo cual se requiere la existencia de carga de trabajo. En ocasiones aceptarán compartirlo con otros gestores de manera parcial o total (se marcha a otro proyecto durante un tiempo con compromiso de volver cuando termine o cuando sea posible), con tal de no perderlos definitivamente, pero si no entra trabajo suficiente pasarán a formar parte del equipo de confianza de otro gestor y se perderá la posibilidad de recuperarlo.

Hasta ahí, todo normal en lo que es una empresa de desarrollo de software. El problema viene y de ahí este antipatrón, cuando un gestor impone su fuerza (ya sea por su mayor grado de influencia con la dirección o por tener a su cargo proyectos importantes) para quitarle a otros gestores a técnicos de su equipo, cuando estos los tienen asignados a proyectos. Es decir, se quita capacidad a otros gestores para que tu equipo gane capacidad.

Los desarrolladores no son todos iguales, en productividad, conocimientos, experiencia, adaptación a un entorno, contexto o cliente, etc…, por lo que si a un proyecto le quitan alguno de sus baluartes, indudablemente le afectará (a lo que hay que sumar el tiempo necesario para que un posible sustituto pueda adquirir un nivel productivo aceptable), afectando también a la productividad del equipo de proyecto en su conjunto sobre todo si el mismo estaba bien consolidado.

A eso hay que sumar el deterioro de la relación entre los gestores y el hecho de que concentrar mucho talento en un equipo no necesariamente garantiza nada.

Siempre he defendido que una organización debe intentar asignar a cada proyecto al mejor conjunto posible de personas para poder realizarlo dentro del conjunto de técnicos que puedan estar disponibles (estén o no asignados a proyectos, es decir, se puede estar asignado a un proyecto y por la naturaleza del mismo o su estado, puedan ser sustituido sin mucha pérdida por otras personas).

Ahora bien, también defiendo que si hay equipos que funcionan bien, no hay por qué romperlos, de manera que el mejor conjunto posible de personas que indicaba en el párrafo anterior no lo será si para ello se fractura a un equipo que produce buenos resultados, están contentos y trabajan eficientemente.

Este antipatrón lo tenemos cuando gestores de proyecto o gerentes se centran exclusivamente en que los procesos que orquestan el desarrollo se realizan de manera adecuada sin dedicar tiempo a comprender la naturaleza de los trabajos que se están realizando, de esta forma no pueden evaluar el grado efectivo de avance de un proyecto o tener una comunicación adecuada con el cliente, pudiendo dar lugar a falsas expectativas o a transmitir mensajes que no son acordes con la realidad del proyecto.

Es compatible verificar el cumplimiento de los procesos con tener una cierta información de los objetivos del proyecto, de las contingencias que se están produciendo, de sus posibles riesgos, etc…, es cierto que se necesita bajar a más nivel de detalle, pero de no hacerse así (y es algo que no quita tanto tiempo como parece) no se puede evaluar de manera adecuada cómo van los trabajos y tratar de los mismos con conocimiento de causa con el cliente.

La situación se ve agravada cuando incluso en estas circunstancias, el gestor decide tirar para adelante él solo en conversaciones con directores del área usuaria o del cliente, sin buscar la colaboración de componentes de su equipo que conocen mejor el estado del proyecto, ni que decir tiene que por mucha experiencia que se tenga, lo más normal es que de alguna u otra forma se meta la pata (se acepten responsabilidades o culpas de su equipo de manera injusta, apoye decisiones que no sean las más convenientes para el proyecto, gestione incorrectamente las expectativas, etc…).

Cuando se trabaja en muchos proyectos, este antipatrón puede venir dado de manera casi forzada, pero por poco tiempo que se disponga, en la medida de lo posible es necesario estar informado de qué es lo que se cuece y contar con el apoyo de componentes del equipo cuando sea necesario.

Los gestores del proyecto, los directores usuarios, etc… tienen en muchas ocasiones ideas equivocadas de cómo va el proyecto, ya sea porque no se han preocupado por el estado real del mismo, porque han analizado mal la situación o porque le han vendido la moto (ver antipatrón “Humo y espejos“).

En cualquiera de los tres casos se tiene un miedo exacerbado a contarles la realidad del proyecto (en el caso de no haberles contado exactamente la realidad puede ser comprensible, pero ten en cuenta que si no lo haces al final será peor) y eso alimenta una falsa expectativa del mismo o lo que es lo mismo se pone al proyecto un listón tan alto que difícilmente podremos superar.

Una mala gestión de expectativas al final se termina volviendo en contra de quien no ha sabido transmitir de manera adecuada la situación del proyecto o de quien no ha corregido a tiempo una impresión equivocada del mismo porque te terminarán exigiendo lo que no vas a poder dar con el agravante de que ya lo daban por hecho y pensaban, por tanto, que lo tenían en la mano (si hay algo peor a no tener algo es creer que lo vas a tener y al final no conseguirlo) y lo que es peor, es posible que ellos mismos a otros departamentos de la organización o a sus superiores trasladasen unas expectativas que no se van a ver cumplidas (en este caso, no lo dudes, el tortazo será inversamente proporcional a tu posición en la jerarquía de la organización).

Recomiendo también leer el artículo: “Desarrollo de software. Barry Boehm. Ciclo de vida en cascada y la incertidumbre del producto final“.