Gestor del Proyecto (Project Manager) ​

Es el responsable del seguimiento de la gestión del proyecto y documentación del mismo, asegurando que se cumplan las actividades establecidas según los requerimientos del usuario.

El Gestor del Proyecto no es la persona que crea el proceso o que lo mueve, sino la persona que lo suaviza, al estar entre los dos frentes siempre abiertos en cualquier proyecto informático: el usuario y los desarrolladores. Por tanto, un Gestor de Proyecto, en el agilismo, tiene un rol de gestión muy marcado, dejando en parte las labores más técnicas que debe realizar al seguir otras metodologías.

Con las Metodología Ágiles, el análisis lo realiza el usuario en bastante mayor proporción que en otras metodologías al usar las Historias de Usuario; el diseño es una labor muy ligada a la programación y son los propios desarrolladores los encargados; hay que documentar muy poco, por lo que gran parte de toda la burocracia que acarrea un proyecto la tenemos resuelta. Pero todo esto no significa que el Gestor del Proyecto sea prescindible o que no tenga nada que hacer. Al contrario, surgen nuevas necesidades, nuevas tareas y nuevos riesgos que el Gestor del Proyecto debe enfrentar y asumir.

El Gestor del Proyecto debe alejarse del camino que toman los desarrolladores. Debe preocuparse por lo que rodea al equipo, pero abandonando la preocupación de lo que están haciendo. Debe ser un buen gestor, lo cuál implica detectar aquellos puntos negros que enlentecen el desarrollo del sistema, combatir aquello que se detecta como fuente de problemas, controlar el buen funcionamiento de la logística y de todo aquello que necesitan usar los desarrolladores. En resumen, conseguir que todo esté en orden para que los desarrolladores puedan terminar su trabajo a tiempo.

Además de esta parte de gestión más bien de recursos físicos, el Gestor del Proyecto debe acometer otro tipo de gestión, la de planificación de recursos humanos. Una vez centrados en el día a día, el gestor es el encargado de acometer las reuniones de Apertura Diaria y de conocer labores que hacen los miembros del equipo bajo la recomendación del Líder de Desarrollo. Una vez asignadas esas labores, el gestor no debe ir a más bajo nivel, conseguirá hacer un buen trabajo si tiene todas las labores que se deben hacer en la jornada de trabajo asignadas y a todos los miembros del equipo trabajando, lo cuál es bastante complicado.

Como se puede apreciar claramente, el día a día del Gestor es el de preparar las ceremonias (reuniones). Realizar las reuniones es una tarea tediosa, ya que hay muchos puntos que tener en cuenta:

• Planificar la fecha, el lugar, coordinar a todo el mundo para que asista y reservar el lugar adecuado, teniendo en cuenta de reservar el material necesario, tanto bebidas y “snacks” como la pizarra para exponer las ideas y desarrollar la planificación. (Estas labores suelen ser ejecutadas por segundas personas, pero el gestor debe ser quién invoque a estas segundas personas a ejecutarlas).
• Contactar con el usuario para que asista y cree nuevas Historias de Usuario que proporcionarán nuevo trabajo a los desarrolladores. Además, se les debe proporcionar ayuda en dicha labor.
• Después de las ceremonias se debe proporcionar la documentación necesaria para aquellas partes externas al desarrollo del proyecto que la necesiten.
• Coordinar todas las labores a todo el equipo. Además de toda la parte dedicada a la planificación del proyecto en sí, un buen Gestor de Proyecto debe asegurarse de la buena cooperación entre los diferentes miembros del equipo, intentando que exista el menor número de conflictos internos posibles.

Aptitudes que debe tener ​

• Buen carisma para las negociaciones: Ser carismático y contar con una marcada tendencia negociadora, abrirá las puertas a que los cambios organizacionales de lo tradicional al agilismo, se conviertan en un hecho que no provoque “roces”.
• Analítico y observador: El poder de observación será fundamental a la hora de coordinar con el Dueño del Producto y el Equipo de Desarrollo.
• Amplia capacidad para la resolución de problemas: La facilidad para resolver los impedimentos detectados será una característica clave de la cual, si se carece de ella, no habrá éxito posible.
• Excelentes conocimientos del Metodologías Ágiles: El Gestor del Proyecto debe contar con amplios conocimientos de los Valores y Principios del Agilismo, así como las Buenas Prácticas de la Programación eXtrema, del Marco Técnico de Scrum y de las Tablas de Visualización (Kanban).

