“Scrum Master”, “Coach Agile”, “Project Manager”, autant de nouveaux noms que vous ne connaissez peut-être pas encore mais qui pourraient bien devenir votre futur métier ! Et parmi eux, celui de “Product Owner“, plus familièrement appelé “PO”.

Puisant son origine en startup, le rôle de Product Owner est depuis quelques années très prisé des grandes entreprises en pleine transformation digitale. Voyons donc ensemble à quoi pourrait bien ressembler votre futur job en 4 points :

• Le rôle du Product Owner
• L’environnement de travail
• Les outils du PO
• La journée type

Le rôle du Product Owner

Il est courant de définir le rôle du Product Owner comme le lien entre la partie métier et la partie technique au sein d’une équipe projet. Le PO est l’interlocuteur principal des utilisateurs du produit, et s’assure que les livraisons techniques sont bien en accord avec les besoins définis.

Une fois les besoins utilisateurs définis et correctement détaillés, le PO va prioriser les fonctionnalités en fonction de leur valeur ajoutée et de la charge de travail pour les développer. Ensuite, il va suivre la progression des développements et mettre en place des indicateurs pour mesurer la vélocité du projet.

Cependant, le PO ne se contente pas de développer un produit et de le livrer aux utilisateurs. En effet, il se doit souvent de mettre en place un plan de conduite du changement afin de faire adopter la solution développée aux utilisateurs, soit via des sessions de coaching, soit via des documents de formation.

L’environnement de travail

Le rôle de Product Owner s’effectue au sein d’une équipe projet, souvent dans un contexte digital fonctionnant en mode Agile. Nous étudierons ici le rôle de PO dans un contexte Scrum.

La structure de l’équipe du Product Owner peut varier d’une entreprise à une autre, mais elle est toujours composée au moins :

• d’une équipe de développeurs, qui représentent la partie technique ;
• de sponsors, incarnés par des postes hiérarchiques, qui apportent leur soutien au projet.

Pour certains projets de grande ampleur, il est nécessaire d’avoir une équipe plus conséquente. C’est pourquoi le Product Owner peut choisir de s’entourer de Proxy PO, qui seront également en charge de la vision métier et l’assisterons dans ses missions. Egalement, un Scrum Master peut venir compléter l’équipe. Son rôle est de s’assurer que celle-ci applique correctement le cadre de travail Agile Scrum.

Les outils du PO

Pour l’aider dans ses tâches, le Product Owner utilise de nombreux outils au quotidien lui permettant d’assurer un bon suivi du projet.

• L’expression de besoin (EDB) : il s’agit d’un document regroupant l’ensemble des besoins de manière globale pour estimer la faisabilité du projet général.
• Le Product Backlog, ou Backlog : outil fondamental du PO, le Backlog est une sorte de liste regroupant tous les besoins recueillis au cours du projet. Il peut être composé de nouvelles fonctionnalités à développer, de bugs à corriger ou encore d’items techniques.
• Le Kanban : il s’agit là d’un tableau de bord composé de plusieurs colonnes représentant les différentes étapes du projet. Comme dans l’exemple ci-dessous, les fonctionnalités sont chacune décrites sur une carte. Ainsi, au fur et à mesure de la progression de son développement, la carte est déplacée dans les différentes colonnes.

• La “user story” : ou “récit utilisateur” en français, est une description standard et simplifiée d’une fonctionnalité. En effet, ce format de demande permet de mentionner le profil de l’utilisateur, le besoin fonctionnel et la raison de cette fonctionnalité. Autrement dit, elle répond aux questions qui, quoi, pourquoi. La phrase se décline souvent comme suit :

En tant que <qui>, je veux <quoi>, afin de <pourquoi>.

• Les critères d’acceptation : ils complètent le récit utilisateur en précisant les conditions à satisfaire pour que la fonctionnalité soit considérée comme terminée.

Plusieurs logiciels full web permettent de gérer ces différents outils de manière informatique, par exemple Jira, GitHub ou encore Redmine.

D’autres outils peuvent être utilisés en complément, tels que des outils d’analyse, des KPIs ou même des outils de prototypage.

La journée type du Product Owner

Pour rendre cet article plus concret, prenons l’exemple d’un Product Owner, en charge de développer un logiciel pour des agents immobilier. Nous l’appellerons Justine. Ainsi, nous obtiendrons le schéma d’équipe suivant :

• 9h : Les développeurs et Proxy PO participent au Daily, une réunion quotidienne dans laquelle ils échangent sur l’avancement des développements. La Product Owner peut y assister mais n’est pas obligée.
• 9h15 : Justine se connecte à son outil de gestion de projet en ligne et visualise le Kanban. Ceci lui permet de vérifier la progression du projet et de relancer les parties prenantes.
• 9h30 : Elle teste les développements réalisés pour les valider ou non. S’ils répondent aux critères d’acceptation, elle prend les cartes et les déplacent dans la colonne suivante.
• 11h : Un utilisateur la contacte pour lui signaler un bug sur le logiciel d’immobilier. Elle crée une carte dans le backlog et la fait passer en priorité pour qu’il soit corriger au plus vite.
• 14h : Elle organise un atelier de Design Thinking avec un groupe d’agents (utilisateurs) pour recueillir les nouveaux besoins. Parmi eux, la nécessité de pouvoir ajouter des photos facilement aux fiches produits.
• 15h : Elle crée des user stories pour chaque demande, dont une comme suit :

En tant qu’agent immobilier, je veux pouvoir ajouter une photo dans une fiche produit afin de visualiser le bien concerné.

Critères d’acceptation : l’ajout doit se faire via un bouton visible et je dois pouvoir ajouter jusqu’à 10 photos.

• 16h : Elle répond aux questions des agents sur l’utilisation du logiciel.
• 17h : Justine prépare des documents de formation et diverses communications à destination des utilisateurs.

Pour conclure …

Le Product Owner représente le rôle central de l’équipe projet ; cependant, celle-ci ne pourrait pas fonctionner sans une équipe de développeurs apte à répondre aux besoins métiers par des développements techniques et fonctionnels.

Pour mener à bien cette mission, quelques connaissances techniques, un bon sens de l’organisation et de la négociation sont nécessaires. Mais le PO doit avant tout avoir un grand sens de l’écoute, sans quoi le produit ne conviendra pas au client !

Sources :

• Idea vector created by stories – www.freepik.com
• Business vector created by freepik – www.freepik.com
• People vector created by pikisuperstar – www.freepik.com
• Design vector created by pikisuperstar – www.freepik.com
• People vector created by freepik – www.freepik.com
• https://blogmdce.fr/
• https://www.apollo-formation.com/gestion-de-projet/methode-kanban-it.html