La histórica separación entre negocio y desarrollo y por qué es tan importante el Product Owner

De entre muchas cosas que han acompañado y caracterizado, de siempre, la creación de negocios basados en tecnología, una de ellas, de muchas, ha sido la «gestión» de la separación entre la gente de Negocio y la gente Técnica, los equipos de creación de productos.
Desde aquellos ancestrales tiempos de las llamadas «Especificaciones de Requisitos», que intentaban, documentalmente, trasladar, y ser la interfaz, las ideas de la gente de negocio a la gente que tenía que crear los productos, hasta estos tiempos más Ágiles, en los que la estrategia es que esa unión no se base tanto en el pdf (Documentar tiene un coste y un muy probable gasto (desperdicio)) y se base más en que fisicamente, o lógicamente, todos los roles necesarios para la creación del producto (incluido negocio) estén juntos, dentro del llamado equipo y que así las ideas pasen de una cabeza a otra más rápidamente y con menos errores de interpretación (máximo valor y mínimo desperdicio).

En estos tiempos ágiles, y teniendo en cuenta que la agilidad ya tiene sus muchos años, diferentes frameworks pusieron de moda que el rol de negocio se establecería dentro de los equipos de creación, junto a ellos (lógica o físicamente). El equipo puede estar distribuido, pero existe la entidad equipo y el sentimiento de que alguien de negocio es parte de él.
En eXtreme Programming (uno de los modelos Ágiles más importante, aunque mucho menos famoso que Scrum) a ese rol de negocio cerca de los equipos lo llamaban Cliente (así, a secas) y en Scrum Product Owner, nombre que, finalmente, la mayoría de empresas, han tomado (añadiéndole las necesarias adaptaciones del antiguo «Cliente» de eXtreme Programming, como las historias de usuario, etc.).
Hasta aquí lo teórico porque… ¿qué es lo que realmente tenemos en la mayoría de sitios? Bueno, como cada uno cuenta la realidad que vive, la mía es que el Product Owner sigue siendo el punto débil de un montón de intentos de «transformación» ágil (y por ello que el primer curso de la nueva plataforma de formación online de 233 es sobre el Product Owner, ojo que en breve termina el early del 25% de descuento, con el código 31EneDescuentoLanzamientoPO) .

Romper los silos (como te dibujaba en aquel post, y te habré contado en otros tantos), no es nada fácil. Aún, aunque parezca increíble, sufrimos la necesidad de que alguien, con conocimientos de negocio, dedique el 100% de su tiempo a detallar, al menor nivel de detalle, las necesidades de negocio a la gente de creación, la que debe incorporar esas necesidades al producto (si alguien de negocio no lo hace… el equipo técnico acabará teniendo que hacerlo), a negociar con los llamados Stakeholders qué va primero, qué va después y qué no irá. Así, sólo por resumir algunas de las necesidades más importantes que debe tratar un Product Owner.
De nuevo, lo que me encuentro mucho es que aún hay intentos de «ser ágiles» (extrapolable a intentos de trabajar mejor) que aún se sorprenden cuándo escuchan que debe haber un Product Owner, ejerciendo como tal, o, mejor dicho, cuándo escuchan QUÉ debe hacer un Product Owner.
Que valga este post para concienciarte de que el Product Owner es una pieza esencial, no la dejes de cuidar.
Te dejo algunos post relacionados sobre este tema, que da para mucho, y para mucho más que un post:
– 7 responsabilidades vitales de un product owner (año 2013)
– Interiorizando el significado del Dual-Track y que un Sprint Review no es para el Product Owner
– ¿Cuantos Product Owner puede tener un equipo?