Sélectionner une page
Si vous avez apprécié cet article, vous êtes libre de le partager ! :)

Product Owner
Date_et_heure

Quiz introductif :

 

Loana a l’habitude de travailler sur des projets fondés sur une approche de développement « prédictive ». On lui annonce qu’elle va désormais devoir travailler sur un nouveau projet de façon « adaptative », en se basant sur le framework « Scrum ». Elle découvre ce nouveau cadre de travail et les différents rôles suggérés par la méthode. D’après-vous, c’est quoi un Product Owner ?

A – Un directeur de produit

B – Un responsable du produit

C – Un responsable du backlog

D – Un administrateur du produit

Corrigé du quiz en bas de cet article [1].

C'est quoi un Product Owner

 VeuillLe Product Owner en bref :  

 

Le rôle de product Owner vient d’une méthode d’organisation du travail appelée « Scrum » (je vous présenterai l’intégralité de la méthode dans un guide pratique prochainement). La méthode « Scrum » propose un cadre de travail, un « Framework » à l’intérieur duquel on retrouve différents rôles (la Scrum Team) :

  • L’équipe de développement : celle qui exécute le travail à produire (entre autres) ;
  • Le Scrum Master : celui qui est garant du cadre de travail tel que défini dans le scrum guide (Master = Maitre) ;
  • Le Product Owner : il est le représentant de son client auprès de l’équipe de développement, il est responsable du product backlog (le tableau sur lequel il va écrire les exigences du client) et il va veiller à maximiser la valeur du travail produit par l’équipe. 

Comme vous le verrez dans cet article, le Product Owner a des responsabilités assez subtiles. Pour introduire ces diverses responsabilités, je vous propose de les découvrir au travers d’un dialogue entre un Product Owner, sa cliente et son équipe de développement.

Dialogue :

Cliente : Bonjour Monsieur,

Le Product Owner : Bonjour Madame, que pourrais-je faire pour vous ?

Cliente : eh bien voilà, j’aimerais créer une application mobile dans le domaine des transports de personnes.

Le Product Owner :  Oui avec plaisir Madame c’est notre spécialité. Comment vous voyez les choses ? (vision)

Cliente : L’idée serait de se baser sur le principe de la livraison de pizza (compréhension du besoin), j’ai besoin d’un moyen de transport, je clique sur moins de 3 boutons et 10 min après mon taxi arrive.

Le Product Owner : D’accord très bien Madame. Je vous propose de nous fixer un rendez-vous pour faire le point et lister ce que vous aimeriez faire (recueil des exigences du produit). 

Cliente : D’accord, voici ce que j’aimerais proposer à mes futurs clients : l’application devra être avec cette charte graphique, et puis les clients pourront installer l’application en moins de 5 minutes sur leur smartphone, et puis […] (le Product Owner continue de recueillir les exigences produit). Parce que vous comprenez, j’ai attendu pendant plus de deux heures un taxi un samedi soir, ce n’est pas normal, je suis persuadée qu’il y a un vrai besoin. Je suis sûre que je ne suis pas la seule à avoir ce besoin […]

Le Product Owner : Oui c’est sûr, c’est un secteur que je connais bien. J’ai travaillé pour un projet analogue (le Product Owner a une très bonne connaissance « métier ») et mon équipe est spécialisée dans le développement d’applications mobiles (l’équipe de développement a une très bonne connaissance « technique »). C’est un très beau projet que vous avez là. Toutefois à l’époque, j’avais rencontré quelques contraintes : les chauffeurs arrivaient bien en moins de 10 min mais ils n’étaient pas très sympas. De plus, les chauffeurs n’étaient pas diplômés. Sans parler du fait que les chauffeurs de taxi traditionnel étaient très contrariés car l’application générait une concurrence déloyale vis-à-vis des chauffeurs.

