Pourquoi des thèmes ?

Nous pensons que l'analyse post-incident doit aller au-delà de l'analyse des causes profondes. Nous encourageons l'analyse thématique des incidents afin d'obtenir une meilleure compréhension de votre travail, autrement dit une analyse thématique.

Mais qu’entendons-nous par thèmes ? Les thèmes sont les conclusions tirées d’un incident et l’analyse qui en a résulté. En se concentrant sur les conclusions, au lieu de se concentrer uniquement sur la « seule et véritable cause fondamentale » ou de passer directement aux mesures à prendre, les enquêteurs peuvent extraire des connaissances de l’investissement qu’a représenté l’incident. Se concentrer sur ces autres éléments peut conduire à une faux sentiment de sécurité ou d'accomplissement , laissant encore beaucoup à apprendre sur la table.

Par exemple, sans analyse thématique, nous pouvons penser que nous avons appris tout ce qu’il y avait à apprendre d’un incident parce que nous avons décidé de corriger un bug et de dire aux gens de ne plus interrompre la production. Mais avec l’analyse thématique, nous pouvons examiner les conditions qui ont permis aux individus d’interrompre la production en premier lieu, ou la façon dont les ingénieurs comprennent l’impact des changements apportés. Ce type de connaissances et de compréhension « peut mieux équiper les ingénieurs pour gérer les surprises futures » en plus de minimiser le mode de défaillance spécifique observé dans l’incident.

Comment les repérer

Dans le Guide Howie nous encourageons les gens à « penser à vos thèmes comme aux sujets d’intérêt qui ont fait surface tout au long de l’enquête : qu’est-ce qui vous a surpris, que pensez-vous que les autres devraient savoir davantage, ce qui est partagé entre d’autres incidents. »

Il est difficile de donner une définition exacte de ce à quoi ressemble un thème. Franchement, les trouver nécessite souvent un « flair » ou un « sens de l’araignée ». C’est pourquoi nous pensons que la narration est si importante dans l’analyse des incidents. Nous aimons entendre les personnes impliquées dans l’incident raconter l’histoire de leur point de vue, laisser les personnes impliquées se poser des questions, puis poser les nôtres. Les choses que les gens ont trouvées fascinantes ou qui méritent d’être résumées peuvent être des « thèmes ». Les choses dont les gens parleront lors de la fête de fin d’année ou des mois plus tard lorsqu’ils discuteront du travail avec un nouveau coéquipier. Ce sont tous des points importants à retenir et des thèmes potentiels de l’enquête.

Jeli est conçu pour ce type d'analyse d'incidents basée sur la narration. Notre fonction de chronologie vous permet de voir exactement ce qui s'est passé et à quel moment au cours de l'incident, ce qui constitue un excellent point de départ pour que les gens partagent ce qu'ils ont vécu à ce moment-là. Lorsque vous vous préparez à un examen d'incident, vous pouvez parcourir la transcription Slack de ce qui s'est passé, commencer à faire émerger un récit et noter des questions. Ensuite, examinez les questions que vous avez et commencez à les organiser en fonction de ce qu'elles ont en commun :

