31 janvier 2017, fin de soirée. Un ingénieur de GitLab essaie de relancer la réplication d'une base de données de production. Il supprime un répertoire de données qu'il croit être celui du serveur secondaire. C'est le primaire. Il interrompt la commande une seconde ou deux plus tard : environ 300 Go de données ont déjà disparu. L'équipe se tourne vers les sauvegardes et découvre qu'aucune ne fonctionne comme prévu (GitLab, 2017).
La lecture paresseuse tient en une phrase : « un ingénieur a fait une erreur ». C'est celle que font la plupart des organisations après un incident, un lancement raté ou un client perdu. Elle soulage, elle désigne, et elle ne change rien. Amy Edmondson raconte avoir vu pendant vingt ans des managers sincères consacrer de nombreuses heures à des retours d'expérience et des post-mortems qui ne produisaient aucun changement réel, parce qu'ils pensaient l'échec de la mauvaise façon (Harvard Business Review, 2011).
Pourquoi vos post-mortems ne changent rien : les trois pièges qui transforment l'analyse en procès, en usine à tickets ou en document mort.
Ce que font Google, Etsy et Atlassian, d'après leurs propres publications, et ce que révèle le cas GitLab lu jusqu'au bout.
Le livrable : un kit complet de revue post-incident sans coupable, utilisable tel quel : critères de déclenchement, préparation, canevas d'atelier de 75 minutes, banque de questions, modèle de document, grille de qualité des actions et baromètre de culture en six questions.
Un plan d'action à 7, 30 et 90 jours pour installer la pratique sans en faire une usine à gaz.
La suite est réservée aux membres de The Mavericks Club. Si vos équipes vivent des incidents, des livraisons ratées ou des projets qui déraillent, ce kit est fait pour vous.