Cliente : Ah mais oui vous avez raison, d’ailleurs vous me faites penser à ce propos à 2 ou 3 points. Il faudrait pouvoir noter les chauffeurs sur l’application mobile et puis il faudrait aussi que l’application n’accepte les chauffeurs qu’après validation de leur diplôme. Et il faudrait aussi pouvoir négocier avec les autorités publiques pour voir cette histoire de concurrence déloyale (la cliente ajoute de nouvelles exigences et le Product Owner les ajoute au fur et à mesure dans son tableau).

Le Product Owner : Pour les 2 premiers points, aucun problème. Pour le 3e point, je vous laisse voir directement avec les autorités compétentes car c’est en dehors de mon périmètre d’intervention (le product filtre les exigences au fur et à mesure du temps).

Cliente : Oui bien sûr, je réfléchissais à voix haute.

Le Product Owner s’adressant à l’équipe de développement : Salut tout le monde, eh bien alors voilà le client attend de nous les fonctionnalités 1, 2, 3, 4, 5 sur une application mobile destinée à transporter des personnes. Laissez-moi vous faire un petit schéma de ce que la cliente aimerait faire (le Product Owner apporte la vision du produit à l’équipe puis il présente les exigences [2] attendues par la cliente dans un tableau qu’on appelle « Product Backlog ». Ces exigences sont traduites en divers « services à rendre », qu’on appelle aussi des « outcomes » (des résultats). Ces exigences sont notées dans le product backlog via des post-it (généralement on utilise l’endroit où travaille l’équipe pour y coller les post-it. C’est soit le « mur » d’une salle de réunion, soit le mur de l’open space qui fait office de product backlog). Ces post-it décrivent généralement les « résultats souhaités » par le client (l’outcomes) avec une technique d’écriture qu’on appelle  « User Story » [2] .     

L’équipe : On pourrait même imaginer une product box pour se représenter encore mieux ce que souhaite la cliente.

Product Owner : Oui bien sûr, c’est vous qui voyez. Souvenez-vous qu’en approche de développement « agile », c’est vous qui vous « auto-organisez » comme vous le souhaitez pour atteindre les objectifs sur lesquels vous vous êtes engagés vis à vis de moi (après discussion avec le product owner, l’équipe de développement s’engage sur un objectif global qui leur permettra de répondre à une ou plusieurs des exigences). Il n’y a pas de lien hiérarchique entre nous ! (tel un entraîneur de football, le Product Owner explique les résultats souhaités, la stratégie à mener et la tactique, mais laisse l’équipe s’auto-organiser pour marquer des buts !).   

L’équipe : Effectivement. C’est top ça ! Franchement d’un point de vue technique, on ne voit pas de difficulté particulière ça ressemble beaucoup à une application qu’on a faite pour des livreurs de pizza (l’équipe de développement a une très bonne connaissance « technique »). À part peut-être pour les exigences 128, 90, et 58, je ne vois pas de difficulté particulière. Par contre, d’un point de vue « business », on a noté quelques questions (l’équipe de développement maîtrise moins bien le « métier » que le Product Owner). Est-ce que par exemple, sa carte bancaire doit être débitée avant ou après son trajet de transport ? Est-ce qu’il peut noter le chauffeur pendant son trajet ou après ?

Le Product Owner : Oui bien sûr, voyons ça ensemble […] (le Product Owner clarifie autant que nécessaire la partie « métier » à l’équipe, pour qu’ils puissent proposer des résultats ultra-pertinents. Exemple : accès au paiement via Paypal, accès à une page de connexion via Google ou via Facebook, etc.). D’ailleurs peut être que l’un d’entre vous pourrait m’aider à monter en compétence d’un point de vue technique sur la fonctionnalité 128 (Le Product Owner n’est pas un expert « technique » donc il n’hésite pas à affiner ses propres lacunes auprès de l’équipe. C’est un jeu d’aller-retour permanent). Et puis, j’aurais également besoin de connaître la quantité d’effort que cela représenterait, pour créer cette fonctionnalité 128 notamment par rapport à la fonctionnalité 103 (le Product Owner doit pouvoir prioriser le travail à fournir et savoir ce qu’il va proposer sur le marché « au plus vite » !).

L’équipe : En fait, tu peux être sûr que la fonctionnalité 103 est au moins 3 x plus complexe à développer que la fonctionnalité 128. Si je devais les comparer, je dirais que la 128 c’est l’équivalent d’une taille « S » de T-Shirt et la 103, je dirais que c’est l’équivalent d’une taille « XL ».  

Le Product Owner : Ah ok, c’est cool merci de me le dire. Dans ce cas, je vous propose de faire la 128 d’abord et on fera la 103 un peu plus tard quand notre cliente nous aura éclairé sur les 2-3 points manquants.   

La cliente : Ah au fait, j’aimerais aussi ajouter la fonctionnalité 132,133 ,134. 

Le Product Owner : Oui bien sûr Madame on peut regarder cela ensemble. Par contre compte tenu de votre objectif je pense que les fonctionnalités 103, 131,132 et 133 (qui consistent à changer le chauffeur en raison d’une mauvaise note) seraient antinomiques avec le fait d’avoir un chauffeur qui arrive en moins de 10 min. (faire prendre conscience au client des conséquences de leur demande et savoir dire « non » le cas échéant).  

La cliente : Ah oui c’est vrai, je n’y avais pas pensé. Bon, alors on retire ces 4 fonctionnalités. De toute façon, ce qui est important, pour moi c’est qu’un chauffeur arrive en moins de 10 min. Le reste est moins important…

Les responsabilités du Product Owner : 

Comme vous avez pu le voir le Product Owner est situé au carrefour de plusieurs parties prenantes : sa cliente, les clients de sa cliente (les utilisateurs finaux), son équipe de développement, ses fournisseurs etc. Si on raisonne d’un point de vue strictement sémantique, on pourrait croire que ce rôle est une espèce de chef d’orchestre du projet : le responsable du produit. Or ce n’est pas tout à fait le cas : en approche adaptative, il n’y a pas vraiment de « chef de projet » au sens PMI® du terme (ou alors on pourrait dire que le chef de projet au sens PMI® du terme correspondrait à la fois à un Product Owner et à un Scrum Master mais cela nous emmènerait très loin en termes de débat donc je referme vite cette parenthèse :)). En approche adaptative, les personnes sont plutôt auto-organisées, tout le monde s’oriente vers une performance du produit, une valeur produit (et c’est dans leur intérêt de le faire car sinon, ils n’ont plus de travail ! Ils ne sont généralement recruté que pour cela […]). En approche SCRUM (cf. Scrum Guide), chacun est responsable de son travail, chacun doit prendre sa part. Le Product Owner n’est pas vraiment redevable du résultat du produit, il est redevable de « maximiser la valeur du produit résultant du travail de la Scrum Team ». Ce qui n’est pas tout à fait la même chose. Ce qui veut dire qu’il doit se concentrer sur son backlog (par contre, il est redevable de son product backlog), ce qui se traduit par les points suivants :

  • « Formuler et communiquer explicitement l’Objectif de Produit ;
  • Créer et communiquer clairement les éléments du Product Backlog [2] ;
  • Ordonner les éléments dans le Product Backlog [2] ;
  • S’assurer que le Product Backlog est transparent, visible et compris. »

