Wszystkie szablony

Analiza głównej przyczyny metodą 5 Whys

364wyśw.
2użycia
1polubienia

Zgłoś

Analiza głównej przyczyny metodą 5 Whys

Streszczenie

Analiza głównej przyczyny metodą 5 Whys to ustrukturyzowana metoda rozwiązywania problemów, w której zaczynasz od sformułowania problemu i zadajesz pytanie "Dlaczego?" pięć razy z rzędu. Każda odpowiedź staje się podstawą kolejnego pytania. Celem jest przejście poza objawy i ujawnienie leżącej u podstaw awarii procesu lub systemu, którą można faktycznie naprawić.

Kto może z niej korzystać

  • Zespoły produktowe i inżynieryjne

  • Zespoły operacyjne i DevOps

  • Zespoły wsparcia i obsługi klienta

  • Kierownicy projektów

  • Zespoły zapewniania jakości

  • Osoby badające powtarzające się problemy lub incydenty

Jak tego używać

  1. Napisz jasny opis problemu — co się wydarzyło, kiedy i jaki był wpływ.

  2. Zadaj pytanie „Dlaczego to się stało?” i zapisz odpowiedź (Odpowiedź 1).

  3. Zadaj pytanie „Dlaczego wystąpiła Odpowiedź 1?” i zapisz odpowiedź (Odpowiedź 2).

  4. Powtórz dla Odpowiedzi 3, 4 i 5.

  5. Przerwij, gdy dojdziesz do przyczyny, którą możesz usunąć przez zmianę procesu lub systemu — to jest Twoja Przyczyna źródłowa.

  6. Określ działania naprawcze: przypisz każdemu działaniu właściciela i termin wykonania.

  7. Wskazówka: dobra przyczyna źródłowa wskazuje na proces lub system, a nie na osobę. Jeśli Twoja odpowiedź to czyjeś imię, zapytaj „dlaczego?” jeszcze raz.

Przykład

Opis problemu: Strona realizacji zamówienia była niedostępna przez 3 godziny 12 sierpnia — ok. $18,000 w utraconych zamówieniach i ponad 40 zgłoszeń do wsparcia. (Zbadane 13 sierpnia przez zespół platformy.)

  • Why 1: Serwer płatności wyczerpał pamięć i uległ awarii.

  • Why 2: Usługa płatności ma wyciek pamięci.

  • Why 3: Wydanie z 8 sierpnia nie zamyka starych połączeń z bazą danych.

  • Why 4: Wydanie nigdy nie było testowane obciążeniowo przed uruchomieniem.

  • Why 5: Lista kontrolna wydania nie zawiera kroku testów wydajnościowych.

  • Root Cause: Proces wydania nie zawiera obowiązkowego kroku testów obciążeniowych/wydajnościowych.

  • Corrective Actions:

    • Dodaj zautomatyzowany test obciążeniowy do potoku CI (DevOps lead, 30 sierpnia)

    • Skonfiguruj alerty pamięci przy 80% użycia (SRE team, 22 sierpnia)

    • Zaktualizuj listę kontrolną wydania i przeszkól zespół (Eng manager, 20 sierpnia)

Pozdrawiam!

Khawaja Rizwan

Rizwan Khawaja

ICT Solution Architect @ NUST

I hold master's degrees in computer science and project management along with trainings and certifications in various technologies. All this is coupled with 25+ years of industry experience.


Kategorie

Podobne szablony