En el día a día y en muchas empresas tenemos el rol de Dueño del Producto (Product Owner) con otros nombres como: Gestor de proyecto de negocio o Gerente de proyecto. Aunque lo que vemos más seguido en las empresas es que este rol es compartido entre todas las otras funciones diarias de una persona quien ya tiene un rol “principal”, lo que hace que este rol pueda lograr su máximo valor.
Un Dueño de Proyecto no puede ser un Analista Funcional, dado que por más que este conozca mucho del negocio, la mayoría de las veces no tiene la capacidad de tomar decisiones sobre el producto/proyecto, en comparación a los roles anteriores.
El Dueño de Producto es la persona empoderada por la gerencia, capaz de ver más allá de lo evidente. ¿Qué? Sí, él es capaz de visionar el producto final, es quien conoce el negocio mejor que nadie, es quien podrá convertir los requerimientos en dinero o en algún beneficio para la empresa. Además, será quien negocie directamente con los Stakeholder (todos aquellos que hicieron sus requerimientos), los tiempos, los costos y las prioridades.
Ok Johana, pero ¿realmente que haría en su día a día como para crear este rol y dárselo a alguien a tiempo completo? Veámoslo:
¿Qué hace un Dueño de Producto?
-
- Primero, dependiendo de la organización, se encargará de centralizar los requerimientos (pedidos) de la organización o de un área específica de la organización. El maneja un listado de requerimientos en donde se encuentran los pedidos realizados desde aquellos hechos por la gerencia hasta los hechos por el practicante (pre-aprobados por su jefatura correspondiente).
-
- Luego, se encarga de evaluar si los requerimientos realmente van a generar valor al negocio, es decir, si con el tiempo existirá un retorno de inversión monetario, si tendrá algún beneficio para la empresa o si son compromisos u obligaciones necesarias de hacerse por ley.
Para este punto, él se reunirá una o las veces necesarias con las jefaturas y con los que considere correspondiente para entender el qué, el porqué y el cuándo necesitan el requerimiento y si realmente es necesario hacerse (evaluará la factibilidad de cada uno).
- Luego, se encarga de evaluar si los requerimientos realmente van a generar valor al negocio, es decir, si con el tiempo existirá un retorno de inversión monetario, si tendrá algún beneficio para la empresa o si son compromisos u obligaciones necesarias de hacerse por ley.
-
- Siendo él quien recopila está información, el Dueño de Producto conoce los detalles de cada requerimiento y con esto crea las Historias de Usuario o Especificaciones de Requerimiento en lenguaje textual, como él entiende el pedido en un Listado de Requerimientos o Product Backlog en forma priorizada, lo que da más valor al negocio al inicio.
-
- Se reúne con el equipo de Desarrollo para mostrarle la lista y que le indiquen (el Equipo de Desarrollo) en cuanto tiempo estarán listos los primeros requerimientos e informar a los Stakeholder los acuerdos tomados.
-
- Él y solo él es quien administra y controla su listado de requerimientos (Product Backlog).
- Además, es quien clarifica los requerimientos y resuelve las dudas con respecto a los requerimientos que pueda realizar el equipo de desarrollo. Por ello, la comunicación debe ser totalmente transparente y abierta.
Entendido quién y qué hace un Dueño de Producto, debo confesar que me gusta mucho este rol. El problema que suelo encontrar frecuentemente es que muchas empresas creen que este rol le pertenece al área de TI o de Sistemas. Y a veces por más de tratar de explicarles la importancia del rol, las respuestas suelen ser siempre las mismas:
- El área de negocios no tiene tiempo para hacer estas labores, que lo haga Sistemas.
- Nosotros estamos concentrados en ganar dinero, no en estar haciendo requerimientos.
- Para eso tenemos un equipo de sistemas, que lo vean ellos, y si tienen dudas que pregunten.
Y es allí donde empiezan los problemas. Un equipo de desarrollo sin tener como parte fundamental al Dueño de Producto tarde o temprano terminará fallando, esto es por la carencias de conocimiento del negocio y la toma de decisiones que se necesita realizar.
Una empresa que no apueste por crear este rol tenga el nombre que tenga, no podrá sacarle el máximo provecho a sus requerimientos y por ende a sus sistemas finales. Yo les pediría que apuesten.
Si tienes preguntas cómo: ¿Por dónde empiezo a formarme como Product Owner? ¿Quienes son los Product Owner y cómo puedo llegar a ser uno de ellos?… y sobre todo, si buscas respuestas a estas y otras preguntas, te esperamos en Product Owner Fundamentals, dale clic aquí y entérate de todos los detalles. ¡Nos vemos el 8!
Saludos.
Johana Chuquino
Johana Chuquino