Responsabilidades de un Product Owner (PO)

Imagen de portada de Jason Goodman en Unsplash

Responsabilidades y roles de un Product Owner en el área de Desarrollo de software.

Si estas leyendo esto es porque quieres conocer mas a profundidad el rol de Product Owner, si bien es cierto, las responsabilidades de un PO varían según la empresa donde estés, aquí te contare las principales responsabilidades del roll que encontraras en cualquier empresa, comencemos!

Recoger y conocer los requisitos.

Todo proyecto comienza con un brainstorming o Lluvia de ideas, por lo general se realiza con los lideres de proyecto conjuntamente con stakeholders/clientes, este paso de recoger y conocer los requisitos es sumamente importante porque te hará entender la visión del producto y lo mas importante, conocer los deseos del cliente o en su defecto de los staketholders.

Foto de Tyler Nix en Unsplash

Los métodos para realizar esta recogida suelen venir acompañado de reuniones llamadas Product Discovery, Brainstorming, Kick off o simplemente un café con tu cliente. Ten en cuenta que debes ponerte del lado del usuario final para tener un mejor entendimiento, no te preocupes del como lo harás, solo recauda todos esos requisitos en esa primera Reunión, por lo general los stakeholder suelen pedir fechas estimadas, esto no lo debe dar nunca un Product Owner, los que estiman el proyecto o el tiempo del sprint y cuando será posible un MVP es el equipo de scrum, es decir, todo el equipo. cuando el Product Owner tiene ese dato es cuando traslada unas fechas tentativas a los Project manager o en su defecto a los stakeholder.

Gestionar el Product Backlog en su totalidad, ordenando y priorizar las tareas para alcanzar los objetivos  de la mejor forma. Asegurarse de que el Product Backlog(PB) sea visible, transparente y claro para todos.

El Product Backlog es el artefacto mas importante del Product Owner, es parte de él, sin un Product Backlog ordenado y priorizado el PO no podrá tener éxito ni maximizar el valor del producto. Como lo digo en el titulo, el Product Backlog debe estar ordenado por prioridades y no siempre son las prioridades del cliente, suelen ser prioridades de negocio o hasta técnicas, la idea de tenerlo priorizado y ordenado es para poder llegar de una manera fácil y ágil al objetivo del sprint / proyecto.

Como Product Owner debes asegurarte de que el PB sea visible y transparente para todo el departamento y suele estar visible hasta para toda la empresa. Por lo general el Product Backlog esta en sitios visibles o en algún programa de gestión accesible para todos los usuarios, no obstante existe un tablero llamado Road Map, el Road Map es un tablero donde se muestran épicas a un nivel superior para los administradores de proyectos y debe estar alineado con el Product backlog y otros tableros internos de los equipo de desarrollo.

Definir el producto mínimo viable (MVP)

La definición de un MVP suele hacerse conjuntamente con los dev lead, para poder dimensionar que podrán entregar en un sprint. En ciertas ocasiones el MVP lo puede definir un PO conjuntamente con un Project Manager pero la ultima palabra de lo que va a ser entregable la dice el equipo de desarrollo. Los desarrolladores son los únicos que pueden determinar el tiempo exacto de las tareas que deben hacer esto se llama Estimar las historias de usuarios(US).

Optimizar el valor del trabajo del Equipo.

Un Product Owner puede identificar falencias o malas practicas en el equipo scrum conjuntamente con el Scrum Master, es por eso que debe asistir a las reuniones de retrospectiva para aportar mejoras y así optimalizar el valor del trabajo en equipo.

Decidir qué desarrollar y qué no.

Foto de Jason Goodman en Unsplash

La decisión de lo que se debe abordar en el sprint siempre la tiene el PO, lo determina en el Sprint Planning ya que él sabe la prioridad de las épicas y proyectos que deben ser entregados como MVP. Esta decisión la toma teniendo un Product backlog ordenado y priorizado, sobre todo conociendo la visión del producto mínimo viable que se quiere entregar.

El qué no desarrollar suele venir con una decisión técnica o de sentido común, no obstante tambien viene por ordenes de mas arriba (Gerentes o Stakeholder) pero siempre debe tener argumentos convincentes de por qué no se va a desarrollar alguna funcionalidad. (El equipo de desarrollo puede apoyar a tomar esta decisión)

Definir buenas historias de usuario.

Para los que no saben que es una Historia de Usuario o User Story es básicamente la definición de la funcionalidad que el equipo de desarrollo debe abordar, esta US suele tener la siguiente estructura:

Como

Quiero…

Con el fin…

Sin embargo para mayor entendimiento de los desarrolladores, es útil crearla con mas información por ejemplo añadir lo siguiente:

Términos de aceptación

Información relevante

recuerden que dichas US se deben defender o explicar a los desarrolladores en los Sprint Planning, tengan en cuenta que una US es una tarea relacionada a una Épica, las épicas se suelen “partir” o “dividir” en varias tareas y las tareas tambien pueden ser divididas en sub tareas. Esto lo comento porque un PO debe conocer y entender a 100% el contenido o requerimiento de una Épica para poder trasladar el mismo en un lenguaje técnico o mas especifico a los desarrolladores con la finalidad de que los desarrolladores puedan estimar sus tareas en el sprint planning.

Acordar junto con el equipo scrum una «definición de listo» y «definición de hecho»

Existe los términos DoR y DoD

Definition of Ready(DoR), es una definición que debe acordarse en conjunto con el equipo scrum con la finalidad de saber cuando una épica o US estará lista para ser abordada.

Definition of done, simplemente un acuerdo entre todos los integrantes del equipo scrum para cuando una tarea esté 100% finalizada. aquí puede entrar procesos de validaciones, testers.

David Espina Rincon

Technical Product Owner, Nómada digital, emprendedor y fotógrafo.
Amante de las experiencias sociales y viajes al rededor del mundo.

Deja una respuesta

Translate »