Actitudes que debe evitar ​

• No debe asignar tareas a uno o más miembros del Equipo de Desarrollo.
• El Gestor del Proyecto no puede involucrarse en las decisiones organizativas del trabajo del Equipo de Desarrollo, pues no le corresponde.
• Debe evitar entrometerse en la gestión del equipo dejando definir su propio proceso de trabajo: recordemos que los desarrolladores deben ser un equipo auto-gestionado.
• No debe colocarse en actitud de autoridad frente al Equipo de Desarrollo: el Gestor del Proyecto no tiene “super-poderes”. Debe ser servil y no intentar “dominar”. Una actitud autoritaria, podría provocar el quiebre del equipo, obteniendo resultados poco deseables.
• No debe negociar con el usuario la calidad del producto a desarrollar: el Gestor del Proyecto debe tener muy claro, que solo el usuario tiene autoridad para decidir que otorga valor al negocio y que no.
• No debe delegar la resolución de un conflicto a un miembro del equipo o a un tercero: el Gestor del Proyecto tiene la obligación de tomar en sus manos la resolución de un problema. Cuando ésta, no esté a su alcance, deberá “golpear las puertas” que sean necesarias, y ser él, quien realice un seguimiento a fin de asegurarse que el problema ha sido resuelto.

El peor error que un Gestor del Proyecto puede cometer, es delegar la resolución de un conflicto administrativo (del proyecto) a un miembro del Equipo de Desarrollo, o intentar colocarse en posición de autoridad frente a dicho equipo.

Labores del Gestor del Proyecto ​

Para poder visualizar las labores, obligaciones y responsabilidades del Gestor del Proyecto, vamos a comenzar tomando una visión como defensor de los derechos del usuario, lo cual es cierto, ya que debe ser quién controle que se cumplan ciertos requisitos:

• Debe ofrecer al usuario una visión global del sistema, para que éste sepa que es lo que se va a hacer, cuándo, y a que coste.
• Debe conseguir que se ofrezca, por cada semana de trabajo, la mayor parte de tareas implementadas posibles.
• Debe ofrecer dinamismo al usuario, para que este vea un sistema en evolución.
• Debe ofrecer al usuario la posibilidad de cambiar los requerimientos a un coste no exorbitante.
• Debe tener informado constantemente al usuario del calendario del proyecto, así como de los posibles retrasos, para que este pueda realizar las modificaciones que considere oportunas si desea rescatar el calendario original.
• Debe resolver los conflictos que entorpezcan el progreso del proyecto.

El Gestor del Proyecto debe asumir una serie de responsabilidades bastante importantes, entre ellas, siendo una de las principales, que todo se cumpla de acuerdo a lo previsto. Básicamente las responsabilidades son:

• Causar
• Coordinar
• Reportar
• Planificar
• Acordar

Causar ​

La razón de ser de un Gestor de Proyecto, en primera instancia, es la de “causar” , conseguir que las cosas ocurran siendo el desencadenante de todos los procesos necesarios para el desarrollo del proyecto. En alguna forma, el gestor debe ser la chispa que haga que se inicie cualquier tarea en el proyecto.

Si un Gestor de Proyecto tiene en cuenta esto, conseguirá darse cuenta que debe estar alejado, en la medida de lo posible, del desarrollo del proyecto, ya que debe ser quién proporcione una medida objetiva o pseudo-objetiva del desarrollo del proyecto al tener una perspectiva lo más exterior posible a lo que es el desarrollo en sí. Debe tener más parte de usuario que de desarrollador, intentando ofrecer la información al Equipo de Desarrollo sobre lo que deben hacer y corrigiendo todo aquello que considere sea un fallo, o que interrumpa el transcurso normal del proyecto.

Coordinar ​

Por una parte, el Gestor del Proyecto es el “defensor del usuario”, en otra gran medida es “defensor del equipo”. Esto es así, porque debe intentar hacer ver a su equipo las necesidades del usuario y por otra parte debe limitar las exigencias del usuario a lo posible. Esta labor es difícil, pero se consigue teniendo al usuario como objetivo final a satisfacer, el usuario es el jefe del Gestor, en cierta medida.

