Vous voulez comprendre ou apprendre des compétences en développement produit ? Ce post est le troisième post d’exercices d’une série de 5.
Je les ai découpé en 5 parties Comprendre, Explorer, Décider, Construire, Valider qui correspondent peu ou prou au design sprint de google ventures. Je vais utiliser le fil rouge de la vente en ligne de produits frais avec comme exemple Auchan Direct.
C’est quoi cette idée de m… ? Et bien, il est temps de poser cette question interdite dans le précédent post. On va cependant faire cela de manière un peu plus poli et plus rationnelle. Cela va se passer en trois temps :
Il s’agit de donner du feed-back pour fermer des options, mais de manière la plus objective possible. Pour cela, on demande à chacun d’endosser un habit pour critiquer par un axe. Cela permet une critique avec moins de jugement. Il est aussi possible de le faire avec les sept nains. L’atelier s’appelle Six Thinking Hats.
Ouvrir le site auchandirect.fr et taper dans la recherche levure. Critiquer ensuite la solution en passant tour à tour par les 6 chapeaux.
Voir comment le chapeau influe sur la qualité de notre feed-back qui devient moins émotionnel.
Rome ne s’est pas fait en un jour, Auchan Direct non plus. La question que l’on va se poser, c’est si je devais le refaire comment je le ferai ? L’épisode 1 nous a permis de fermer certaines options car jugées non viables. Dans ce kata, nous partons sur du découpage pour identifier la valeur potentielle des options ouvertes.
Ouvrir les sites dans l’ordre et découper en incrément de valeur. Chaque incrément doit pouvoir répondre à la question « qu’est-ce que l’utilisateur pourra faire de différent ? ».
Cet exercice est beaucoup plus dur et j’aide donc par des exemples :
Pour avancer, je conseille d’identifier des utilisateurs types et de définir leurs usages (personas). Ensuite, il faut identifier comment je peux livrer de la valeur au fur et à mesure, cela veut dire quelle est l’expérience utilisateur minimale. Ne pas oublier la partie basse du process à savoir choix du créneau, saisi de l’adresse,… On peut aussi retrouver des incréments sur cette partie avec des options comme ‘Modifier’, ‘Annuler’, ‘Copier’…
Si je ne suis pas capable de répondre à la question « qu’est-ce que l’utilisateur pourra faire de différent ? », c’est que la solution envisagée ne répond pas à un besoin. Je peux alors fermer l’option.
On est dans le pur slicing avec identification d’incrément de valeur. C’est une partie cœur du développement produit. Pour la suite, j’appellerai l’incrément de valeur minimum MVE pour ‘Minimum Viable Experience’. C’est la clé pour une livraison de valeur au fil de l’eau.
Dans le précédent épisode, j’ai identifié de potentiels changements de comportement utilisateurs (MVE) et donc la valeur potentielle. C’est bien mais pas suffisant avec comme question suivante : comment je pourrai valider le succès de ma réponse au besoin? En sortie, je vais avoir 3 cas :
Un indicateur de succès doit répondre à 3 critères : actionnable, accessible, auditable. Voir 3-metrics
Prendre les MVE identifiés précédemment et définir pour chacun les conditions de succès.
Faire bien la différence entre critères de succès (du besoin) et critère d’acceptance (de la solution). Je ne veux dans les critères de succès que de la validation d‘hypothèses et pas de conformité de la solution. On n’est pas en train de faire de la spécification.
Vous avez identifié des incréments de valeur et savez comment identifier si c’est un succès ou non. Certaines options sont maintenant fermées et il vous reste à faire le tri dans les options ouvertes. Vous arrivez donc au moment de faire des choix. Il y a plusieurs façons de prendre des décisions que l’on ne perçoit pas nécessairement. Le but de cet exercice est de percevoir les différences et comment le protocole de décision influence la décision. Pour la suite, nous utiliserons 3 protocoles :
Répondre aux questions suivantes en utilisant les 3 protocoles de décision.
Prendre du recul sur la prise de décision. Le protocole influe le résultat final.
Dans l’article suivant, nous allons construire, parce qu’à l’arrivée il y a un client.
Développeur, maitrise d’ouvrage, chef de projet, manager, coach agile et maintenant … coach en organisation agile
It is not the strongest of the species that survives, nor the most intelligent that survives. It is the one that is most adaptable to change. (Darwin)