Josianne et Robert sont dans un projet

Pour développer une application informatique, nous partons d'un besoin "du marché", c'est à dire des utilisateurs, donneurs d'ordre, marketeurs et stratèges, clients ou autres, qui ont mot à dire par rapport au nouveau "produit", qui est donc ici une application ou un système informatique. Entre le besoin et le produit, on trouve la formulation du besoin, que nous désignerons par spécification du besoin. Cette spécification peut être écrite, rédigée et présentée comme exhaustive, ou être le résultat d'interactions quotidiennes. Cette spécification est en général formulée par quelqu'un d'autre que celui qui réalise.

Nous faisons donc face à deux types de risques:

• les risques sur le besoin: leur effet est que l'expression du besoin est incomplète, incorrecte ou obsolète;
• les risques techniques: leur effet est que l'expression du besoin est mal ou incomplètement traduite dans le produit.

Les risques sur le besoin sont de plusieurs ordres: compréhension partielle du besoin, manque de communication, changement. En pratique, nous constatons souvent que le rôle de définition du besoin est le plus difficile, et également que les risques sur le besoin peuvent avoir plus de conséquences indésirables que les risques techniques - ceci est au moins vrai pour nos applications informatiques courantes, applications de gestion, applications métier ou sites Internet. Il en serait probablement différent en informatique embarquée par exemple.

Paradoxe redoutable: beaucoup des risques en informatique viennent du besoin, et certainement parmi les plus dangereux, mais nos organisations et processus se focalisent sur le risque technique. Si vous ne connaissez pas la blague sur le fou qui cherche sa montre dans un buisson, envoyez-moi un e-mail !

Josianne et Robert

Illustrons tout ceci par une petite histoire: Josianne et Robert sont dans un projet. Ils ont été désignés par le DSI, Hervé, pour travailler ensemble sur un nouvel outil de reporting de vente pour les responsables de boutiques. Josianne est une analyste expérimentée et connaît bien la boutique. Robert connait bien l'environnement technique.

Première semaine: Josianne défriche le besoin avec les responsables de boutiques, donne quelques idées à Robert. Celui-ci s'empêtre dans l'installation du framework, des outils... Bref, pas grand'chose à montrer à la démo, mais tout le monde reste de bonne humeur.

Deuxième semaine: Robert développe. Josianne interagit de nouveau avec les responsables, et la définition des cas d'usage change trois fois. Robert s'énerve. A la démonstration de fin de semaine, il n'y a toujours pas grand'chose à montrer. Robert fait une sortie contre Josianne, mais au final c'est lui qui se fait engueuler par Hervé.

Troisième semaine: Robert demande des spécifications écrites à Josianne. Mais "ce n'est pas dans la méthode," donc pas de spécification, et le besoin continue de bouger. Résultat: nouvelle engueulade à la démonstration, mais Robert a gain de cause et Hervé demande à Josianne d'écrire des spécifications.

Quatrième semaine: Josianne écrit des spécifications, Robert commence à développer sur cette base. A la démonstration, Hervé voit surtout les beaux documents, et le climat s'améliore.

Cinquième semaine: L'application prend forme à partir des spécifications, mais la démonstration aux utilisateurs est catastrophique: ce n'est pas du tout ça. Robert se défend auprès d'Hervé et a gain de cause. L'application est conforme aux spécifications écrites, et du coup c'est Josianne qui se fait engueuler et le prend très mal.

Sixième semaine: Josianne révise les spécifications, Robert redéveloppe mais a du mal: il s'agit d'un virage à 90°, plus difficile à exécuter sur une application que sur des spécifications Word. Les spécifications sont à jour, mais l'application est à mi-chemin du changement et plante en cours de démonstration aux responsables de boutique. Effet catastrophique. Hervé engueule tout le monde.

Interrompons le fil et demandons-nous comment cette histoire pourrait se poursuivre. Si le besoin n'est pas si criant que ça, Hervé pourrait décider de jeter l'éponge et d'arrêter une affaire mal engagée. Mais le besoin est là. Supposons que d'un coup:

• Josianne reconnaît qu'elle ne sait pas tout, que sa tâche est difficile et qu'elle a besoin d'exploration pour affiner le besoin. Ce qui veut dire qu'elle ne peut pas écrire une spécification immuable, même incomplète. Elle est en charge d'exprimer le besoin, mais ne possède pas la vérité ultime sur ce besoin, et l'expression qu'elle en fait est un outil de travail pour arriver à le remplir. La mesure de succès de Josianne est la satisfaction du besoin, et non seulement son expression correcte et complète;
• Robert accepte cet état de fait et se met en disposition pour pouvoir changer facilement certains éléments, notamment les aspects visibles (toujours très sensibles!). Il est en charge de traduire l'expression du besoin (sa compréhension de l'expression du besoin) en un outil informatique. Sa mesure de succès est la satisfaction du besoin, et non pas simplement la conformité à une expression du besoin;
• Josianne et Robert réalisent qu'ils ont besoin l'un de l'autre, et s'aident en aidant l'autre.

Septième semaine: Josianne et Robert travaillent en binôme sur l'application, à partir des retours utilisateurs, en recherchant des quick wins qui permettraient de restaurer la confiance. Josianne écoute les suggestions de Robert, Robert accepte des modifications à partir des "nouvelles idées" de Josianne. A la grande surprise d'Hervé, prêt à tout arrêter, les utilisateurs sont ravis de la démonstration. Ils n'ont pas vu toute l'application, mais ont enfin l'impression d'avoir été entendus et écoutés.

Que s'est-il passé? Le pari de la coopération a payé. Certes, Josianne continue à gérer le risque sur le besoin, Robert le risque technique. Mais ils travaillent ensemble. Quelle est différence cela fait-il?

• Ils ont un objectif commun, la satisfaction du besoin des utilisateurs, et donc d'une certaine manière portent le fardeau ensemble, plutôt que de le passer à l'autre à un moment du chemin;
• Ils travaillent maintenant en plus grande proximité, avec une interaction plus rapide et un feedback plus immédiat et bien accueilli.

Quelle est la baguette magique qui permet le changement de la septième semaine pour notre projet, qui permet de changer l'attitude de Josianne et de Robert ? Il n'y a pas de recette universelle, mais il y a bien souvent des choses à faire, ne serait-ce que d'essayer une posture différente sur un temps court - Josianne et Robert sont en général de bonne volonté et cherchent à bien faire leur travail.