Product Owner Alias PO alias El que sabe lo que quiere

Últimamente estoy viendo muchos blog hablando de esta figura tan importante en Scrum, “ El PRODUCT OWNER” y sobre la que se sustenta una gran parte del existo del proyecto.

No obstante, hay que saber bien de quien se trata para saber de su importancia.

La Teoría:

Como bien indica el primer el punto es una teoría que en pocos sitios se cumple y que queda desvirtuada incluso no significando nada.

La teoría dice que es la persona que sabe lo que quieren los usuarios del sistema y las prioridades de ellos y tiene el conocimiento y habilidades para validar el desarrollo realizado. En muchos sitios debido a esta exigencia el product Owner es una figura que aporta el cliente.

Como funciones principales podemos definir las siguientes:

• Tener claro los requisitos y necesidades del producto o proyecto

• Definir las historias de usuario de forma clara

• Fijar criterios de aceptación de cada historia de usuario

• Aclarar las dudas del equipo y dividir historias cuando estas sean demasiado grandes

• Ordenar y priorizar las historias de usuarios

• Definir un minimo del producto viable o necesario

• Accesible y disponible para el equipo

• No debe dar ordenes al equipo

• Maximo responsable sobre lo que se debe hacer y de las decisiones tomadas.

La Realidad:

Esta realidad no es absoluta sino que esto es lo que ocurre bastantes veces en los proyectos de diferentes empresas.

Iniciamos diciendo que muchas empress han implantado Scrum para el trabajo en equipo en los proyectos con el problema que existe de que hacer con la persona que tenian de Jefe de proyecto, de comercial, de analisis y otros multiples perfiles.

En este caso nos vamos a centrar en lo que ocurre con el perfil de product Owner. A primera vista lo que hacen las empress es adjudicar este papel al responsable del proyecto, coordinador u otros de perfil similar.

Primer error. El responsable del proyecto no tiene por que saber los requisitos o definir que es lo que quiere el usuario, por lo que no sabra abrir esas historias de usuarios.

Segundo error: el responsable manda en el equipo por lo que una de sus funciones es no mandar, ser un miembro más del equipo.

Tercer error: en algunos sitios no es nada accesible y menos si es un coordinador de programa que lleva 15 o 20 proyectos. Cierto es que decide sin embargo imponiendo su logica o necesidades y no la de los usuarios que es de lo que se trata.

Muchos estaréis pensando, Y que hacemos con esta gente donde encajan entonces. La teoría es que el equipo se gestiona solo y tienen a un Scrum Master para realizar cierta gestión del equipo, no obstante este tampoco sería el papel del responsable del proyecto.

El responsable queda como una persona más del proyecto que en este caso ira analizando como va el proyecto desde otros puntos de vista. Retrasos que se lleven, ajustes, gestión de recursos y otras muchas gestiones que se puede encargar como de los proveedores para que las cosas esten a tiempo, vacaciones, gestiones con el cliente y el Product Owner.

¿Qué hacemos entonces con este perfil?

Si el cliente no se hace cargo de la metodología aúnque te exija que trabajes con ella(De esto hablare en otro Post) lo más conveniente es que esta figura sea un consultor con experiencia en el sector del cliente y que este en contacto con los usuarios o bien el antiguo analista de otras metodologías que es el que antes definia los requisitos y sabia tomar las notas de los que necesita el usuarios y las plasmaba en documento para su desarrollo.

Ojo: Requisitos no es igual a Historia de usuario.

Espero que este primer Post técnico hay sido de vuestro agrado.

#ProductOwner #Scrum #Gestiónequipos