• Y avait-il un élément technologique que nous n'avons pas compris lors de l'incident (ou dont je ne suis pas sûr en tant qu'enquêteur) ?
• Les gens n’étaient-ils pas certains de l’impact ? Les gens des différentes parties de l’organisation ont-ils compris l’impact différemment ?
• Les intervenants étaient-ils confus quant aux signaux qui leur étaient présentés ?
• Y avait-il une incohérence dans la manière dont l’incident a été communiqué ?
• Quelqu'un a-t-il fait quelque chose de vraiment cool lors du dépannage ?

Dans l'exemple ci-dessus, nous ne mentionnons même pas les technologies impactées. Cela ne signifie pas que nous n'en tirons aucun enseignement. Nous pouvons discuter des facteurs contributifs et des facteurs atténuants lors de la réunion d'évaluation et dans le rapport d'incident. Les gens en apprendront davantage sur leurs systèmes et appliqueront leurs connaissances à leur travail. Mais nous devons également discuter des thèmes particuliers qui ont conduit à l'incident de la manière dont il s'est produit. Cela conduit à une compréhension plus riche de l'incident, ce qui à son tour renforcera la résilience future.

Qu'est-ce qui n'est pas un thème ?

Bien qu'il n'existe pas de définition spécifique des thèmes d'incident, il existe un certain nombre d'écueils à éviter lorsque vous découvrez des thèmes dans votre incident.

• Éléments d'action. Si un problème peut être résolu par une demande d'extraction, il ne s'agit pas d'un problème à emporter. Cela ne signifie pas que nous ne traitons pas les bugs lors d'un examen d'incident, mais que nous ne nous arrêtons pas là.
• Blâmer ou dénoncer. Peut-être avez-vous appris lors de votre réunion d’évaluation qu’une personne ou une équipe a « déclenché » l’incident. Bien qu’il soit facile de dire « un tel ne sait pas faire son travail », il n’est avantageux pour personne d’arrêter l’enquête à ce stade et cela peut amener les gens à perdre confiance dans le processus post-incident. Nous voulons plutôt comprendre comment les événements ont conduit cette personne ou cette équipe à déclencher l’incident. Ont-ils hérité d’une nouvelle technologie qu’ils ne comprennent pas complètement ? Y a-t-il des lacunes dans le processus d’intégration ? La rotation des astreintes ne tient-elle pas compte des silos de connaissances ?
• Tout ce qui est trop vague. Bien que le thème d'un incident puisse s'appliquer à d'autres incidents, technologies et même à d'autres organisations, ils devraient toujours nous permettre d'apprendre quelque chose ! Il y a une différence entre « les incidents se produisent pendant le gel du code » et « l'urgence de l'ingénierie à publier rapidement avant la période de gel du code peut conduire à précipiter les choses sans les contrôles et équilibres habituels/appropriés, ce qui conduit à une augmentation des incidents ».

Que faire avec ces thèmes ?

Maintenant que vous avez une meilleure idée de ce que nous entendons par thèmes et comment les repérer, vous devriez répartir la richesse.

Les partager!

Comme pour tout autre apprentissage lié à un incident, il ne suffit pas de les avoir identifiés. Votre travail portera ses fruits lorsque vous le partagerez avec d'autres. J'aime inclure des enseignements thématiques dans tous mes résultats d'incident. Lorsque je rédige un résumé, je l'inclus généralement à côté de l'impact de l'incident et des éléments d'action. Si vous rédigez un rapport d'incident, assurez-vous d'avoir une section pour les enseignements à retenir. Parlez-en dans les mises à jour hebdomadaires, les rétrospectives de sprint et l'intégration !

Repérez-les dans d’autres incidents

Il semble que l'analyse des incidents croisés soit dans tous les esprits de nos jours. Au lieu de discuter du temps moyen de résolution des incidents du trimestre dernier, commencez à examiner les points communs entre les incidents. Combien d'incidents sont liés à une mauvaise compréhension des dépendances ? Quels impacts d'incidents n'avons-nous pas compris en raison d'un manque de données ? Nous expliquerons plus en détail l'analyse des incidents croisés dans un prochain article de blog, mais une analyse individuelle des incidents de qualité est une condition nécessaire pour les apprentissages croisés.

Commencer!

L’analyse thématique est une nouvelle compétence, différente de l’analyse traditionnelle des causes profondes ou de la réalisation d’analyses axées sur les mesures à prendre. La meilleure façon de devenir bon dans ce domaine est de le faire. Ce n’est peut-être pas facile ou parfait au début (la perfection n’est certainement pas nécessaire pour apporter de la valeur), mais l’analyse des incidents est un muscle : plus vous l’utilisez, plus elle sera forte ! Alors, pour votre prochaine analyse, passez un peu de temps (peut-être 30 minutes) à revoir le récit, notez les questions et essayez de trouver deux ou trois thèmes à discuter en groupe.

Bonne analyse !