Satisfaire le client : le client est roi, vraiment ?

Commençons notre série des principes de l’agilité en parlant de la satisfaction client. Le plus dur quand on réalise un projet c’est de satisfaire notre client, nous allons voir ensemble les erreurs sur nos modes de pensées habituelles, et comment on peut changer cette vision, comment on peut restaurer la confiance client.

Le client n’est pas un roi, la cliente n’est pas une reine

Dès que l’on commence la phrase « le client est », tout le monde (ou presque) répond : « roi ». C’est presqu’un automatisme !

Ok, et ça veut dire quoi « roi » ? Quels sont les privilèges d’être roi, d’être reine ?

Je fais ce que je veux, nah

Vous avez sans doute vu ces films où le roi demande à ses sujets de faire quelque chose, puis, juste après, change d’avis, en fait il ne veut plus ça, mais autre chose.

Et ce va et vient peut durer éternellement, n’est-ce pas ?
Comment l’arrêter ?

Souvent on n’ose pas dire non à un roi. Dans l’imagerie populaire, on a peur de se faire couper la tête, nous craignons subir le courroux de ce roi, cette reine capriceux-euse !

Une image que j’aime bien apporter vient d’un de mes dessins animés préférés : Kuzko, l’empereur mégalo.
Personne n’ose dire non à tous les caprices du roi Kuzko. A part une personne, une seule (je vous laisserai découvrir qui si vous n’avez pas vu ce délicieux dessin animé).

Transformons l’image d’un client capricieux

Osez dire non à un client, ce n’est pas simple et surtout c’est couteux :

Devenir pro-actif-active et prendre le taureau par les cornes en disant non à son client, à sa cliente, pourtant, ça n’apporte que du bon.

Vous allez être aligné-e avec ce que vous êtes, ce que vous croyez, ce que vous savez. Vous allez chercher à réellement satisfaire votre client, votre cliente, sur ce que vous savez faire, et réellement faire.

Mieux vaut ne pas faire quelque chose une fois, quitte à décevoir que de le faire, le faire mal et en payer le prix toute une vie.

Gagner la confiance du client

confiance client
Photo by Fancycrave on Unsplash

En disant non, on va chercher à expliquer, à démontrer pourquoi. Nous allons donc nous aligner sur les valeurs de notre entreprise, sur nos valeurs.

En plus des valeurs, notre expertise, ce pourquoi le client vient nous voir, sera mis en avant : si nous disons non, ce n’est pas par principe de refus, de contradiction.

Savoir dire non, C’est un des premiers piliers pour une confiance durable.

Les 4 piliers de la confiance

Rappelons les 4 piliers de la confiance :

En disant non, nous assurons donc à notre client notre intégrité.

Promettre n’est pas faire

Bien que soit pavé-e de toutes les bonnes intentions du monde, avec une équipe du feu de dieu, motivée, autonome et prête, si vous n’amenez pas :

Votre client commencera à douter de vous, et avoir l’impression de perdre son argent : la confiance va commencer à s’effriter ! (et ça peut aller très vite).

Comment être sûr alors que ce l’on fait est ce qu’attend notre client-e ?

Des enfants et des cadeaux

Tenez, reprenons une histoire bien connue :
Vous voilà à votre noël, vous n’avez pas spécialement de souhait de cadeau. Mais, avouons-le, sisi on va l’avouer ensemble : vous attendez quand même des cadeaux.
Et là, devant vous plein de cadeaux : des petits, des gros.
Et aucun pour vous … vous vous sentez comment ? Déçu-e, n’est-ce pas ? (même si on est adulte, on aime bien les cadeaux aussi).

Quand on est client-e, on redevient enfant. On attend des cadeaux, des cadeaux qui font plaisir, qui nous font plaisir, pas à ceux qui les ont achetés !

Et là, sur le côté, un cadeau, avec votre nom dessus. Ah, ouf, on a pensé à moi, vous vous dîtes. Vous déballez le cadeau, avec hâte, pas trop quand même, mais tout de même !

Vous ouvrez et …. oh non … j’aime pas XXX pourtant je leur avais bien dit que j’aimais pas XXX (remplacez les XXX).

cadeau empoissonne deception
Photo by Kira auf der Heide on Unsplash

Vous voilà déçu !

Même si on livre quelque chose à temps à un client, une cliente, on peut le-la décevoir : si ce qui est livré n’a pas de valeur, n’est pas ce qui était comme imaginé, souhaité ….la déception sera là.
Et plus l’attente sera forte, plus la déception l’emportera et grandira.

