Table des matières
- Qu’est-ce qu’un Product Owner ?
- Ce que fait un Product Owner
- Ce qu’un Product Owner ne fait pas
- Qu’est-ce qu’un chef de projet ?
- Ce que fait un chef de projet
- Ce que ne fait pas un Chef de Projet
- Caractéristiques et compétences communes au Product Owner et au Chef de Projet
- Caractéristiques ou compétences d’un Product Owner
- Caractéristiques ou compétences d’un Chef de Projet
- Les trois principales responsabilités se chevauchent entre le Product Owner et le chef de projet :
- Les trois principales différences de responsabilité entre le Product Owner et le Chef de Projet :
- Articles similaires
Qu’est-ce qu’un Product Owner ? Quelles sont les différences entre un Product Owner et un Chef de Projet ? Un Product Owner n’est-il pas une sorte de Chef de Projet Agile ? . Avant d’explorer les différences entre un Product Owner et un Chef de Projet, la conclusion est : Le Product Owner n’est pas un Chef de Projet Agile. Il y a certains chevauchements entre le rôle de Product Owner et le poste de Chef de Projet, cependant, être un Product Owner est très différent d’être un Chef de Projet. Dans ce blog, nous allons approfondir le sujet : « Product Owner vs Chef de Projet ».
Qu’est-ce qu’un Product Owner ?
Le Product Owner est une personne (et non un comité) qui, dans le cadre de Scrum, est responsable de la maximisation de la valeur. La façon dont le Product Owner maximise la valeur est en faisant continuellement des choix sur ce qu’il faut construire et ce qu’il ne faut pas construire dans le produit. Pour ce faire, le Product Owner est également responsable de la vision du produit et de la gestion du Product Backlog et des parties prenantes.
Ce que fait un Product Owner
Voici quelques exemples de ce que doit faire un Product Owner :
- Être responsable du succès ou de l’échec du produit ;
- Fournir une direction unifiée au produit ;
- Fournir les ressources et autoriser les fonds pour le produit ;
- Fournir un soutien visible et durable au produit ;
- Maximiser la valeur du produit pour les clients, les utilisateurs et l’organisation. Cela signifie qu’un Product Owner possède réellement le produit. Le Product Owner est la personne chargée de veiller à ce que le produit apporte le plus de valeur possible. Cela signifie également qu’il est responsable du retour sur investissement, du budget, du coût total de possession et de la définition, du maintien et du partage de la vision du produit, par exemple.
- Le Product Owner est également responsable de la gestion du Product Backlog. Cela comprend des activités telles que l’expression claire des éléments du Product Backlog, l’ordonnancement des éléments du Product Backlog afin d’atteindre au mieux les objectifs et les missions et l’assurance que le Product Backlog est visible, transparent et clair pour tous, et qu’il indique ce sur quoi l’équipe Scrum va travailler ensuite.
- Le Product Owner est responsable de la gestion des parties prenantes, afin d’aligner tout le monde sur la vision du produit et sur les buts et objectifs (business) à atteindre. Cela implique également d’inviter les bonnes parties prenantes (clés) à la revue de sprint, de discuter de l’état actuel du Backlog du produit, des prochaines cibles et objectifs, des dates de livraison probables et des progrès réalisés, au cours de la revue de sprint, ainsi que de suivre le travail total restant (au moins à chaque revue de sprint) pour le produit, de créer des prévisions et de rendre ces informations transparentes pour les parties prenantes.
Si vous souhaitez en savoir plus sur les tâches, les responsabilités et les pouvoirs du Product Owner, consultez cet article. En plus d’expliquer ce qu’est un Product Owner, voyons aussi ce qu’il n’est pas.
Ce qu’un Product Owner ne fait pas
Ce qu’un Product Owner ne doit pas faire :
- Être un greffier. Cela signifie qu’un Product Owner n’est pas quelqu’un qui rend visite à toutes les parties prenantes et leur demande à toutes ce qu’elles veulent. Un Product Owner ne doit pas collecter les commandes des parties prenantes. Il doit avoir une vision claire et recueillir des commentaires sur cette vision. Il ne doit pas recueillir des ordres.
- Être un rédacteur de Stories (tout le temps). Cela signifie que ce n’est pas le travail quotidien du Product Owner de rédiger des User Stories, des critères d’acceptation ou des détails de Product Backlog Item (PBI) tout au long de la journée. Bien sûr, trouver des PBI fait partie du travail, mais un Product Owner n’est pas un secrétaire de Backlog !
- Être un gestionnaire de projet. Cela signifie qu’un Product Owner n’est pas un chef de projet Agile. Le Product Owner ne crée pas et ne gère pas de plans de projet (étendus) tels que le Document d’Initiation de Projet, le Plan de Projet, les Diagrammes de Gantt ou autres. Le Product Owner ne doit pas non plus suivre et mesurer les progrès de l’équipe. Il ne doit pas non plus gérer les personnes et les ressources ou la capacité de l’équipe de développement, par exemple. Le Product Owner s’intéresse à la vélocité d’une équipe, mais il ne se préoccupe pas du chiffre réel ou de l’ « optimisation » de cette vélocité.
- Être un expert en la matière. Cela signifie qu’un Product Owner n’est pas l’expert en processus ou en systèmes le plus expérimenté et le plus compétent de l’entreprise. Un Product Owner est avant tout un entrepreneur. Quelqu’un qui ose prendre des risques, commettre des erreurs et s’approprier le projet. Bien sûr, il est important de connaître le produit, le marché, les clients et le domaine. Mais il n’est pas nécessaire d’être un expert connaissant tous les détails. C’est pourquoi le Product Owner ne doit pas se préoccuper outre mesure de tous les petits détails. C’est pourquoi il travaille avec des experts, appelés l’équipe de développement !
- Être un gardien. Cela signifie que le Product Owner n’est pas le point de contact unique entre l’équipe de développement et le monde extérieur. Le développement de produits et de services est favorisé lorsque les équipes de développement interagissent directement avec les clients et les utilisateurs. Il n’est pas nécessaire d’avoir une personne « entre les deux ». Le Product Owner ne doit donc pas être un point de contact unique. Un Product Owner n’est pas un pigeonnier.
- Être un manager. Cela signifie qu’un Product Owner n’est pas responsable des performances de l’équipe ou des processus RH, tels que la gestion des performances. Bien sûr, le Product Owner peut faire part de ses commentaires aux membres de l’équipe, comme toute autre personne dans l’entreprise. Mais le Product Owner n’est pas un « chef d’équipe », ni un « manager », ni un « responsable RH ».
Qu’est-ce qu’un chef de projet ?
Maintenant que nous avons exploré le rôle du Product Owner, passons à la partie « vs Chef de Projet » de ce blog. Qu’est-ce qu’un Chef de Projet ? Et quelles sont ses responsabilités ? Si l’on examine certaines méthodologies de gestion de projet bien connues, telles que PM-BOK ou PRINCE2, on constate ce qui suit :
Le chef de projet gère un projet au jour le jour et est le seul à se concentrer sur le projet au quotidien. Par conséquent, ce rôle ne peut jamais être partagé. Le chef de projet dirige le projet pour le compte du comité de projet dans le respect des contraintes spécifiées et assure la liaison tout au long du projet avec le comité de projet et l’assurance du projet. Le chef de projet est généralement (de préférence selon PRINCE2) issu du client. Il est responsable de tous les processus PRINCE2, à l’exception des processus Diriger un projet et Gérer la livraison du produit.
Source: https://prince2.wiki/roles/project-manager/
Outre la définition ci-dessus, un chef de projet est également responsable du soutien du projet et de la gestion de l’équipe, dans le cas où il n’y a pas de chefs d’équipe dans l’organisation. Cela signifie que le chef de projet gère (le travail et les performances) des membres de l’équipe au quotidien.
Ce que fait un chef de projet
Le rôle/le métier de Chef de Projet est très vaste. Il existe de nombreuses tâches et responsabilités liées au rôle de chef de projet. En voici quelques-unes :
- La création et la gestion de l’analyse de rentabilité.
- Gérer les changements et les demandes de changement (concernant le champ d’application, le temps et le budget).
- Gérer l’organisation du projet.
- Créer et gérer les plans du projet, y compris le document de lancement du projet, le plan du projet, les diagrammes de Gantt et autres.
- Suivre et mesurer les progrès du projet/de l’équipe.
- Gérer la qualité.
- Identifier, suivre et gérer les risques du projet.
- Fournir des services administratifs pour le projet.
- Fournir des conseils et des orientations sur les outils de gestion de projet ou de gestion de la configuration.
- Administrer les procédures de gestion de la configuration dans le cadre de l’approche de contrôle des changements.
Ce que ne fait pas un Chef de Projet
En plus de toutes les obligations, responsabilités et tâches à accomplir, il doit y avoir quelque chose qu’un gestionnaire de projet ne doit pas faire, n’est-ce pas ? Voici donc ce qu’un gestionnaire de projet ne doit pas faire :
- Rendre compte de la réussite ou de l’échec du projet (ce qui est fait par le conseil du projet) ;
- Fournir une direction unifiée au projet (ce qui est fait par le conseil de projet) ;
- Fournir les ressources et autoriser les fonds pour le projet (c’est le conseil du projet qui s’en charge) ;
- Apporter un soutien visible et durable au chef de projet (c’est le rôle du conseil de direction du projet) ;
- Assurer une communication efficace au sein de l’équipe de projet et avec les parties prenantes externes (c’est le rôle du conseil de projet) ;
- Spécifier les besoins (exigences) des utilisateurs qui utiliseront les produits du projet (c’est l’utilisateur principal qui s’en charge) ;
- Assurer la liaison entre l’équipe de gestion du projet et les utilisateurs (tâche confiée à l’utilisateur principal);
- S’assurer que la solution répondra aux besoins des utilisateurs, notamment en termes de qualité et de facilité d’utilisation, et qu’elle sera conforme aux exigences (c’est l’utilisateur principal qui s’en charge) ;
- Fournir des informations sur les avantages pour l’approche de la gestion des avantages (cette tâche est effectuée par l’utilisateur principal) ;
Si vous souhaitez en savoir plus sur le rôle du chef de projet, il existe de nombreux ouvrages et articles que vous pouvez lire. Sur la base de ce que nous avons abordé jusqu’à présent, nous pensons que vous pouvez déjà déceler quelques grandes différences entre les rôles de Product Owner et de Chef de Projet. C’est pourquoi nous aimerions passer aux compétences requises pour les deux rôles.
Caractéristiques et compétences communes au Product Owner et au Chef de Projet
Les excellents Product Owners possèdent de nombreuses compétences et caractéristiques pertinentes. Il existe également de nombreuses caractéristiques et compétences que les bons gestionnaires de projet devraient posséder. Par conséquent, voici une liste plus générique de caractéristiques et de compétences pour les deux rôles :
- Communication – Les propriétaires de produits et les gestionnaires de projets doivent être capables de bien communiquer avec toutes les parties prenantes de l’organisation. Ils doivent pouvoir communiquer efficacement avec les clients, la direction, les membres de l’équipe, les utilisateurs, les fournisseurs et bien d’autres encore.
- Leadership – Le leadership est une compétence importante pour les deux rôles également, mais le type de leadership est différent. Un Product Owner peut adopter un style de leadership plus inspirant et motivant. Il utilise la vision, la stratégie et l’histoire du produit pour inspirer les équipes et les parties prenantes. En règle générale, le Product Owner dirige et inspire les personnes en vue d’obtenir des résultats commerciaux. Pour un chef de projet, il est également important de posséder d’excellentes compétences en matière de leadership. Par exemple, pour motiver les équipes, convaincre les gens de l’approche du projet, diriger les gens dans le processus du projet, etc. En règle générale, un chef de projet dirige et inspire des personnes afin de produire des résultats.
- Organisation – Les Product Owners et les Chefs de Projet doivent être des personnes bien organisées. Ils doivent être capables d’organiser leur propre travail, de concilier vie professionnelle et vie privée et d’avoir une vue d’ensemble de la situation dans laquelle nous nous trouvons. En outre, ils doivent tous deux être capables de voir où nous en sommes actuellement, quelle est notre destination souhaitée et quel est notre carnet d’objectifs et de travail pour atteindre cette destination.
Caractéristiques ou compétences d’un Product Owner
Les excellents Product Owners possèdent de nombreuses compétences et caractéristiques pertinentes. Afin de ne pas dresser une liste exhaustive, nous nous contenterons de partager dans cet article nos trois principales compétences/caractéristiques.
- Esprit d’entreprise – Les meilleurs Product Owners sont des entrepreneurs. Ils sont pleins d’idées, voient de nombreuses opportunités, assument leurs responsabilités et prennent des décisions conscientes afin de minimiser les risques et de saisir les opportunités.
- Visionnaire – Les grands Product Owners ont une vision claire. Ils savent ce qu’ils veulent pour leurs clients et utilisateurs et, plus important encore, pourquoi ils le veulent ! Ils se concentrent sur la réussite du produit et sur sa vision à long terme.
- Décisif – Les Product Owners doivent être décisifs. Ils doivent faire de nombreux choix, ce qui implique souvent de dire « non » à certaines personnes et donc de les décevoir. Ils doivent s’assurer de faire les choses les plus importantes et les plus utiles pour le produit.
Caractéristiques ou compétences d’un Chef de Projet
Comme pour le rôle de Product Owner, il existe de nombreuses caractéristiques et compétences qui caractérisent les grands Chefs de Projet.
- Gestion du temps – La gestion du temps est un élément important de la gestion de projet. Les chefs de projet doivent être en mesure de mener à bien leur projet dans les délais impartis. Il doit gérer les délais du projet. Ils doivent donc veiller à ce qu’aucune partie du processus ne prenne plus de temps que nécessaire. Outre la gestion de leur propre temps en tant que chef de projet, ils doivent aider leur équipe à gérer leurs journées et à tirer le meilleur parti de leur temps de travail.
- Négociation – Les chefs de projet doivent posséder de solides compétences en matière de négociation, ce qui les aidera à maintenir le projet sur la bonne voie et à éliminer les obstacles importants. Il doit être capable de négocier efficacement avec le conseil d’administration, les équipes, les utilisateurs, les clients et les fournisseurs, par exemple.
- Gestion des risques – Les chefs de projet doivent savoir gérer les risques. Ils doivent être capables d’identifier, de gérer et d’aborder les risques de manière efficace.
Conclusion
Comme vous l’avez peut-être remarqué, il existe des différences notables entre les rôles de Product Owner et de Chef de Projet. Bien entendu, les caractéristiques et les compétences (plus génériques) se recoupent dans les deux cas. En ce qui concerne les responsabilités, il y a également un certain chevauchement entre le rôle du Product Owner et celui du Chef de Projet. Toutefois, le Product Owner a tendance à rendre des comptes, alors que le gestionnaire de projet est responsable ou se contente d’exécuter. Récapitulons les trois principaux points de chevauchement et les trois principales différences entre ces deux rôles :
Les trois principales responsabilités se chevauchent entre le Product Owner et le chef de projet :
- Le Product Owner et le chef de projet s’intéressent tous deux à ce qu’il faut construire. Ils identifient tous deux les besoins des clients et des utilisateurs. Ils gèrent et s’engagent avec les parties prenantes afin de déterminer ce qu’il faut construire et ce qu’il ne faut pas construire pour le produit. Ainsi, un chef de projet gère sa « structure de répartition du travail » et ses « plans de projet », tandis qu’un Product Owner gère le carnet de commandes du produit (Product Backlog). Dans les deux cas, il s’agit de listes de souhaits ou de listes d’achats pour le produit à construire, ce qui est assez similaire. La grande différence réside dans le fait qu’un gestionnaire de projet gère la liste de souhaits de quelqu’un d’autre, alors qu’un Product Owner gère sa propre liste de souhaits. Cela signifie que le Product Owner a un contrôle total sur le Product Backlog, alors que le Chef de Projet se voit généralement dire ce qu’il faut ajouter ou supprimer de la liste de souhaits.
- Le Product Owner et le chef de projet doivent tous deux gérer les éléments du triangle de fer que sont le temps, le budget et le champ d’application. Le chef de projet doit en principe gérer une portée, un budget et un délai fixes pour le compte de quelqu’un d’autre. En revanche, le Product Owner dispose généralement d’un budget fixe, d’un délai fixe et d’un champ d’application flexible. En outre, étant donné que le Product Owner est propriétaire du budget et qu’il décide du temps (il décide du moment de la mise en production), le Product Owner a beaucoup plus de contrôle et de capacité à diriger.
- Le Product Owner et le gestionnaire de projet sont tous deux concernés par le retour sur investissement. Un gestionnaire de projet travaille généralement à la création d’une analyse de rentabilité pour le commanditaire du projet au début de celui-ci. Il doit régulièrement évaluer l’analyse de rentabilité avec le comité de pilotage et déterminer s’il est toujours utile de poursuivre le projet. Un Product Owner peut également (demander à quelqu’un) de créer une analyse de rentabilité. Cependant, le Product Owner n’est pas seulement responsable de la gestion de l’analyse de rentabilisation, il doit également s’assurer que l’analyse de rentabilisation génère suffisamment de valeur et de résultats. Ainsi, un Product Owner peut décider d’arrêter un produit (ou un projet) s’il le juge utile.
Les trois principales différences de responsabilité entre le Product Owner et le Chef de Projet :
- Un chef de projet n’est pas responsable du succès ou de l’échec d’un produit. Il peut être tenu pour responsable de l’échec du projet, mais dans le sens de la portée, du budget et du temps principalement. Dans un contexte Scrum, cependant, le Product Owner est responsable en dernier ressort de la réussite du produit. Le Product Owner est donc responsable du succès d’un produit, mais aussi de la valeur et des résultats résultant de l’exécution des projets, si cette méthode de travail s’applique. Dans le cadre d’un projet, c’est le comité de projet (l’exécutif du projet) qui est responsable du produit et des résultats, et non le chef de projet.
- Le chef de projet crée, gère, répartit et distribue les paquets de travail entre les membres de l’équipe. Il gère également le champ d’application pour les parties prenantes. Le chef de projet a donc une responsabilité liée aux exigences et au contenu. Le Product Owner ne gère pas ces détails. Il ne gère pas les lots de travail, les personnes, les ressources, les matériaux ou autres. Il s’assure simplement qu’il existe une liste de travail ordonnée et compréhensible (Product Backlog), que les équipes de développement auto-organisées peuvent utiliser.
- Il a été mentionné précédemment que le Product Owner et le Chef de projet sont tous deux responsables des éléments du triangle de fer que sont le temps, le budget et le champ d’application. Cela est vrai. Une grande différence que nous constatons cependant est que les chefs de projet se préoccupent principalement de la gestion de ces éléments dans leur pratique quotidienne. Il en va tout autrement des Product Owners, qui se concentrent davantage sur la création de valeur. Les Product Owners mesurent généralement la satisfaction des clients, les revenus, l’utilisation du produit, le coût total de possession, etc. La grande différence entre les Product Owners et les Chefs de projet est donc que les premiers se concentrent sur la création de valeur, tandis que les seconds se concentrent sur le contrôle du temps, du budget et de l’étendue du projet.
Nous espérons que cet article vous a été utile. Si vous avez des questions complémentaires ou si vous souhaitez en savoir plus sur Professional Scrum, n’hésitez pas à nous contacter.
Pas De Commentaire! Soyez la première personne.