Le glossaire (jargon) de la culture (méthode) produit

La conception et le développement de services numériques peuvent reposer sur une diversité de méthodes. Depuis plus de 20 ans, les principes du manifeste agile ont infusé les organisations et sont désormais mobilisés par les organisations. Parce que nous mobilisons ces concepts, méthodes et outils au quotidien avec nos clients et partenaires, nous vous proposons de les décortiquer avec ce nouveau glossaire. Découvrez les concepts, étapes, rôles, format et outils principaux de la méthode produit !

Disclaimer : il s’agit d’un glossaire non exhaustif, et il existe une littérature foisonnante pour aller plus loin.

Nos inspirations principales :

• Culture Produit et Product Management – OCTO
• Des startups d’Etat à l’Etat Plateforme – Fondapol, Henri Verdier et Pierre Pezziardi
• La documentation betagouv

1. Les concepts et étapes

• Méthode produit : la méthode produit est un modèle de conception qui consiste à se baser purement et simplement sur les besoins (ou irritants) des utilisateurs pour concevoir les fonctionnalités d’un produit numérique, et ce de manière itérative et incrémentale. Il s’agit, par la réalisation d’entretiens utilisateurs ou d’ateliers collectifs, de recueillir les besoins des utilisateurs en lien avec une problématique. Ces besoins sont ensuite priorisés au regard de l’impact qu’ils apportent et de leur faisabilité technique, avant d’être développés au cours d’un “sprint” de développement. Le résultat de ce sprint est ensuite présenté aux utilisateurs pour assurer l’adéquation de la solution avec la problématique initiale et l’agrémenter avec de nouvelles fonctionnalités.

• Agilité : il s’agit d’une méthode de travail, empruntée au développement informatique, qui consiste à réaliser les tâches d’un projet de manière itérative et incrémentale en favorisant l’adaptation au changement de l’équipe plutôt que le respect “bête et méchant” du plan initial. C’est en fin de compte un mode de gestion de projet qui privilégie les individus et les interactions aux processus et outils, les solutions opérationnelles à la documentation exhaustive, la collaboration avec les clients aux négociations contractuelles, la réponse au changement au respect du plan initial.

• Cas d’usage : un cas d’usage peut être représenté de manière textuelle ou schématisé, et décrit le besoin initial de l’utilisateur (ex : connaître les aides sociales auxquelles j’ai droit d’une manière la plus simple) et peut se décliner de manière plus détaillée avec l’ensemble des étapes que souhaite réaliser l’utilisateur. Identifier un cas d’usage, ou “cas d’utilisation” est comme un préalable avant de se lancer dans le développement d’un service. En effet, on peut avoir une intuition sur la nécessité d’un service, mais si ce besoin n’a pas été exprimé par les personnes concernées (ie. les utilisateurs), on risque de passer à côté de l’objectif. Un cas d’usage aide ainsi à définir les fonctionnalités clés d’un service numérique.

• Mesure d’impact : la mesure d’impact consiste à évaluer les résultats du service numérique auprès des utilisateurs et vérifier que l’objectif recherché est atteint. Souvent, il s’agit de définir un impact principal (ex : réduire le délai entre une demande d’aide sociale et son versement effectif), de le décliner en différents indicateurs quantitatifs et qualitatifs et de s’accorder sur des objectifs de résultats. Cela implique ainsi de mettre en place des actions de collecte et d’analyse de données. Dans la méthode produit, la mesure d’impact est réalisée le plus souvent possible, car elle guide le développement du service numérique et son adaptation. Vous entendrez peut être d’OKR pour “objective and key results”, c’est une méthode empruntée du management qui peut justement aider à définir des résultats vérifiables et facilement mesurables.