Livrer fréquemment, oui mais livrer quoi ?

Comment être sûr de livrer un produit :

Déjà, commençons par livrer fréquemment : au lieu d’attendre le dernier moment : (ça peut être 2 ans après la précision des besoins), livrez fréquemment.

A quel rythme

Souvent j’entends : alors SCRUM m’a dit que c’est toutes les 3 semaines, donc même si le client veut plus fréquemment, je dis non, comme ça je suis intègre, et puis nah ! c’est comme ça et pas autrement.

Si vous souhaitez vraiment être agile : cherchez un accord commun avec votre client-e, et ça sera le mieux, c’est aussi ça : satisfaire le client, la cliente.

Montrer au client, à la cliente que l’on avance

Une fois l’accord validé, livrer fréquemment va permettre au client, à la cliente, de le-la rassurer : vous avancez (vous montrez vos résultats) !

Et deuxième effet positif : il-elle peut vous faire des retours, rapidement, pour encore plus être satisfait-e, et affiner ses besoins à lui-elle !

Livrer ce qui a de la valeur, ce qui est prioritaire

Tiens pour finir, si vous me demandez de vous construire une maison (ok, ok admettons que je sache construire une maison :D), si je vous livrais juste une fenêtre, et puis tiens la terrasse, et que je partais, vous diriez quoi ?

Livrer ce qui est prioritaire …

Cherchons ensemble les priorités du client : qu’est ce qu’il veut en premier, qu’est ce qui est le plus important pour lui-elle ?

Pour vous aider à trouver réponse à cette question, posez la question suivante au client : si je vous quitte dans 2 semaines (pour de bon), que voulez-vous avant mon départ ?

… avec de la valeur

OK, mais si vous livrez quelque chose que le client veut mais qui n’a pas vraiment de valeur (au sens de fonctionnalité qui apporte une plus-value), est-ce vraiment important de la livrer prochainement ?

Cherchez toujours à définir avec votre client-e si ce qu’il-elle souhaite a de la valeur, apporte de la valeur au produit final en construction !

Un client arrive, il vous demande un produit, et l’attend pour dans 2 mois. Pour ce produit : il veut 50 fonctionnalités. Et il les veut toutes ! Toutes ? Un village de fonctionnalités résiste encore et toujours à l’envahisseur.

Découvrons ensemble comment apprendre à combattre l’envahisseur JeVeuxToutToutDeSuite, grâce à un jeu agile (Serious Game)

Le client est Roi, vraiment ?

Quand on commence à créer un produit, on cherche à satisfaire un client, qui a souvent la posture du Roi, de la Reine.

On commence à s’armer contre lui, et, pourtant, on lui laisse la porte ouverte à ce qu’il-elle demande : à savoir tout. Et en plus, quel toupet, il-elle veut tout, tout de suite.

Se remettre en question : changer de positionnement

Alors, oui, c’est sûr, quand on demande au client-à la cliente, ces fonctionnalités, vous les voulez pour quand ?

Il-elle vous répondra : tout de suite (quand votre client-e est sympa), il-elle vous dira aussi : hier (quand il-elle est honnête)

Une question biaisée

En fait, ce n’est pas une bonne question : on induit automatiquement par cette question : quand veux-tu, ô mon-ma client-e, que je te livre tout le produit-que-tu-souhaites-depuis-tellement-longtemps.

Il devient alors évident que le client ne voudra se séparer d’aucune fonctionnalité de son produit.

Comment alors réussir à se sortir de ce piège, tendu par le client (et contre lui-même), et à l’équipe ?

Tout est une question de priorité

Au lieu de lui parler du produit final, posons-lui des questions sur ses priorités.

La vision Priorité – L’équipe aussi

Le client conquis par cette vision de la création de produit, reste à convaincre l’équipe, et surtout, reste à savoir comment le faire bien.

Il paraît bien simple de connaître les priorités, il devient plus dur, une fois sur le terrain de l’appliquer, réellement.

C’est ici qu’intervient notre jeu : AgiPuzz.

Avec quoi : avec un puzzle, où il y a des personnages. Prenez par exemple un puzzle où est charlie.

Règles du jeu

La partie se joue par équipe de 3 à 5.
(note: il existe une variante avec 10 à 20 joueurs, où l’on cherche à montrer les difficultés de travailler ensemble).

Chaque équipe s’affronte, le but étant de faire le plus de points.

