Trop souvent, le changement fait peur et la facilité consiste à seulement trouver une correspondance entre l’ancien monde et le nouveau. Les bénéfices apportés par le nouveau monde ne sont alors pas compris et donc optimaux. Dans les transformations digitales, en passant d’une approche projet à une approche produit, combien de chefs de projet ou leader technique se sont retrouvés du jour au lendemain Scrum Master ? Combien d’AMOA ou chef de projet fonctionnel ont été décrétés Product Owner (PO) et tout ça sans accompagnement ? Loin de moi l’idée que ces personnes ne sont pas capables de tenir ces rôles, mais il faut que les rôles soient bien compris afin de maximiser les bénéfices de cette transformation.
Les raccourcis sont trop faciles à prendre et cet article a pour objectif de partager une liste non exhaustive de tâches/responsabilités du PO héritées d’autres méthodes de travail et qui ont un intérêt limité (voire inexistant) dans sa nouvelle mission principale : porter la vision produit, maximiser le ROI et la valeur délivrée.
“Le PO écrit des spécifications détaillées”
Commençons par le plus classique : en tant que nouveau PO, on va sûrement vous demander d’écrire une spécification détaillée du besoin. Si c’est le cas sur votre projet, commencez par vous interroger sur la nécessité d’avoir une spécification fonctionnelle détaillée (la fameuse SFD) et à qui s’adresse-t-elle. Les stories ne sont-elles pas suffisantes ? Un simple wiki avec les informations principales ne peut-il pas faire le job ? “Working software over comprehensive documentation”, cela ne vous rappelle rien ? L’Agile manifesto bien sûr. Si vous voyez tout de même une raison valable à cette spécification, essayez de la rendre la plus simple possible en ciblant surtout les éléments qui nécessitent cette spécification. Le but de cette simplicité? Réduire les coûts de mise à jour de cette documentation.
N’oubliez pas que vous êtes responsable de la vision produit et du coup un interlocuteur clé dans l’organisation, notamment de l’équipe de développement, des parties prenantes et des utilisateurs. Cette activité est chronophage mais elle est cruciale dans l’organisation, ce doit donc être l’une de vos préoccupations principales.
“Le PO s’occupe de la phase de recette”
Sur un projet Agile, la recette doit être effectuée en continu. Hormis quelques cas spécifiques, il ne doit donc pas y avoir de phase de recette à proprement dit. Certes, le PO participe à la définition des critères d’acceptation des stories, mais c’est à l’équipe de développement de s’assurer que les tests en lien avec ces critères d’acceptation sont passés avec succès. En Agile, l’équipe de développement est responsabilisée sur la qualité et cela passe aussi par les tests. La mise en place de BDD (Behaviour Driven Development) est une bonne pratique à mettre en place sur les projets pour partager la vision de ce qu’il faut développer à travers les attendus en termes d’exemples. Des ateliers menant à un “example mapping” sont une manière de co-construire et partager de manière synthétique ces tests.
Le PO se doit, lui, de valider la solution à minima via des tests libres pour s’assurer de la cohérence fonctionnelle du produit, de sa simplicité et de son efficacité, mais aussi dans le but d’identifier ses manques actuels et ainsi participer à l’amélioration continue du produit.
“Le PO est responsable de l’équipe”
Le PO fait partie de l’équipe (à la différence d’un MOA), ni plus ni moins. Ce n’est pas un chef de projet et pour que l’équipe fonctionne de manière efficace, il n’a aucune relation hiérarchique sur l’équipe. Il doit se concentrer sur ce que fera le produit au niveau fonctionnel. Il revient à l’équipe de définir la conception de la solution, que ce soit au niveau design/ergonomie (si un UX/UI est présent dans l’équipe) ou au niveau de la conception technique. Le PO donne un objectif (réaliste) et définit avec l’équipe ce qui doit être développé pour atteindre cet objectif. L’équipe est au plus proche de la réalisation, elle est donc la plus légitime pour estimer et savoir ce qu’il est possible de faire. Le PO ne peut que challenger mais n’a en aucun cas le dernier mot comme il s’agit au final d’un engagement de l’équipe. L’équipe est responsable de son travail et de son engagement, pris d’un commun accord.
Mais alors, qui est “responsable” de l’équipe? Au-delà de l’organisation hiérarchique au sein de l’entreprise, personne d’autre que l’équipe elle-même n’en est responsable. Cette autonomie et auto-responsabilisation doit faire partie des transformations Agile. Il faut tout de même que l’équipe garde en tête que le but est de délivrer un produit avec des contraintes business, de qualité et de time-to-market et c’est au PO de rappeler à l’équipe ces contraintes si nécessaire. Le PO reste cependant responsable pour donner les ressources nécessaires à l’équipe pour répondre à ces contraintes et délivrer de manière efficace un produit à forte valeur.
Vous aurez compris que le PO n’est ni un MOA, ni un testeur, ni un chef de projet fonctionnel. Il est un rôle différent agissant sur des projets Agile où la responsabilisation et l’auto-organisation de l’équipe, la démarche incrémentale ainsi que l’approche “user-centric” font que cela demande une adaptation et un accompagnement dans la transformation et le changement de mindset. Le PO doit savoir comment optimiser son temps et son énergie pour apporter le plus de valeur possible à son produit. Avoir un bon PO, c’est la certitude d’avoir un bon sherpa qui vous guidera dans le développement d’un produit répondant au mieux aux besoins des utilisateurs tout en favorisant la communication entre les différents acteurs (utilisateurs, parties prenantes, équipe de développement) afin de créer une dynamique positive autour de ce produit et ainsi maximiser sa valeur pour l’utilisateur.
Petite astuce pour finir à destination des futurs PO : avant de faire, commencez par vous poser la question de “Pourquoi” je fais cette tâche et qu’est-ce qui se passe si je ne la fait pas afin d’éviter de gaspiller du temps sur des tâches à faible valeur.
