Blog ENI : Toute la veille numérique !
🐠 -25€ dès 75€ 
+ 7 jours d'accès à la Bibliothèque Numérique ENI. Cliquez ici
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
  1. Livres et vidéos
  2. Product Owner
  3. De la vision stratégique au plan opérationnel
Extrait - Product Owner Préparation à la certification Professional Scrum Product Owner™ (examen PSPO I)
Extraits du livre
Product Owner Préparation à la certification Professional Scrum Product Owner™ (examen PSPO I)
1 avis
Revenir à la page d'achat du livre

De la vision stratégique au plan opérationnel

Prérequis et objectifs

1. Prérequis

Avoir assimilé le deuxième chapitre.

2. Objectifs

À la fin de ce chapitre, vous serez en mesure de :

Construire ou vous approprier une vision produit.

Identifier la valeur d’un produit.

Établir une stratégie à partir de la vision produit.

Établir un plan opérationnel à partir de la vision produit.

Affiner votre vision et être capable de la faire évoluer au rythme des itérations.

La vision produit

Steve Sakoman est un employé d’Apple méconnu du grand public, bien qu’il ait eu une vision produit qui modifiera la vie de milliards d’individus.

Le Newton, sur lequel il commence à travailler en 1984, ne sera commercialisé que neuf ans plus tard et seulement durant cinq ans. C’est pourtant sur la base de ce modèle que Steve Jobs, personnage plus célèbre, concevra sa vision de l’iPhone.

Le téléphone multifonction que de nombreuses personnes utilisent aujourd’hui est le fruit d’une succession d’itérations plus ou moins réussies basées sur la vision produit d’un ingénieur méconnu.

images/Illus-3-1.png

1. La vision produit est la cible

La vision produit est la cible permettant d’atteindre les objectifs du produit. Pour la construire, le Product Owner doit anticiper, faire de la prospective, c’est-à-dire se projeter dans le futur pour imaginer quel devrait être idéalement le produit final. Il ne s’agit pas de chercher à concevoir comment il fonctionne techniquement, mais plutôt quel service il peut rendre aux utilisateurs. La façon d’y arriver ne dépend pas du Product Owner, mais de ses échanges avec l’équipe de développement. C’est sur cette base qu’il pourra étoffer sa vision du produit et convaincre les parties prenantes d’y adhérer. Cette dynamique crée de l’engouement, de l’engagement personnel, et nourrit la motivation de chaque individu.

Le Product Owner se base sur les objectifs du produit pour définir cette vision stratégique, mais doit également prendre en compte les contraintes, dont la contrainte structurelle liée à la nature du produit.

La vision produit est liée aux objectifs et aux contraintes du produit.

2. Les trois principales typologies de produits

Aucun produit n’est réellement identique, et il est impossible de définir une approche globale. Cependant, ils peuvent être répartis en trois grandes typologies permettant d’identifier trois approches stratégiques adéquates.

Il y a une nette différence entre un nouveau produit, qu’il faut créer de toutes pièces, et un produit existant, qu’il faut faire évoluer...

La valeur du produit

Identifier clairement la valeur du produit permet de construire une vision produit mesurable empiriquement. Cela aide aussi le Product Owner à mieux remplir sa mission : maximiser la valeur du produit résultant du travail de l’équipe de développement.

La valeur du produit est constituée d’un ou plusieurs attributs mesurables. Elle est donc propre à chaque produit, et il n’existe pas d’algorithme universel permettant de la construire.

En identifiant clairement les attributs de valeur d’un produit, le Product Owner affine la description de sa vision et accroît sa capacité à communiquer efficacement sur le produit. Cette activité nourrit également la conduite d’anticipation rationnelle, basée sur des faits et des données chiffrées.

De même que le Backlog de produit évolue tout au long de la vie du produit, la vision produit est progressivement affinée ; seule la valeur du produit est stable. Changer celle-ci reviendrait à changer de produit.

1. Identifier les attributs de valeur