Par ailleurs : « Pour que les Product Owners réussissent, toute l’organisation doit respecter leurs décisions. »

 

Le Product Owner ressemble à un entraîneur de football

On pourrait comparer le Product Owner à un entraîneur de football. Il définit une stratégie et conseille l’équipe sur les meilleurs gestes à réaliser (action motrice). L’équipe applique la stratégie en appliquant les directives de l’entraineur toutefois l’équipe conserve sa singularité technique (c’est-à-dire ses habiletés motrices). Puis, à la fin du match, l’équipe obtient un résultat dont la valeur est censée être maximisée grâce aux conseils de l’entraineur. C’est la stratégie de l’entraineur qui a permis de maximiser la valeur produite par l’équipe. C’est grâce à son expertise métier, grâce à la clarté de ses explications, grâce à son expérience personnelle et professionnelle etc.   

Le Product Owner ressemble à un videur de discothèque

 

On pourrait également comparer le Product Owner à un videur de discothèque. Il doit faire face à l’engouement des parties prenantes, tel un videur de discothèque, il doit savoir dire « non » pour veiller à ce que les personnes qui entrent dans la discothèque correspondent bien à l’objectif de marque de celle-ci. Pour rappel un videur filtre les personnes à l’entrée de la discothèque par rapport à la capacité d’accueil de la structure mais aussi par rapport à la capacité des barmans à livrer les clients. (et je ne parle pas du filtre lié aux éventuelles personnes violentes fondé généralement sur des expériences passées). De la même façon le Product Owner doit filtrer les diverses exigences des parties prenantes pour éviter que l’équipe ne se retrouve débordée par le travail à produire et pour veiller à ce que les exigences listées par les parties prenantes correspondent bien à l’objectif globale du projet (cf. comment créer de la valeur). En effet avec la pratique (et grâce au Scrum Master), le Product Owner saura à peu près estimer la capacité de travail de l’équipe (ce qu’on appelle la vélocité) : imaginons que sur une durée de 2 semaines l’équipe produise 5 fonctionnalités, il y a de fortes chances qu’elle ne puisse pas en produire 15 pour les 2 semaines qui suivent. Elle va avoir une certaine capacité de travail et c’est sur cette capacité de travail que va s’appuyer notre Product Owner pour prioriser les exigences de son client. 

