Votre tableau de bord ne vous donne probablement pas le feedback dont vous avez besoin

Vous avez un tableau de bord. Il affiche les taux d'erreur, les temps de réponse et les requêtes échouées. Les graphiques se mettent à jour en temps réel. Les couleurs sont vert, jaune et rouge. Vous avez l'impression d'avoir de la visibilité.

Mais posez-vous cette question : qui lit réellement ces données ? Quand les lit-on ? Et que fait-on après les avoir lues ?

De nombreuses équipes ont des tableaux de bord impressionnants qui ne génèrent presque aucune action utile. Le problème n'est pas la donnée. Le problème est que la donnée n'atteint pas la bonne personne au bon moment et sous la bonne forme. Un tableau de bord est un affichage. Un système de feedback est quelque chose qui change la façon dont une équipe travaille.

Le feedback doit atteindre la personne qui peut agir

Lorsque les taux d'erreur grimpent après un déploiement, qui est informé en premier ? Est-ce l'équipe qui vient de déployer, ou une autre équipe qui est de garde par hasard ?

Dans de nombreuses organisations, l'équipe qui déploie n'est pas celle qui reçoit l'alerte. L'alerte va à une équipe d'exploitation séparée ou à un ingénieur de garde en rotation qui n'a aucune idée de ce qui vient de changer. Il passe les vingt premières minutes à essayer de comprendre ce qui s'est passé. Il vérifie l'historique Slack. Il regarde le journal de déploiement. Il demande autour de lui. Au moment où il comprend la situation, l'équipe qui a déployé est déjà partie.

C'est une boucle de feedback cassée.

L'équipe qui a effectué le déploiement devrait être la première destinataire du feedback sur ce déploiement. Elle sait ce qui a changé. Elle sait pourquoi cela a changé. Elle peut décider de revenir en arrière, de corriger en avant, ou de laisser faire. Envoyer le feedback à quelqu'un d'autre en premier n'ajoute que de la latence et de la confusion.

Tout feedback n'a pas besoin d'une alerte de pager

Les équipes commettent souvent l'erreur de traiter tout feedback de la même manière. Chaque métrique a un seuil. Chaque seuil déclenche une notification. Chaque notification va dans le même canal. Le résultat est du bruit, de la fatigue, et finalement les gens ignorent complètement les alertes.

Le feedback doit correspondre au contexte.

Certains feedbacks sont urgents. Si les requêtes échouées passent de 1 % à 30 % pendant un déploiement, cela nécessite une attention immédiate. Quelqu'un doit être pagé. Quelqu'un doit regarder l'écran maintenant.

D'autres feedbacks sont lents et cumulatifs. Une augmentation progressive du taux d'erreur sur deux semaines n'est pas une urgence. C'est un signal que quelque chose se dégrade. Cela appartient à un rapport quotidien ou à une revue hebdomadaire. Cela ne nécessite pas de réveiller quelqu'un à 2 heures du matin.

Lorsque vous traitez un feedback lent comme un feedback urgent, votre équipe apprend que la plupart des alertes sont de fausses alarmes. Ils cessent de répondre. Puis, quand une vraie urgence se produit, personne ne la remarque.

Définissez comment répondre, pas seulement quoi regarder

Un schéma courant est que les équipes construisent des tableaux de bord puis s'arrêtent. Elles supposent que si la donnée est visible, quelqu'un saura quoi faire. Cette hypothèse est presque toujours fausse.

Lorsque le feedback arrive, l'équipe a besoin d'un schéma de réponse clair. La première étape n'est pas la recherche de coupable. La première étape est la compréhension. Ce problème est-il déjà arrivé ? Y a-t-il un changement récent qui pourrait l'expliquer ? Pouvons-nous revenir en arrière, ou avons-nous besoin d'un correctif en avant ?

Les équipes qui gèrent bien le feedback ont une habitude simple : elles vérifient, elles agissent, elles enregistrent. Elles vérifient ce que le feedback leur dit. Elles agissent en fonction de ce qu'elles savent. Elles enregistrent ce qu'elles ont appris pour que la prochaine fois que le même schéma apparaît, elles le reconnaissent plus rapidement.

Cela semble évident, mais la plupart des équipes sautent l'étape d'enregistrement. Elles corrigent le problème et passent à autre chose. Trois mois plus tard, le même problème se reproduit, et personne ne se souvient comment il l'a résolu la dernière fois.

Le feedback le plus précieux vient souvent de l'extérieur de votre système

Vos tableaux de bord mesurent ce que vous avez décidé de mesurer. Ils ne mesurent pas ce à quoi vous n'avez pas pensé.

Parfois, un utilisateur signale qu'une fonctionnalité semble lente, alors que toutes vos métriques techniques affichent des valeurs normales. Parfois, l'équipe de support reçoit des plaintes qui n'apparaissent dans aucun tableau de bord parce que le problème ne se produit que sur un appareil ou une condition réseau spécifique.

Si votre système de feedback n'inclut que des données automatisées, vous manquerez ces signaux. L'utilisateur et l'équipe de support font partie de votre système de feedback, que vous l'ayez conçu ainsi ou non. La question est de savoir si vous les écoutez.

Facilitez la tâche aux utilisateurs pour signaler des problèmes. Facilitez la tâche au support pour escalader les schémas. Traitez une plainte d'utilisateur aussi sérieusement qu'un pic de taux d'erreur. L'utilisateur vous dit quelque chose que votre surveillance ne peut pas voir.

Les systèmes de feedback ont aussi besoin de maintenance

La première version de votre système de feedback ne sera pas la bonne. Les seuils seront erronés. Les alertes iront aux mauvaises personnes. Les rapports contiendront trop de bruit ou trop peu de signal.

C'est normal. L'important est de traiter le système de feedback lui-même comme quelque chose qui a besoin de feedback.

Chaque fois que votre équipe répond à une alerte, demandez : cette alerte est-elle arrivée au bon moment ? Était-elle utile ? Est-elle allée à la bonne personne ? Si la réponse est non, changez-la. Ajustez le seuil. Changez le destinataire. Simplifiez le format. Supprimez complètement l'alerte si elle ne mène jamais à une action.

Un bon système de feedback n'est pas conçu une fois et laissé tranquille. Il grandit à mesure que l'équipe apprend ce qui compte et ce qui ne compte pas.

Une courte liste de vérification pratique

Si vous voulez vérifier si votre système de feedback fonctionne réellement, parcourez ces questions :

• Qui reçoit la première alerte après un déploiement ? Est-ce l'équipe qui a déployé ?
• Les alertes urgentes sont-elles séparées des signaux lents et cumulatifs ?
• L'équipe a-t-elle un schéma de réponse clair lorsque le feedback arrive ?
• Existe-t-il un moyen pour les utilisateurs et le support de renvoyer du feedback dans le système ?
• Le système de feedback a-t-il été ajusté au cours du dernier mois en fonction de ce que l'équipe a appris ?

Si vous avez répondu non à l'une de ces questions, vous avez un point de départ pour vous améliorer.

Le véritable enseignement

Un tableau de bord sur lequel personne n'agit n'est pas du feedback. C'est de la décoration. Le feedback n'existe que lorsqu'il atteint quelqu'un qui peut prendre une décision, sous une forme qu'il peut utiliser, à un moment où cela compte encore. Construisez votre système de feedback autour de ce principe, et vos déploiements cesseront d'être une source d'anxiété pour devenir une source d'apprentissage.