¿Qué pinta un Project Manager en el desarrollo ágil?

0

Miles de project managers del mundo del software han visto como su perfil de repente desaparecía. Ya nadie quiere gestores de proyecto. ¿Qué hacemos con esa masa de profesionales? Pues como todo en esta vida, cuando tu área profesional palidece, te toca reciclarte.

El cambio cultural

Primero de todo, hay vida ágil más allá de Scrum. Por lo que no me limitaré a decir la típica frase de que el project manager debe convertirse en Scrum Master (como por ejemplo dicen en este artículo de Dananthi Arnott), o que debe asumir el rol de product owner. Ni siquiera que las responsabilidades se distribuyen, tal y como indica Juan Luis Vila en este artículo. Si vas a Scrum, este último artículo puede tener validez, pero hay otros casos.

La diferencia principal es la de transferencia de responsabilidad. Tal y como indica el décimo primer principio del manifiesto para el desarrollo ágil:

The best architectures, requirements, and designs emerge from self-organizing teams.

Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados.

Un cambio que para mí es básico es que la responsabilidad final recae en el equipo. En las estructuras clásicas es habitual tener un jefe, pero en este nuevo paradigma se prima esa ausencia de “jefe” con lo que la responsabilidad se difumina en el equipo.

El project manager tradicional siente que el proyecto o producto que gestiona es su responsabilidad, y el equipo de desarrollo a su cargo, no suele sentirlo. Por ello, siempre que aparece algo que hay que hacer, pero que no se sabe quién, le toca al jefe de proyecto. Ya os dije que el jefe de proyecto es un chico para todo.

Pasamos de una persona con responsabilidad sobre un equipo a un equipo que es responsable de si mismo. Acostumbrarse y aportar valor en ese nuevo entorno es clave.

Las tareas habituales de un Project Manager

Bueno, vemos que el entorno ha cambiado. Así que vamos a analizar qué es lo que (en teoría) sabe hacer un gestor de proyectos para ver en dónde lo podríamos colocar.

  • Comunicar: Es la parte principal del trabajo de un gestor de proyectos. Comunicar, resumir, informar, … Según algunas fuentes, la mayoría de jefes de proyecto usan más del 75% de su tiempo a la gestión de interesados. Los buenos jefes de proyecto son cracks en esto.
  • Dialogar: Junto con comunicar, el diálogo está en el día a día. Técnicas de negociación, o de debate son claves. Hay que conseguir tener influencia sobre los interesados, negociar los puntos, gestionar los cambios, gestionar los conflictos, etc.
  • Gestionar: Juntar la información de múltiples fuentes, elaborarla y gestionar el proyecto como un todo. No es sencillo. Algo que a primera vista podría parecer fácil, como por ejemplo indicar el grado de avance un proyecto y su fecha estimada de finalización es realmente muy complejo. Es fácil dejarse llevar por la miopía en las estimaciones, o por las tareas casi acabadas. Es fácil confundir estimaciones con compromisos, o comenzar a abusar de colchones. Un buen jefe de proyecto sabe lidiar con eso.
  • Liderar: Sí, aunque os suene raro. Un buen gestor de proyectos debería liderar al equipo y motivarlo. Aquí los soft skills vienen a la orden del día. Intentar llegar a tiempo a un proyecto para el que el equipo está en contra, es una tarea casi imposible. Así el jefe de proyecto debería ser capaz de liderar al equipo en estos casos, aunque no sea el jefe de ese equipo.

Otras tareas habituales de un Project Manager

Un gestor de proyectos debe gestionar proyectos. Pero la sensación de propiedad que solía tener esta persona, y esa sensación de ser el jefe del equipo, le llevaba a ocupar otras posiciones extra:

  • Estimador: Ninguna guía, y menos PMBOK, te dice que el Project Manager deba hacer las estimaciones. Debe juntarlas, usando técnicas como PERT por ejemplo. Pero de hecho PMBOK recomienda lo que llama el juicio de expertos, o lo que es lo mismo, que se le encargue a los que saben. Es decir, que se encarguen los desarrolladores más senior. Aún así, es habitual ver jefes de proyecto que saben estimar y hacen las estimaciones.
  • Analista: Sobretodo de negocio. Era (y todavía es) muy habitual ver a esa persona haciendo el análisis funcional. Lo mismo que antes, el PMBOK no te dice que hagas ese análisis, ni siquiera que definas el alcance. Te dice que gestiones esa definición. Pero como es una parte clave del proyecto, la mayoría de los gestores han solido escoger hacerlo ellos mismos.
  • Arquitecto: No sólo es fácil verlos  haciendo el análisis funcional, sino también muchas veces el técnico. Muchos Project Managers vienen de ser desarrolladores, por esa manía de ascender cambiando de puesto de trabajo, y cargándonos a buenos programadores. Como ahora es el jefe, puede decidir, y los programadores a acatar.

¿Qué hacemos con él?

Lo primero es ver, de todo lo anterior, en qué es fuerte. Y plantear esto es el nuevo esquema del equipo. Lo que está claro es que no hará de todo.

Pero lo que sí tengo claro es que no hay una respuesta directa. Por ejemplo, si los equipos se rigen por SCRUM podría adoptar los roles de Scrum Master o de Product Owner, dependiendo de en qué vaya más fuerte. Si su fuerte está como analista, como gestor, como comunicador y como dialogador, entonces será más afín a Product Owner. Si su fuerte está en el liderazgo y esos soft-skills, entonces Scrum Master será mejor opción.

En otros esquemas puede dedicarse a llevar el portfolio de productos o proyectos, siendo como el líder del capítulo de los product owners, ya que es un trabajo para el que gran parte de su preparación le serviría. Y si la empresa tiene líderes de equipo que asumen la responsabilidad (que las hay, aunque no sea algo que me guste) también puede ser una buena opción.

En cualquier caso, lo más difícil será hacer ese cambio de chip y dejar de ser un jefe para ser uno más. Muchos lo verán como un paso atrás. Pero yo creo que es un paso adelante. En mi experiencia es muchísimo más difícil ser un buen Scrum Master que un buen jefe de proyecto.

Conclusiones

Si eres un jefe de proyecto en el mundo TI, te recomiendo que te analices. Mires en qué eres bueno, y te planees un nuevo rol. Lo aprendido te servirá y mucho en tu nuevo trabajo. Te hará tener un conocimiento mucho más rico que los que han entrado directamente en esos roles. Así que no lo veas como que te has equivocado de camino, sino como que se te abren ahora múltiples caminos ante ti y hay que escoger uno.

Sobre el autor

Jose M. Huerta

Jose es Gestor de Proyectos y Gestor de Servicios en Mallorca. Es Ingeniero de Telecomunicaciones y obtuvo el Master of Advanced Studies durante su etapa como investigador. Pero no tardó en abandonar ese mundo y meterse de cabeza en el mundo de las Tecnologías de la Información. Está certificado como ITIL Expert. Tiene amplia experiencia en gestión de servicios, clásica e integrada con desarrollo, gestión de proyectos, usando metodologías clásicas y ágiles, gestión de programas y portfolios, gestión de grandes grupos de personas, localizadas y off-shore, sin dejar de perder de vista el lado técnico y freak del sector. Ha trabajado en varias empresas del sector con distintos roles en áreas tanto de gestión de servicios de soporte como de equipos de desarrollo. Actualmente trabaja en WebBeds, como responsable del equipo de operaciones TI.

Sin comentarios