Autre exemple : observez Lean startup, une approche extrêmement puissante pour construire rapidement un produit/service en itérant directement avec ses utilisateurs. Si vous deviez construire un quartier en mode Lean, vous commenceriez par construire rapidement des logements répondant aux besoins minimum exprimés par les utilisateurs : un sol, des murs, un toit et une porte pour assurer le clos et le couvert du logement. La condition minimum de l’habitat est respectée. Par contre si vous produisez ça à l’échelle du quartier vous avez construit une favela.
En voulant répondre rapidement au besoin minimum de l’utilisateur vous avez livré un produit qui générera rapidement des problèmes de salubrité, de promiscuité, et de violence. Finalement vous avez bien suivi la méthode mais la qualité de vie (ou l’expérience utilisateur) n’est pas satisfaisante.
Dans cet exemple la production s’est attachée à répondre aux besoins conscients de l’utilisateur. Les besoins futurs, non-conscients et non-exprimés, comme une bonne qualité de vie, la sécurité ou la salubrité, n’ont pas été pris en considération. Ils conditionnent pourtant largement la qualité de l’expérience utilisateur.
En Lean comme ailleurs l’expert est aussi là pour, si j’ose dire, préserver l’utilisateur de lui-même. Si l’utilisateur est conscient de ses besoins présents, est-il conscient des conséquences futures de ces choix ? On peut en douter…
Non, la conception centrée utilisateur doit être encadrée par des ressources responsables de la vision du projet. Il faut des visionnaires, il faut des innovateurs, des planificateurs. Il faut des garants de la qualité du produit/service pas seulement pour l’usage présent, mais aussi pour les usages futurs.
Il y a 2 choses qui me gênent dans cet extrait :
- la première de penser que la démarche Lean aboutira à la construction d’une favela ;
- la seconde d’avoir l’arrogance de croire que l’expert est un visionnaire qui connait mieux le problème que ceux qui le vivent.
Si je reprends l’exemple de l’habitat, la première itération débouchera en effet peut-être sur une cabane. Puis la seconde, une fois que des personnes y auront vécu, débouchera sur un groupe de cabanes avec une pièce commune et des sanitaires externes. Puis la troisième pourrait être à l’origine d’un renforcement des murs existants et la construction d’une école. Enfin lors de la quatrième on démolirait la pièce commune pour faire une salle des fêtes en béton. Ou tout autre chose en fonction des besoins des personnes qui sont concernées au quotidien. Lean n’est pas fait pour développer un prototype et passer à l’échelle à partir de celui-ci mais bien pour itérer sur ce prototype de manière à ce qu’il acquiert le maximum de valeur avant de passer à l’échelle. Si personne ne souhaite vivre dans une favela, un projet Lean ne devrait jamais aboutir à une favela (au passage comparer une n-ième fois le développement logiciel à du BTP est délirant).
Passons à l’encadrement des utilisateurs trop stupides pour pouvoir avoir une vision de leur produit. Dans un système complexe, l’expert et l’utilisateur sont sur un pied d’égalité vis-à-vis de la prédiction qu’ils peuvent faire sur un produit innovant : c’est entre la voyance et le bullshit. Personne ne peut anticiper dans un tel système. La chance de notre domaine c’est la flexibilité que l’on a pour pouvoir s’adapter au changement. L’agilité propose des outils pour que les compétences de l’expert (estimation relative de la complexité et qualité interne) et l’utilisateur (priorité et budget) puissent travailler ensemble afin de maximiser la valeur de chaque itération. Inutile d’anticiper (faussement) sur les usages futurs si l’on est suffisamment réactif dans les développements présents. L’enjeu est de rester suffisamment réactif tout au long du processus, à la fois techniquement mais aussi en terme de retours utilisateurs.
Je fais rarement de la pub par ici mais la formation qu’expérimente Stéphane dans le domaine est vraiment éclairante.
