Quand planifier ses tests métier?

Dans mon article Design Thinking, Lean Startup et Agile : quelle est la différence ?, j’évoquais les différences de vision entre les approches de Design Thinking, Lean Startup et Agile.

Quand il s’agit de tester un concept, une idée, un produit, un service ou encore une application informatique, plusieurs approches sont également envisageables, selon le type de gestion de projet choisi.

Dans la majorité des cas, les grandes étapes d’un projet, qu’il soit industriel, IT ou autre, sont les suivantes:

• Phase de conception : Design, Ingénierie, spécifications fonctionnelles…
• Suivie d’une phase de validation;
• Elle-même suivie de la construction (ou architecture du SI en IT) et/ou de développement (du produit industriel / service / application)
• Puis, vient la phase de test (en IT: test unitaire, d’intégration, fonctionnel puis recette client);
• Et enfin la mise sur le marché (de déploiement des processus métier, de la solution informatique, du service proposé aux clients finaux ou encore du produit industriel).

Tester dans un contexte projet de type “cycle en V”

Dans un projet géré suivant un cycle traditionnel en V, ces étapes peuvent prendre parfois plusieurs années. Il reste à espérer que la demande initiale du client ait été bien comprise, pour que la solution envisagée lors de la conception du produit y corresponde bien. Dans le cas contraire, le risque d’une phase de test trop éloignée de la phase de conception est de se solder par la remise en cause de l’intégralité du projet.

Dans ce type de pilotage projet, les tests métier ne sont donc réalisés qu’à l’issue de la phase de fabrication du produit fini (ou de la conception du service, ou encore du développement applicatif)

Les avantages et surtout les inconvénients de la gestion en cycle en V ont été abondamment documentés de toutes parts (voir Contexte du projet), et ont conduit à l’émergence des méthodologies agiles.

Le test métier sur un projet géré en contexte agile

Les méthodologies agiles sont réputées plus efficaces que l’approche précédente (voir La Business Analysis en contexte Agile).

Du moins, il semblerait qu’elles soient plus adaptées dans le cadre de projets complexes sur lesquels il y a peu de visibilité, permettant une meilleure gestion des risques de par la flexibilité qu’elles accordent.

A l’inverse, la méthode de Cycle en V permet de mieux cadrer des projets, notamment industriels, pour lesquels la vision cible est très précise en termes de besoins, planning et risques.

Sur les projets agiles, toutes les phases “classiques” sont itérées jusqu’à produire la solution complète. Chaque itération doit conduire à la livraison d’un produit minimum viable correspondant aux exigences définies pour l’itération en cours.

Cependant, je suis sûre que nombre d’entre vous ont déjà vécu des expériences frustrantes et de grandes désillusions en travaillant ainsi. L’usage de ces méthodologies s’est tellement dévoyé que l’un de ses pères fondateurs, Ron Jeffries, en préconise même l’abandon (voir mon article Marre des pseudo-projets agiles!).

Outre la confusion entre agilité et rapidité, ce sentiment de frustration découle du constat fréquent que, malgré l’application d’une méthode censée coller au plus près du besoin métier, les résultats ne sont pas à la hauteur des attentes des utilisateurs finaux.

Et c’est à que le Design Thinking intervient.

Tester dans un projet géré avec Design Thinking

A l’opposé, le Design Thinking englobe la phase de test dans la phase de conception et ne s’interdit pas les premières itérations avant même le début de la phase de construction. L’avantage d’un projet dont le concept est testé auprès du client au cours de sa phase de conception est de ne pas s’éloigner de la demande client, d’apprendre sur la pertinence du modèle retenu, d’évaluer la capacité ou les limites de la solution choisie. La phase de test permet de s’assurer de la convergence des idées et du consensus sur les décisions co-validées par le groupe de travail.

A minima, il est souhaitable de tester le concept auprès des participants aux ateliers qui ont contribué à sa co-conception. Cela permet d’identifier et de réduire les écarts entre ce qui est décrit et ce qui est produit, afin d’optimiser la cohérence au maximum. N’oublions pas que l’être humain a besoin de visualiser, de toucher et d’essayer pour se représenter un concept. Dans le cadre d’un projet digital, il peut même y avoir des résultats différents entre tester un écran statique et tester un enchaînement d’écrans de façon dynamique. Cela permet de détecter les ruptures dans la cinématique et de replacer les éléments dans leur contexte d’utilisation.

Le plus efficace reste, lorsque c’est possible, de tester le concept auprès des utilisateurs. Cela permet d’observer leur comportement d’usage en situation réelle et de récolter de nouvelles informations : c’est l’opportunité de réviser le concept et de l’ajuster avant même son développement.

“Si le plan A ne marche pas, il reste encore 25 lettres dans l’alphabet.” (Ulrich Kévick Tossa)

Par ailleurs, produire plusieurs maquettes permet de considérer plusieurs hypothèses et plusieurs scenarios, afin de n’en retenir que les meilleurs : ceux qui constitueront le Minimum Viable Product (MVP).

Concevoir le Minimum Viable Product grâce au Design Thinking permet de s’assurer de la viabilité du produit minimum…

Ainsi, l’étape de test dans ce contexte sert à oser proposer une maquette aux utilisateurs afin d’observer leur comportement, de recueillir leurs premières impressions, de détecter les erreurs de conception et d’améliorer le concept avant même son développement.

Cette étape permet également de tester, de valider, ou d’invalider les hypothèses ou les scénarios différents. Elle permet en outre de détecter les axes sur lesquels l’entreprise ne peut ou ne veut pas aller pour des raisons de coûts ou de stratégie.

A l’issue des tests, le produit minimum viable est clairement co-validé par l’ensemble des parties prenantes, pour en lancer le développement.

Ainsi, le Design Thinking permet de faire entrer les tests métier en amont du projet, pendant la phase d’idéation, et ainsi livrer une feuille de route précise déjà validée décrivant les Minimum Viable Products à développer suivant une méthodologie projet appropriée.