El usuario es el objetivo último, él es a quién debemos satisfacer. Tener esto claro nos ayuda a resolver muchos problemas. Básicamente, el usuario debe estar en todas las partes de nuestro proyecto, desde el comienzo hasta el final. Para empezar, el análisis se hace con él, las pruebas se deben enseñar al usuario para que éste de su aprobación y el usuario recibirá todas las versiones del producto que se vayan produciendo.

Además, el usuario debe resolver cualquier duda de cualquier desarrollador acerca de lo que éste quiere conseguir con una determinada tarea. El usuario es la persona idónea, más bien, es la única que tiene el conocimiento, para resolver estas dudas, por lo que nunca se debe dudar el consultarle al respecto.

Como conclusión, se podría decir que la clave para un desarrollo correcto al 100% es la coordinación entre los programadores y el usuario.

Reportar ​

A pesar de que la “Programación eXtrema” proponga que se deben eliminar todos los papeleos que no sean útiles, siempre queda una parte de documentación que es necesaria. Para “Scrum”, la documentación más preciada es aquella sobre las distintas versiones, en la cuál se definen cuantas y qué Historias de Usuario han sido implementadas en el incremento funcional y cuales serán implementadas en la futura versión.

Además de esta documentación, a veces, es necesario generar documentación para terceras partes, bien por requerimientos del usuario o por otro tipo de necesidades. Siempre se debe minimizar la carga de trabajo que necesiten estas actividades por ser consideradas como no productivas, pero nunca se deben obviar.

Planificar ​

Una de las labores más arduas para el Gestor del Proyecto es la división temporal de este, intentando que los plazos de tiempo prefijados se cumplan. Para poder tener una idea de cómo realizar esta labor, conviene tener muy claro cuál es el ciclo de trabajo seguido con Scrum.

Desde un punto de vista simplista, el ciclo de desarrollo de Scrum se basa en un bucle en el cuál el usuario define sus necesidades y el desarrollador las implementa. Esto viene reflejado por la asignación de las “Historias de Usuario” a los desarrolladores en las reuniones de apertura, creando gran dinamismo. Esto es el ciclo de vida a un nivel muy simple, por lo que podemos redefinirlo, dándonos cuenta de otras actividades que el Equipo de Desarrollo debe realizar.

Una de las labores del Equipo de Desarrollo es la de estimar el esfuerzo ante una petición del usuario. De esta manera, el usuario enuncia sus necesidades y éstas son estimadas en el baremo de esfuerzo. Una vez conociendo el esfuerzo que hay que invertir, el usuario puede evaluar el conjunto de requisitos que desea que sean implementados en el producto final.

Esta información acerca de la estimación de esfuerzo, es ofrecida por el propio Equipo de Desarrollo, ya que la experiencia de este equipo les permite evaluar la dificultad y el tiempo que va a necesitar para implementar aquello que le ha sido requerido. Evidentemente, esta es una ayuda de gran calidad para el Gestor del Proyecto.

La experiencia proporciona el poder realizar un buen trabajo, tanto a la hora de estimar los esfuerzos como a la hora de implementar aquello que es requerido por el usuario. Entonces, cuanta más experiencia acumulada y más se tenga aprendido, más fácil será alcanzar las necesidades del usuario. Y esta experiencia que es requerida para acercarnos mejor a las necesidades del usuario es lo que nos proporciona el propio trabajo.

En cada iteración, tanto el desarrollador como el usuario aprenden. El desarrollador acumula experiencia al enfrentarse con nuevas situaciones con nuevos usuarios y el usuario aprende a definir cada vez mejor sus necesidades. De esta forma se puede lograr un estado de equilibrio, o de facilidad, para poder consolidar mejor los objetivos comunes al proyecto (usuario y equipo). Todo esto puede parecer más una ayuda al Equipo de Desarrollo que al Gestor del Proyecto. Pero tener una buena visión de las iteraciones para implementar los requerimientos del usuario, nos permite darnos cuenta de ciertos factores que pueden ayudar al Gestor del Proyecto a definir las fechas de entrega de las distintas versiones del proyecto:

