• La Collaboration comme moteur
• L’agilité : réduire la taille des lots pour apprendre vite
• De la Maquette au Prototype : premières itérations
  • La maquette
  • Le prototype
  • Supports d’arbitrage
• PoC et Spikes : dérisquer la faisabilité
  • Proof of Concept
  • Les Spikes
  • Arbitrer la faisabilité technique
• Le MVP : l’aboutissement de la frugalité
• Expérimentations, étape par étape
• Sources

Avec les précédents articles, nous avons non seulement vu comment rédiger le PRD, mais aussi comment il est censé évoluer dans le temps. Pour résumer en quelques mots l’idée : le PRD est initié avec des propositions de solution, qu’il faut ensuite explorer, tester, expérimenter, jusqu’à valider une proposition, et l’implémenter. Et là aussi, nous devons être en mesure d’ajuster le tir au fur et à mesure de son implémentation et des retours utilisateurs.

Nous sortons du confort intellectuel du PRD pour nous confronter à la dure réalité du marché et du code.

§La Collaboration comme moteur

Dès la rédaction, nous avons vu l’importance d’impliquer les développeurs. Lorsque les développeurs prennent le relais sur l’implémentation, cette collaboration reste fondamentale, mais dans l’autre sens : le Product Owner apporte la vision produit et sa compréhension des enjeux clients à l’équipe pour répondre aux questions du quotidien.

J’ai eu l’occasion d’aborder ce sujet en détail dans un précédent article : les enjeux techniques du Product Owner, car l’expertise technique est de plus en plus attendue chez le Product Owner, justement pour être capable de créer et entretenir ce pont entre la partie technique d’un côté et le marché de l’autre.

§L’agilité : réduire la taille des lots pour apprendre vite

Scrum et Kanban commencent à être bien connus : ces méthodes agiles proposent des outils d’optimisation pour fluidifier le partage de connaissance, et favoriser l’adéquation de la solution avec le besoin de l’utilisateur.

Nous avons déjà abordé à plusieurs reprises la notion de MVP, ou « Produit Minimum Viable » : l’idée fondamentale est de valider nos hypothèses aussi fréquemment que possible. Pour cela, nous allons procéder par itération :

• Plan : formalisation de l’hypothèse que nous voulons traiter,
• Do : implémentation de la solution correspondante dans le produit (ou dans un démonstrateur),
• Check : validation (ou invalidation) de l’hypothèse avec les utilisateurs, et
• Act : mise à jour de notre hypothèse en fonction des retours.

Le PDCA est d’ailleurs à la racine autant des approches projet que produit : chaque itération est l’occasion d’apprendre pour les prochaines occasions… La principale différence entre projet et produit étant qu’en méthode projet, la prochaine itération concerne un prochain projet, tandis qu’en approche Produit, la prochaine itération concerne le même produit.

Cela signifie que nous allons procéder par itérations courtes – beaucoup plus courtes que la durée de vie du produit – c’est-à-dire les sprints : à chaque itération, nous traitons un petit lot lié à un récit utilisateur précis (ce récit formalisant notre hypothèse), de façon à réduire progressivement le risque. À chaque itération, nous confrontons notre proposition à l’arbitre ultime : l’utilisateur (ou le consommateur).

§De la Maquette au Prototype : premières itérations

Lors de nos premières itérations, nos certitudes sur nos hypothèses sont trop minces pour intégrer directement notre proposition dans le produit. Nous allons donc chercher à collecter des preuves, au travers d’outils de démonstration, chacun correspondant à un besoin spécifique (nos besoins, cette fois-ci).

§La maquette

Aussi appelée « Mockup », elle sert à évaluer l’apparence et l’expérience générale qu’aura l’utilisateur avec notre proposition. Une maquette est statique, sans interactions. Parfois, nous parlons même de Wireframe : le design final n’est pas intégré, seule la structure envisagée est présentée. Nous proposons donc un aperçu vraiment très haut niveau.

§Le prototype

Cette fois-ci, nous proposons une solution interactive, permettant à l’utilisateur de réellement tester les interactions. Nous avons donc une maturité plus importante sur le prototype que sur la maquette, bien qu’il n’y ait toujours pas de traitement de données concrètes derrière cette interface. Cependant, nous sommes déjà en mesure d’évaluer la facilité d’utilisation (ou « utilisabilité ») en mettant le prototype entre les mains des utilisateurs.