Comment gagne-t-on des points ?
Pour gagner des points, il suffit de finir un bonhomme.
Par finir, on entend fini : pas un bout qui manque, pas bras qui n’est pas présent.

En fait, c’est l’animateur qui définit ce qu’il entend par fini.
(on travaille ainsi la notion de fini, donc d’attendu, donc de tests d’acceptation).


La partie se joue en 6 itérations (round) de 2 minutes chacune:

Puis, on ajoute une nouvelle règle au jeu : on ne peut gagner des points que si l’ensemble des bonhommes appartiennent à un même bloc de puzzle.
Exit, donc, les bouts de puzzles éparpillés partout : il va falloir prioriser, donc choisir.

On finit donc par trois itérations, avec cette nouvelle règle.

NOTE: avant chaque itération, on demande, au doigt levé, (en moins de 10 secondes) pour chaque équipe, combien elle estime faire de bonhommes finis pour la prochaine itération.

NOTE: à chaque fin d’itération, on débrief : nombre de points gagnés réels, par rapport à l’estimé.

Il existe une variante, où trouver charlie fait gagner 3 points au lieu de 1 😉

Photo by Ryoji Iwata on Unsplash

Debrief avec l’équipe

Maintenant, vous pouvez débriefer avec vos équipes, sur ces sujets :

Bien difficile de s’y retrouver entre Scrum, agilité, lean, extreme programing, et tout ce qui touche à l’agilité. Faisons un tour sur ce qu’est vraiment l’agilité, et pourquoi on confond outil et approche, état d’esprit et méthodologie.

Pas de méthode agile

Mettons les pieds dans le plat : ça n’existe pas la méthode agile. Oui, ça peut vous paraître bizarre au vue des livres que l’on voit un peu partout dans le commerce.

Tiens, rien que sur Amazon : https://amzn.to/2Cb0rl9. Le nombre de titres à propros de méthode agile est impressionnante, et peut amener la confusion, vous ne trouvez pas ?!

Une méthode, c’est une recette qui fonctionne

Si l’on commence par une définition du Larouse :

Ensemble ordonné de manière logique de principes, de règles, d’étapes, qui constitue un moyen pour parvenir à un résultat

Ainsi, si l’on appliquer la « méthode agile », on doit arriver à un résultat, n’est-ce pas ?

Ce résultat, quel est-il ? La réussite du projet bien sûr !

Si vous voulez faire un gâteau, vous suivez une recette et ça fonctionne … vraiment ?

Réussite d’un projet, vous avez dit ?

Pensez-vous qu’un projet, dit agile, réussit à tout prix ?
Détrompez-vous ! Les statistiques ne sont pas convaincantes, hélas!

On apprend qu’en moyenne, le taux de réussite d’un projet informatique ocille entre 11 et 35% selon les définitions de réussite.

Et l’agilité dans tout ça ? Aide-t-elle les projets à mieux réussire ?

Un projet informatique utilisant les approches agiles voit sa probabilité de réussite doubler (voir tripler)

OK, ça nous donne un taux de réussite allant de 30 à 45% environ …

Appliquer une « méthode agile » ne garantit pas la réussite du projet

agile-vs-waterfall-success-rates-2013-2017_blog-2

L’agilité, c’est avant tout un état d’esprit

Il ne suffit pas de claquer des doigts et dire : ça y est on fait de l’agilité pour que ça fonctionne !

C’est un état d’esprit, une autre approche de la gestion de projet !

Repenser le projet autour de valeurs et de principes :

L’approche agile, une amélioration continue

Il ne suffit pas de dire je veux faire de l’agilité, vous l’aurez compris.

Bien souvent, on a envie de décréter : allez hop, on utilise la méthode agile et tout va fonctionner … et on sera vite deçu !

C’est un vrai travail d’amélioration continue qui doit se mettre en place dans votre entreprise, dans les équipes.

Et le plus dur c’est d’accepter que certains postes clefs ne seront (à terme) plus nécessaires :

SCRUM, c’est une méthode alors ?

Quand on parle d’agilité, souvent, si on fait un question pour un champion, on a soit : Stéphanie de Monaco, soit Scrum qui arrivent comme proposition.

Blague à part, Scrum est un mot, une notion qui arrive bien souvent, qui commence même à être connue aujourd’hui.

autonomie des équipes
Photo by rawpixel on Unsplash

Scrum, ce n’est pas une méthode