• El tiempo destinado a cada necesidad depende en parte de la dificultad y en parte de la capacidad de los desarrolladores. En la mayoría de las situaciones es el propio desarrollador el más consciente de su capacidad, y el que mejor puede estimar el tiempo necesario para cada problema planteado.
• Es bueno conseguir que tanto el equipo como los usuarios se den cuenta que dependen unos de otros. Lograr una buena cooperación implica lograr un mayor ritmo de trabajo que ayuda a cumplir los objetivos.
• Hay que encontrar ciertos compromisos entre valores complementarios. Un Equipo de Desarrollo bajo presión es capaz de cumplir las fechas de entrega, pero la calidad se consigue rebajando el nivel de presión, para que se pueda pensar mejor y con mayor claridad. Para conseguir productos de calidad en el tiempo adecuado hay que compensar estos dos valores en su justa medida.

Para estimar el tiempo de un proyecto, comenzaremos realizando estimaciones aproximadas de las Historias de Usuario, contando con la ayuda de cada uno de los miembros del Equipo de Desarrollo. Una vez tengamos una serie de ellas implementadas, la mejor manera de conocer el tiempo a dedicar a cada una de las restantes es estableciendo comparaciones con las ya desarrolladas, lo cuál nos dará una mejor visión del tiempo que necesitemos emplear.

También es relativamente frecuente encontrarnos con tareas que son difícilmente planificables, ya que no conocemos mucho acerca de las necesidades. Para poder ofrecer una visión más o menos acertada acerca del coste temporal, conviene realizar un pequeño prototipo de las necesidades, implementando en unas horas o, como mucho, un día, una parte básica de las necesidades de la tarea. Una vez que podemos establecer con mayor precisión el coste temporal de las restantes, se debe recomponer la escala de tiempo para el proyecto de forma global para poder ofrecer al usuario una mejor aproximación a la escala temporal final.

Acordar ​

Otra labor del Gestor del Proyecto que resulta realmente escabrosa es acordar una fecha de entrega. Fijar una fecha para el fin del proyecto, es una labor que nos pueden conducir al fracaso como Gestor del Proyecto.

A cualquier programador se le puede pedir que construya un producto determinado en un tiempo determinado, siempre que el plazo de tiempo sea razonable, sea cuál sea la dificultad del proyecto, el programador se pondrá a hacerlo, con más o menos gusto. Pero si a este programador le pedimos que evalúe el tiempo del proyecto, seguramente le estemos dando un gran disgusto.

En el mundo de la informática, los proyectos suelen establecer tiempos de espera, por lo menos, con un margen muy pequeño de posibles modificaciones. Esto es así porque es la manera que casa mejor con las necesidades del usuario y del equipo.

• Para el usuario, ofrece: Calendario predecible - Entregas predecibles
• Para el equipo, ofrece: Beneficios predecibles - Demanda predecible

Todo esto son características visibles a priori, el problema viene a la hora de trabajar en proyectos reales, a que muchas veces, encontramos que algún requerimiento es más complicado de implementar que lo que a priori parecía. En estos casos, como el usuario no va a querer esperar más ni va a permitir que alarguemos la entrega, probablemente, entreguemos una parte con un nivel de calidad inferior, debido a tener que trabajar más, en menos tiempo y a desgana. Con este cuadro pierde el usuario de forma indirecta al perder calidad en el producto.

Con todo lo visto, nos podemos dar cuenta que estamos ante una filosofía que pone al Dueño del Producto y al Gestor del Proyecto en contra uno del otro, lo cuál se verá mejor, todavía, en el siguiente cuadro.

Para evitar muchos de estos problemas, debemos tener en cuenta una serie de variables que afectan a los proyectos informáticos:

• Alcance.
• Calidad.
• Coste.
• Tiempo.

Ahora, la mejor manera de fijar un acuerdo es tener en cuenta estas variables. Además, incluso podemos eliminar la variable de calidad, porque, hoy por hoy, los desarrolladores quieren ofrecer calidad, y usan estándares diversos para ello, porque son conscientes que su trabajo lo requiere.

Para resumir el Gestor del Proyecto proporciona ​

• Revisión y validación de la Pila del Producto.
• Moderación de las reuniones.
• Resolución de impedimentos logísticos que en el Sprint pueden entorpecer la ejecución de las tareas.
• Configuración, diseño y mejora continua de las prácticas de Metodologías Ágiles en la organización.