• Les différentes étapes d’un produit : il existe une diversité de modèles pour décrire les étapes de conception et développement de produits numériques ! Navigant le plus souvent dans l’écosystème des startups d’Etat, nous vous partageons donc celle-ci :

  • Investigation (aussi parfois appelée discovery) : pendant une période de 6 à 8 semaines, l’équipe vient approfondir l’identification des besoins et irritants des utilisateurs via des entretiens et de la recherche, et propose des scénarios de suite ou non (passage en construction, arrêt, nécessité de continuer l’investigation)
  • Construction : lorsqu’un produit passe en construction, cela signifie que l’équipe commence à développer une première version du service numérique, justement selon la méthode produit (sprint, open lab et mesure d’impact permanente). La durée de la phase de construction varie selon le service développé
  • Accélération : c’est le moment où l’on décide de déployer plus largement le produit développé, en y intégrant de nouvelles fonctionnalités, en allant cibler un volume plus important d’utilisateurs, en développant des partenariats et des actions d’animation de communautés.

2. Les rôles dans une équipe produit

• Product owner : le ou la product owner (PO) est celui ou celle qui est responsable des orientations que prend le produit. C’est lui ou elle qui priorise les fonctionnalités au regard des besoins exprimés par les différents types d’utilisateurs et de leur faisabilité technique. Il travaille de concert avec le ou la designeur(euse), l’équipe de développement et le ou la product manager.

• Product manager : le ou la product manager (PM) est responsable d’un portefeuille de produits. Cette personne est chargée de s’assurer que les produits qu’elle pilote sont en cohérence avec la stratégie et la vision long terme de l’organisation et le mandat qui lui est donné par des sponsors, partenaires ou porteurs de haut niveau. Elle est également chargée d’accompagner les product owners qu’elle supervise et leur apporter des idées et orientations.

• Coach agile : le coach intervient pour accompagner la transformation d’une organisation en développant une culture de l’agilité. Généralement externe à l’équipe, il/elle joue un rôle de facilitateur et de formateur. C’est un.e mentor pour tous les autres rôles de l’équipe produit, qu’il/elle pousse à mettre le doigt sur leurs problématiques organisationnelles pour les aider à les résoudre en mettant en place les cadres méthodologiques et outils nécessaires tout en s’autonomisant.

• UX Designer : le ou la designer UX (ou designer d’expérience utilisateur) est la personne qui intervient pour écouter les utilisateurs et traduire leurs besoins en réalisant une diversité d’actions – production de personas (profils types d’utilisateurs), parcours utilisateurs, maquettes, etc. Elle est très présente durant la phase d’investigation et intervient en rebond lors des phases de construction pour adapter les parcours utilisateurs en fonction des orientations techniques mais surtout en fonction des retours utilisateurs lors de sessions de tests.

3. Les rituels, formats et outils

• Stand-up : le stand-up est un réunion de synchronisation qui permet de suivre l’avancement de chaque membre de l’équipe dans le déroulement du sprint afin de s’assurer de rester sur les bons rails pour réaliser les objectifs fixés.

• Rétroplanning : concevoir un rétroplanning consiste à positionner les jalons d’un projet en partant de la date d’atterrissage souhaitée.

• Sprint : un sprint est une période de travail associée initialement au développement agile de service numérique. Cette période dure généralement une ou deux semaines et les fonctionnalités à développer sont définies en début de période. Cette méthodologie est transposable à des projet plus classiques, il s’agira alors de définir en début de période les tâches à accomplir, les entretiens à réaliser, la documentation à produire…

• Sprint review : à la fin d’un sprint, le ou la PO est chargé d’organiser les sprint reviews – ou revues de sprint. Il s’agit d’un temps d’équipe ou chacun.e présente ses travaux de la période afin de mettre toutes les parties prenantes au même niveau d’information. Dans le cadre du développement d’un produit numérique, il est essentiel d’inclure au maximum les futurs utilisateurs et utilisatrices à ces moments afin de leur présenter les maquettes et fonctionnalités développées pour recueillir leurs retours à chaud et s’assurer que les travaux sont alignés avec leurs besoins et qu’il n’y a pas d’externalités négatives.

