Les rôles et le produit - épisode 1 : Product Manager, Product Owners, Business Analysts

Il existe plusieurs termes que nous utilisons pour désigner les personnes qui s’occupent de la valeur métier d’un produit. L’existence de tout ces mots n’est pas un problème, aussi longtemps que nous nous mettons tous d’accord sur ce que sont ces différentes personnes et qu’elles prennent la responsabilité qui va avec. Si nous ne sommes pas d’accord, nous courrons le risque de ne pas être en mesure de maîtriser notre stratégie, de ne pas penser en terme de problèmes, et de ne pas être en mesure de maîtriser nos tactiques. Voici comment j’envisage les différents rôles agiles en lien avec le produit : product managers, product owners, et business analysts¹.

Le Product Managers gère la stratégie du produit

Il s’agit de quelqu’un (et par là je veux dire une seule personne) qui défend la cause du produit auprès des clients, auprès des personnes qui prennent les décisions stratégiques de l’entreprise, et auprès des personnes de l’organisation.

Cette personne pourrait travailler avec les clients pour comprendre les différents problèmes que le client rencontre. Cette personne pourrait alors travailler avec d’autres personnes dans l’organisation pour définir les problèmes que l’organisation veut résoudre pour ces gens.

Le product champion/product manager travaille aussi avec les gens qui font les décisions stratégiques pour l’organisation. Ce groupe de personnes peut porter différents noms :

• Le comité/groupe/équipe opérationnel(le)
• L’équipe en charge du portefeuille projet
• Le PMO (Project Management Office)

Quel que soit leur nom, ces gens ont en charge la stratégie de l’organisation et décide de quelle variété de produits et de services l’entreprise va offrir pour remplir sa stratégie. (J’ai déjà écrit à propos de la stratégie dans Manage Your Project Portfolio.)

Vous pourriez désigner cette personne sous le terme de product champion, product manager, ou sous un autre terme qui montre cet aspect stratégique du rôle de cette personne.

(Je n’apprécie guère le terme de « Chief Product Owner» parce ce que je n’apprécie pas le terme « Chef ») dans une approche agile. Et l’expression « Chief Product Owner» ne décrit en rien la nature stratégique du poste.

Un product champion passe la plupart de leur temps avec les clients, avec les commerciaux (pour voir les problèmes potentiels à résoudre), et avec les équipes de direction pour définir la stratégie de l’organisation.

Remarque : la planification stratégique ne peut pas être évoquée qu’une fois par an. Elle doit être continue et itérative. Je suppose que cela devra faire l’objet d’un autre article à part entière.

Je pense au product manager/product champion comme la personne qui définit le « problème dans sa globalité ». C’est une des raisons pour lesquelles cette personne apprécie avoir des feuilles de route à grosse mailles. Ces feuilles de route aident les gens à se projeter dans le futur du produit et dans l’aspect stratégique.

Et le product champion doit travailler avec les gens qui travaillent au quotidien avec les équipes, les product owners. Lorsqu’ils le font, les feuilles de route sont créées en équipe.

Les product owners définissent les problèmes que les équipes vont résoudre

Les équipes ont besoin de problèmes à résoudre. Elles n’ont pas besoin qu’on leur dise de « créer un bouton radio » ou « d’utiliser ce champ » ou qu’on leur dise tel ou tel détail spécifique de conception ou d’implémentation comme « utiliser un minuteur chien de garde² »

Les équipes sauront quoi faire si quelqu’un leur défini le problème à résoudre. Les product owners définissent ces problèmes.

Les product owners embrassent la vision à long terme et la vision à court terme. Ils travaillent avec l’équipe pour créer la vision du projet. La vision représente l’objectif et les critères de livraison pour celle-ci.

Cela signifie que la vision à court terme comporte des expériences, des produits viables à minima ³, des fonctionnalités commercialisables à minima⁴, tous les livrables intermédiaires. Les livrables intermédiaires créent les points de décisions pour le projet/programme :

