Connaissez cette bande dessinée représentant un arbre et une balançoire ? Une métaphore visuelle qui montre comment une demande simple (une balançoire) peut être interprétée de manière très différente par le client, le chef de projet, l’analyste, le développeur, …
Une histoire d’expression du besoin ?
La première version de cette image date des années 70, paraît-il. Pourtant l’image ne vieillit pas, et reste tellement représentative de ce qui peut se passer durant la gestion d’un projet digital. J’ai vu …
- Un commercial et un technicien être d’accord et employer les mêmes mots pour décrire une fonctionnalité, mais être en désaccord total lors de la validation de celle-ci.
Dialogue de sourds : le commercial indique que, non, ça ne fonctionne pas en toute bonne foi, le technicien répondant que, oui, tout fonctionne bien pourtant.
- Des commerciaux décrire la mécanique de précision d’un site à des clients (la pensée positive vous connaissez ?), alors que les enjeux stratégiques ne prévoyaient même pas d’explorer ce chemin.
- Des développeurs être impliqués à 300%, et pourtant livrer une balançoire à terre. Ils étaient déjà positionnés sur les starting blocks, ‘full-motivés’ à itérer une nouvelle fois pour le nouveau défi : relever la balançoire ! (lol)
- Le manque de temps, créant des spécifications dans lesquelles la balançoire est ‘peut-être un peu trop proche du tronc ‘, rendant l’utilisation quasi impossible et ‘poussant’ gentiment l’effort à l’équipe de développement. Dommage pour les dév …
- Je me rappelle des devis épais, impressionnants, colorés, mais peu personnalisés en fonction de nos différents projets.
- Et le client, avec un sourire béat, se balancer sur son nouveau jouet : la ‘balançoire-pneu’ !
En dépit de sa demande initiale de balançoire à trois étages, la ‘balançoire-pneu’ reflétait totalement son originalité et lui allait si bien.
À qui la faute ? Biais cognitif ?
C’est facile de se dire que ‘l’autre’ n’a pas compris, ‘c’est normal, il n’y connaît pas grand chose ‘, qu’il n’a pas su écouter ou prêter attention, mais ça ne résout rien.
Alors comment faire ?
Chaque personne ‘imagine’ le projet à travers ses propres lunettes. Il ne s’agit pas de manque de connaissances, de compétences ou de communication, nous avons tous notre vécu et nos filtres d’interprétation : nos biais cognitifs.
Quelques pistes pour visualiser, clarifier et prioriser
- Avant de parler de fonctionnalités, quel problème résout-on ? Pour qui ?
- Quel changement CONCRET, PHYSIQUE doit-on observer comme preuve de résolution du problème ?
- Quels sont les objectifs de chacun des acteurs du projet et comment chacun comprend ces objectifs ?
- Quels sont les contraintes de chacun ?
- Quels visuels, maquettes rapides peuvent rendre visible ce que des mots peinent à montrer ?
On entend souvent qu’il faut plus ou mieux communiquer.
Là aussi, augmenter ou changer de communication ne sera pas déterminant tant que l’équipe ne travaille pas ensemble.
Il ne s’agit pas non plus de travailler constamment ensemble, mais plutôt de créer des plages d’ateliers aussi courtes que possible pour prendre le diapason et le temps de s’accorder.
Car un projet ne déraille pas faute de compétences.
Il déraille faute d’alignement.
Et l’alignement ne se décrète pas.
Il se construit, volontairement.
