Les 7 qualités du Product Owner

Le Product Owner est le « Propriétaire du produit ». La tâche paraît simple et claire, mais détrompez-vous !  Le Product Owner est aussi bien un chef de produit qu’un ingénieur système, un ergonome, un architecte logiciel, un analyste métier, un ingénieur qualité et même un rédacteur technique. Le Product Owner doit porter plusieurs casquettes ! Pour ce faire voici les compétences dont il a besoin :

PO

Le Product Owner est un des membres de la chaîne du processus Scrum. Son rôle est de représenter le client et les utilisateurs. Nous avions vu les 6 qualités du Scrum Master. Intéressons-nous maintenant à celles du Product Owner :

Connaître et comprendre son rôle

Il est évident que le Product Owner doit connaître son métier : savoir quel est son rôle et ceci parfaitement. Il doit savoir où et quand il doit intervenir. Mais comme évoqué plus haut, son rôle s’étend sur plusieurs larges domaines, il peut donc parfois s’emmêler les pinceaux s’il ne saisit pas précisément où sont ses responsabilités et jusqu’où va son domaine de compétence. Il est souvent associé au métier de chef de projet. Il est important que le Product Owner sache que c’est à lui d’orchestrer le projet et qu’il sache dans quelles mesures il se doit d’intervenir. En effet personne ne lui dira ce qu’il a à faire, c’est bien l’inverse : c’est à lui de distribuer les tâches et les objectifs.

 

Savoir organiser

Le Product Owner est celui qui va créer et maintenir le Backlog du produit. Le Backlog est le document qui listera toutes les fonctionnalités du produit et les étapes qui sont nécessaires à sa réalisation, toutes classées par ordre de priorité. Ce document servira pour planifier les sprints. Il faut donc que le Product Owner sache prioriser ce Backlog. Il doit aussi le découper en stories de courtes tailles afin qu’elles puissent être traitées dans un sprint. Et pour ce faire des compétences dans le domaine de l’organisation lui sont indispensables.

Comprendre facilement la définition du produit et savoir la retranscrire

Le Product Owner doit comprendre vite et facilement le produit qui lui est demandé. C’est lui qui porte la vision du produit, il est le référent en matière de demande client : de tous les membres du processus Scrum c’est celui qui a le rôle le plus proche du client mais aussi des utilisateurs. Et oui on a vu que c’est lui qui donnera les tâches et les objectifs : donc c’est lui qui va gérer le Backlog du produit. Il faut alors qu’il comprenne parfaitement ce qui lui est demandé pour pouvoir le partager avec l’équipe. Afin que la demande soit compréhensible par l’équipe des développeurs il faut que le Product Owner face preuve d’un esprit de synthèse.

Pour réussir à bien comprendre et synthétiser on peut utiliser la méthode des 5W :

  • Who (qui) : A qui s’adresse le produit, la cible client
  • What (quoi) : A quoi sert le produit : quel est le produit ou le service qu’il offre
  • Why (pourquoi) : Pourquoi ce produit est utile/intéressant, qu’est-ce qui le démarque des autres
  • Where (Où) : Où sera-t-il distribué/utilisé (position géographique)
  • When (Quand) : Quand sera utilisé le produit (exemple : 24H/24 à partir du mois de Janvier)

 

Savoir gérer les attentes de toutes les parties prenantes

Comme vu plus haut : le Product Owner est la personne la plus proche du client. Il représente le client et s’engage pour lui. Il est donc de ce fait l’unique maillon de la chaine qui relie le client aux équipes. Pareil pour les utilisateurs. Il joue le rôle d’interface de communication entre les différentes parties prenantes. C’est donc à lui de gérer leurs demandes d’un côté comme de l’autre et de réussir à faire en sorte qu’elles aillent dans le même sens (ce qui est très difficile). D’un côté on a le client qui demande des choses ambitieuses (parfois trop), d’un autre on a les développeurs qui sont parfois débordés et ne peuvent réaliser des fonctionnalité en temps et en heures et encore d’un autre côté on a les utilisateurs qui donne leur avis sur le produit. C’est donc au Product Owner de faire comprendre au client que parfois certaines tâches demandent plus de temps que d’autres pour être réalisées. Tout comme il doit aussi faire en sorte que les développeurs fassent le maximum de tâches demandées par le client en respectant la vision du produit et l’avis des utilisateurs.

Être ouvert aux changements

Tous les projets peuvent avoir besoin à un moment ou un autre d’être changés, réadaptés ou encore réinventés. C’est la base de l’agilité. Un des fondements même de l’agilité selon l’agile Manifesto, c’est la 4e et dernière valeur : L’adaptation au changement.

On le sait, le client change beaucoup d’avis au cours d’un projet, et si le Product Owner n’a pas un état d’esprit assez ouvert pour pouvoir mettre en place facilement des changements : la demande du client ne sera pas prise en compte assez rapidement ce qui mènera donc à un échec. Idem pour la prise en compte de l’avis des utilisateurs.

Et même au sein des équipes : le Product Owner doit pouvoir changer le cours du projet à la fin de chaque sprint, d’ailleurs il ne doit pas hésiter à terminer un sprint en cours si un changement radical est nécessaire à la bonne conduite du projet.

Savoir se rendre disponible

Le Product Owner, aussi occupé soit-il, doit impérativement se libérer pour les équipes. Il a une position indispensable à la bonne conduite du projet il ne peut donc pas se permettre de faire le « fantôme ». Comme dit plus haut c’est le référent en matière de demande client : pour faire simple, il n’y a que lui qui sait concrètement ce que veut le client. Il doit donc absolument participer aux stand-up, aux rétrospectives, aux réunions de planification des sprints. Il doit aussi être présent si un des membres de l’équipe a besoin de lui.

Savoir guider une équipe

Le Product Owner a le rôle de chef de projet : c’est le leader du groupe. Il doit mener les équipes vers l’objectif final du client. Il doit réussir à leur faire comprendre la vision du projet et les porter dans cette direction. Pour cela il doit savoir se faire respecter par les différents membres de l’équipe tout en restant correct avec eux bien sûr. C’est à lui aussi d’accepter ou de rejeter le travail effectué. Il ne doit pas avoir peur de prendre des décisions : il doit les imposer. Bien sûr il doit le faire en prenant en compte les divers avis des membres de l’équipe.

La communication a ici un rôle extrêmement important. Il réussira à faire faire ce qu’il veut à l’équipe (ou presque) s’il sait comment leur parler. Pour cela il doit être à l’aise à l’oral et ne pas hésiter à prendre la parole. Concernant la communication encore, il doit tenir les membre informés de l’état d’avancement du projet.

Sources : Fabrice Aimetti Aubry Conseil Blog Erlem

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *