Comment construire un système de feedback pour vos déploiements
C’est le grand jour : c’est le premier jour du déploiement de votre outil. Les premiers retours utilisateurs arrivent… et là, personne ne sait quoi en faire. 😬 Que fait-on des feedbacks ? Où est-ce qu’on les stocke ? Qui les traite, et quand ? Dans cet article, je vous explique comment organiser un système de feedback de bout en bout.
Je tiens à préciser que je vais utiliser les termes de « retour » et de « feedback » dans cet article.
Pourquoi un système de feedback est si important
Commençons par une métaphore
Imaginez. Vous êtes au restaurant et vous commandez une bonne soupe aux oignons. Le serveur vous sert votre soupe, et en goûtant vous vous apercevez que la soupe est beaucoup trop salée.
Vous faites la remarque au serveur qui, poliment, vous remercie et vous indique qu’il va partager votre retour aux cuisines.
Deux semaines plus tard, vous allez au même restaurant, vous commandez la même soupe car, après tout, quoi de mieux qu’une soupe aux oignons pour un déjeuner en plein hiver. Le serveur vous apporte votre soupe, vous la goûtez et… la soupe est trop salée !
Il y a plusieurs réactions qui peuvent suivre :
- vous faites à nouveau la remarque au serveur et commanderez (peut-être) à nouveau la soupe
- vous ne commanderez plus jamais de soupe, tant pis pour eux ! Mais vous restez fidèle à ce restaurant.
- vous n’irez plus jamais dans ce restaurant car vous ne vous êtes pas senti écouté.
Quel rapport avec des projets dans les organisations ?
C’est la même chose pour vos utilisateurs. S’ils font part de leur retour et qu’ensuite ils voient que rien n’a changé entretemps, ils vont arrêter de vous faire des feedbacks.
Collecter et organiser un système de feedback
Les feedbacks sont primordiaux car, tout d’abord, ils montrent que les utilisateurs s’intéressent à l’outil et ils prennent le temps de faire un retour. Et ensuite, les feedbacks (de qualité) permettent d’améliorer l’outil.
Une durée de vie courte
Le feedback est « périssable« . Un utilisateur ne fait pas un retour par gentillesse, il le fait parce qu’il croit que son retour va changer quelque chose.
Et croyez-moi sur parole, cette croyance a une durée de vie courte.
S’il ne voit pas que son retour va faire quelque chose, il va arrêter de le faire. Il peut même devenir résistant au changement s’il ne se sent pas écouté.
Deux objectifs, pas un seul.
L’organisation des feedbacks sert deux objectifs :
- améliorer le produit maintenant
- Et aussi préparer les déploiements suivants.
Les retours ne sont pas que du service après-vente, ils sont aussi des pistes de capitalisation pour améliorer l’outil, les formations, le suivi.
Qu’est-ce qu’un bon système de feedback (et ce qu’il n’est pas)
Définissons les termes
Par système de feedback j’entends l’organisation de l’ensemble des canaux (emails, Teams, Slack, réunion), des rôles et des rituels qui permettent qu’un feedback soit collecté et traité.
La boucle des feedbacks
Un feedback suit un chemin. Ce chemin commence par l’expression du feedback dans un « registre » dédié (un fichier ou une plateforme), ce feedback est revu et qualifié, ensuite il est priorisé afin d’être traité. La fin du chemin est la restitution du feedback à son émetteur.
Les deux points critiques de la boucle
Le début et la fin de la boucle sont l’enjeu majeur d’un bon système de feedback.
Début de la boucle : l’expression
L’enjeu pour le début est d’avoir un feedback de qualité. Plus il est de qualité, meilleure (et plus rapide) sera sa prise en charge par l’équipe qui traite les feedbacks.
Un feedback de qualité c’est :
- Une date
- Le contexte
- Expliquer concrètement et objectivement ce qu’il se passe et qui pose problème
- Quelle est l’amélioration souhaitée
La fin de la boucle : retour à l’envoyeur
La fin de la boucle est celle que l’on oublie le plus souvent. Et pourtant, c’est ce retour qui va donner confiance à l’émetteur du feedback et lui faire comprendre qu’il peut continuer à faire des retours car ils sont pris en compte.
Un retour de qualité c’est :
- Rappeler le feedback initial qui a été fait
- Expliquer (brièvement) le travail qu’il y a eu
- Expliquer le résultat
- Poser la question « est-ce que ce retour t’aide ? » pour vous assurer que le retour qui a été fait répond à l’interrogation de l’envoyeur.
Les 3 idées reçues sur l’organisation des feedbacks
- Ce n’est pas un help desk. On ne dépanne pas, on améliore.
- Ce n’est pas à voie unique, c’est une boucle.
- Ce n’est pas le rôle de toute l’équipe de récupérer les feedbacks.
Mettre en place un système pour collecter les feedbacks et les traiter, étape par étape
Étape 0 – Le meilleur feedback est celui qui n’est pas fait
Je provoque avec ce titre. L’idée est que, avant de penser à l’organisation des feedbacks, il faut s’assurer que les utilisateurs ont accès à une documentation de qualité pour bien comprendre et utiliser l’outil.
Cela peut être des vidéos explicatives, les supports de formation, des guides explicatifs.
Ainsi, l’utilisateur, avant de penser à faire un retour, peut aller chercher lui-même la réponse avant d’écrire un feedback.
Cela fait un feedback de moins à traiter.
Par contre, il arrive souvent que le feedback ne trouve pas de réponses dans la documentation.
Étape 1 – Définir l’objectif avant les canaux
L’étape 0 étant maintenant posée, il s’agit à présent de définir ce que vous attendez de ces feedbacks.
Vous voulez dépanner les utilisateurs ? Améliorer le produit ? Capitaliser pour continuer de déployer l’outil dans d’autres villes/pays ?
En répondant à ces questions, vous arriverez plus facilement à choisir le bon dispositif et le bon outillage.
Étape 2 – Cartographier les sources de retours
Cette cartographie des sources des feedbacks est importante car les utilisateurs ne sont pas la seule source des feedbacks.
Il y a aussi les managers des utilisateurs (qui sont peut-être utilisateurs eux aussi), il y a aussi les équipes périphériques, les ambassadeurs, l’externe (clients, prestataires, fournisseurs) etc.
L’idée, avec la cartographie, est d’avoir une vue d’ensemble de la provenance des retours.
Étape 3 – Distribuer les rôles
Organiser la collecte et le traitement des feedbacks, c’est répartir les rôles.
Pour cela, je vous propose trois rôles distincts qui sont souvent pris en charge par une seule personne qui se trouve rapidement débordée :
- un rôle pour faire les remontées auprès des différentes sources
- un rôle pour qualifier les remontées, c’est-à-dire trier, catégoriser, prioriser
- un rôle pour traiter les remontées : technique, métier ou communication
Le rôle de qualification est central car c’est lui qui fait le gardien du temps. En effet, l’équipe technique est limitée en temps et en ressources et elle a besoin de travailler sur des feedbacks de qualité et priorisés.
Étape 4 – Limiter les canaux
L’idée est d’éviter les emails + les discussions sur Teams + les réunions.
Vous pouvez très bien avoir un canal pour répondre à tout ce qui est urgent (bug, blocage). Et un autre canal pour faire du travail de fond sur les retours sur le projet.
L’approche est d’avoir deux ou trois canaux maximum, avec une règle d’usage écrite, partagée et validée par tous les participants.
Étape 5 – Choisir un support unique, accessible et modifiable
Le point central est un document de référence.
Un document de référence, c’est un Excel partagé, un PowerPoint, un Word, un Kanban, un Klaxoon, un outil de ticketing comme Service Now. Qu’importe.
L’idée est d’avoir un document de référence.
Ce document doit être consultable et modifiable par tous, à jour et clair.
Étape 6 – Installer le rituel d’animation
Le (ou les) canal est identifié, un fichier de référence existe, maintenant il s’agit de faire fonctionner ce système de feedback.
L’idée est de créer une instance dédiée à la revue, qualification et priorisation de ces feedbacks. Dans cette réunion, doivent être présents ceux qui qualifient les remontées et ceux qui traitent les remontées.
Pendant ce rituel, l’équipe met à jour le statut des feedbacks (à partager, en cours de résolution, en dehors du périmètre, résolu) et on échange sur de nouveaux feedbacks.
Étape 7 – Clore la boucle
La dernière étape, et non des moindres, est de partager un statut des retours aux utilisateurs. Cela va donner confiance aux utilisateurs sur l’organisation du projet et aussi sur la prise en compte de leurs feedbacks.
Cette étape est PRIMORDIALE, j’insiste parce que c’est très important.
Étape bonus – Faites la chasse aux feedbacks de l’ombre (Shadow Feedback)
La bonne organisation d’un système de feedback demande de la rigueur, de la constance et de la discipline. Et parfois les mauvaises habitudes reprennent le dessus.
Une astuce est de demander lors de la réunion rituelle d’animation sur les feedbacks si des personnes autour de la table ont été sollicitées sur d’autres canaux que ceux qui ont été instaurés ? Si oui, alors pourquoi ?
L’idée est de rappeler constamment qu’il faut garder le système de feedback actuel. Cela peut aussi vous donner des idées d’amélioration de ce système.
Les erreurs à éviter
Un système de feedback peut prendre de mauvaises directions. Voici ce qu’il faut éviter.
Ne pas anticiper
Définissez avant le Go Live les rôles, le canal et le support à utiliser. Il faut à tout prix éviter de rendre public le projet sans avoir une structure et une organisation pour les feedbacks.
Bref… anticipez.
Votre « vous » futur vous remerciera.
La boîte noire
C’est un sentiment que connaissent énormément d’utilisateurs : ils partagent un retour et ensuite… plus rien !
Leurs retours disparaissent dans le triangle des Bermudes.
Les utilisateurs ont besoin d’avoir un retour sur… leur retour. D’où l’importance de mettre en place un système de feedback.
Des emails, des appels, des réunions et bla bla et bla bla
Tout récemment, j’ai fait un retour à l’équipe technique auprès de qui je faisais des feedbacks, je leur disais « J’ai l’impression d’être éparpillé en une centaine de petites parties ».
Je disais cela parce qu’il y avait tellement de discussions sur Teams, d’emails, de réunions et de comptes rendus que je ne voyais plus rien, tout était flou !
Évitez à tout prix la prolifération des canaux. Chaque canal supplémentaire rend floue la traçabilité et multiplie les doublons, triplons et pire encore !
Monsieur (ou Madame) « Je fais tout »
Lorsque vous voyez une personne du projet qui collecte, priorise et traite les retours, une alarme doit tout de suite s’allumer dans votre tête 🚨
Ce n’est pas tenable pour une personne de tout faire.
Le respect des rôles assure une bonne répartition de la charge.
Un interlocuteur technique = Un interlocuteur métier
Lorsque vous collectez des feedbacks, je vous invite à toujours associer un feedback entre un interlocuteur du métier (le sachant du process et du terrain) et un interlocuteur IT (le sachant de la solution).
Ainsi vous aurez toujours le bon interlocuteur l’un en face de l’autre.
L’iceberg du feedback
C’est facile, très facile de faire des feedbacks.
C’est plus difficile de prioriser et qualifier les feedbacks.
Et c’est ENCORE plus difficile de traiter les feedbacks.
Soyez trop vigilant à être très, très rigoureux sur les feedbacks qui arrivent. Il s’agit de faire en sorte que seuls des feedbacks de qualité arrivent dans la todo list de l’équipe technique car sinon elle risque d’être noyée par le traitement de tous les feedbacks.
Si vous ne deviez retenir qu’une seule chose de cet article, c’est qu’un feedback sans retour détériore la perception des utilisateurs sur un projet. La boucle de feedback ne s’arrête pas quand le problème est traité, elle s’arrête quand l’émetteur le sait.
Et vous, est-ce que vos utilisateurs ont des nouvelles de leurs retours ? Quelles sont vos astuces ?👇