Je suis un Product Owner… Un quoi ?

Au moment où j’écris ces lignes j’occupe le rôle de Product Owner chez Profideo. Je me donne 20 minutes pour vous expliquer en quoi ça consiste. C’est parti !

Le contexte d’abord. Il y a environ 2 ans, on me nomme chef de projet dans une petite équipe informatique au sein d’une société dont le métier à la base n’est pas du tout focalisé IT. Mon premier reflexe est d’employer la bonne vieille méthode qui a court à ce moment là, l’arrache.

Il faut voir que dans une petite structure très dynamique, cette méthode a plein d’avantages, à commencer par le fait qu’elle impose une espèce de connivence très particulière entre le commanditaire d’un nouveau besoin et le chef de projet. Par certains aspects, ça ressemble un peu à la relation entre un serveur de brasserie et sa cuisine :

• Chaud devant ! J’ai besoin d’une évolution fonctionnelle pour la table 6 ! Et au passage la 4 attend toujours son correctif de bug ! Ah et puis, j’ai la 3 qui demande si on peut lui rajouter un morceau de l’application A sur l’application B, mais avec la sauce à part. J’ai dit pas de problème. C’est pour hier…
• OK Dédé, on envoi, mais y’avait plus d’application B en stock et le stagiaire à fait cramer le serveur avec les correctifs, mais t’inquiète y’a Jean-Louis qu’a développé une fonction aux petits oignons à la place, on t’en met à toutes les tables, si t’offre les café avec, ils seront ravis.

Bon ne vous attardez pas trop sur la puissance des dialogues (je n’ai que 20 minutes après tout), mais comprenez bien qu’on est dans un système de débrouille qui a le mérite d’être basé sur la communication et les itérations rapides. Tout est orienté pour faire en sorte que le client soit content (même s’il n’obtient pas ce qu’il a demandé).

Assez vite, j’ai voulu apporter un peu plus d’ordre et d’organisation dans tout ça. Ce qui m’apparaissait évidant c’était qu’il fallait a tout prix conserver cette communication et ces aller-retour très fréquents, quelle que soit le mode d’organisation choisi. Pour vous la faire courte à ce stade (le chrono tourne, ou plutôt le bus arrive) le mouvement autour des méthodes Agiles s’est imposé à moi et Scrum en était le fer de lance.

Le Product Owner = l’un des trois rôles de Scrum

D’abord, il a fallu répartir les rôles. Dans Scrum, il y en a trois : le Scrum Master, le Product Owner et l’équipe. Pour le troisième, les choses sont évidentes, pour les deux autres c’est plus subtile. La méthode Scrum commence par expliquer qu’il n’y a plus de chef de projet, car les plannings et la hiérarchie c’est beaucoup trop old-school (bien-sûr la méthode avance des arguments plus tangibles que je ne détail pas) et parce-que l’équipe est auto-organisée. Bref, plus besoin d’un supérieur qui explique qui doit faire quoi. Dans Scrum, on se focalise sur le fait de livrer des choses, coûte que coûte, à intervalles régulières (toutes les deux semaines pour nous). Ce qui repose la question de l’organisation en ces termes : qu’est-ce qu’on livre à l’issue du “sprint” (le petit nom qu’on donne à nos itérations) et comment on y arrive ? Le Product Owner et le Scrum Master sont respectivement là pour répondre à ces deux questions. Le premier défini ce qu’il y a à faire pendant que le second est un peu le capitaine (comme au foot) qui va coacher, animer, l’équipe pour la faire parvenir à son but.

Je ne veux pas trop m’étendre ici dans le rôle du Scrum Master qui est un sujet en soit, mais plutôt expliquer ce que je fais, en tant que “PO” (Product Owner), et en quoi c’est important dans ce type d’organisation.

[Mode je raconte ma life] A ce stade j’ai bien sûr éclaté les 20 minutes (fallait s’y attendre). Je fini tranquillement devant la TV. De toute façon ma femme corrige des copies et ma fille de 5 mois dors paisiblement (Quand je vous dis que je vais avoir le temps d’alimenter ce blog…). [/ Fin du mode je raconte ma life]

