Las organizaciones que usan PMPeople ejecutan múltiples proyectos dentro de los respectivos departamentos, portafolios y programas. Dependiendo del tipo de enfoque de desarrollo de los entregables, estos proyectos son predictivos, adaptativos o híbridos.

Nuestra recomendación para gestionar la parte ágil de un proyecto es mantener la gestión del proyecto en PMPeople, descomponiéndolo en paquetes de trabajo, un paquete por cada release. El paquete #0 (el proyecto completo) puede incluir tareas relacionadas con las principales funcionalidades (épicas). Las releases pueden incluir tareas relacionadas con las funcionalidades que habrá que demostrar operativamente a los interesados (historias de usuario). Para favorecer la colaboración con el equipo de desarrollo, recomendamos usar nuestra integración con Asana: los proyectos de Asana pueden conectarse con los paquetes de trabajo de PMPeople, de manera que los usuarios gestores pueden seguir las tareas significativas sin necesidad de entrar en Asana.

Veamos un caso práctico desde la planificación del proyecto hasta la primera retrospectiva. Para simplificar el ejemplo, asumimos que el project manager ejerce también los roles de coach y product owner. Sea un proyecto ágil denominado PR1:

  1. El Project Manager facilita la planificación de la release: Los Team Members revisan la versión actual del product backlog para decidir qué historias (o épicas) son las más valiosas para la nueva release. Durante la discusión se añaden nuevas historias, se anotan aclaraciones, algunos elementos se aparcan, etc. El resultado es una lista prorizada en un proyecto de Asana para gestionar la release, denominado PR1_REL1. Todos los elementos de la release también pertenecen al proyecto para gestionar el product backlog PR1_PBL. Los elementos relevantes para la alta dirección se pueden incluir en otra lista llamada PR1_EPICS. Los elementos aparcados se mueven a la lista PR1_PARKING.
  2. El Project manager planifica el proyecto: Usa PMPeople para compartir la información relevante del caso de negocio, el acta de constitución, el registro de interesados, los entregables, requisitos, riesgos, cronograma, hitos, costes, etc. Pasa el estado del proyecto a ejecución.
  3. Los Team Members ven sus asignaciones al paquete llamado REL1 en PMPeople. Colaboran para redactar el team charter. Pueden registrar su estado anímico anónimamente, pasar comentarios para el Project Manager, etc.
  4. El Project manager conecta el paquete #0 y el paquete REL1 a los proyectos de Asana PR1_EPICS y PR1_REL1, respectivamente.
  5. El Project Manager explica la funcionalidad esperada en la demo del primer sprint. Los Team Members descomponen las funcionalidades en tareas técnicas. Pueden usar una lista para el primer sprint backlog de la primera release del proyecto PR1, como el proyecto de Asana PR1_SPR1.1. Las historias de usuario también se incluyen en esta lista, quedando las tareas técnicas como subtareas que también pueden ponerse en la sección “to-do” del proyecto de Asana titulado KANBAN, que se visualizará como tablero, , por ejemplo.
  6. Los Team Members usan el tablero KANBAN durante los daily stand-ups. Cuando un Team Member se auto-asigna una tarea, los demás pueden saber a quién está asignada y la fecha prevista. En cualquier momento, todos pueden comprobar fácilmente que se sigue la buena práctica de “flujo de una pieza” porque nadie tiene más de una tarjeta en la sección “in-progress” del tablero KANBAN. Si alguna tarea tiene impedimentos, esto puede quedar debidamente anotado en la descripción de la tarea y también se puede etiquetar el título con un emoji 😡. La buena práctica recomendable aquí es que todos los impedimentos se resuelvan antes del siguiente daily.
  7. Si los Team Members anotan las horas ideales (planificadas y pendientes) en las tareas de Asana, el Project Manager puede actualizar fácilmente el sprint burndown chart. Si las historias de usuario se estiman con story points, el Project Manager puede actualizar el release burndown chart.
  8. Los Team Members pueden imputar horas y gastos en cualquier momento via web o con la aplicación móvil. El Project Manager puede aprobar/rechazar las imputaciones al final de la semana. Si hay que controlar los costes, la imputación en línea evita los desperdicios causados por los procesos y la burocracia.
  9. Cuando un Team Member completa una tarea, la marca como completada en el tablero KANBAN o en la lista PR1_SPR1.1 y la mueve a la sección “done” del tablero KANBAN. Cuando todas las tareas de una historia se han completado, el Project Manager puede marcar la historia como completada en PR1_REL1. La información de épicas e historias puede sincronizarse automáticamente desde Asana a PMPeople.
  10. Durante la demo del sprint, los Team Members demuestran las historias completadas a los Stakeholders. Si una historia no es aceptable, se marca como incompleta. Las historias incompletas podrán planificarse con facilidad posteriormente .
  11. En PMPeople, los Project Managers normalmente planifican las fechas de revisión coincidiendo con los finales de los sprints. El Project Manager puede registrar la información relevante sobre el informe de seguimiento para la release 1 y para el proyecto completo. Los Stakeholders pueden comprobar el estado del proyecto a través de la web o la aplicación móvil.
  12. Finalmente, el Project Manager puede facilitar la retrospectiva del equipo si los Team Members han ido anotando su estado anímico en PMPeople.

PMPeople es la herramienta para la economía de proyectos. Se diseñó para unificar la gestión profesional de los proyectos de las organizaciones, destacándose por los siguientes puntos:

  • Diseñada por y para project managers profesionales, siguiendo los estándares de gestión de proyectos profesional.
  • Productividad en línea (menos reuniones, menos documentos, menos flujos) por colaboración distribuida entre 12 roles especializados: Dueño de la Organización; 6 roles para la gestión de la demanda y 5 roles para la gestión del suministro.
  • Aplicación freemium (uso gratuito por tiempo ilimitado, pago por uso, solo pagan los gestores) con usabilidad equivalente por web y por la aplicación móvil.

Comience a usar PMPeople gratis, sin límite de tiempo, sin límite de usuarios. En las organizaciones premium solo pagan los gestores. Algunos roles (interesados, team members, patrocinadores y gestores de recursos) son siempre gratis. Podrá añadir o reducir usuarios premium según las necesidades reales de su organización. En todo momento, tendrá acceso a nuestro soporte interactivo por Slack. Nuestros servidores se encuentran dentro de la UE. Si lo prefiere, el software puede quedar alojado en sus instalaciones.

Leer este artículo en inglés.