¿Buscas nuestro logo?
Aquí te dejamos una copia, pero si necesitas más opciones o quieres conocer más, visita nuestra área de marca.
¿Buscas nuestro logo?
Aquí te dejamos una copia, pero si necesitas más opciones o quieres conocer más, visita nuestra área de marca.
transformacion-organizacional-rev
Raúl Alonso Sáez Hace 5 días Cargando comentarios…
«Un producto, un Product Backlog, un Product Owner». Algo tan sencillo en apariencia tiene muchísimos matices en el mundo real. Y es que Product Owners hay muchos y de muy diversa índole, e incluso en ocasiones… ¡ninguno!
De hecho, ya uno de los fundadores de Scrum lo contempló en su origen: «En ausencia del Product Owner (...), se requiere que el Scrum Master (...) actúe en su lugar». Esto es, ni más ni menos, lo que Ken Schwaber decía en Agile Project Management with Scrum allá por 2004.
Además, tal y como se apunta en Scrum Reboot, mientras que para el rol de Scrum Master se especifican unos profundos conocimientos no solo de Scrum, sino de Agile, así como de un completo repertorio de técnicas y herramientas, para el rol de Product Owner parecen relajarse un tanto las exigencias. Tanto es así, que desde la propia Guía Scrum se apunta que es labor del Scrum Master «ayudar al Product Owner a encontrar técnicas para gestionar el Product Backlog», o incluso que el PO puede pedir al equipo de desarrollo ordenar y gestionar el backlog en su lugar.
¿Cómo es esto posible en un rol tan clave? Es decir, ¿cómo en un ideal, que sería lo que está sobre el papel, un Scrum Master puede y debe ayudar a un PO a ejercer su propio rol o incluso este delegue parte de sus funciones?
Estos pliegues denotan lo que desde el principio se ha venido experimentando en una gran parte de los proyectos: que el rol ha sido históricamente desempeñado por personas expertas en su negocio, absorbiendo sus competencias sin total dedicación y, por tanto, con tiempo limitado en el crecimiento en torno a él, disponibilidad y, en ocasiones más flagrantes, suficiente conocimiento.
Está claro, como apunta Lyssa Adkins, que cualquier tema relacionado con la dirección, calendario y presupuesto de un producto debería recaer en el ámbito del Product Owner, que es quien por definición toma las decisiones de negocio que impactan en los aspectos del producto.
Pero, en muchos casos, a lo que llamamos PO no es a una persona con potestad para definir la estrategia e influenciar con su manera de trabajar al resto de la compañía, ni siquiera con poder de decisión. Porque, como especifica Melissa Perri, Product Owner es un rol que se desarrolla en un equipo Scrum, mientras que Product Manager es la función a la que nos estamos refiriendo. Y ambos perfiles suelen estar plenamente diferenciados. De hecho, como ya hemos visto, las competencias del rol de Product Owner pueden suplirse desde dentro del propio equipo de desarrollo.
Sea como fuere, a la hora de la verdad lo más relevante es que las prioridades de negocio lleguen claras y ordenadas. Que alguien sea capaz de transmitirlas (más que de plasmarlas) para que el trabajo que se entregue aporte el valor de negocio esperado, sobre todo cuando en muchísimas ocasiones lo que cubrimos es un servicio.
¿Puede ser esa figura el Scrum Master, entendiendo por Scrum Master no tanto la persona que ejerce el rol en Scrum sino la que lidera la gestión Agile de un proyecto? Lo cierto es que no parece que haya motivos de peso para no poder compaginarlo, más allá de que el tiempo exigido seguramente impida el correcto desempeño de ambas funciones, de la misma manera que también se desaconseja seguir ligado al desarrollo en caso de proceder de la rama técnica.
En Paradigma nos dimos cuenta hace tiempo de la necesidad de reforzar la parte más enfocada al negocio en los proyectos y, de hecho, conforma uno de los dominios de Polaris, nuestra hoja de ruta en la gestión de proyectos.
Por ejemplo, en varios proyectos que hemos realizado, observamos que la estructura de negocio, por diversas razones, ponía mayor foco en la estrategia del producto: había una persona responsable de área que tenía un dominio avanzado sobre el producto y el negocio en directa interlocución con los stakeholders. Sería el equivalente al rol de Product Manager. Sin embargo, el día a día de esas personas les dificulta aterrizar las funcionalidades emergentes, definir prioridades, ayudar en la entrega, así como identificar tareas de mejora o incluso de deuda técnica. Por ello, siempre y cuando percibimos la necesidad, incorporamos una figura que quizá no sepa tanto del negocio específico, pero sí de maximización del valor de negocio.
Es por todo esto que entra a calentar la figura del Product Owner “Proxy” para, precisamente, llevar a cabo las labores necesarias a las que este no llega. Una figura que, al igual que el Scrum Master, destaque como una pieza importante sin ser un mero “analista agile” (crucial función, por otro lado) ni un mayordomo del equipo y el cliente.
Pon un Product Owner en tu vida y, si no tienes tiempo, confía en Paradigma para que mediante el rol de Product Owner Proxy te ayudemos a maximizar la entrega y valor de tu producto.
Los comentarios serán moderados. Serán visibles si aportan un argumento constructivo. Si no estás de acuerdo con algún punto, por favor, muestra tus opiniones de manera educada.
Cuéntanos qué te parece.