Rss Feed Tweeter button Facebook button Linkedin button

subscribe: Posts | Comments | Email

El complicado Rol de Product Owner

0 comments
El complicado Rol de Product Owner

Segun un artículo publicado por la consultora Forrester, el Rol del Product Owner,  es un rol complicado que se tiene que “refactorizar” para ser ampliamente efectivo.

El amplísimo rango de responsabilidades que recaen sobre este nuevo Rol hace muy difícil que todas las funciones que debe desempeñar puedan recaer en una sola persona.Si no se trata de un “superheroe” dificilmente va a poder acometer todo lo que de él se espera.

El artículo clasifica las responsabilidades del PO en tres grandes grupos :

– Deber ser un agente y lider del cambio, lo cual requiere de unas grandes habilidades de comunicación y motivación de todos los stakeholders del negocio afectados por el proyecto, así como del equipo o equipos de desarrollo.

– Debe tener habilidades para la definición de la estrategia del producto y de definición de la visión.

– Debe poseer habilidades relativas a la ejecución  de tipo táctico y entender y comunicar los detalles trabajando con el equipo de desarrollo para conseguir los objetivos definidos en el proyecto.

La dimensión  y el número de actores implicados serán también claros determinantes  en cuanto a la organización del proyecto para el desarrollo de un producto o servicio. Asi pues, nos encontraremos con situaciones en las que un solo  Product Owner puede ser físicamente incapaz de responsabilizarse de todas las cosas que la teoría dice que debe hacer.

 La organización física de la empresa  también será determinante sobre la estructura que se le tenga que dar al proyecto en cuanto a la asignación de los nuevos roles.

-Estructuras organizativas de negocio separadas en ubicaciones diferentes.

-Estructuras organizativas de Sistemas y Tecnología separadas en ubicaciones diferentes.

-Equipos de desarrollo deslocalizados.

 Salvo que el siguiente avance de la tecnología sea la “teletransportación”, un solo Product Owner será incapaz de liderar un proyecto de con esta suerte de estructuras.

Y otro factor determinante es el enfoque de la empresa  y su actividad principal, ya que :

 a) En empresas en las que su actividad principal sea el desarrollo de productos  de software con fines comerciales, o en los que un desarrollo informático propio sea el sustento de su actividad ( ejemplo : centrales de reservas on-line, portales de comercio electrónico, etc)  el rol del   Product Owner y sus responsabilidades, sin ser sencillas, son más claras.

  b) En empresas cuya actividad principal sea otra distinta ( Financiero, Industria , Energia, etc.) con una gran estructura organizativa, tanto si disponen de equipos internos de desarrollo como si subcontratan los proyectos con proveedores de TI, el rol de  Product Owner entendido como el representante del negocio dentro del equipo es difícil de concretar y muy dificil de seleccionar.

En el segundo de los casos, me atrevería a decir que  por encima de las teorías de Agile, es imposible designar y separar a una persona de una Área de negocio para que sea el Product Owner de un proyecto Scrum. Nos encontraremos entonces ante la necesidad de nombrar a un Rol que algunos autores denominan “Product Owner Proxy” que desde TI se encargará de representar los intereses del negocio e intervenir más en el tercer grupo de responsabilidades definidas al comienzo de este artículo :  el planeamiento Táctico de la visión del proyecto hacia el equipo desarrollo , aunque también deberá ser capaz de obtener y compartir la visión estratégica con todos los stakeholders del negocio y de otros grupos de TI afectados por el proyecto.

Aún así, el rol de Product Owner sigue siendo extremadamente complicado, pero las funciones de Marketing, Comercial, Comunicación, etc, que recaerán también en el “superheroe”en el  caso de empresas cuya actividad principal sea el desarrollo de productos de SW comercial, seguiran asignadas a las unidades de Negocio de la organización descargando en parte su ámbito de responsabilidad.

 Por último si el  proyecto tiene una dimensión importante y afecta a gran parte de la empresa,  el modelo Scrum para estos casos tiene detractores debido a una “percepción de NO escalado”. Esto es, se tiene la tendencia a pensar que Scrum funciona en proyectos de tamaño más reducido y con un solo equipo afectado.

Esto es cierto en parte. Para que funcione el escalado se requiere que TI al completo haya adoptado el modelo Agile. El enfoque Top-Down es obligatorio en estos casos , pero una vez que se haya obrado la transformación, con todo lo que conlleva el cambio de paradigma en cuanto a comunicación, formación y coaching , hay modelos que nos permitirán adoptar ampliamente un enfoque de desarrollo Scrum  en grandes proyectos con varios equipos afectados.

 En un siguiente artículo expondré mi visión sobre como se podría instrumentar, bajo la premisa anterior un desarrollo de un proyecto cuyo objetivo sea la creación de un Broker-Online para una entidad financiera con multiples areas de negocio afectadas, multitud de equipos de TI internos involucrados y otras entidades externas participantes.

Leave a Reply

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


*