Toutefois, un problème se pose lorsque la demande de fonctionnalité augmente et que la vélocité de l’équipe se stabilise. C’est ce que j’appelle « l’effet tonneau des danaïdes ». Ce n’est pas parce que l’on met plus d’eau dans un arrosoir que le débit d’eau qui s’écoule va s’améliorer. Si cette demande augmente, cela va donc à chaque fois allonger les délais, donc les coûts ou alors diminuer le périmètre. Et c’est généralement là que le bât blesse car les clients souhaite ajouter des fonctionnalités sans que cela n’ait d’impact sur les délais, les coûts ou le périmètre.

Tout l’enjeu pour le Product Owner réside dès lors dans sa capacité à dire « non » et à veiller à ce que les fonctionnalités produites par l’équipe produisent le plus de valeur possible.

Le Product Owner ressemble à un restaurateur

Enfin le Product Owner ressemble aussi à un restaurateur. Un restaurateur et un visionnaire, un expert du positionnement de la chaîne de valeur à proposer à ses clients (cf. film : le fondateur), bref c’est un expert de son secteur d’activité (c’est ce qu’on appelle le « métier »). Toutefois, un restaurateur s’appuie sur une équipe de cuisinier qui maîtrise fortement la technicité des plats cuisinés. De la même façon, le Product Owner n’est pas un expert de la technique des fonctionnalités (des plats cuisinés) mais un expert « métier », c’est-à-dire un expert du business, du positionnement, de la vision, de la pertinence des fonctionnalités à créer etc. Toutefois, il doit savoir faire un « minimum » de choses et n’hésite pas à demander conseil le cas échéant. Par exemple, il sait qu’on ne fait pas d’omelette sans casser des œufs ! (à lire au sens propre plus qu’au figuré) 🙂

 


Quel est le salaire d’un Product Owner ?

 

Salaire

