Chez OCTO, avant de publier un article, on effectue une revue interne. Et il faut dire que cet article a lancé un grand débat. Il y a eu deux camps : ceux qui pensent que ce n'est applicable que sur les projets innovants, et ceux qui pensent que c'est applicable sur tous les types de projet.

Et vous qu'en pensez vous ?

Disclaimer : Nous allons parler du rôle MOA, pas des personnes de la MOA. De plus, nous parlons ici de la MOA informatique "classique", pas de l'expert fonctionnel/métier (le business analyst hors de nos frontières).

Le nom MOA nous vient des métiers du bâtiment. Elle représente l'entité porteuse du besoin, définissant l'objectif du projet, son calendrier et le budget consacré à ce projet (source Wikipédia). En informatique, elle représente les sachants fonctionnels : ceux qui connaissent les utilisateurs/le métier et qui retranscrivent le besoin en texte compréhensible pour la MOE, nous informaticiens.

Ce rôle dans un projet est-il vraiment encore utile, surtout au vu des nouvelles méthodologies Agile et Lean ? N'oublions-nous pas un peu rapidement le vrai but d'un projet informatique : rendre les utilisateurs plus efficaces dans leurs tâches (ou sur le web : améliorer la vie des utilisateurs).

Adieu MOA

Depuis quelques années, le mouvement agile nous explique que la MOA doit disparaître, certes pas dans ces termes mais c'est l'idée globale. Avoir des gens qui écrivent des spécifications de ce qu'ils pensent être utile aux utilisateurs finaux, qui seront retranscrites en d'autres spécifications puis enfin développées est un non-sens. Ceci produit de l'inventaire, du stock donc du gâchis.

Les agilistes ont donc supprimé ce rôle pour le remplacer par un autre : le PO, le product owner, celui qui a la vision produit. Et ils ont surtout intégré ce rôle directement dans l'équipe de développement. De plus, l'équipe (PO compris) rencontre régulièrement le sponsor du projet, généralement toutes les semaines lors de la démo.

Donc globalement, le rôle MOA n'existe plus dans un projet agile. Je suis persuadé que cette façon de fonctionner a grandement amélioré la qualité (du point de vue des utilisateurs finaux) des logiciels développés.

Arrêtons-nous 30 secondes et regardons ce qu'il se passe. On nous parle de PO, de sponsor mais jamais d'utilisateur. C'est pourtant bien lui qui devra utiliser le produit, pas le PO ni le sponsor.

Mais où est-il ?

Au revoir PO

Si on résume, le PO est (encore) un intermédiaire entre l'équipe et les utilisateurs. On a donc remplacé un proxy, la MOA, par un autre, le PO. Et les utilisateurs sont encore oubliés.

Il est vrai que certaines méthodologies agiles préconisent des tests utilisateurs. Mais le "sachant" reste le PO. Quelle est sa légitimité ? En sait-il plus que les utilisateurs ? A-t-il accès à une boule de cristal magique ?

Je ne crois pas.

Le seul et unique sachant sont les utilisateurs. C'est lui qui sera devant son écran à cliquer sur des icônes toute la journée. C'est lui qui devra utiliser le produit pendant plusieurs années.

Alors pourquoi ne pas lui demander son avis directement ?

Bonjour utilisateurs

Bon facile me direz vous, on kidnappe des utilisateurs, et on les questionne jusqu'à avoir la substantifique moelle de leur besoin, et hop c'est gagné.

Malheureusement, ce n'est pas si simple. Le soucis avec les utilisateurs c'est que globalement ils ne savent pas ce dont ils ont besoin avant d'avoir pu l'essayer. Il est donc impossible de trouver du premier coup la fonctionnalité qui les satisferons.

C'est ici qu'intervient le Lean et plus particulièrement les idées issues du Lean Startup : les hypothèses produits. L'idée est simple, on applique la boucle du PDCA :

• On pose une hypothèse sur le produit
• On effectue la plus petite action nécessaire pour la réaliser
• On mesure son utilité pour les utilisateurs
• On en tire des conclusions

Les hypothèses produit sont une intuition sur une fonctionnalité à développer pour améliorer le produit du point de vue des utilisateurs. Elles sont généralement émises par les PO/PM (product manager). Oui, le fameux PO que l'on a excusé un peu plus haut. Il n'est toujours pas un utilisateur, mais il est celui qui les connaît sûrement le mieux et est donc le plus à même d'émettre des hypothèses au début du projet. Puis, au fur et à mesure de l'avancement du projet, c'est l'équipe entière qui devient capable d'émettre des hypothèses, car elle acquiert de l'expertise sur qui sont les utilisateurs. Précisons que l'équipe décrite ici est une équipe composée de tous les profils nécessaires au bon déroulement du projet. Elle inclut (de manière non exhaustive) : les développeurs, les UX, les designers, le marketing, etc.

Une fois que l'on a notre hypothèse il faut l'implémenter. C'est cette étape qui est à mon sens la plus complexe, pas parce que l'hypothèse peut nécessiter beaucoup de code ou de cadrage. Mais parce qu'il est crucial de trouver l'action la moins coûteuse pour valider l'hypothèse. Par exemple, si l'hypothèse est "mon utilisateur veut pouvoir effectuer une simulation de prêt", l'action la plus petite n'est pas de réaliser un simulateur de prêt complet. Elle est de vérifier que l'utilisateur veut effectivement bien un simulateur de prêt.

Lors de l'implémentation de l'hypothèse il faut garder à l'esprit que le but est de mesurer si notre hypothèse apporte de la valeur aux utilisateurs. Il faut donc s'équiper pour pouvoir la mesurer. L'implémentation va donc grandement dépendre de la façon dont la mesure sera effectuée. Si on est sur le web on peut utiliser des outils comme google analytics. Mais si on décide d'aller directement rencontrer des utilisateurs on peut ne réaliser qu'un questionnaire, et donc 0 ligne de code.

La dernière étape est celle où l'on regarde les métriques et on prend une décision : "Oui, à plus de 90%, les utilisateurs souhaitent un simulateur de prêt. Alors passons donc à réalisation"

La suite est simple, on recommence cette boucle. Notre utilisateur souhaite un simulateur de prêt, alors réalisons le plus simple simulateur possible et mesurons comment et qui l'utilise, ce qui nous permettra de l'améliorer en gardant toujours l'utilisateur au centre de nos préoccupations.

Conclusion

Je ne pense pas que demain la MOA et les PO vont disparaître. Ils restent les sachant fonctionnels, ceux qui, par exemple, savent comment calculer un prêt. Mais leur rôle se doit d'évoluer, pour aller encore plus au contact des utilisateurs : comment recueillir le feedback rapidement, comment valider au plus tôt les fonctionnalités, … Il doit aussi évoluer pour aller plus proche des projets pour apporter le plus efficacement et rapidement de la valeur à ceux-ci.

Si vous souhaitez aller plus loin, je vous conseille les livres Lean Startup et Running Lean, sans oublier les sessions USI (ici et ici).