por Vanessa Amaya

El impacto que provoca la falta de entendimiento temprano de los requerimientos es enorme, siempre lo ha sido por lo que todos los que hemos padecido el trabajar en silos con perfiles de negocio brincamos de emoción cuando llega Scrum y nos presenta el rol de Product Owner como PARTE del equipo, con DISPONIBILIDAD para el equipo. Leer esto hasta sonaba como “el poema esperado”:

El Product Owner es el responsable de maximizar el valor del producto y del trabajo del equipo de desarrollo a través de la gestión y priorización efectivas de la lista de producto (Product Backlog) y de expresar sus elementos claramente al equipo.

Este rol trae todo para hacer sentido a:

• Soluciones de fondo para evitar malos entendidos a tiempo y con bajo impacto.

• Romper los silos que han dividido a quienes piden y a quienes realizan.

• Soluciones a las quejas del negocio porque no se entrega lo que se espera cuando se necesita.

La definición es clara, es directa. La confusión y la ambigüedad es el resultado de la resistencia el cambio y de los esfuerzos entorno a trabajar con marcos ágiles que no se toman en serio.

Confusión: Product Owner vs Business Analysis

Es impresionante la cantidad de nombres de roles que surgen en todas las empresas, junto con cada rol viene una expectativa, el problema es cuando solo hacemos el bautizo pero no hacemos la formación del rol, es decir, nos limitamos a decir “y ahora tu rol es….” y esperamos que por arte de magia la persona se comporte y logre lo que se espera.

Una confusión muy clásica es que en las empresas donde ya había roles Business Analysis (Analista de Negocio) se determinó que “ahora son Product Owners”. Un Product Owner para ejercer su rol debe de incluir prácticas de Business Analysis, pero una diferencia fundamental es el alcance del rol respecto a decisiones y priorización, porque un Business Analysis provee información que otros toman para decidir y priorizar pero NO tiene empoderamiento para tomar decisiones y la característica más importante del Product Owner es el empoderamiento para decir, sin pedir permisos: “esto si”, “esto no”, “esto después”.

Ahora bien, si al re-bautizar a la gente que hace Business Analysis se les empodera, está bien, será un Product Owner, si no, será un Business Analyst con otro nombre y sin facultades de ejercer el rol como se debe.

Y también se vale que el Product Owner cuente con el apoyo de un Business Analyst, sobre todo en el caso que explicaré a continuación.

Ambigüedad: Si es Product Owner pero no tiene tiempo de serlo.

La visión de negocio lo da la experiencia y entre mayor experiencia se tiene dentro de una empresa, no solo crece la visión sino las habilidades para mantener, crear y descubrir nuevos negocios y con ello, la reputación suficiente internamente para poder tomar decisiones de peso para la empresa y de valor para los clientes.

Ser Product Owner implica otros conocimientos y habilidades relacionadas a requerimientos (identificación, redacción, comunicación, dimensionamiento, independencia, priorización, entre otros) así que si esa persona no tiene esos conocimientos y habilidades, es vital desarrollarlas porque la mayoría del tiempo se van a estar haciendo acciones con respecto a eso, y ahí viene el problema: Resulta que se seleccionan personas con visión de negocio y empoderamiento suficiente, pero sin disponibilidad de tiempo ni para formarse en el rol, nuevos conocimientos y ser parte de un equipo.

En el mejor de los casos delegan a alguien más, en el peor de los casos no se delega a nadie y se queda el equipo con un hueco enorme, el mismo hueco de siempre respecto a entendimiento y empatía con el negocio.

Hay que considerar también, que cuando delegan, la persona a la que delegan se convierte en cuello de botella si no se le da empoderamiento para decidir ni se le invierte tiempo para formarlo con criterios para que crezca su visión de negocio. El Product Owner que no tenga tiempo de serlo, debería ser mentor de alguien que si pueda serlo y trabajar en esa transición.

Conclusiones

• Para decir que estamos trabajando bajo Scrum, si o si deben de tenerse implementados los roles adecuadamente, no hacerlo así, implica triple esfuerzo y mucha frustración en las personas y cuando queramos hacer las cosas en serio e implementar los roles bien, habremos aumentado la resistencia al cambio.

• Si alguien porta el rol de Product Owner debe de tener capacidad y poder de decisión, visión de negocio, habilidad para escribir y transmitir Historias de Usuario para el equipo e involucramiento con el equipo técnico, realmente sentirse parte del equipo.

• Nadie nace siendo Product Owner, es un rol nuevo por lo tanto, la formación es un pilar fundamental para que la implementación de este rol de alto valor realmente funcione.