Il est très difficile de répondre à cette question car le salaire est intimement lié au niveau d’expertise métier du Product Owner. Imaginons que vous travailliez sur un projet d’application mobile disruptif (du même acabit que l’application mobile « Uber »). Votre salaire de Product Owner sera directement lié à votre capacité à comprendre et à même à dépasser les besoins de votre futur client. Si vous êtes en compréhension parfaite de la réglementation des taxis (ou plutôt du transport de personnes pour être précis), des systèmes de navigation GPS qui « fonctionnent bien », des procédures de radiation des chauffeurs, etc. vous aurez plus de chance d’être pertinents face aux besoins clients et donc, vous n’aurez aucun mal à vous vendre. A l’inverse, si vous débutez, il faudra apprendre le métier dans lequel vous interviendrez. Cela vous prendra certainement un peu plus de temps. Toutefois pour vous donner une fourchette, notez que selon le site internet : regionsjob, le salaire des Product Owner juniors se situe aux alentours de 50K€/an et aux alentours de 65-70 k€/an pour les profils confirmés (cela peut monter à 90-100 k€ pour les profils seniors c’est-à-dire pour les grands « experts-métiers »).

Si vous souhaitez vous former au métier de Product Owner, il y a plusieurs stratégies à mener. Soit vous passez les certifications SCRUM et il en existe 2 spécifiques au métier de Product Owner : les certifications PSPO I (niveau intermédiaire) et la certification PSPO II (niveau avancée), soit vous passez la certification PMP®. En effet, la certification PMP® apporte beaucoup plus d’agilité depuis la réforme du 01 janvier 2021. Elle bénéficie d’un rayonnement plus prestigieux que les certifications SCRUM et d’un périmètre beaucoup plus large (pour en savoir plus à ce sujet, je vous invite à cliquer ici : 10 bonnes raisons d’être certifié PMP®

Pour résumer, le Product Owner est responsable de son backlog et veille à maximiser la valeur du produit final grâce à son expertise métier. C’est un facilitateur qui n’hésite pas à se remettre en question pour apprendre à communiquer avec l’équipe de développement car il ne dispose pas d’un grand bagage technique (sauf si c’est un ancien développeur). Il apprend à filtrer les diverses demandes des parties prenantes pour éviter de trop retarder le projet (ou de trop l’alourdir financièrement) et pour faire en sorte que les fonctionnalités fournissent la plus grande valeur possible. Pour conclure : Le Product Owner ressemble à la fois à un entraîneur de sportifs (il définit une stratégie et priorise des actions), à un videur de discothèque (il doit savoir dire « non ») et à un restaurateur (il connaît bien ses clients mais ne sait pas cuisiner) ou très peu ! :).    

________________________________

Envie de faciliter votre chemin vers la certification PMP® ? Découvrez notre formation dédiée et notre simulateur de questions d’examen 100% francophone (avec corrigé au format vidéo). Cliquez-ici pour simplifier votre préparation et restez centré sur l’essentiel.

__________________________________

Sources et références :

 

[1] Corrigé du quiz : Réponse C. le responsable du backlog. Les Canadiens avaient utilisé l’expression « administrateur du produit » pour parler du product Owner mais ce terme n’a pas survécu à l’expression Product Owner.

[2] Veuillez noter que depuis la dernière mise à jour du guide Scrum, le terme « exigence » a été supprimé et remplacé par le terme « élément ». J’ai conservé le terme « exigence » pour des raisons pédagogiques. D’abord parce qu’on retrouve souvent le terme « exigence » dans la littérature du PMI® (y compris pour les approches agile de gestion de projet) et ensuite parce qu’il me paraît plus facile à comprendre que le terme « élément » (qui au contraire est plus abstrait). Je profite de ce petit « nota bene » pour vous dire qu’en approche agile, ces exigences sont traduites en format d’écriture qu’on appelle « User Story ». Exemple d’écriture : en tant que client (qui), je veux effectuer un paiement en ligne en moins de 3 clics (quoi) pour recevoir mon colis à mon domicile (pourquoi)


Si vous avez apprécié cet article, vous êtes libre de le partager ! :)