Archivo

Archivo de la etiqueta: jefe de proyectos

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.

Sin un plan, unos objetivos, el funcionamiento de una organización, un departamento o un proyecto va a la deriva y se guía exclusivamente por las contingencias del corto plazo y estás a merced, como un títere, de los que tienen más claro que tú lo que quieren.

Para ir a algún sitio tenemos que saber a dónde dirigirnos y determinar las acciones que tenemos que realizar para llegar allí. Para un jefe de proyectos es esencial tener claro esos objetivos y ese plan de acción. El problema de todo esto es que hasta que no te pegas unas cuantas tortas, no terminas de darte cuenta que en los proyectos necesitas tomar una dirección, que puede ser equivocada, pero una dirección.

Esa es la base, tener un plan, pero después toca sortear los obstáculos, tanto los que vienen de atrás (de la fase de venta y/o negociación del desarrollo con el cliente) como los que se producen durante el desarrollo. Si en el proyecto andamos en círculo o sin rumbo, nos tendremos que enfrentar al mismo obstáculo más de una vez y dada la complejidad que rodea al desarrollo de software y los presupuestos con los que se suele contar para llevar a cabo esta tarea, no está la cosa para invertir esfuerzos que no producen ningún tipo de avance en el proyecto.

Hay veces que es necesario escalar decisiones, conflictos, etc…, pero soy partidario que las contingencias ordinarias que ocurren en el proyecto se traten entre el equipo del proyecto, su coordinador o jefe de proyectos y el responsable técnico del cliente.

No es operativo y no favorece en absoluto la confianza entre las partes, cuando ante el más mínimo problema o ante el menor conflicto se escala el problema, trátalo primero con la otra parte, trata de llegar a un acuerdo, a un consenso, acepta tu rol en el proyecto, intenta tener una cierta empatía, si todo falla y la contingencia es lo suficientemente importante será necesario que terceras partes discutan el asunto, pero hasta llegar a eso, hay un trecho que se debe recorrer.

Estoy hablando de asuntos que competen a la gestión ordinaria y del ámbito de la competencia entre las partes, aspectos que se salen de eso sí que entiendo que lo traten quienes los deben tratar.

Seguir

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

Únete a otros 1.754 seguidores