Les attributs de valeur sont des constituants ou des caractéristiques du produit que l’on peut mesurer. Dans le cadre d’un produit existant que l’organisation souhaite faire évoluer, le Product Owner identifie l’amplitude de changement pour chaque attribut. Pour une société commerciale, un attribut de valeur marchande est souvent le plus important et peut se décrire de la manière suivante :

« Ce produit génère un chiffre d’affaires mensuel de 50 000 €. »

D’autres attributs peuvent venir le compléter pour décrire les coûts mensuels liés à l’exploitation de ce produit et ainsi identifier une marge bénéficiaire :

« Ce produit génère une marge nette mensuelle de 7 000 €, et nous aimerions l’accroître jusqu’à 8 000 €. »

Plus le produit dispose d’attributs mesurables permettant de définir sa valeur, plus le Product Owner dispose de moyens différents d’atteindre les objectifs du produit. Par exemple, pour obtenir une rentabilité cible, s’il ne peut plus accroître la valeur marchande...

Construire un référentiel d’exigences

Un référentiel d’exigences sert à cartographier l’ensemble des exigences liées à un produit. Cela permet de clarifier le périmètre fonctionnel d’un produit, par l’identification des exigences fonctionnelles, mais également les objectifs à atteindre et les contraintes à respecter. Dans un cycle séquentiel, la construction du référentiel d’exigences est réalisée lors de la phase de cadrage du projet et doit être la plus précise et la plus exhaustive possible. Avec un cycle itératif, ce référentiel peut être construit dans les grandes lignes, puis étoffé ou affiné à mesure que le produit est réalisé et que le Product Owner reçoit des retours des utilisateurs du produit.

Un référentiel d’exigences exhaustif comporte les exigences liées aux moyens d’atteindre les objectifs du produit, mais également celles qualifiant les besoins exprimés par les utilisateurs. Ces besoins sont recueillis sous forme d’interviews, de sondages, de statistiques, d’analyses comportementales, ou par toute méthode propre à l’organisation. Dans tous les cas, l’exigence exprime une condition essentielle : ce qui est exigé par ce moyen, ou ce que ce besoin exige.

1. La méthode descendante

Cette première partie de la constitution du référentiel d’exigences consiste à partir des objectifs, à identifier les moyens de les atteindre, puis à qualifier ces moyens par des exigences.

a. Identifier les objectifs de base

Pour identifier les objectifs de base, le Product Owner peut s’appuyer sur la description initiale du produit et sur des experts métiers ou des responsables de marché, ou bien échanger avec d’autres Product Owners, avec des Scrum Masters, mais également avec l’équipe de développement. Les principaux objectifs d’un produit apparaissent assez rapidement et font souvent consensus sur leur nature. L’identification de ces objectifs nécessite parfois plus de négociation mais demeure assez simple.

b. Identifier les moyens

Pour chaque objectif, le Product Owner...

Établir une stratégie produit

La vision du produit, constituée entre autres de ses objectifs et de sa valeur, représente un point ou une cible à atteindre. Ce point est le fruit d’une étude factuelle, basée sur des éléments existant aujourd’hui, et sur une conduite d’anticipation, basée sur des choses à venir.

La stratégie produit définit de quelle manière le Product Owner espère faire cheminer le produit de l’état actuel jusqu’à l’état cible. L’état actuel peut être représenté par un produit fonctionnel ou un produit imaginaire, tel un projet. Lorsque le Product Owner dispose d’une stratégie produit, il est capable de rassurer les équipes de développement et les parties prenantes. Cette capacité est essentielle quand l’équipe Scrum rencontrera des difficultés liées au développement du produit.

La vision du produit représente une cible, l’endroit où l’on souhaite amener le produit. La stratégie produit constitue la route à suivre.

1. Les spécificités d’une stratégie produit dans un cycle itératif et incrémental

Dans un cycle séquentiel, le chef de projet établit une stratégie de moyens sous la contrainte d’un budget et d’un délai. Ce faisant, il fige les moyens d’atteindre les objectifs, ce qui peut aller jusqu’à la production de spécifications détaillées illustrant la mise en œuvre des moyens retenus. La stratégie de moyens repose sur un organigramme des tâches et un plan de charge dont les informations seront consolidées dans un diagramme de Gantt.

