Les méthodologies Agile se propagent au-delà des frontières du développement traditionnel, dans tous les domaines d'activité, y compris le marketing ! Nous devons donc réfléchir à quoi ressemble l'agilité dans l'univers de la gestion des incidents ? Chez Atlassian, nous définissons Agile comme une approche structurée et itérative de la gestion de projet et du développement de produits. Agile permet à votre équipe de répondre au changement sans dévier de sa route.
C'est parce que les bugs au cours de la production, les incidents et les temps d'arrêt peuvent clairement être considérés comme des moments où « tout part de travers » que nous avons pensé qu'une méthodologie comme Agile (conçue pour aider les équipes à garder le cap) avait sa place dans la gestion des incidents, en particulier dans la communication associée.
Application des valeurs Agile à la réponse aux incidents
Alors que les outils ne manquent pas pour aider votre équipe à détecter, à signaler, à traiter et à résoudre les incidents, les outils seuls ne sauraient remplacer une communication claire avec les parties prenantes. Et soyons réalistes : les enjeux peuvent être élevés. Réputation, attrition de la clientèle, temps passé sur la limitation des dégâts, pour n'en citer que quelques-uns. Les méthodologies Agile peuvent aider à réduire au maximum l'importance de ces enjeux.
Bon nombre d'entre vous connaissent probablement déjà les quatre valeurs clés du Manifeste Agile : 1) Les individus et leurs interactions plutôt que les processus et les outils, 2) Un logiciel fonctionnel plutôt qu'une documentation complète, 3) La collaboration avec les clients plutôt que la négociation des contrats et 4) L'adaptation au changement plutôt que le suivi d'un plan. Voyons ces valeurs plus en détail et découvrons comment elles peuvent être exploitées pour obtenir une communication sur les incidents plus Agile.
Principe de communication sur les incidents : communication sur les incidents axée sur l'humain
Ce principe repose sur la valeur Agile les individus et leurs interactions plutôt que les processus et les outils. Les processus et les outils sont importants pour tout processus de gestion des incidents, mais ils sont inutiles pris séparément des personnes qui tentent de les utiliser et de la culture développée autour d'eux. Qu'est-ce qui fait le lien entre les personnes, les processus et les outils ? La communication, bien sûr !
La communication est essentielle lorsqu'un problème survient, que ce soit un petit bug en cours de production ou une panne généralisée du système. Même le plan de réponse aux incidents le plus exhaustif requiert une communication fréquente afin de trouver une solution et de maintenir la confiance.
Lors d'un incident, les utilisateurs affectés rencontrent certainement des erreurs frustrantes (voire handicapantes) et doivent savoir ce qui se passe au plus vite. Beaucoup vont très vite envoyer des e-mails, des tweets ou des tickets à propos du problème. Il est donc dans l'intérêt commun de prendre rapidement la situation en main en envoyant un message qui montre que vous êtes conscient du problème et que vous cherchez à le résoudre. Chez Atlassian, nous utilisons Statuspage pour communiquer avec les parties prenantes internes et externes au cours d'une panne. Il devrait vous être utile pour communiquer les informations sur un incident à vos utilisateurs de façon rapide et à grande échelle. En réalité, Statuspage a permis aux utilisateurs d'accélérer leur communication sur les incidents de 50 % (incroyable !).
Inscrivez-vous ou connectez-vous à Statuspage >>
Une fois connecté, découvrez-en plus sur les bonnes pratiques pour faciliter l'abonnement de vos utilisateurs finaux et communiquer efficacement durant un incident :
- Parcourez notre guide de mise en route pour découvrir les bases de la configuration et de la gestion de votre page d'état
- Lisez notre article sur les bonnes pratiques en matière de communication sur les incidents
- Découvrez comment configurer les notifications d'utilisateur final
Mais peu importe l'outil que vous utilisez pour donner à vos clients le 4-1-1, la communication axée sur l'humain est essentielle. Des personnes en chair et en os comptent sur vous pour les tenir informées lorsque quelque chose ne va pas. Si les modèles sont utiles dans un monde parfait, vous devrez pouvoir compter sur des personnes capables de rédiger des messages clairs, concis, empathiques et pertinents pour renforcer la confiance des clients dans les moments difficiles. Prenons Dyn, par exemple. L'entreprise a été victime d'une panne importante lors de ce qui devait être la plus grosse attaque par déni de service de l'histoire, mais les utilisateurs l'ont tout de même remerciée pour sa franchise lors de cette interruption de service :
Comme l'a déclaré Werner Vogels, Chief Technology Officer chez AWS, lors de la panne majeure qui a touché AWS S3 en février 2017 :
« Les clients n'apprécient pas les conseils les invitant à rester tranquilles et à ne rien faire. Cela ne répond pas à leurs attentes. Il faut plutôt leur fournir des informations pertinentes, les aider à comprendre ce qui se passe, et expliquer quand le service sera de nouveau disponible si vous disposez de telles informations. »
Principe de communication sur les incidents : Création d'une page et mises à jour aisées des incidents
Pour ce principe, nous analysons la valeur Agile, « Des logiciels opérationnels plus qu'une documentation exhaustive ». La documentation sur votre produit doit être claire et conviviale, tout comme les mises à jour sur les incidents ! Vos utilisateurs ne doivent pas avoir besoin de lire entre les lignes (ou de lire en diagonale des paragraphes interminables) pour savoir où est le problème et quand il sera potentiellement corrigé. Vous devez réfléchir sérieusement à vos mises à jour sur les incidents et garantir une communication empathique et humaine. Mais ne laissez pas les étapes d'approbation ou les multiples révisions vous empêcher de fournir des mises à jour fréquentes et honnêtes.
En analysant l'incident Dyn, vous pouvez voir que l'équipe n'a pas perdu de temps pour communiquer les mises à jour à ses utilisateurs. Dans les 11 heures qui ont suivi l'incident, elle a mis 11 fois à jour sa page d'état (soit 61 minutes en moyenne entre les mises à jour). Elle disposait d'un emplacement unique où communiquer sur l'incident, au lieu de passer des heures à trouver des listes de diffusion à envoyer par e-mail ou de se demander comment les mises à jour allaient pouvoir être communiquées en 140 caractères sur Twitter. En d'autres termes, elle a fait passer le message tout en tâchant de résoudre la panne.
Un outil de communication de l'état prêt à l'emploi est très utile : une page fiable est fonctionnelle en un rien de temps. Moins de 30 minutes sont nécessaires pour créer une page d'état, et comme Agile, votre page d'état peut et doit être itérative. Pensez à mettre en ligne une page de travail pour vos clients, puis améliorez-la au fur et à mesure. Après avoir rencontré quelques incidents avec une page d'état dans votre processus, vous pouvez l'améliorer au fur et à mesure.
Prêt à créer votre propre page d'état ? Inscrivez-vous ou connectez-vous à Statuspage >>
N'attendez pas le prochain incident pour créer une page d'état. Prenez quelques minutes maintenant, afin d'être prêt en cas de problème. N'oubliez pas, pas besoin de passer des heures sur la configuration d'une page pour qu'elle soit efficace :
- Découvrez comment personnaliser votre page d'état
- Trouvez l'inspiration dans d'excellents designs et personnalisations de pages d'état
Principe de communication sur les incidents : Communication transparente pendant et après les incidents
La valeur Agile La collaboration avec les clients plutôt que la négociation des contrats concerne le travail réalisé avec vos clients pour fournir le meilleur produit possible et une expérience optimale. Pour nous, cela implique de créer des canaux de feedback appropriés, de sorte que les clients puissent faire part de leurs préoccupations et vous alerter sur tout problème qu'ils rencontrent (à l'aide d'outils, comme Jira Service Management, Twitter, etc.). Les entreprises de classe mondiale comprennent que les clients attendent un retour sur leur feedback et souhaitent être impliqués dans les améliorations apportées à votre produit et à votre processus de réponse aux incidents. Un peu d'empathie et quelques explications peuvent produire d'excellents résultats (et les clients n'ont pas peur de les demander) comme le prouvent ces tweets :
Cela implique également de maintenir une politique de transparence sur votre disponibilité afin que les utilisateurs sachent exactement ce à quoi ils auront droit s'ils s'inscrivent. Lorsque vous souscrivez à un service cloud, vous vous attendez à bénéficier d'un service fiable. Il ne s'agit pas toujours d'un contrat physique, mais plutôt d'un contrat inhérent négocié entre le client et le fournisseur de services. Lorsque les choses tournent mal, les deux parties collaborent pour s'assurer que les problèmes sont rapidement résolus et que tout le monde reste informé. Ce qui nous amène à notre dernière valeur relative à la réponse au changement…
Principe de communication sur les incidents : Rétrospectives Agile
Même les plans les mieux élaborés… Vous connaissez la suite. Rappelant la valeur Agile, L'adaptation au changement plutôt que le suivi d'un plan, nous savons que même les plans les mieux conçus devront inévitablement changer pendant et après un incident. Agile consiste à être capable de s'adapter immédiatement à une nouvelle situation et d'obtenir un feedback rapide pour améliorer votre produit et votre culture.
En 2013, Wistia, une société d'hébergement de vidéos et d'analyses sur Internet, a appris à quel point il était important de rester agile lorsqu'un incident inattendu a paralysé son infrastructure de statistiques. Prise au dépourvu, l'entreprise s'est vue submergée de tickets de support de clients mécontents. Pour commencer, elle a créé sa propre page d'état afin de se simplifier la vie dans des situations similaires. Toutefois, après avoir créé son propre outil de communication sur l'état, elle a dû assurer le support d'un nouveau produit, en plus de son produit principal. Il est vite apparu que c'était un coût que cette équipe de 20 personnes (à l'époque) ne pouvait pas se permettre. L'entreprise a ensuite abandonné sa solution interne pour migrer vers Statuspage.
Jordan Munson, ingénieur de support chez Wistia a décrit la migration comme suit : « Après quelques mois de frustration avec notre solution interne (presque dépourvue de fonctionnalités, mais néanmoins utile), nous avons décidé que nous avions besoin de plus, d'une solution qui ne nécessiterait pas autant de support. Nous sommes passés à Statuspage. Depuis la migration, nous avons pu réaliser tout ce que nous souhaitions, tout en tenant rapidement et facilement nos clients au courant de l'état de l'application. Il aura seulement fallu une panne massive et la création d'un nouveau produit pour y arriver. Quelques années plus tard, notre processus semble beaucoup plus fluide. Les gens reçoivent des mises à jour directes en cas de panne, ils savent où rechercher des informations, et les mises à niveau apportées à notre page d'état sont directement envoyées à différents destinataires. »
L'équipe de Jordan Munson a vraiment pressé des citrons (la panne de 2013) pour en faire de la limonade (un nouveau processus de communication amélioré et évolutif). Voilà un parfait exemple de réponse Agile à un changement.
Les rétrospectives sont également un élément clé de cette valeur Agile. Une rétrospective permet à votre équipe de prendre du recul et de discuter de ce qui a bien fonctionné pendant la communication de votre incident, de ce qui a posé problème et, surtout, de ce que vous allez faire pour éviter que ces problèmes ne se reproduisent. Ne cédez pas à la tentation de sauter une rétrospective lorsqu'un incident est marqué comme « résolu » ou si vous pensez que votre équipe a bien réagi. Il est toujours possible de s'améliorer, et il existe toujours d'autres opportunités de renforcer la relation et la confiance avec vos utilisateurs.
Essayez ce scénario du Playbook des équipes Atlassian : il fournit un espace sûr à votre équipe pour réfléchir et discuter des choses qui fonctionnent (et qui ne fonctionnent pas !) afin de vous améliorer.
Revisitant notre premier Manifeste Agile, les rétrospectives nécessitent une communication axée sur l'humain pour aboutir et générer des résultats durables. Jetez un œil ci-dessous à quelques formulations à considérer lorsque vous faites une rétrospective sur la résolution d'un incident. Certains de ces termes devraient également être intégrés dans la revue post-mortem ou post-incident (PIR) que vous envoyez aux utilisateurs après le rétablissement de votre service. Être agile signifie améliorer continuellement non seulement la façon dont vous exécutez les tâches liées à l'incident, mais également celle dont vous contactez vos coéquipiers et exercez votre rôle dans une situation stressante.
Langage humain | Langage des produits |
|---|---|
| Hypothèses, espoirs et craintes | Tâches, tickets et actions |
| Motivations, mécompréhensions et comportements | Sprints, epics, stories et versions |
| Préférences, relations et respect | Étapes importantes, dépendances et dates |
| Rôle et responsabilités | Réunions, calendriers, e-mails et fichiers |
N'oubliez pas la confiance
Nous parlons beaucoup de confiance dans Agile, et ce cas d'usage ne fait pas exception. Une communication efficace sur les incidents requiert de la confiance et une certaine habilitation. Grâce aux connaissances dont elles disposent, les équipes au sein de l'organisation doivent se sentir maîtres pour communiquer sur les incidents avec les utilisateurs. Tout le monde doit pouvoir faire confiance aux autres, et croire que chacun s'acquittera des tâches qui lui ont été assignées lors d'une réponse à un incident et n'hésitera pas à intervenir et à accepter une interruption du processus en cas d'imprévu. Laisser le soin à votre équipe de communiquer efficacement sur les incidents permettra d'informer les clients plus rapidement et renforcera la confiance et la fidélité de l'utilisateur vis-à-vis de votre service (67 % des clients Statuspage disent que l'outil a permis de renforcer la confiance des utilisateurs !) C'est gagnant-gagnant.