Bien entendu, aucune ligne de code du prototype ne doit se retrouver dans le produit en production, précisément pour éviter de créer des failles de sécurité ou de dégrader la qualité du produit avec des évolutions qui ne sont pas encore validées.

§Supports d’arbitrage

En mettant les maquettes et prototypes entre les mains de nos utilisateurs, nous contrôlons la viabilité de notre proposition. Nous disposons ainsi de données concrètes – les retours des utilisateurs – dépourvues d’ambiguïtés, à présenter à nos parties prenantes, pour appuyer notre proposition… Et valider les évolutions sur notre produit.

Imaginons par exemple que nos utilisateurs disposent d’un tableau avec pagination pour afficher leurs ressources. Cependant, cette pagination montre ses limites face au volume de données à charger (lenteur, voire gel de l’interface, etc.). Nous envisageons d’explorer un mécanisme de scroll infini (les données se chargent au fur et à mesure que nous descendons dans le tableau).

La maquette permettra de montrer l’allègement de l’interface (la disparition de la pagination, par exemple), tandis que le prototype permettra de montrer concrètement comment se matérialisera le scroll infini dans notre application, car ce mécanisme ne se comprend qu’en mouvement.

§PoC et Spikes : dérisquer la faisabilité

L’un des dogmes les plus dangereux est de séparer la « conception » de la « réalisation ». Or, nous devons valider la faisabilité de nos idées pendant la phase de discovery, pas après.

C’est là qu’interviennent le PoC et le Spike.

§Proof of Concept

Une « Preuve de Concept » est une implémentation technique rapide et complète, focalisée sur une idée précise. Son but est de prouver qu’elle est réaliste, et réalisable, en montrant qu’elle peut marcher dans la pratique.

§Les Spikes

Ce sont des prototypes techniques auxquels nous réservons au maximum deux à trois jours d’expérimentation. Rarement complets, les spikes sont destinés à réduire une incertitude technique ou fonctionnelle, souvent liée à une technologie nouvelle ou complexe.

§Arbitrer la faisabilité technique

Si nous reprenons notre exemple précédent, un spike permettra de tester différentes bibliothèques pour l’affichage d’un tableau avec scroll infini dans notre interface web, tandis qu’un PoC permettra de contrôler que notre solution s’intègre bien avec nos données fournies par le serveur et que celui-ci sera capable de supporter les données renvoyées de façon séquentielle.

§Le MVP : l’aboutissement de la frugalité

Tout ce processus converge vers notre fameux « Minimum Viable Product ». Ce MVP n’est pas un produit bâclé, c’est la plus petite version de notre idée permettant d’atteindre avec succès l’outcome souhaité, c’est-à-dire « pour prouver ou infirmer une hypothèse » selon les mots de Jeff Patton. Maquette, prototype, PoC et Spikes sont ainsi des jalons, nous amenant petit à petit vers le MVP, validation ultime de notre hypothèse.

Nous le rejoignons là sur un point fondamental : « En fin de compte, votre travail consiste à minimiser la production (output), et à maximiser le résultat (outcome) et l’impact. » Notre travail est de minimiser le nombre de fonctionnalités (l’output) en éliminant au fur et à mesure des itérations tout ce qui serait superflu dans le produit final, pour maximiser la valeur qu’elles apportent à l’utilisateur (l’outcome), et l’impact sur les bénéfices de l’entreprise.

§Expérimentations, étape par étape

S’émanciper du plan pour embrasser l’expérimentation, c’est accepter que nous ne sommes pas omniscients. Le marché est un processus de découverte permanent. En utilisant des prototypes, des spikes et des itérations courtes, nous ne gérons plus un projet, nous basculons dans l’approche Produit : nous réduisons activement les obstacles qui séparent nos utilisateurs de leur satisfaction.

De mon expérience, toutes les expérimentations menées en chemin, les allers-retours avec les clients et utilisateurs, et le code produit pour ces démonstrateurs sont souvent perçus comme de la perte de temps et du gaspillage d’énergie.

Pourtant, nous ne construisons pas pour le plaisir de construire, mais pour satisfaire les besoins de nos utilisateurs : nous validons que nous avons les moyens de lever la gêne du consommateur.

§Sources

• Inspired, Marty Cagan.
• Escaping the Build Trap, Melissa Perri.
• The Lean Product Playbook, Dan Olsen.
• User Story Mapping, Jeff Patton.
• Continuous Discovery Habits, Teresa Torres.