#98 Blameless Postmortem (Analiza po zakończeniu projektu bez obwiniania)

1. Nazwa metody

Blameless Postmortem (Analiza po zdarzeniu bez obwiniania)

2. Nazwy alternatywne

Analiza zdarzenia, analiza po zdarzeniu

3. Krótki opis

Jest to specyficzny rodzaj spotkania poświęconego wyciąganiu wniosków, które odbywa się po nieoczekiwanej awarii lub incydencie (np. awarii systemu). Kluczową zasadą jest to, że analiza koncentruje się na identyfikacji przyczyn awarii związanych z systemem i procesami, a nie na poszukiwaniu osoby odpowiedzialnej. Opiera się ona na przekonaniu, że ludzie popełniają błędy, ale przyczyną są wadliwe systemy, a nie zła wola.

4. Cel / Kiedy stosować

Stosuje się to przede wszystkim w firmach z branży IT i technologicznej (popularność tej metody zawdzięcza się Google SRE) po każdym poważnym incydencie. Celem jest maksymalizacja wyciągania wniosków, zapobieganie powtórzeniu się tych samych awarii oraz budowanie kultury bezpieczeństwa psychicznego.

5. Sposób postępowania / Jak ją stosować

1. Zorganizuj spotkanie jak najszybciej po zdarzeniu, póki wspomnienia są jeszcze świeże.
2. Zacznij od „Prime Directive” (podobnie jak podczas retrospektywy), aby stworzyć bezpieczną atmosferę.
3. Stwórz oś czasu wydarzeń: szczegółowo i opierając się na faktach, odtwórz przebieg zdarzeń, kto co zrobił i jakie były tego skutki. Skoncentruj się na „co”, a nie na „kto”.
4. Przeanalizuj przyczyny: Wykorzystaj techniki takie jak „5 Why”, aby odkryć przyczyny systemowe (np. brak monitoringu, niejasna procedura, dług techniczny).
5. Określ działania naprawcze: Opracuj konkretne, mierzalne działania naprawcze mające na celu usprawnienie systemu (np. „Dodaj alert dotyczący wykorzystania procesora”, „Ulepsz dokumentację dotyczącą sytuacji kryzysowych”). Przypisz osoby odpowiedzialne i terminy.
6. Udostępnij raport: Wynikowy raport z analizy po zdarzeniu jest publicznie udostępniany w całej organizacji, aby inni również mogli wyciągnąć z niego wnioski.

6. Przykład z praktyki

Po awarii sklepu internetowego zespół spotyka się na spotkaniu „Blameless Postmortem”. Okazuje się, że awarię spowodował błędny kod wdrożony przez nowego współpracownika. Zamiast obwiniać nowicjusza, zadają pytanie: „Dlaczego nasz system dopuścił, by błędny kod trafił do środowiska produkcyjnego?”. Identyfikują przyczyny: niewystarczające testy automatyczne oraz brak procesu weryfikacji kodu dla juniorów. Działania mają na celu usprawnienie tych procesów.

7. Zalety

- Buduje kulturę bezpieczeństwa psychicznego i zaufania.
- Sprzyja szczerości i szybszemu rozwiązywaniu problemów (ludzie nie boją się przyznać do błędu).
- Prowadzi do powstania solidniejszych i bardziej odpornych systemów.
- Maksymalizuje możliwość uczenia się na błędach.

8. Ryzyko / Limity

- Wymaga to całkowitego zaangażowania kierownictwa w realizację zasady „blameless”. Jakikolwiek ślad poszukiwania winnego zniszczy zaufanie.
– Może być nadużywana jako usprawiedliwienie zaniedbań, jeśli nie zostanie właściwie zrozumiana. Nie chodzi tu o brak odpowiedzialności, ale o skupienie się na odpowiedzialności systemowej.

9. Wskazówki z praktyki

- W razie konieczności należy oddzielić dochodzenie w sprawie incydentu od rozstrzygania kwestii kadrowych.
- Zautomatyzuj tworzenie osi czasu na podstawie logów i narzędzi komunikacyjnych.
- Skoncentruj się na „czynnikach przyczyniających się”, a nie na jednej „przyczynie źródłowej”, ponieważ złożone awarie rzadko mają tylko jedną przyczynę.