Définir le produit

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.

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 les Developers. 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 ou remplacer. Il peut...

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. Ces attributs sont généralement exprimés sous forme de vecteurs ou flux de valeur. Etant constituée de vecteurs d’ampleur et de nature variables, la valeur est 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...

Structurer le produit

Structurer un produit consiste à le cadrer, en définir un périmètre clair. Cela peut être réalisé en clarifiant des contraintes, c’est-à-dire des limites, mais également en clarifiant des objectifs donnant du sens.

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...

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 Developers, le Product Owner doit fournir à ces derniers toutes les informations qui 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 et à ne pas en indiquer qui ne serait...