Le Product Owner (PO), un métier aux interfaces multiples
Le Product Owner, c’est avant tout la personne qui servira d’interface entre le client et l’équipe qui réalisera le produit.
C’est celui qui connaîtra le produit comme si c’était le sien, comme sa poche si l’on puit dire, afin de répondre aux clients. Il sait ce qu’il est possible de faire, ou non.
“Passe plat” qui doit recueillir les besoins utilisateurs et comprendre l’objectif client, le PO est aussi en charge, côté équipe technique et design, de s’assurer de la faisabilité du chantier, avant même de rédiger les specs techniques et le cahier des charges.
Ces spécifications, les fameuses “specs’”, se traduisent dans un backlog produit. Celui-ci est visible par toute l’organisation, mais le Product Owner est responsable de le tenir à jour. C’est ici qu’il rédige des sortes de “petits tickets”. En d’autres termes, je vous parle en direct de la naissance des célèbres User Stories (US), et des Bugs.
Exemple d’une US : “Au vu de ce que je vous ai dit là, au vu de tel screen, à la fin de tel sprint, il faut que ce soit tel résultat, grâce à tel bouton…”
Pour qu’une bonne US soit efficace, le schéma serait idéalement : “En tant que… je souhaite que… afin que….”
Pour reconnaître un bug, rien de plus simple : “Attention, telle erreur est apparue” !
Petit dictionnaire du Product Owner !
User Story : Fiche d’expression de la demande pour faire comprendre à l’équipe de manière claire et précise le besoin exprimé. Elle est rédigée par le PO, validée par le MPO (Manager Product Owner), et peut également être validée et complétée par le scrum master. Enfin, estimée et priorisée pour les futurs sprints.
Bug : Anomalie/régression vis-à-vis de la demande (US), détectée en cours de tests ou de production. Si ce bug est détecté en cours de recette, on repasse alors par le circuit de développement dans le sprint actuel. Si par contre, celui-ci est détecté durant la phase de production, on le placera alors dans le backlog pour développement dans un futur sprint, ou faire un hotfix sur la production en fonction de la criticité du bug. Un hotfix correspond à une mise à jour rapide d’un logiciel, lorsqu’un problème urgent est détecté.
Le PO : un véritable sprinteur
Une autre mission du Product Owner : se tenir à disposition pour rappeler de façon rapide et concise les objectifs du produit, étant donné qu’il doit le connaître sur le bout des doigts !
D’ailleurs, une durée assez longue d’un sprint peut créer une brique complète du produit. C’est pourquoi il est conseillé de capitaliser votre sprint sur la vélocité de l’équipe, et que la durée idéale est comptée entre 3 à 4 semaines !
Pour ce qui est de l’équipe, on dénombre au mieux de 3 à 9 développeurs ! Pas mal n’est-ce pas ?
PO, au repos !
Et ça donne quoi un Product Owner en mission ?
Parce qu’il n’y a rien de plus parlant qu’un exemple concret, juste pour vous, nous avons interviewé un de nos PO chez Amiltone, parti en mission.
Freddy, en mission chez un de nos clients dans le domaine de la santé.
Dans son équipe, nous retrouverons :
- Un Manager Product Owner (le fameux MPO dont nous avons parlé plus haut),
- Deux Product Owners,
- Une référente technique,
- Un scrum master;
- Et trois développeurs.
N.B. : Nous n’avons pas encore parlé du scrum master. C’est la personne qui sera chargée d’animer les daily, les rétrospectives, les sprints mais aussi de faire respecter le workflow agile à l’équipe. Il lève les obstacles de l’équipe de développement, aide l’équipe à développer son auto-organisation… Il est le facilitateur et le garant de la méthodologie, et permet de débloquer les situations. C’est un peu celui qui répand la bonne humeur entre autres !
De plus, cet exemple de composition d’équipe est typique d’un projet numérique.
Et à chaque fin de sprint, il se passe ce que nous appelons un “sprint review” et un “sprint retrospective”. Chacun fait sa démo et parle de ses ressentis, dans le positif comme dans le négatif ! C’est également le moment de préparer les prochaines améliorations : méthode, process, etc.
Allez, déroulons le tapis rouge !
C’est parti pour un exemple concret d’une “cérémonie” : tout est une question de timing.
Tout commence par un Daily scrum : environ 15 minutes.
Le Daily scrum est concis, et permet d’identifier les objectifs.
Au programme :
- Vérifier que le sprint goal tient toujours,
- Ajuster le travail au besoin.
Ensuite, un poker planning : de une à deux heures.
Le but ?
- Sélectionner des évolutions du backlog à estimer.
Passons au sprint review : environ une heure.
Ce temps imparti est réservé aux développeurs :
- Ils vont alors faire une démonstration du sprint fini.
Et enfin, le fameux sprint rétrospective : de une à deux heures.
La finalité :
- Remonter les difficultés, améliorations et points positifs du sprint,
- Établir les objectifs futurs.
Bien évidemment, selon les équipes et les projets, cet ordre peut varier, et s’inverser. C’est à vous de voir et de vous adapter selon les besoins et bon vouloir de chacun !
Il est important de rappeler que l’objectif d’un poker planning est de présenter et d’estimer les prochaines évolutions à effectuer sur les prochains sprints.
Quand nous parlons d’estimer, il s’agit bien de se mettre d’accord, et de parler en termes de points.
Vous allez me dire… des points ?
Maintenant, c’est carte sur table
Le poker planning marche selon la suite de Fibonacci, qui correspond à une suite exponentielle. Plus le chiffre est gros, plus l’évolution est compliquée.
Il arrive également que l’évolution visée soit trop haute, les développeurs doivent alors la diviser en deux, et donc découper la fonctionnalité en deux temps.
Mais une fois n’est pas coutume, donnons un exemple !
« Entre 0 et 1 : c’est juste du texte à changer.”
“Entre 1 et 8 : des plus grosses modifications.”
“Entre 8 et 13 : nous avons vu trop gros, les développeurs doivent diviser l‘évolution. »
Les avantages et les inconvénients du PO
Comme le dit l’adage : qui peut le plus, peut le moins !
Les avantages du Product Owner sont nombreux :
- Il connaît son périmètre grâce à sa vision globale du projet,
- Il priorise les développements,
- Il est le point d’entrée si une question intervient, qu’elle vienne de n’importe quelle personne de l’équipe. Il peut facilement rediriger, il est de partout, sur tous les points,
- Il n’est pas nécessairement technique, même si cela peut être un plus,
- Il peut être sur des sujets divers (la QA, l’UX/UI, etc.),
- Les interlocuteurs sont alors multiples, selon les missions, il peut vraiment parler à tout le monde,
- Il est le booster de l’équipe (moral, compréhension des sujets) : il peut alors accompagner si quelqu’un a du mal.
Cependant, quelques inconvénients restent présents :
- Selon la mission et le client, le poste peut varier. La question de “qu’est-ce qu’un vrai PO ?” se pose alors. Il peut donc louper certaines choses s’il va sur trop de terrains,
- L’adaptation aux domaines de compétences hors périmètres peut également être un problème : “Au fond, qui suis-je pour valider telle ou telle chose ?” par exemple,
- En étant le seul contact, l’information donnée peut guider jusqu’à une mauvaise direction, et donc vers un mauvais développement. Cela peut venir de trop de confiance aveugle.
Quelques outils pour devenir le meilleur PO possible
Azure DevOps, le service couvrant tout le développement dont vous aurez besoin, pour :
- Les tickets (epics, User stories, tâches, bugs…),
- Les tests (rédaction et exécution),
- Les repositories (gestion du code de l’application),
- La CI/CD.
SharePoint, une solution d’intranet dédiée au travail d’équipe, pour :
- Les documents (manuels et guides utilisateurs, notice de version…),
- Les spécifications de chaque module de l’application.
Freshdesk, le logiciel de service client qui vous simplifiera la vie en tant qu’outil de ticketing et de support utilisateur.
Notion, l’issue de prise de notes individuelle ou collaborative, pour l’organisation.
Vous l’aurez compris, être Product Owner, c’est être mis à rude épreuve lors d’une mission. Vous êtes partout, tout le temps, sur tous les fronts. Véritable “passe-plat” et touche-à-tout, vous serez en quelque sorte le leader de l’équipe, celui à qui l’on fait confiance.
Beaucoup d’avantages, et, certes, quelques inconvénients. Mais, ne serait-ce pas ce qui fait les joies et le bonheur d’un bon métier ?
Si vous souhaitez en savoir plus, que ce soit sur le métier de PO, ou sur les métiers qui composent Amiltone, n’hésitez pas à nous contacter !