• Rétrospective agile : la rétrospective agile se tient sur le même rythme que la revue de sprint. Quand la revue de sprint peut être ouverte aux utilisateurs, la rétrospective a plus vocation à être tenue en équipe resserrée. Il s’agit de verbaliser ce qui s’est bien passé et moins bien passé sur la période de travail. Cela peut se faire grâce à une matrice KDS – pour Keep, Drop, Start – : dans les Keep, on indique ce qui s’est bien passé, ce dont on est fier; dans les Drop, on indique ce qui s’est moins bien passé, ce qu’on souhaite voir changer; dans les Start, on propose des actions pour venir pallier aux Drop. C’est finalement un moment d’équipe de libération de la parole. La bienveillance doit primer lors de cet échange.

• User story : un produit numérique est construit pour répondre à un besoin qui est traduit lors de la phase d’investigation par des “cas d’usages” (cf. plus haut). Ces cas d’usages sont traduits en fonctionnalités “macro” que l’on appelle aussi Epic (pour épopée en anglais). Ces EPIC traduisent des besoins assez larges de l’utilisateur : en tant qu’utilisateur, je souhaite pouvoir transmettre les informations sur mes revenus à mon administration fiscale pour calculer mes impôts. Ces Epic sont produites par le ou la PO et le ou la designeur.euse, suite aux entretiens utilisateurs. Ces Epic sont ensuite présentées aux utilisateurs afin de nous assurer de la bonne compréhension de leur besoin. Une fois validée, il s’agit de les traduire en fonctionnalité plus fine pour que l’équipe de développement dispose de suffisamment d’informations pour développer la bonne fonctionnalités. Ces fonctionnalités plus fine sont appelées “user stories”.

• Maquettes : après avoir recueilli les besoins des utilisateurs, et avant de les développer, il est essentiel de leur proposer des maquettes des écrans pour que l’équipe s’assure de la bonne compréhension du besoin des utilisateurs. Il s’agit alors de faire dans un premier temps des “wireframe” qui sont des maquettes succinctes et qui permettent de définir la structure de l’écran (cela peut même se faire sur un papier pour indiquer une en-tête, un menu déroulant, un encart d’actualités…). Une fois la structure d’un écran définie, on peut passer aux maquettes plus élaborées : il s’agit alors de créer les différents écrans, à la charte graphique adéquate avec un enchaînement cohérent. On parle alors d’un parcours utilisateurs.

• Tests utilisateurs : le développement de produits numériques se fait en plusieurs phases et sur différents “environnements” (cf. le jargon des devs). Les fonctionnalités sont d’abord développées sur un environnement de développement qui est l’environnement réservé aux développeurs. Elles sont ensuite transférées sur un environnement de recette afin d’ouvrir les fonctionnalités à l’équipe entière pour la réalisation de tests. Une fois validées par l’équipe, les fonctionnalités sont transférées sur un environnement de pré-production pour les ouvrir aux utilisateurs bêta qui viennent réaliser les tests utilisateurs. Ces tests permettent de confronter les fonctionnalités développées aux besoins des vrais utilisateurs. C’est une fois les retours des utilisateurs bêta recueillis et pris en compte que les fonctionnalités peuvent être déployées à l’ensemble des utilisateurs sur l’environnement de production.

• Open Lab : un open lab est un temps de travail collectif et convivial, d’une journée ou une demi-journée, durant laquelle un PO rassemble les différents utilisateurs d’un produit afin de présenter les avancées d’un produit, de les inviter à exprimer leurs points de frictions en direct, voter en séance pour prioriser les points de frictions les plus problématiques, se répartir en groupe pour concevoir les solutions à ces points de frictions. Il s’agit ensuite pour l’équipe produit de retranscrire les solutions identifiés en maquettes, puis en développement (s’il s’agit d’un produit numérique).