Le terme anglais “scrum” désigne la mêlée au rugby. Cette métaphore sportive, tout comme le fait de travailler toujours dans le cadre d’un “sprint”, sont les indices de l’ambiance et l’état d’esprit que la méthode doit instaurer. Il s’agit d’être focalisé, voir passionné, par un but précis sur une période très courte. C’est très intense. Dans ce cadre, il faut que les choses soient extrêmement claires dès le départ. Du coup on élimine tout le superflus :

• Pas de cahier des charges
• Pas de temps mort
• Pas d’échange entre l’équipe et le client
• On passe en revue le travail à faire, on l’évalue, on le découpe… et on fonce

Dans ce cadre, seul le PO fait l’interface entre l’équipe et le commanditaire du besoin (un peu comme le serveur qui fait l’interface entre le client à sa table et la cuisine). Du coup, il doit être énormément sollicité pour répondre aux questions et faire tous les arbitrages nécessaires, à chaud, pour ne pas retarder l’équipe. C’est pourquoi la méthode stipule même qu’il doit être présent sur place, disponible. S’il n’a pas la réponse, il est le seul habilité à interroger le client final (c’est un gage de cohérence).

Alors, être prêt et dispo à chaud c’est une chose, mais bien-sûr on réalise (parfois dans la douleur) que pour ne pas refaire de la tambouille à l’arrache, il faut avoir super bien préparé son coup. Ou plutôt ses “stories”…

L’arme fatale du Product Owner : les User Stories

La “story” c’est l’unité de travail (la granularité comme on dit par chez nous) à travers laquelle est découpé tout ce qu’on fait faire à l’équipe. On dit qu’une story est un “incrément fonctionnel” apporté à une application. Après, la réalité qu’on met derrière est très discutable, mais on la comprend assez intuitivement par le fait qu’il s’agit d’une évolution qui doit apporter une possibilité fonctionnelle en plus au client (les stories “techniques” qui n’apportent pas de résultat perceptible par les utilisateurs sont à bannir).

Quand on démarre un sprint, le PO doit expliquer à l’équipe le détail des stories qui vont être prises en charge (c’est l’équipe qui détermine combien de stories on traite, mais c’est une autre histoire). Il doit alors littéralement transmettre à l’équipe toute la connaissance nécessaire pour réaliser chaque évolution : le contexte, le besoin, la stratégie, les implications… Il doit avoir une vision parfaitement claire de ce qu’il s’attend à obtenir lors de la livraison. Il s’aide de tout ce qui permet de partager rapidement cette vision. On comprend facilement qu’un cahier des charges n’est surtout pas le bon outil dans cet exercice. Non, là on parlera plutôt de prototypage à base de maquettes, wireframes, Excel, HTML… Bref, tout ce qui peut servir à rendre les choses concrètes et à lever toute ambiguïté dans l’esprit de l’équipe. C’est pourquoi la méthode suggère aussi d’accompagner les stories de “testes d’acceptation”. Ce sont des indications qui explicitent à l’équipe encore plus ce que le PO s’attend à voir à la fin du sprint. Il s’agit en quelque sorte de prédire ce qui va se passer (si tout va bien) pendant la revue finale : “je vais me connecter sur l’application X en tant qu’utilisateur Y, puis je vais faire les actions A, B, C et là je m’attends à constater tél et tél résultat”.

Du coup, un PO c’est forcément un mouton à 5 pattes : quelqu’un capables de comprendre les besoins et la stratégie du client, traduire ça en fonctionnalités applicatives, prototyper les interfaces et les comportements de l’outil… Dans une structure comme la mienne il faut aussi être un peu directeur artistique, pour éviter au maximum les aller-retour de validation et pour concrétiser au maximum la vision du produit. Il faut surtout être capable de fédérer le client et l’équipe autour d’une vision commune.

En gros, Product Owner, c’est un métier.