Archivo

Archivo de la etiqueta: jefe 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.

¿Cómo medir si un gestor está haciendo bien o mal su trabajo?, ¿tal vez el nivel de rentabilidad de sus proyectos?, ¿su nivel de ventas?, ¿el grado de aceptación por parte de las personas que trabajan con él?.

Se nos pueden ocurrir muchos indicadores. A mi hay uno que me parece muy interesante y es que un buen gestor debe solucionar muchos más problemas que los que crea. Evidentemente habría que complementarlo con otros indicadores para formar una opinión con más perspectiva, pero no por ello deja de ser algo sobre lo que se debe reflexionar.

Entrar como un elefante en una cacharrería, actuar a destiempo y/o de forma desmedida (o no actuar), tomar decisiones sin tener una visión clara del problema, tomar decisiones sin tener en cuenta el contexto, no contar con la opinión de tu equipo, mirar solo por tus intereses profesionales en lugar de tener una visión más general, no dar importancia al cliente, etc… son situaciones, decisiones o conductas que pueden dar lugar a la creación de problemas donde no existen o agudizar los ya existentes.

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.

Existe algo todavía peor que el jefe de proyectos o gerente por parte del proveedor tenga como objetivo encajar el máximo número de horas posibles reales e imaginarias en los diversos proyectos que gestiona, dejando en un segundo plano u olvidando (en la mayoría de los casos) el cliente, los usuarios y el producto y es que el jefe de proyectos del cliente también oriente su gestión a la contabilidad, de manera que solo importe ejecutar trabajo, dejando en un segundo plano y olvidando (en la mayoría de los casos) que lo importante no es ejecutar trabajo sino que éste sea efectivo.

Estamos ante otro antipatrón muy típico por parte de las empresas que realizan servicios TIC a terceros y podemos ver un par de ejemplos muy frecuentes en lo que nos lo encontramos:

- Se envían a realizar servicios al cliente, aunque sean pocas jornadas, a personas que no tienen ningún tipo de experiencia en el trato con el cliente y/o a personas que pueden ser excelentes profesionales pero que son de trato complicado.

Muchas empresas se olvidan de que las personas con las que trata el cliente son la imagen de la compañía por mucha marca que haya detrás. Por este motivo es necesaria, como poco, una formación mínima para todas aquellas personas que traten con clientes, además de seleccionar muy bien a quien encomendar este tipo de trabajos.

- En servicios de outsourcing en el cliente, donde la empresa o el gerente de turno los abandona a su suerte, descargando toda la responsabilidad en el equipo (y en su jefe de proyectos) y solo apareciendo en determinadas reuniones puntuales con clientes o para trasladar quejas del mismo (por regla general, sin escuchar a su propio equipo y sin analizar con una cierta objetividad la situación, provocando situaciones donde se produce, por ejemplo, el antipatrón “cantamañanas“).

Esta sensación de abandono quema mucho al equipo, es cierto que se puede hacer más fuerte y homogéneo ya que no les queda otra si quieren sacar el trabajo adelante, pero estar solos, sin que nadie escuche sus problemas, es complicado y todavía más cuando su esfuerzo generalmente no se ve recompensado ya que están prácticamente al margen de la empresa.

Este antipatrón describe un comportamiento que, desgraciadamente, es muy habitual en nuestro sector.

Está asociado al comportamiento de jefes de proyecto, de equipo, gerentes, etc… que son completamente permeables hacia el cliente o hacia sus superiores y después cargan contra su equipo en el caso de que reciban alguna queja, malestar o exigencia.

Todo esto sin tener un conocimiento adecuado del contexto y sin escuchar lo que tenga que decir su gente o no prestando atención a lo que le puedan contar.

Tiene algunos aspectos en común con el antipatrón “abracadabra” con la diferencia principal de que en este se llega mucho más lejos.

Tal vez actuando de esta forma puedas apagar un fuego pero al final te terminarás quemando. No puedes gestionar en contra de tu equipo. Tu equipo tiene que estar respaldado, creer y confiar en ti.

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.

Los equipos de proyecto y, en general, los equipos de trabajo, hasta cierto punto deben funcionar de forma autónoma, utilizando como patrón de funcionamiento los procesos implantados en la organización, la metodología de desarrollo y cualquier acuerdo específico alcanzado para la realización del proyecto.

Ahora bien, existen determinadas decisiones que deben recaer sobre aquellas personas en las que se le ha delegado una determinada competencia y que no se deben diluir por inacción en el equipo de proyecto porque al final esto se volverá en contra de dicho equipo.

También existen determinadas circunstancias donde el responsable máximo del proyecto o el responsable de un equipo de trabajo tiene que intervenir, ya sea para poner un poco de orden, cuando éste se pierde, para reconducir situaciones no beneficiosas para el proyecto, etc…

El antipatrón lo tenemos cuando dichos responsables no aparecen en el proyecto o no aparecen en momentos clave, es decir, cuando se les necesita casi nunca están. Esta circunstancia hace mucho daño al proyecto, ya que su principal misión es mantener el frágil y complicado equilibrio entre todos los stakeholders y entre las personas que conforman un determinado equipo de trabajo.

Cuanto más grande sea la grieta creada por su ausencia, más complicado será reconducir el proyecto a una situación de equilibrio y si se consigue será a costa de un desgaste y/o un esfuerzo innecesario, si el responsable hubiera hecho lo que tenía que hacer.

El hecho de que esté escribiendo una serie de artículos sobre CMMI y que valore positivamente lo que puede aportar a una empresa de desarrollo de software (si su definición es adecuada), no supone un cambio en mi apoyo y creencia en la máxima agilista que dice que: “Los individuos y su interacción se encuentran por encima de los procesos y las herramientas”.

Son las personas las que finalmente hacemos buenos o malos los procesos, ya que participamos en su definición, en su mejora continua y en su ejecución.

Richard (Dick) E. Fairley realiza una reflexión sobre la hegemonía real que existe de las personas sobre los procesos (traducción libre): “Programadores motivados y con conocimientos pueden sobreponerse a procesos inadecuados, sin embargo procesos perfectos nunca pueden compensar malos programadores o malos gestores de proyectos”.

Lo peor que tiene esta pregunta es que gran parte de los gerentes de cuenta o jefes de proyecto (por no decir la mayoría) considerarán que un proyecto ejecutado con éxito es aquel que como mínimo ha igualado el umbral de beneficio esperado o lo que es lo mismo, el grado de satisfacción del cliente y/o del usuario es secundario.

Tampoco es un proyecto de éxito uno que deje satisfecho al cliente y/o usuario sin pensar en la cuenta de resultados, pero si me apuráis es preferible esta opción a la contraria, ya que tal vez este proyecto no haya ido bien económicamente pero puede ser el punto de inicio de una colaboración a más largo plazo con el cliente en la cual no solo pueda recuperar lo perdido sino obtener beneficios.

La satisfacción del cliente y/o usuario no hay que considerarla con una visión cortoplacista, hay veces donde están satisfechos del resultado en primera instancia, pero después conforme van avanzando en el uso y conocimiento del sistema o cuando tienen que realizar mantenimientos del sistema de información, esa satisfacción puede convertirse en todo lo contrario.

Entonces, ¿qué es un proyecto ejecutado con éxito? Son muchas cosas y probablemente haya tantas definiciones como personas estén leyendo este artículo y también es más que posible que la mayoría de ellas incluso no sean excluyentes, ya que el éxito no siempre es fácil de medir.

Para mi un proyecto ejecutado con éxito es aquel que cumple las expectativas del cliente y/o usuario tras la entrega y pasado un tiempo de uso del software (se entienden expectativas funcionales y no funcionales), que tiene una deuda técnica ajustada a los umbrales presupuestarios del proyecto, donde el plazo de entrega se ha cumplido dentro de unos límites admisibles y en donde el proveedor ha visto también satisfechas sus expectativas económicas, sea en el proyecto o con una visión más a largo plazo con el cliente.

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 3.200 seguidores