Lo que un Product Owner no es

La gestión ágil de proyectos, sobretodo scrum, ha traído nuevos roles consigo a los cuales no estamos aún habituados. Parlabras como product ownerscrum master nos suenan ya muy familiares aunque sólo sea de verlas en las ofertas de trabajo. Un error muy habitual es intentar hacer una correspondencia mental entre estos roles y otros anteriores para intentar familiarizarnos. Esto es un error. Los nuevos roles no son un renombrado más actual de los anteriores para enmascararlos. Éstos surgen del nuevo enfoque de gestión, no son ni mejores ni peores, son diferentes.

Si bien el término scrum master es el rol más extendido (que no entendido) de la metodología el término product owner no es ni tan conocido ni tan requerido, a pesar de tener mucha importancia dentro del producto.

El product owner no es un jefe de proyecto

Es importante recordar que en un equipo scrum no existe la figura del jefe de proyecto. Ni lo es el product owner ni lo es el scrum master. El equipo scrum es autogestionado, no es controlado por una figura externa que tiene el control de las actividades, tareas y recursos del desarrollo del producto.

El product owner es lo más parecido a un usuario final de producto pero con mucha responsabilidad. Pero sólo en el ámbito funcional, no en el ámbito técnico. Esto quiere decir que el product owner, aunque sea un técnico, no puede imponer cómo implementar las funcionalidades al equipo. Esto, significa lo siguiente:

  • No puede asignar personas a tareas o funcionalidades, esto es responsabilidad del equipo.
  • No es un responsable técnico, no puede imponer cómo se implementarán esas funcionalidades.
  • No puede estimar, su participación en las estimaciones no es más que estar disponible y atento para explicar las funcionalidad y asegurarse de que no haya ninguna duda.
  • No gestiona el avance o desviación de la implementación de las funcionalidades.

Responsabilidades e influencias del product owner

Sin embargo la figura del producto owner es muy importante y, más que estar ligada a una figura de gestión del proyecto de implantación, está más relacionada con un rol de marketing: el jefe de producto (o product manager).

Tiene mucha responsabilidad y aunque no tiene “poder” directo en la implementación de las funcionalidad tiene mucha presencia indirecta en las mismas.

  • El producto es suyo: pensemos en Steve Jobs y el iPhone. Jobs no programaba el iPhone pero estaba muy presente en todo su desarrollo, hasta el punto que hizo cambiar la pantalla porque se podría rayar. Lo tocaba, lo tenía en el bolsillo, lo usaba…
  • Sabe todo de las funcionalidades: el product owner debe saber cómo se usa su producto. Toda la funcionalidad, lo que hace, lo que no hace, cómo se podrían hacer cosas con él para lo que no está diseñado
  • Sabe cómo lo utilizan los usuarios: además tiene el deber de saberlo porque es el representante de los usuarios y el equipo de desarrollo.
  • Sabe cómo desearían usarlo los usuarios: qué es lo que opinan de las funcionalidades, de su línea de evolución, de las necesidades que no cubre y debería, en definitiva tiene todo el feedback de usuario y la evolución del producto.
  • Decide cuáles son los requisitos del producto: qué es lo que tiene que hacer y cómo lo tiene que hacer. Aunque hemos dicho anteriormente que es el equipo quien decide cómo llevar a cabo estas funcionalidades hay que evaluar cual será el impacto para el producto. Para esto el product owner se sirve de los requisitos no funcionales, porque son requisitos.
  • Decide indirectamente el orden de implementación: porque prioriza las historias de usuario. Aunque no es el orden de implementación en sí porque las dependencias técnicas las decide el equipo y, por tanto, su implementación final; la prioridad es una translación de la importa de negocio al equipo de desarrollo.
  • Debe estar al corriente de cualquier matiz, detalle (sea técnico o no), o cualquier cosa que pueda afectar al negocio del producto. Y por tanto servirse de las historias de usuario y requisitos no funcionales para “gestionarlos”.
  • Es el responsable del producto frente a negocio y los usuarios. Debe controlar todos los factores del producto del software. Esto es mucho más que las historias de usuario, y del desarrollo porque el software es mucho más que el código. La documentación, la entrega, el despliegue, está presente en la publicidad, en las satisfacciones de usuario… El producto software es mucho más que el desarrollo del mismo y de sus funcionalidad.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *

Puedes usar las siguientes etiquetas y atributos HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>