Últimamente leo artículos de la comunidad ágil atacando la figura del project manager y la disciplina del project management. Me llega el mensaje de que los project managers ya no somos necesarios en los proyectos software. Se dice que estamos en en el lado oscuro. Impedimos el buen desempeño del equipo, el trabajo de buena calidad, la orientación al valor, el ritmo sostenible, el espíritu de equipo, la creatividad, el sentido común, etc.
Es verdad que muchas veces se observa todo esto en los proyectos software, pero ¿seguro que siempre es culpa del project manager? Y cuando lo es, ¿seguro que ese project manager está dirigiendo correctamente el proyecto ágil?
Estas lecturas me impactan profundamente porque yo me considero, como muchos otros colegas, parte activa de la comunidad ágil, y de verdad que no sentimos que estemos en el lado oscuro cuando nos toca dirigir un proyecto ágil. Cuando hablan de suprimir nuestro rol, nos preguntamos: Entonces ¿quién se va a responsabilizar de terminar el proyecto en plazo y dentro del coste aprobado? Y seguramente nuestros jefes se preguntarán: Entonces ¿a quién le vamos a echar la culpa cuando el proyecto salga mal? ;-D
Demonizar la figura del project manager, o la práctica de la gestión de proyectos, es una simplificación injusta y desacertada. El estado actual y las tendencias del project management van justo en el sentido contrario:
Los marcos ágiles no mencionan el rol del project manager porque se diseñaron para la gestión de productos, no de proyectos. No obstante, el rol PM es requerido siempre que la organización aprueba un proyecto que debe terminar dentro un plazo determinado y por debajo de un presupuesto. El PM profesional se responsabiliza, entre otras cosas, de que el proyecto ágil termine a tiempo y sin exceder el presupuesto, tratando de satisfacer los requisitos del grupo de interesados.
El project manager de hoy día no es un profesional completo si no sabe cómo se gestionan los dos tipos de proyectos:
En un proyecto predictivo se cierran la mayor parte de los requisitos al principio y después se avanza por fases sencuenciales. Son ejemplos típicos los proyectos de ingeniería y construcción, denominados a veces EPC: Engineering, Procurement and Construction. El rol del project manager en estos proyectos consiste en cerrar un plan para la dirección del proyecto –que incluye un diagrama Gantt y otros muchos componentes que podrán modificarse si es necesario– para utilizarlo a modo de “partitura” para dirigir a los miembros del equipo como si fueran los músicos. En las reuniones de seguimiento, se compara el desempeño real con el planificado y se toman acciones correctoras para acercarnos a las líneas base. De esta manera, midiendo y ajustando sucesivamente, logramos cumplir el plazo, el coste, etc.
Si estamos hablando de un proyecto software en cascada, el flujo es mayoritariamente unidireccional, como en una “cascada”: Se cierran todos los requisitos técnicos, después se desarrolla y se cierra todo el modelo funcional, después se diseña y se aprueba toda la arquitectura, después se acomete la fase de desarrollo, y finalmente la fase de pruebas y el pase a producción.
Cuando se sabe claramente casi todo lo que hay que hacer, es muy eficiente trabajar por lotes: primero todos los requisitos, luego toda la especificación funcional, etc. Ya que nos ponemos a desarrollar el sistema de información en español, hagámoslo también en inglés… Igual que el agua no vuelve hacia arriba en una cascada, una vez se avanza a la siguiente fase, ya no se vuelve a la anterior. Como todo el mundo sabe, este modelo en cascada generalmente no funciona para informática de gestión ni para desarrollos web, pero sigue usándose para desarrollar software de misión crítica –por ejemplo en el sector aeronáutico–, software embebido –sirva como ejemplo el software que puede haber en un coche autónomo–, o bien en productos software con un componente muy alto de requisitos no funcionales, o con un roadmap muy predeterminado, etc.
¿Por qué no sirve el modelo en cascada para la mayoría de proyectos software, dirigidos a usuarios finales que deben utilizarlos para realizar determinadas operativas? Sencillamente, porque es muy difícil, si no imposible, cerrar apropiadamente los requisitos del sistema de información. Si trabajamos en cascada y entregamos por primera vez después de 5 meses, lo más probable es que se rechace mucha funcionalidad y haya que asumir mucho retrabajo.
Yo mismo, que siempre he criticado a los clientes porque no se ponían de acuerdo y me parecía que me querían cambiar los requisitos caprichosamente, ahora que estoy en el lado cliente, desarrollando PMPeople, un software con mucha funcionalidad y para eso estamos subcontratando a una software factory en India, ahora soy yo quien debe de parecer caprichoso porque quiero cambiar los requisitos continuamente. A pesar de que yo me considero experto a la hora de modelar sistemas de información, cuando empezamos el proyecto, yo era incapaz de cerrar los requisitos. Este software era demasiado grande para planearlo suficientemente. Ahora que ya estamos dando servicio a clientes, comparo los mockups de hace 3 años con las pantallas que usan los clientes ahora y no tienen nada que ver.
El gran drama de los proyectos software, con el que tenemos que convivir, es que el cliente de un proyecto software no sabe lo que quiere, solo sabe lo que no quiere.
“El cliente de un proyecto software no sabe lo que quiere, solo sabe lo que no quiere.”
Por eso es tan rentable descubrir el valor, practicando iteraciones frecuentes que terminan demostrando algo funcionando, típicamente cada 2 semanas. Cuando los indios nos hacen una demo, es entonces cuando yo tengo clarísimo lo que quiero. Si hubiéramos elegido un método predictivo para gestionar este proyecto, el proyecto habría fracasado y lo tendríamos que haber cancelado hace tiempo. La mejor decisión de este proyecto fue elegir un ciclo de vida orientado al valor:
¿Como gestioné este proyecto ágil? Al principio limité plazo entre 12-18 meses. El objetivo era tener una versión beta lista para implantar en clientes (B2B). Más allá de esa fecha de fin, al gestionar el trabajo de mantenimiento correctivo, aunque técnicamente era parecido, ya no gestionaba un proyecto, sino un producto. Cuando nos planteamos el lanzamiento de la versión móvil, esto fue otro proyecto, y fue muy beneficioso contar con el mismo equipo de la software factory, al menos con el mismo product owner. El lanzamiento del modelo freemium para el público general (B2C SaaS) fue otro proyecto.
Con ese plazo predeterminado para realizar un trabajo que visualizábamos en líneas generales con los requisitos de alto nivel, y con un tamaño de equipo más o menos estable que nos ofrecían, pude calcular fácilmente una primera estimación del presupuesto. En terminología Scrum, yo me consideraba “chicken” (junto con otros colegas que confirmaban el valor). En el proyecto yo asumí los roles de business analyst y project manager. Hablaba muy a menudo con el Product Owner y detrás había un equipo técnico y el Scrum Master.
Usamos Asana para gestionar las listas y los tableros y Slack para la comunicación continua. Comparto el product backlog con el product owner, no veo los sprint backlogs ni atiendo ya a los daily standups (es muy pronto aquí en España). Tenemos visibilidad sobre el tamaño en horas ideales de cada historia. Practican integración continua: Cuando terminan una historia, la despliegan al entorno de pruebas y mueven la tarjeta del tablero de “in progress” a la columna “testing”. Me llega la notificación de Asana y ya sé que tengo pendiente hacer las pruebas. Si las pruebas se superan, marco la historia como terminada y la muevo a la columna “done”. En caso contrario, la devuelvo a “in progress”:
Diariamente, el Scrum Master actualiza la gráfica de quemado en Excel (para descargar la plantilla, pulsar aquí).
Para controlar un proyecto ágil no suele servir de mucho hacer un Gantt. Veríamos tareas resumen con las releases una detrás de otra, pero el proyecto generalmente va en fecha, siendo las únicas desviaciones ocasionadas por algún que otro spike de vez en cuando.
En nuestro caso, al principio planteamos 5 releases:
En esta experiencia de gestión de un proyecto ágil, me parece que las labores que estoy realizando día a día encajan bastante bien con el rol de agile practitioner delineado por PMI®. En el texto que usa PMI® para especificar el examen PMI-ACP® se describen 7 dominios que resumen las principales áreas de responsabilidad del Director de Proyectos Ágil.
Explorar, fomentar y aplicar principios ágiles en el contexto del equipo del proyecto y la organización.
Entregar resultados de valor produciendo entregas incrementales de alto valor revisables, pronto y a menudo, basándose en las prioridades de los interesados. Hacer que los interesados proporcionen retroalimentación a partir de estas entregas, con el fin de priorizar y mejorar las entregas incrementales futuras.
Gestionar la involucración de los interesados actuales y futuros generando un entorno de confianza que permita alinear sus necesidades y expectativas y equilibrar sus peticiones haciendo que comprendan el coste/esfuerzo que suponen. Promover la participación y la colaboración a lo largo del ciclo de vida del proyecto y proporcionar las herramientas para la toma de decisiones eficaces e informadas.
Crear un entorno de confianza, aprendizaje, colaboración y resolución de conflictos que fomente la auto-organización del equipo, mejore las relaciones entre los miembros del equipo y cultive una cultura de alto rendimiento.
Producir y mantener un plan que evolucione desde el inicio hasta el cierre, basado en objetivos, valor, riesgos, restricciones, retroalimentación de interesados y revisión de los hallazgos.
Identificar continuamente problemas, impedimentos y riesgos. Priorizarlos y resolverlos de manera oportuna. Monitorizar y comunicar el estado de resolución de los problemas e implementar las mejoras de procesos que eviten que vuelvan a ocurrir.