Lors du dernier article nous avons introduit l’agilité en essayant d’être didactique pour clarifier les possibles sources d’incompréhension sur ce sujet de Product Owner.
Sur ce nouvel article, nous allons faire de même, en ciblant maintenant l’un des rôles de Scrum (une des approches agiles), celui du Product Owner.
La culture Produit et la culture Projet
Au sein d’une équipe (ou d’une entreprise), nous pouvons avoir une approche plutôt tournée vers une culture Produit, ou bien vers une culture Projet.
Le Produit
Pour pouvoir développer sur la différence entre les deux approches, commençons donc par définir ce qu’est un produit. Le dictionnaire Larousse définit le terme « Produit » de la façon suivante :« Ce qui résulte d’une activité, d’un état, d’une situation quelconque » et aussi « Ce qui naît d’une activité de la nature ou de l’homme ». Nous travaillerons dans cet article avec cette deuxième définition : les produits résultants de l’activité humaine.
Le concepteur d’un produit (son Product Owner) aperçoit des opportunités dans la réalité et conçoit quelque chose qui a de la valeur pour quelqu’un.
Un exemple d’un Product Owner connu serait Steve Jobs. Il amena sa vision de produit à une équipe d’experts dans les technologies nécessaires, qui, après plusieurs itérations en autonomie et auto-organisation, ont abouti à la création d’un produit disruptif : l’iPhone.
Le Projet
Ayant défini ce qu’est un produit ci-dessus, il nous reste à définir ce qu’est un projet. Le mot « Projet » a pour origine le latin, avec pro (en avant) et jacere (jeter), ce qui viendrait représenter du coup ce que nous faisons avant de démarrer l’exécution.
Aujourd’hui le concept de projet n’est plus exactement le même. Il inclue cet aspect de préparation à l’exécution, mais aussi l’exécution elle-même.
Le Project Management Institute (PMI), définit un projet de la façon suivante : « un projet est un effort temporaire qui a pour objectif de créer un produit, service ou résultat unique. Il est temporaire dans la mesure qu’il a un début et une fin définis dans le temps, et par conséquence a aussi un périmètre et un budget définis ».
Un projet a pour objectif d’amener une idée à sa réalisation. Lors de la planification d’un projet, le chef de projets ira délimiter de façon détaillée le périmètre, en se basant sur plusieurs jalons et en ayant d’avance prévu le coût (monétaire et en temps). Le chef de projets viendra donc intervenir en s’assurant que chaque membre de l’équipe maintienne l’exécution correcte de ses tâches dans le délai imparti.
La définition de succès
Maintenant que nous avons en main la définition de chacun des termes, nous pouvons parler plus précisément des différences entre les deux approches. Posons-nous la question « Qu’est ce qui compte pour l’équipe ? Sur quoi juge-t-on sa performance ? »
Le succès dans une approche Projet est défini en avance lorsqu’on définit l’objectif, le budget et le temps imparti pour la livraison, et avec des mesures internes au projet lui-même. Dans un projet, nous avons une date de fin prévue, le client est bien identifié et c’est le respect du contrat défini qui compte. Si jamais lors du travail l’équipe s’aperçoit que le chemin défini au préalable n’est pas forcément le meilleur, il n’y a pas de marge pour changer sans que cela signifie une renégociation du contrat. Ce qui compte, à la fin, c’est de suivre les spécifications et les règles définies initialement. Le taux de succès sera donc mesuré en voyant l’écart entre ce qui a été prévu initialement par le chef de projets et ce qui a été exécuté, en terme du fameux triptyque Périmètre-Coûts-Délai.
À l’opposé, dans une approche Produit, ce qui compte c’est le succès du produit, son acceptation par l’utilisateur final (qui n’est pas forcément le client) et sa rentabilité. Si on se pose la question « Que veut le client ? », c’est facile à voir que le client se préoccupe plutôt des effets du produit qui lui est livré et pas forcément du projet en soi. L’objectif étant de livrer le plus de valeur possible au client, il vaut mieux donc avoir une approche qui nous permette de livrer cette valeur à travers des produits qui lui conviendront. L’approche produit mène à un alignement entre les objectifs du client et ceux de l’équipe de développement, ce qui favorise naturellement la collaboration.
Le succès d’un produit étant défini par sa réceptivité et son utilisation par le client, mesurer son succès en se basant sur des critères imposés de façon externe (comme avoir ou pas une augmentation du chiffre d’affaires) a plus de chance de succès à long terme dans la vie réelle qu’une simple exécution efficace des tâches (qui serait le succès dans une approche projet).
Nous passons donc d’une approche Projet à une approche Produit en changeant les métriques de succès (qui découlera aussi dans un changement de la façon de travailler), en nous approchant de ce que veulent les clients par des critères comme l’augmentation de performance, la hausse des ventes ou bien l’auto-évaluation de leur satisfaction par exemple. La façon d’impacter ces métriques est donc de livrer quelque chose qui a de la valeur le plus rapidement possible, qui va valider ou invalider les hypothèses business prises.
Résumons les principales différences entre les Modes Produit et Projet par le tableau suivant :
Comme le critère de succès du projet se base sur le triptyque PCD, la qualité est souvent utilisée comme une variable d’ajustement pour que le succès soit assuré. Dans l’approche produit, le but étant de satisfaire le client et les utilisateurs, la qualité devient non négociable, car la satisfaction y est intrinsèquement liée.
La vision produit
Comme exprimé ci-dessus, il y a des bénéfices à implémenter une approche Produit plutôt qu’une approche Projet. Pour faciliter ceci, permettez-moi de vous présenter l’important outil de la vision produit.
Selon Roman Pichler, un expert du Product Management bien connu des communautés agiles, « La vision produit est le but ultime qu’on vise, la raison de créer le produit. Elle apporte un sens de propos continu dans un contexte qui change tout le temps, ainsi que de la motivation en montrant le pourquoi on travaille, facilitant ainsi une collaboration efficace ». Si la vision de produit est claire, ça permet à la direction d’aligner l’objectif avec les équipiers, et aux équipiers de se porter de façon autonome entre ses différentes tâches, sans devoir remonter des décisions d’arbitrage aux instances supérieures.
Une bonne partie de la définition de qualité pour un produit vient justement dans sa vision. La vision d’un produit peut exister dans le contexte de l’entreprise (comme celui d’IKEA par exemple – Créer un meilleur quotidien pour le plus grand nombre de personnes.), ou bien dans le contexte d’une équipe (comme « Aucun utilisateur sans réponse »). Il revient au Product Owner de porter la vision du produit et s’assurer que l’équipe l’ait en tête et au cœur dans leur travail.
Parfois il se peut que les technologies ne soient pas assez développées pour l’implémentation de la vision du Product Owner, ou bien que l’équipe n’ait pas assez de d’expertise pour l’exécuter. Cependant ces risques peuvent être minimisés en faisant des cycles courts d’expérimentation (le Sprint). Ce processus est nommé Scrum.
Scrum
Dans le Scrum Guide (document officiel décrivant la méthodologie Scrum), Scrum est défini comme un « Cadre de travail léger qui aide les personnes, les équipes et les organisations à générer de la valeur grâce à des solutions adaptatives pour des problèmes complexes».
Pour comprendre ce qui est un problème complexe, référons-nous à l’extrait de la Matrice de Stacey présente dans la formation Product Owner proposée par Invivoo
Ou encore, si nous ramenons ces notions de la matrice à des exemples concrets (table préparée par Glouberman and Zimmerman – 2002) :
Finalement, un exemple de problème Chaotique/Anarchique serait une catastrophe naturelle, où nous avons un niveau très grand d’inconnues et où aucune approche ne peut fonctionner. Il faut alors ramener une partie du problème dans la zone du complexe.
En résumé, nous pouvons décrire Scrum comme étant un processus itératif et incrémental (ce qui est très lié à l’agile, souvenez-vous du premier article sur l’agilité) pour développer, délivrer et maintenir des produits complexes.
Dans ce contexte, le rôle du Product Owner dans le Scrum est défini comme le « responsable de maximiser la valeur du produit résultant du travail de la Scrum Team ».
Conclusion
Une culture de développement tournée vers le produit plutôt que vers le projet permet d’obtenir un résultat final qui convient mieux au client, car l’objectif n’est plus de respecter le contrat mais de livrer le plus de valeur possible au client.
De plus, avoir une vision de produit claire permet un meilleur alignement entre les objectifs de la direction et des équipiers, ce qui mène à la possibilité d’un plus grand degré d’autonomie pour les équipiers.
Ayant fait cette introduction aux différences des cultures Produit et Projet, et aussi au rôle du Product Owner dans le cadre de Scrum, nous sommes prêts à commencer à regarder plus en détail le rôle du Product Owner en soi.
Rendez-vous ici, sur le blog d’Invivoo, pour le prochain article où nous aborderons les différentes tâches relatives au métier de Product Owner, ainsi que des outils qui peuvent aider à les accomplir.
Pour toute question ou commentaire relatif à cet article, n’hésitez pas à me laisser un message ci-dessous.
Pour lire la suite, cliquez ici :