• En tant qu’organisation, en avons-nous fait suffisamment pour ce produit pour l’instant ? Est-il de temps de passer cette équipe sur un autre produit ?
• Concernant le produit, quelles décisions devons-nous prendre par la suite ? Quel est le plus petit pas possible que nous pouvons faire pour arriver au prochain moment décisif ?
• Reste t’il encore quelque chose de valeur dans le backlog pour ce produit, à aujourd’hui ?

Vous pourriez avoir d’autres questions bien sûr.

Ces questions et l’effort qu’elles impliquent signifient que le product owner est affilié à l’équipe et qu’il travaille avec le product champion.

Le product owner a dans la main les livrables suivants :

• une vision à plus ou moins long terme allant de quelques semaines à quelques mois de la feuille de route du produit montrant l’ensemble des livrables y compris les expérimentations. Les feuilles de route montrent les problèmes à résoudre, le plus souvent sous la forme d’un ensemble de fonctionnalités.
• Éventuellement une cartographie des impacts⁵ pour être capable de décider entre quoi et quoi l’équipe doit agir « maintenant »
• Des stories bien définies pour les prochaines semaines ou pour un mois. Mon expérience : créer des stories bien définies pour une semaine ou deux de boulot s’avère souvent suffisant tant que la vague de planification est courte elle-aussi.
• Travailler avec l’équipe quotidiennement pour expliquer/affiner les problèmes ou les stories. Même lorsque les POs définissent les stories correctement, lorsqu’ils les regardent à nouveau, ils se cachent le visage avec leurs mains. Ils réalisent seulement maintenant ce qu’ils veulent vraiment.

Parce les POs travaillent avec l’équipe quotidiennement, ils ne peuvent pas aller voir souvent les clients. Ils pourraient avoir besoin d’aide à comprendre les problèmes que le product manager voit. C’est là que le business analyst (BA) pourrait être d’un grand secours.

Les BAs aident à affiner l’énoncé du problème

Les BAs clarifient l’énoncé du problème. Les BAs pourraient faire les entretiens des clients et des potentiels clients pour aider tout le monde à comprendre ce qu’il se passe. Les BAs pourraient même aider à définir les stories et les critères d’acceptation pour l’équipe.

Si vous en avez besoin, les BAs peuvent s’occuper du manque de précision du product champion et des détails du PO.

De quel(s) rôle(s) avez-vous besoin ?

Dans une petite organisation, le product manager est product owner et BA. Oui, une personne essayant de remplir tous les rôles. On appelle souvent cette personne un Product Owner (PO) ou un Product Manager.

Cette personne se sent souvent tirée dans plusieurs directions pour faire son boulot correctement. C’est parce qu’elle est supposée faire toutes les choses qui suivent :

• Voir/consulter et potentiellement définir une partie de la stratégie de l’organisation
• Traduire la stratégie en un ensemble de fonctionnalités
• Travailler avec le client pour définir les problèmes
• Travailler avec les équipes pour expliquer les problèmes, créer les ensembles de fonctionnalités, et les stories
• Travailler avec l’équipe pour vérifier qu’une story donnée résout un problème spécifique tel qu’il a pu être retranscrit par cette personne à partir des dires du client
• Consulter le client afin de faire en sorte que la solution règle bien le(s) problème(s) du client.

Si vous avez une petite organisation mono-produit avec une ou deux équipes, cela peut marcher; C’est beaucoup de travail pour le PO, mais c’est faisable.

Dès lors qu’une personne est supposée défendre plus d’un produit ou travailler avec plus d’une équipe, cela devient un rythme insoutenable.

Oui, nous nous soucions ordinairement qu’il y ait un rythme soutenable pour les équipes de développement. Nous devons faire de même pour les POs aussi.

Une équipe orientée valeur produit peut aider les différents rôles à avoir un rythme soutenable. J’en parlerai davantage dans un prochain article.

Auteur : Johanna Rothman
Source : Product Roles, Part 1: Product Managers, Product Owners, Business Analysts
Date de parution originale : 2 Avril 2019

Traducteur : Nicolas Mereaux
Date de traduction : 17/04/2019

Ce(tte) oeuvre est mise à disposition selon les termes de la Licence Creative Commons Attribution - Pas d’Utilisation Commerciale - Partage dans les Mêmes Conditions 4.0 International.