Oui, vous avez bien lu, Scrum n’est pas une méthode, donc pas une méthode agile.

Scrum c’est un framework ! C’est un cadre qui protège, qui aide. Ce n’est pas un faiseur de miracle.

Reprenons notre idée de recette :
Si Scrum est une méthode, cela veut dire que si je la suis à la lettre, j’obtiens ce que je veux, à savoir : la réussite du projet. Et ce n’est pas le cas !

Appliquer Scrum ne garantit pas la réussite de votre projet

Scrum est un cadre qui nous guide sur ce qui pourrait être bien. C’est en fait une première approche de ce que l’on peut faire dans un projet, dit agile.

Ainsi, si l’état d’esprit de l’équipe (de l’entreprise même) n’est pas agile. Si il ne respecte pas les principes et valeurs de l’agilité, rien ne garantit que Scrum soit la bonne solution !

Scrum n’est qu’un outil, tout comme le marteau pour un clou

Comment se rapprocher de la réussite d’un projet avec l’agilité ?

Déjà, vous n’êtes pas obligé-e d’appliquer Scrum à la lettre !
Vous voilà rassuré-e ?

Souvent durant mes audits, les équipes me disent : « on n’est pas très agile tu sais, on ne fait pas le daily meeting, on le fait plus tous les deux ou trois jours ».

Ce n’est pas parce que l’on applique pas Scrum à la lettre qu’on n’est pas agile ! Loin de là ! C’est un état d’esprit, une volonté, un guide, presqu’une vocation !

La réussite d’un projet se construit autour de plusieurs facteurs clefs :

Et de là découle plein de sous-points clefs, comme : la communication, tuer l’implicite, autoriser l’erreur, l’essai, permettre d’être créatif, apprécier le client, échanger avec le client, …

Une équipe ne se décrète pas comme agile, elle va apprendre à le devenir, elle va construire son expertise dans le temps.
Et la réussite du projet viendra, petit à petit.

Si je vous dis cahier des charges, vous pensez tout de suite : grosse documentation en amont. Vous pensez aussi : non réussite du projet, non ?  Et puis il y a tout ce temps pour construire le cahier des charges, qui devient inutile 6 mois plus tard (lorsque le cahier des charges est fini d’être construit). Je vous propose un jeu simple que j’utilise en formation, pour démontrer : l’apprentissage par répétition et aussi la construction d’un cahier des charges, en agilité, par itération. Laissez-moi vous présenter le téléphone agile (je tiens le nom du jeu d’un des apprenants qui m’a dit : »Evan on dirait un téléphone arabe, mais agile => c’est un téléphone agile », merci à lui).

Open serious game

Je fais partie d’un collectif qui prone les valeurs de la transmission et du jeu en entreprise. Non pas le jeu pour le jeu, mais le jeu pour apprendre. Une vocation pour ce collectif : réveiller le pouvoir de transmettre en chacun de nous !

Si ce jeu de fin de module vous plaît : utilisez-le, réutilisez-le, modifiez-le ! D’ailleurs je serai ravi d’avoir ravi d’avoir vos idées d’amélioration !

Contexte

Vous arrivez à la fin d’un module de la formation que vous donnez, ou bien, vous souhaitez voir si les personnes avec qui vous êtes se rappellent bien ce qui a été vu ?

En plus, vous souhaitez montrer les bienfaits d’un cahier des charges agile : évolutif et itératif ?

Règles du jeu

Nombre de personne : inférieur à 15. Autrement, ça peut sembler long pour le/la dernier-e de la salle.

Durée : temps nécessaire pour que chaque personne ait parlé une fois.

But : construire une phrase avec tous les intervents, pour résumer ce qui a été vu.

Déroulement :
Chaque personne va pouvoir dire de 1 mot à un bout de phrase et le transmettre à son voisin, sa voisine.
Il/Elle doit toujours penser à ce qui est transmis est : compréhensible, retenable, lié à ce qui a été vu dans le module, la formation.

L’autre personne doit reprendre ce qui a été dit (tout ce qui a été dit auparavant), et compléter avec son mot, son bout de phrase.

Continuez jusqu’à ce que tous les participants aient joué.

Ecrivez le résultat sur le tableau, sur slack  …

Débriefer sur ce travail du téléphone agile

Posez d’abord la question sur le ressenti.

Proposez d’échanger sur le positif, les axes d’améliorations.

Parler du cahier des charges, et échangez avec eux sur ce qu’il pense de cette construction itérative.