L’organisation est contrainte par la charge estimée. Les moyens sont figés, et toute modification ultérieure a un impact sur le budget et le délai.

Dans un cycle itératif et incrémental, le Product Owner établit une stratégie produit. Il ne fige pas les moyens, mais se concentre au contraire sur les objectifs et leur priorisation. Il ne planifie pas l’activité par rapport à un plan de charge mais selon l’importance qu’il accorde à chaque objectif. S’il...

Un plan opérationnel

À partir de la vision du produit, s’appuyant sur la notion de valeur, le Product Owner dessine un chemin à suivre avec sa stratégie. Ce n’est pour l’instant qu’une vue théorique. Elle peut s’appuyer sur des éléments tangibles, très factuels, mais cela n’engage pas encore l’équipe. Un plan opérationnel (à ne pas confondre avec un organigramme des tâches ou un diagramme de Gantt) enjoint l’équipe à prendre le chemin tracé. Il comporte deux aspects : une vision à long terme décrivant comment l’équipe pourrait atteindre les objectifs fixés et quels sont les moyens alloués en matière de budget, de ressources ou de temps ; puis une vision à court terme affinant le cadre des prochains Sprints.

Le plan opérationnel n’est pas construit par le Product Owner, mais par l’équipe Scrum à partir de la stratégie qu’il a établie.

1. Une vision à long terme

Dans un projet reposant sur un cycle séquentiel, la vision à long terme est traduite par un diagramme de Gantt, de PERT ou un macroplanning. Ces éléments de planification reposent sur des estimations de charges et de durée portant sur ce qui doit être réalisé. Plus les moyens sont finement détaillés, plus la planification sera proche de la réalité. Cela force le chef de projet à figer durablement une stratégie de moyens.

Dans un cycle itératif et incrémental, la vision à long terme porte exclusivement sur les objectifs. Le raisonnement du Product Owner est totalement différent de celui du chef de projet. Pourquoi devons-nous tenter d’atteindre cet objectif en priorité ? C’est une question qu’il se pose lorsqu’il établit sa stratégie. Dans quel ordre serait-il judicieux de les traiter ? Combien de fois allons-nous itérer ? Combien de temps peut-on consacrer à tenter d’atteindre au mieux cet objectif ? Ce sont des questions qu’il se pose au moment d’entrer dans la partie opérationnelle.

Le Product Owner planifie l’activité à long terme afin de s’assurer...

Rédiger des critères d’acceptation

Dans le développement logiciel, certains sujets sont des sources récurrentes de conflits, voire de disputes, liés à des incompréhensions, et les critères d’acceptation en sont un parfait exemple. Ce sujet divise tant les experts que les groupes de personnes impliqués dans le développement et l’utilisation d’un produit.

Entre le Product Owner qui souhaite tout contrôler et procéder à une recette de chaque incrément et celui qui considère que tout va bien tant qu’il n’y a pas d’anomalie bloquante, il y a un grand nombre de bonnes pratiques, ces deux extrêmes étant à bannir.

1. Rappel des rôles

Ce n’est ni au Product Owner, ni aux parties prenantes, ni à une équipe AMOA de procéder à une recette de l’incrément. À chaque itération, l’équipe de développement s’assure qu’elle livre un incrément « Fini » de la manière qu’elle juge la plus efficace. Le Product Owner n’a pas à remettre en doute le travail de contrôle qualité réalisé par l’équipe ni à s’en assurer. En cas d’erreur, la rétrospective de Sprint permet d’identifier les processus à améliorer.

En revanche, en tant que pivot entre les utilisateurs, les parties prenantes et les équipes de développement, le Product Owner doit fournir à cette dernière toutes les informations qui lui permettront effectivement de délivrer un incrément « Fini » correspondant aux exigences propres au produit et aux contextes dans lesquels il peut être utilisé.

2. Les critères d’acceptation basés sur les contraintes

Le Product Owner doit au minimum indiquer les contraintes liées au produit au fur et à mesure qu’il les découvre. Sur la base de ces informations, l’équipe de développement peut alors affiner sa définition de « Fini » et s’assurer que ce qu’elle livre correspond au mieux aux besoins connus à ce jour des utilisateurs. 

La difficulté consiste à n’omettre aucune contrainte...

Affiner sa vision par rapport à la valeur du produit

Le Product Owner peut avoir une vision du produit avant même d’avoir rencontré l’équipe de développement ou la construire dans les tout premiers Sprints mais, dans tous les cas, il doit pouvoir affiner celle-ci, voire la modifier profondément en fonction des retours du marché, c’est-à-dire selon l’usage réel qui est fait des premières itérations par les consommateurs ou les utilisateurs, ou selon les bénéfices réels du produit à la date de l’inspection. C’est la base de l’empirisme.

S’il a élaboré sa vision sans avoir consulté l’équipe de développement, ce travail d’affinage doit impérativement se faire avec elle, sans attendre les retours des utilisateurs, mais en se basant sur un affinage des coûts potentiels.

Dans tous les cas, cette démarche doit permettre au Product Owner de mieux prioriser ses objectifs, donc son plan de release, et de s’adapter à la situation actuelle, tout en restant focalisé sur les objectifs produit à long terme.

Afin d’affiner la valeur du produit, et donc la vision produit, le Product Owner peut mesurer les gains potentiels et réels, mais également les coûts, et en déduire un bénéfice. C’est sur le bénéfice que son attention est focalisée, car il représente la valeur du produit.

1. Les gains du produit

Il peut s’agir des gains financiers, mais également d’un accroissement de l’image de marque, du temps de parcours, de la performance, d’une meilleure sécurisation, etc.

a. À court terme

Dès la première mise en service ou release du produit, le Product Owner doit mesurer les gains réels et les comparer aux gains escomptés initialement. Il peut ainsi mesurer précisément et de manière empirique si les objectifs sont partiellement atteints ou dépassés.

Les écarts sont analysés avec les parties prenantes lors des revues de Sprint, en présence de l’équipe de développement ou, mieux encore, avec l’équipe de développement. Il n’y a donc pas besoin de maintenir de comité...

Validation des acquis : questions/réponses

Répondez à ces questions ouvertes, comparables à celles qui pourront vous être posées lors de la certification, mais ces dernières seront sous forme de QCM ou demandant une réponse courte saisie au clavier.

1. Questions

1 À quoi est liée la vision du produit ?

2 Quels sont les trois grands types de produits que l’on peut rencontrer en ingénierie informatique ?

3 Quels sont les deux types d’anticipation sur lesquels le Product Owner peut s’appuyer pour construire sa vision du produit ?

4 Quel est le principal impact concernant le choix de la conduite d’anticipation ?

5 De quelle manière le marché peut-il impacter la vision produit ?

6 Quel est l’attribut le plus facilement utilisable pour mesurer la valeur d’un produit ?

7 Pourquoi le Product Owner a-t-il intérêt à fixer des objectifs mesurables ?

8 Quelle méthode le Product Owner peut-il utiliser pour identifier les objectifs du produit ?

9 À quoi sert une stratégie produit ?

10 Qu’est-ce qui conditionne la stratégie produit dans un cycle itératif et incrémental ?

11 À partir de quel moment un produit développé avec un cycle itératif et incrémental commence-t-il à délivrer de la valeur ?

12 Sur quoi le Product Owner doit-il se baser pour établir son plan de release ?

13 Quelles sont les deux principales contraintes que le Product Owner doit prendre en compte pour établir son plan de release ?

14 Quelle est la taille idéale d’une équipe de développement ?

15 Sur qui le Product Owner peut-il s’appuyer pour établir son plan opérationnel ?

16 Qui a pour responsabilité de s’assurer de la qualité de chaque incrément de produit ?

17 Sur quoi le Product Owner peut-il s’appuyer pour rédiger des critères d’acceptation ?

18 À quoi servent les critères d’acceptation ?

19 Quel évènement Scrum permet au Product Owner d’affiner sa stratégie ?...