Como project manager siempre me ha parecido muy interesante dedicar tiempo a investigar sobre las herramientas más adecuadas para gestionar los proyectos. En mis proyectos, muchas veces hemos desperdiciado tiempo en tareas que no aportaban valor, que debería haberme encargado de sumprimir.
De nosotros se espera que el proyecto termine a tiempo, en coste, entregando lo que se comprometió dentro del alcance, satisfaciendo los criterios de calidad de los interesados y demás objetivos de gestión. Cuando terminamos tarde no me sirve de nada eharle la culpa a que hemos perdido mucho tiempo comunicándonos por email, manteniendo demasiadas reuniones, elaborando demasiados informes, documentando los cambios, validando horas y gastos, planificando tareas en detalle, estimando pequeños esfuerzos, microgestionando cronogramas, etc.
Si el proyecto no cumple los objetivos de gestión y yo soy el project manager, sé que estoy aquí para que me echen la culpa.
Así pues, cuando he visto que ahorrábamos tiempo y mejorábamos la colaboración, siempre me he empeñado en usar las herramientas más adecuadas, si estaban a mi alcance. Si esas herramientas no se usaban todavía en la organización, o para lo mismo ya se usaban otras, me las arreglaba para conseguir que se usaran en mi proyecto. Yo aceptaba tener la culpa si el proyecto salía mal, pero a cambio exigía cierta autonomía para decidir las herramientas más productivas: pocos jefes me negaban este trato.
Ahora que me dedico a la consultoría en gestión de proyectos, siento que tengo la obligación mantener mi hábito de revisar herramientas. Me preocupa que alguna buena herramienta se me escape del radar. Cuando me entero de alguna nueva herramienta, o alguna innovación en herramientas que ya conozco, tengo el hábito de procesar esa información. Esto ahora es más sencillo gracias a los magníficos recursos disponibles para evaluar comparativamente herramientas, entre los que destacan los vídeo-tutoriales de ciertos expertos. También he descubierto muchas herramientas gracias a alumnos, colegas y colaboradores.
Steven R. Covey decía que “de vez en cuando hay que parar de cortar el árbol para invertir tiempo en afilar la sierra”. A veces debemos replantearnos las herramientas que usamos. ¿Mejoraría el desempeño en mi siguiente proyecto si cambiamos la herramienta A por la herramienta B? Lamentablemente, no podemos responder a esta pregunta desde un plano teórico. En los proyectos, nos convencemos de las herramientas cuando las probamos en la práctica.
Actualmente estoy dirigiendo un proyecto para desarrollar una herramienta de gestión de proyectos. Queremos lanzar un producto freemium para que todas las personas que deban colaborar en la gestión de un proyecto puedan hacerlo desde su móvil. El desarrollo lo hemos externalizado a una software factory en India, que usa Scrum. Hablamos principalmente con el Product Owner, tienen un equipo Scrum de 3 personas y un Scrum Master. Algunas mañanas (a las 7:00 en España, las 10:30 en India) nos conectamos por videoconferencia para resolver impedimentos, aclarar funcionalidades y ver demos. Mantenemos viva la comunicación por Slack y la colaboración por Asana.
En el cuento del cerdo y la gallina, nosotros nos consideramos “chicken”, asumiendo los roles de project manager y business analyst. Decimos qué hay que hacer, no cómo hacerlo. Creemos que es muy importante que nos mantengamos en esta posición funcional y de gestión.
Este es sin duda el proyecto más arriesgado al que yo me he enfrentado. Esto se debe principalmente a que el software, aunque no es demasiado complejo, tendrá muchas reglas de negocio para los 11 tipos de usuarios posibles, que accederán por web o por móvil, y además queremos que se integre con otras herramientas de scheduling, mensajería instantánea, gestión de tareas, gestión documental y CRM. Como queremos crecer por viralidad, habrá que validar el modelo de negocio siguiendo el método Lean Startup. No menos importante es el hecho de que no contamos con financiación en esta fase y estamos invirtiendo fondos propios.
Ahora que el jefe soy yo, nadie me discute qué herramientas hay que usar ;-). Desde mayo de 2017 han generado 3 releases, ya van por la cuarta. Hemos tenido tiempo de usar las herramientas y estoy contento con los resultados. Creo que esta experiencia me está decantando sobre las herramientas que puedo recomendar a cualquier project manager que dirija proyectos software.
A continuación enumeraré las herramientas que usamos para gestionar este proyecto. No incluiré los frameworks de desarrollo web y móvil que usan en la factoría, los productos para gestión de versiones, pruebas automáticas, integración continua, etc. Me centraré a las herramientas que a nosotros nos permiten dirigir el proyecto. Estas herramientas pueden clasificarse en 3 niveles:
- PROJECT GOVERNANCE: Herramientas para dar seguimiento e informar a los comités de dirección, PMO, etc. El nivel de información y reporte adecuado aquí es el de cuenta de control. Sobre estos bloques de gestión que nos permiten resumir la gestión del cronograma, el alcance y los costes del proyecto, debemos explicar a los jefes las desviaciones y los pronósticos, así como proponer acciones preventivas o correctivas para que el proyecto termine cumpliendo los objetivos de gestión. En este proyecto concreto no necesitamos muchas herramientas de esta categoría, quizá solo el registro de riesgos, para lo que nos vale un simple excel cuya plantilla puede descargarse pulsando aquí.
Recordar que PMBOK® es un marco, no un método. Es decir, nos dice qué debemos gestionar, no cómo hacerlo. Cuando aplicamos Scrum, el marco de gestión del proyecto sigue siendo válido.
- PROJECT MANAGEMENT: El nivel de gestión del proyecto propiamente dicho. Aunque el proyecto siga un modelo de ciclo de vida ágil, podemos aplicar el estándar PMBOK® para decidir qué hay que hacer para terminar en plazo, en coste, con los interesados satisfechos. Recordar que PMBOK® es un marco, no un método. Es decir, nos dice qué debemos gestionar, no cómo hacerlo. En este caso aplicamos la metodología Scrum (3 roles, 3 artefactos, 4 ceremonias), pero el marco de gestión PMBOK® sigue siendo válido. Desde el punto de vista de las herramientas, más abajo hablaré de las herramientas que usamos para la gestión de los requisitos. Por lo que se refiere a la gestión del alcance, el cronograma y los costes, yo he aprendido a unificar toda esta información en una sola herramienta: Microsoft Project®. El nivel más bajo del cronograma lo llamo actividad, no tarea. Prefiero usar el término tarea en el siguiente nivel. Yo siento que llego a un buen nivel de descomposición cuando me convenzo de que si controlo las fechas de las activiades y los hitos, entonces seré capaz de controlar que el proyecto termine en plazo. Si descompongo más abajo en Project, ya me parece microgestión. Para representar en Project las cuentas de control, utilizo la vista Timeline y el campo Priority = 1 para poder filtrar las cuentas de control y también los hitos más relevantes. Si copio el Timeline a un informe de seguimiento, los responsables de gobernar el proyecto tienen toda la información del cronograma que necesitan. En los proyectos ágiles, mis actividades suelen representar los sprints. En las tareas resumen represento las releases, que suelo identificar con las cuentas de control del Timeline. Usando la vista Tracking Gantt puedo actualizar la información de desempeño y ver gráficamente las desviaciones sobre la línea base.
- PROJECT WORK: Utilizo el término tarea para referirme al trabajo elemental asignable a los miembros del equipo. Usamos Asana como herramienta de gestión de tareas. Nosotros vemos la lista que gestiona el Product Owner para el product backlog y el release backlog. En el sprint backlog, que representan como lista y como tablero kanban, no ponen las tareas técnicas, aunque me gustaría, solo dejan que les informemos de los tickets con los defectos o tareas técnicas adicionales que les pedimos. Nosotros tenemos buena sensación de control usando Asana como herramienta de ticketing.
A continuación voy a citar las otras herramientas que usamos para colaborar en el nivel de WORK MANGEMENT:
- Para conversar con el Product Owner por mensajería instantánea usamos Slack. Nunca usamos el email con la factoría, salvo para las facturas y otros temas formales.
- Para informar los defectos, normalmente incluimos un vídeo grabado con Jing o una captura de pantalla tomada con LigthShot (ambas herramientas permiten guardar en la nube y compartir enlaces).
- Para las videoconferencias usamos GoToMeeting porque ya la estamos pagando para nuestros cursos, en otro caso usaríamos Zoom.
Por último, pero no menos importante, voy a intentar explicar cómo hacemos la gestión de requisitos, o business analysis. Nuestra forma de mantener el control funcional de los requisitos se basa en tres puntos:
- Mantenemos dos prototipos interactivos en PDF, desarrollados con la herramienta Balsamiq.
- Mantenemos la especificación del modelo de datos usando ERwin como herramienta CASE, lo que nos permite dividir el esquema del modelo de datos desde múltiples vistas.
- Mantenemos en Microsoft Word® el documento de especificación (sobre la que se basan las órdenes de trabajo contractuales con la factoría) y también otros documentos para desarrollar los customer journey. Estos documentos funcionales cambian continuamente. Mantenemos una única versión compartida con el Product Owner a través de Google Drive. La especificación detallada de los requisitos la llevamos a Asana.
A continuación pueden ver una imagen extraída del documento de especificación funcional:
Y por último, aquí tienen una imagen de los mockups navegables en pdf:
