Contacto +34 93 737 62 70
           
Contacto +34 93 737 62 70
P11_proxy.png

 

En este artículo revisamos que es un Proxy Prodict Owner, porque suele darse este rol en las organizaciones que adoptan la agilidad, y finalmente algunas propuestas para superar este rol y conseguir un Product Owner completo.

¿Qué es un Proxy PO?

Un Proxy Product Owner (Proxy en adelante) es un rol que actúa como intermediario entre las personas que toman las decisiones sobre el producto y el equipo de desarrollo. Adopta parte de las responsabilidades que habitualmente desempeña un Product Owner (PO en adelante) como:

  • Recoger las necesidades de los clientes
  • Estructurar y priorizar el Backlog de Producto
  • Negociar con el equipo la realización del Backlog
  • Validar cuando el producto está listo para ser entregado a los clientes

Aún así, el Proxy es una versión incompleta de un PO auténtico, hecho que le resta mucha efectividad y dificulta la misión del PO, maximizar el valor sobre el producto. Las principales carencias de un Proxy suelen ser:

  • No es el dueño del producto, por lo que no toma las decisiones fundamentales ni suele ser responsable de su resultado.
  • No controla el presupuesto.
  • A veces no define la visión ni la estrategia del producto.
  • No tiene la última palabra sobre los ítems que forman parte del producto.

Así pues, es una mejora respecto a no tener un PO, pero tener este rol conduce a resultados muy mejorables respecto al valor del producto, especialmente en organizaciones complejas con múltiples actores interesados.

 

Las organizaciones funcionales y el Proxy PO

Érase una vez una organización que agrupaba a sus miembros según el tipo de trabajo que realizan y sus capacidades. Estas agrupaciones reciben nombres como áreas de negocio, los departamentos o grupos de trabajo, y es el tipo de organización de las empresas más frecuente, y de largo, siendo una herencia del Management Científico, o Taylorismo.

Una organización funcional (departamental) suele tener a sus miembros divididos entre «Negocio» e «Informática», y dentro de estas áreas existen otros departamentos, p.e. márketing/RR.HH/ventas y desarrollo/sistemas/calidad respectivamente. En el gobierno IT tradicional, suele ser un responsable de cliente (Business Relationship Manager o Business Partner en inglés) quien gestiona la demanda de necesidades del negocio que debe realizar «Informática», y un jefe de proyecto quien lidera la realización de estas demandas.

Cuando se trata de adoptar Scrum, si no se tiene un buen entendimiento del rol de PO, suele identificarse este rol como un miembro de informática que debe continuar la interlocución entre el «Negocio» y el equipo de desarrollo. Además, se piensa frecuentemente que debe ocuparse de analizar, estructurar (e incluso definir las pruebas de aceptación) de las demandas. Esto encaja muy bien con el rol de jefe de proyecto, que además no suele verse a si mismo como Developer o Scrum Master, por lo que frecuentemente adoptan este rol de Proxy. Por otro lado, si se le plantea a los responsables de negocio, que serían los PO ideales, que deben estar dedicados a actividades funcionales como la gestión detallada del backlog y los requisitos, es lógico que piensen que supone un volumen de trabajo que hace incompatible ser el PO con sus actividades actuales. Así pues, tenemos todos los ingredientes para la receta «Proxy Product Owner».

P11_proxy.png

 

Propuestas para conseguir un auténtico PO

En primer lugar, es necesario que las organizaciones y los Scrum Master (o Agile Coaches) que las asesoran, entiendan bien el rol de Product Owner. Además, y lo más difícil, deben entender el severo rediseño organizativo que esto supone, integrando en Equipos Scrum autónomos y autosuficientes a personas de «Negocio» (p.e. el PO) y otros roles desperdigados entre diferentes grupos de IT (p.e. desarrolladores, testers, analistas, etc.). Sin esto, la adopción de Scrum comienza con mal pie.

En segundo lugar, es importante que se entienda que un Development Team auténtico debe ser autosuficiente, y por ello se le puede delegar perfectamente las actividades de más detalle de la gestión del backlog, como su estructuración, definición de los ítems e incluso la definición de criterios de aceptación. Esto debe hacerse basándose en la transparencia, la confianza y el principo que el Product Owner debe estar informado y tomar las decisiones más importantes que afecten al valor del producto.

En tercer y último lugar, es necesario encontrar un buen encaje a los jefes de proyecto tradicionales donde éstos se encuentren cómodos. Si estos son expertos en gestión de equipo, quien mejor que ellos para entrar dentro del Development Team y ayudar a los demás miembros a desarrollar esta capacidad de gestión, teniendo claro desde el primer momento que debe fomentarse la autoorganización y que su rol no es el de líder de equipo.

¡Si has llegado hasta aquí, comparte este artículo!

¿Podemos ofrecerte más información?

Newsletter mensual

Cada mes enviamos una newsletter a más de 1.000 personas con contenido interesante que hemos encontrado en Internet, artículos nuestros y nuestras novedades. Queremos ofrecer contenido de calidad y no saturarte con muchos correos.

Formulario de contacto

Si crees que podemos ayudarte con alguna duda o necesidad de soporte, no dudes en contactar con nosotros. Estaremos encantados de ayudar.

Ir arriba

Newsletter mensual

Un boletín mensual. Respetamos tu privacidad.