El Product Owner y El Project Manager

Actualmente muchas empresas que han organizado sus procesos de de proyecto de acuerdo al PMBoK del PMI, ISO 21500, Prince2 o algún otro marco de trabajo con un enfoque tradicional, se están viendo afectadas cuando por alguna razón, se ven expuestas a enfoques ágiles por parte de sus proveedores o hay una iniciativa de utilizar un enfoque ágil dentro de la organización. El Product Owner y El Project Manager son roles fundamentales dentro de nuestra organización y tenemos que conocer muy bien cuales podrían ser sus funciones dentro de este escenario.PO

Si bien hay que cumplir con los procesos de la PMO, quiero conversar en este momento sobre el rol del Product Owner en un entorno de una oficina de proyectos alineada con los procesos tradicionales y en donde el proyecto ha sido delegado a un Project Manager.

Este post no es para agilistas, de hecho creo que será criticado altamente porque los procesos de desarrollo ágil no ve a un project manager dentro de su gestión de proyectos, sin embargo la realidad es otra y aún los PM existen dentro de las organizaciones 🙂

El Product Owner es un rol de los procesos ágiles, y Agile no cubre todos los procesos de la gestión de proyecto, de allí podemos identificar ciertas responsabilidades dentro de este entorno:

Iniciación del Proyecto

  • Asistir al Project Manager para definir el alcance del producto a partir de documentos de adquisición extractos relacionados del contrato del proyecto y el caso de negocio.
  • Contribuir a identificar los riesgos relacionados con los requerimientos del producto.
  • Contribuir a identificar los requisitos relacionados con las necesidades de comunicación
  • Contribuir a identificar estimaciones en actividades relacionadas con el Product Owner basadas en el alcance y la complejidad de los requisitos del producto.
  • Contribuir a identificar a los interesados del área del negocio, el momento y el nivel de participación de estos.
  • Identificar los requisitos de aprobación del producto con el Project Manager
  • Trabajar con el Project Manager para identificar hitos del cronograma.

Planificación del proyecto

  • Planificación de los Releases
    • Involucrar a los actores funcionales sobre las principales necesidades del cliente.
    • Ordenar de manera objetiva los requisitos de los productos que se incluirán en el alcance del proyecto. 
    • Identificar los criterios de aceptación e incluir en forma corta la descripción asociada con historias en esta etapa.
    • Desarrollo del backlog
  • Reunión de planificación de sprint: Trabajar con el equipo en busca de historias que se incluirán en el backlog según prioridades establecidas 
  • Asistir al Project Manager para desarrollar el cronograma, presupuesto, revisar las necesidades de recursos, revisar las necesidades de comunicación e incertidumbres relacionadas con los requisitos para el sprint actual.
  • Asistir al  Project Manager para identificar impedimentos del productos como parte del backlog

Ejecución (entendiendo que la planificación es un proceso iterativo)

  • Establecer la ‘Definición de Hecho’ de las historias de los sprints
  • Después de diseño preliminar involucrar a los desarrolladores para identificar los casos de prueba para la unidad de las historias incluidas de los sprints
  • Desarrollar los criterios de aceptación de las historias
  • Identificar el flujo completo de historias en el caso de flujo de procesos involucrados.
  • Desarrollar la estructura de historias que participan en los sprint.
  • Identificar el flujo de mensajes dentro de historias.
  • Identificar los componentes y dependencias asociadas.
  • Guiar al equipo para producir los entregables de productos de acuerdo a la ‘Definición de Hecho’

Monitoreo y Control

  • Participar en el Daily Stand Up Meeting con el Project Manager para identificar:
    • Obstáculos técnicos.
    • Riesgos relacionados con los requisitos.
    • Problemas de calidad del producto
  • Trabajar con el Project Manager en los procedimientos de control de requisitos relacionados con los cambios.
  • Monitorear los riesgos  relacionados con los requisitos.
  • Contribuir en la identificación de las causas de la mala calidad de los productos
  • Asistir al Project Manager en el reporte de estatus del burndown chart
  • Realizar el seguimiento de los cambios de la aplicación

Cierre de fase

  • Involucrar al Project Manager en la retrospectiva del sprint
  • Participar en el desarrollo del repositorio de lecciones aprendidas y las plantillas para proyectos similares
  • Revisar la participación de los interesados con el Project Manager

Cierre del Proyecto

  • Involucrarse con el Project Manager en el proceso de lecciones aprendidas

 

Quizás no pasará mucho para que los Project Managers en organizaciones donde todos sus procesos estén alineados bajo un enfoque Agile dejen de existir, pero particularmente no veo al Product Owner del área de negocios o al Scrum Master (por poner un ejemplo) documentando y llevando a cabo una auditoría SOX 🙂

 

Saludos,
Leandro

leandrojpachec
Share
This

1 Comments

  1. GUILLERMO COTTA ESCOBAR

    ok

Post a comment