« Product Owner vs Product Manager » : différence entre les versions

De Wiki Agile
Aller à la navigation Aller à la recherche
Aucun résumé des modifications
Aucun résumé des modifications
 
(8 versions intermédiaires par le même utilisateur non affichées)
Ligne 1 : Ligne 1 :
[[Category: Portail Product Owner]]
[[Category: Portail Product Owner]]
<div id="content_view" class="wiki" style="display: block"><span class="s1">Auteur : [https://twitter.com/jmilunsky Jack Milunsky]</span><br /> <span class="s1">Source : [http://agilesoftwaredevelopment.com/blog/jackmilunsky/product-owner-vs-product-manager “Product Owner vs Product Manager“]</span><br /> <span class="s1">Date : 2009</span><br />
[[Category: Rôle du Product Owner]]
[[Category: Rôle du Product Manager]]
Auteur : [https://twitter.com/jmilunsky Jack Milunsky]<br />
Source : [http://agilesoftwaredevelopment.com/blog/jackmilunsky/product-owner-vs-product-manager “Product Owner vs Product Manager“]<br />
Date : 2009<br />
----
----
<span class="s1">Traducteur : Fabrice Aimetti</span><br /> <span class="s1">Date : 10/11/2009</span><br />
Traducteur : Fabrice Aimetti<br />
Date : 10/11/2009<br />
----
----
<span class="s1">Traduction :</span><br /> <br />  
Traduction :<br />


==Introduction==
==Introduction==
 
A la lecture d'un récent message sur les forums de Yahoo, je constate qu'il semble y avoir une confusion sur les différences entre ces deux rôles. Des questions comme : est-ce que ces deux rôles empiètent l'un sur l'autre ? le Product Manager peut-il assumer les responsabilités du Product Owner ? quelles sont les missions spécifiques propres à chacun de ces rôles ? et ainsi de suite...<br /> <br />  Il y a eu une très bonne discussion sur ce sujet sur le groupe Yahoo "Scrum Development" et certains points ont été très bien traités. Donc, je vais essayer de récapituler cela pour vous dans ce billet, et bien sûr y ajouter ma touche personnelle.<br /> <br />  Je pense que les fondateurs de Scrum ont volontairement choisi un titre différent. Ils auraient facilement pu garder le même titre. Mais je pense qu'il y avait de bonnes raisons pour cela. Et c'est pourquoi le PO a un ensemble spécifique de tâches dédiées à ce rôle dans Scrum.<br />
A la lecture d'un récent message sur les forums de Yahoo, je constate qu'il semble y avoir une confusion sur les différences entre ces deux rôles. Des questions comme : est-ce que ces deux rôles empiètent l'un sur l'autre ? le Product Manager peut-il assumer les responsabilités du Product Owner ? quelles sont les missions spécifiques propres à chacun de ces rôles ? et ainsi de suite...<br /> <br />  Il y a eu une très bonne discussion sur ce sujet sur le groupe Yahoo "Scrum Development" et certains points ont été très bien traités. Donc, je vais essayer de récapituler cela pour vous dans ce billet, et bien sûr y ajouter ma touche personnelle.<br /> <br />  Je pense que les fondateurs de Scrum ont volontairement choisi un titre différent. Ils auraient facilement pu garder le même titre. Mais je pense qu'il y avait de bonnes raisons pour cela. Et c'est pourquoi le PO a un ensemble spécifique de tâches dédiées à ce rôle dans Scrum.<br /> <br />  


==Comment leurs rôles diffèrent-ils?==
==Comment leurs rôles diffèrent-ils?==
 
D'abord et avant tout, le PO définit les priorités pour l'équipe de développement. Cela se fait via le product backlog. Une entreprise a la capacité de transformer certaines exigences en un code opérationnel. La façon dont cette capacité est utilisée, est entièrement entre les mains du PO.<br /> <br />  Pour que le PO puisse le faire, il a besoin de disposer d'une vue globale. Que le PO obtienne effectivement cette information à partir d'autres rôles ou qu'il l'obtienne par lui-même dépend de l'organisation de l'entreprise.<br /> <br />  Une fois qu'il a bien compris le contexte dans son ensemble, le PO doit exécuter quelques tâches supplémentaires spécifiques (pas nécessairement formellement définie d'ailleurs) :
D'abord et avant tout, le PO définit les priorités pour l'équipe de développement. Cela se fait via le product backlog. Une entreprise a la capacité de transformer certaines exigences en un code opérationnel. La façon dont cette capacité est utilisée, est entièrement entre les mains du PO.<br /> <br />  Pour que le PO puisse le faire, il a besoin de disposer d'une vue globale. Que le PO obtienne effectivement cette information à partir d'autres rôles ou qu'il l'obtienne par lui-même dépend de l'organisation de l'entreprise.<br /> <br />  Une fois qu'il a bien compris le contexte dans son ensemble, le PO doit exécuter quelques tâches supplémentaires spécifiques (pas nécessairement formellement définie d'ailleurs) :<br /> <br />
 
# <span style="line-height: 1.5">Communiquer la vision du produit à l'équipe</span>
# <span style="line-height: 1.5">Communiquer la vision du produit à l'équipe</span>
# <span style="line-height: 1.5">Définir les objectifs au début de chaque sprint</span>
# <span style="line-height: 1.5">Définir les objectifs au début de chaque sprint</span>
Ligne 20 : Ligne 22 :
# <span style="line-height: 1.5">Être capable de prioriser les user stories et être en mesure de négocier / collaborer sur les priorités avec l'équipe. Négocier les priorités se produit lorsqu'après avoir pris les user stories de plus haute priorité en haut du backlog, il reste une certaine capacité non suffisante pour traiter la user story suivante dans son entier. Dans ce cas, une user story de moindre priorité (mais de plus petite taille) peut être sélectionnée.</span>
# <span style="line-height: 1.5">Être capable de prioriser les user stories et être en mesure de négocier / collaborer sur les priorités avec l'équipe. Négocier les priorités se produit lorsqu'après avoir pris les user stories de plus haute priorité en haut du backlog, il reste une certaine capacité non suffisante pour traiter la user story suivante dans son entier. Dans ce cas, une user story de moindre priorité (mais de plus petite taille) peut être sélectionnée.</span>
# <span style="line-height: 1.5">Doit être disponible lors de toutes les occasions où l'on inspecte & adapte afin de répondre aux questions et aider à guider l'équipe de façon très concrète.</span>
# <span style="line-height: 1.5">Doit être disponible lors de toutes les occasions où l'on inspecte & adapte afin de répondre aux questions et aider à guider l'équipe de façon très concrète.</span>
<br />  Les Product Managers doivent d'autre part être capables de faire tout un tas d'autres choses, y compris mais sans s'y limiter :<br /> <br />
<br />  Les Product Managers doivent d'autre part être capables de faire tout un tas d'autres choses, y compris mais sans s'y limiter :
 
# <span style="line-height: 1.5">Définir les stratégies de marketing et la communication marketing</span>
# <span style="line-height: 1.5">Définir les stratégies de marketing et la communication marketing</span>
# <span style="line-height: 1.5">Les stratégies de tarification</span>
# <span style="line-height: 1.5">Les stratégies de tarification</span>
# <span style="line-height: 1.5">Comprendre le positionnement du produit sur le marché</span>
# <span style="line-height: 1.5">Comprendre le positionnement du produit sur le marché</span>
# <span style="line-height: 1.5">Faire une analyse de la concurrence</span>
# <span style="line-height: 1.5">Faire une analyse de la concurrence</span>
<br />
 
===Quelques citations du forum qui valent le coup d'être répétées ici===
==Quelques citations du forum qui valent le coup d'être répétées ici==
<br /> ''"Scrum n'impose pas de responsabilité au-delà de celle d'optimiser le développement pour assurer la réussite de l'entreprise."'' (Anonyme)<br /> <br /> ''"Le rôle du Product Owner est, d'autre part, de vraiment représenter le côté métier et de travailler avec l'équipe pour optimiser la livraison du produit complet."'' (Greg)<br /> <br />  La meilleure...<br /> <br /> ''"Le rôle du Product Owner est un rôle véritablement nouveau et perturbateur pour la plupart des organisations, puisqu'il ne s'intègre pas facilement dans les rôles et les structures existantes."'' (Roman)<br /> <br />  En résumé, selon votre situation, les rôles de PM et de PO seront tenues par la même personne, par un groupe de personnes ou par des personnes différentes - et franchement, je m'en soucie peu. Tant qu'il y a une personne pour assurer la mission de PO et les responsabilités telles que définies dans les 6 points ci-dessus, alors tout roule d'un point de vue Scrum.<br /> <br />
''"Scrum n'impose pas de responsabilité au-delà de celle d'optimiser le développement pour assurer la réussite de l'entreprise."'' (Anonyme)<br /> <br /> ''"Le rôle du Product Owner est, d'autre part, de vraiment représenter le côté métier et de travailler avec l'équipe pour optimiser la livraison du produit complet."'' (Greg)<br /> <br />  La meilleure...<br /> <br /> ''"Le rôle du Product Owner est un rôle véritablement nouveau et perturbateur pour la plupart des organisations, puisqu'il ne s'intègre pas facilement dans les rôles et les structures existantes."'' (Roman)<br /> <br />  En résumé, selon votre situation, les rôles de PM et de PO seront tenues par la même personne, par un groupe de personnes ou par des personnes différentes - et franchement, je m'en soucie peu. Tant qu'il y a une personne pour assurer la mission de PO et les responsabilités telles que définies dans les 6 points ci-dessus, alors tout roule d'un point de vue Scrum.

Dernière version du 10 septembre 2024 à 12:11

Auteur : Jack Milunsky
Source : “Product Owner vs Product Manager“
Date : 2009


Traducteur : Fabrice Aimetti
Date : 10/11/2009


Traduction :

Introduction

A la lecture d'un récent message sur les forums de Yahoo, je constate qu'il semble y avoir une confusion sur les différences entre ces deux rôles. Des questions comme : est-ce que ces deux rôles empiètent l'un sur l'autre ? le Product Manager peut-il assumer les responsabilités du Product Owner ? quelles sont les missions spécifiques propres à chacun de ces rôles ? et ainsi de suite...

Il y a eu une très bonne discussion sur ce sujet sur le groupe Yahoo "Scrum Development" et certains points ont été très bien traités. Donc, je vais essayer de récapituler cela pour vous dans ce billet, et bien sûr y ajouter ma touche personnelle.

Je pense que les fondateurs de Scrum ont volontairement choisi un titre différent. Ils auraient facilement pu garder le même titre. Mais je pense qu'il y avait de bonnes raisons pour cela. Et c'est pourquoi le PO a un ensemble spécifique de tâches dédiées à ce rôle dans Scrum.

Comment leurs rôles diffèrent-ils?

D'abord et avant tout, le PO définit les priorités pour l'équipe de développement. Cela se fait via le product backlog. Une entreprise a la capacité de transformer certaines exigences en un code opérationnel. La façon dont cette capacité est utilisée, est entièrement entre les mains du PO.

Pour que le PO puisse le faire, il a besoin de disposer d'une vue globale. Que le PO obtienne effectivement cette information à partir d'autres rôles ou qu'il l'obtienne par lui-même dépend de l'organisation de l'entreprise.

Une fois qu'il a bien compris le contexte dans son ensemble, le PO doit exécuter quelques tâches supplémentaires spécifiques (pas nécessairement formellement définie d'ailleurs) :

  1. Communiquer la vision du produit à l'équipe
  2. Définir les objectifs au début de chaque sprint
  3. Raconter chaque user story de sorte que l'équipe de développement comprenne ce qui est demandé. Le PO doit donc aussi comprendre les exigences des utilisateurs finaux.
  4. Définir ou aider à définir les critères d'acceptation des user stories afin que l'équipe sache quand elle a terminé.
  5. Être capable de prioriser les user stories et être en mesure de négocier / collaborer sur les priorités avec l'équipe. Négocier les priorités se produit lorsqu'après avoir pris les user stories de plus haute priorité en haut du backlog, il reste une certaine capacité non suffisante pour traiter la user story suivante dans son entier. Dans ce cas, une user story de moindre priorité (mais de plus petite taille) peut être sélectionnée.
  6. Doit être disponible lors de toutes les occasions où l'on inspecte & adapte afin de répondre aux questions et aider à guider l'équipe de façon très concrète.


Les Product Managers doivent d'autre part être capables de faire tout un tas d'autres choses, y compris mais sans s'y limiter :

  1. Définir les stratégies de marketing et la communication marketing
  2. Les stratégies de tarification
  3. Comprendre le positionnement du produit sur le marché
  4. Faire une analyse de la concurrence

Quelques citations du forum qui valent le coup d'être répétées ici

"Scrum n'impose pas de responsabilité au-delà de celle d'optimiser le développement pour assurer la réussite de l'entreprise." (Anonyme)

"Le rôle du Product Owner est, d'autre part, de vraiment représenter le côté métier et de travailler avec l'équipe pour optimiser la livraison du produit complet." (Greg)

La meilleure...

"Le rôle du Product Owner est un rôle véritablement nouveau et perturbateur pour la plupart des organisations, puisqu'il ne s'intègre pas facilement dans les rôles et les structures existantes." (Roman)

En résumé, selon votre situation, les rôles de PM et de PO seront tenues par la même personne, par un groupe de personnes ou par des personnes différentes - et franchement, je m'en soucie peu. Tant qu'il y a une personne pour assurer la mission de PO et les responsabilités telles que définies dans les 6 points ci-dessus, alors tout roule d'un point de vue Scrum.