El foco del Product Manager está en la visión y la estrategia. El equipo se encarga de la ejecución. Así lo hacen en Facebook, y así lo debería hacer cualquier verdadera empresa de producto.
A la final no me quedó claro quien escribe las HU. En mi pensar es aquel que habla con los stakeholders, y si los que lo hacen Son el PO, el BA y el DM entre ellos debe estar esa tarea. Ellos son los que tienen las ideas claras de que es lo que quiere y necesita el usuario final.
Hola Simón, el artículo es muy interesante y toca un tema importante, pero no estoy de acuerdo con el planteo.
Coincido con Alex: escribir historias de usuario no es "redactar tickets" ni "gestionar proyecto" o "administrar tareas". Es parte de la definición del producto y, como tal, es una de las tareas principales del product manager. Entre otras cosas, porque es responsabilidad del PM priorizar el desarrollo del producto, y esto se hace fundamentalmente controlando el orden de las historias el la pila de producto.
El tuit que citas, de hecho, no dice que Ben Erez no escriba historias de usuario: dice que no escribe tareas ("tasks"), un concepto que en el vocabulario scrum es distinto de "user stories". Es verdad que dice que no está involucrado en los sprints, y se entiende por qué él está contento: la dinámica agile es muy exigente. Pero me parece una evidencia circunstancial, y no creo que algo esté necesariamente bien porque lo haga Facebook.
Como dice Álex, Marty Cagan, que es probablemente el mayor experto en product management, es bastante terminante en cuanto a que ser PO es una de las responsabilidades del PM. Además de tratar el tema en sus dos libros, también escribió un par de artículos en su blog, con muy buenos argumentos basados en la observación del mercado que trabaja:
Cito de este último artículo: "(...) more than a few companies were using the relatively new role of the product owner as an excuse to once again separate “the business person” from the “the person that talks with the developers. This causes serious problems (...) and I absolutely still believe it’s critical to be a single person rather than two".
Dicho esto, te felicito por el trabajo de divulgación que haces en tus artículos, ya que estos temas son cruciales para el desarrollo del product management en nuestro mercado.
quería felicitarte por el artículo, bien escrito y mejor documentado. He hecho me he suscrito a tu lista.
Hay varios puntos de éste con el que no coincido, principalmente por mi punto de partida, como trainer de Scrum.org y el enfoque "Professional Scrum" que defendemos.
En primer lugar, el foco del PO no es únicamente interno (delivery) sino que debería ser también la visión, estrategia y discovery (cuando le dejan). Coincidimos en que el PO es un rol y el PM un trabajo, pero desde Scrum.org defendemos que el PM adquiera el rol de PO. Así lo expliqué en este artículo, y allí apuntaba a otro de Ken Schwaber de hace 10 años donde insistía en el propósito original del rol de PO era que lo ejercieran los PM.
En nuestra (Scrum.org) opinión y experiencia, un PM puede ejercer el rol de PO si delega al equipo la mayoría o todos los detalles de la solución. Pero si está cerca del equipo en el proceso de Discovery, junto con el diseñador y el tech lead, se trabaja mejor tanto en el espacio del problema como de la solución. Esto lo explicamos en el curso Professional Scrum with UX. En cualquier caso, pensamos que el Product Owner NO se limita únicamente al delivery.
Finalmente, las historias de usuario pueden entenderse como tácticas (como USER quiero una FEATURE) pero también como estratégicas (como USER tengo un problema o Job To Be Done). El origen de las historias de usuario son problemas o necesidades que el usuario explicaba directamente al ingeniero, y evitar que alguien (p.e. un analista) "traduzca" una necesidad a una especificació de solución.
De hecho, una historia puede comenzar como la descripción de una necesidad y evolucionar hacia la solución mediante el Discovery. Entedidas así, un PM sí podría/debería escribir historias (pero no su detalle).
No me alargo más, espero que el comentario sea útil.
A la final no me quedó claro quien escribe las HU. En mi pensar es aquel que habla con los stakeholders, y si los que lo hacen Son el PO, el BA y el DM entre ellos debe estar esa tarea. Ellos son los que tienen las ideas claras de que es lo que quiere y necesita el usuario final.
Hola Simón, el artículo es muy interesante y toca un tema importante, pero no estoy de acuerdo con el planteo.
Coincido con Alex: escribir historias de usuario no es "redactar tickets" ni "gestionar proyecto" o "administrar tareas". Es parte de la definición del producto y, como tal, es una de las tareas principales del product manager. Entre otras cosas, porque es responsabilidad del PM priorizar el desarrollo del producto, y esto se hace fundamentalmente controlando el orden de las historias el la pila de producto.
El tuit que citas, de hecho, no dice que Ben Erez no escriba historias de usuario: dice que no escribe tareas ("tasks"), un concepto que en el vocabulario scrum es distinto de "user stories". Es verdad que dice que no está involucrado en los sprints, y se entiende por qué él está contento: la dinámica agile es muy exigente. Pero me parece una evidencia circunstancial, y no creo que algo esté necesariamente bien porque lo haga Facebook.
Como dice Álex, Marty Cagan, que es probablemente el mayor experto en product management, es bastante terminante en cuanto a que ser PO es una de las responsabilidades del PM. Además de tratar el tema en sus dos libros, también escribió un par de artículos en su blog, con muy buenos argumentos basados en la observación del mercado que trabaja:
https://svpg.com/product-manager-vs-product-owner/
https://svpg.com/product-manager-vs-product-owner-revisited/
Cito de este último artículo: "(...) more than a few companies were using the relatively new role of the product owner as an excuse to once again separate “the business person” from the “the person that talks with the developers. This causes serious problems (...) and I absolutely still believe it’s critical to be a single person rather than two".
Dicho esto, te felicito por el trabajo de divulgación que haces en tus artículos, ya que estos temas son cruciales para el desarrollo del product management en nuestro mercado.
Saludos,
Germán
Hola Simón,
quería felicitarte por el artículo, bien escrito y mejor documentado. He hecho me he suscrito a tu lista.
Hay varios puntos de éste con el que no coincido, principalmente por mi punto de partida, como trainer de Scrum.org y el enfoque "Professional Scrum" que defendemos.
En primer lugar, el foco del PO no es únicamente interno (delivery) sino que debería ser también la visión, estrategia y discovery (cuando le dejan). Coincidimos en que el PO es un rol y el PM un trabajo, pero desde Scrum.org defendemos que el PM adquiera el rol de PO. Así lo expliqué en este artículo, y allí apuntaba a otro de Ken Schwaber de hace 10 años donde insistía en el propósito original del rol de PO era que lo ejercieran los PM.
https://www.linkedin.com/posts/alexballarin_marty-cagan-released-the-article-the-cspo-activity-6809182749677649920-pwwK
En nuestra (Scrum.org) opinión y experiencia, un PM puede ejercer el rol de PO si delega al equipo la mayoría o todos los detalles de la solución. Pero si está cerca del equipo en el proceso de Discovery, junto con el diseñador y el tech lead, se trabaja mejor tanto en el espacio del problema como de la solución. Esto lo explicamos en el curso Professional Scrum with UX. En cualquier caso, pensamos que el Product Owner NO se limita únicamente al delivery.
Finalmente, las historias de usuario pueden entenderse como tácticas (como USER quiero una FEATURE) pero también como estratégicas (como USER tengo un problema o Job To Be Done). El origen de las historias de usuario son problemas o necesidades que el usuario explicaba directamente al ingeniero, y evitar que alguien (p.e. un analista) "traduzca" una necesidad a una especificació de solución.
De hecho, una historia puede comenzar como la descripción de una necesidad y evolucionar hacia la solución mediante el Discovery. Entedidas así, un PM sí podría/debería escribir historias (pero no su detalle).
No me alargo más, espero que el comentario sea útil.
Alex Ballarin / ITNOVE.com