Szablon analizy „5 × dlaczego”

Celem analizy „5 × dlaczego” jest ustalenie głównej przyczyny problemu poprzez usunięcie powierzchownych trudności, które w rzeczywistości są jego objawami, a nie właściwą przyczyną. Wielokrotnie zadając pytanie „dlaczego?” i analizując odpowiedzi, możesz odkryć głębsze i często pomijane przyczyny problemu. 

Celem jest dojście do momentu, w którym dalsze pytania nie przynoszą już przydatnych odpowiedzi i wskazano główną przyczynę. Po określeniu głównej przyczyny możesz rozpocząć pracę nad wdrożeniem praktycznych rozwiązań problemu i środków zapobiegających jego ponownemu wystąpieniu.

Przykład użycia szablonu analizy „5 × dlaczego”

Oto przykład zastosowania szablonu analizy „5 × dlaczego” do problemu:

Zdefiniowanie problemu: Aplikacja często ulega awarii, gdy korzysta z niej wielu użytkowników, czego efektem są gorsze wrażenia z użytkowania.

1. Dlaczego oprogramowanie ulega awarii, gdy korzysta z niego wielu użytkowników?

• Odpowiedź: Serwer jest przeciążony równoczesnymi żądaniami użytkowników.

2. Dlaczego serwer jest przeciążony równoczesnymi żądaniami użytkowników?

• Odpowiedź: Konieczne jest odpowiednie skalowanie przepustowości serwera, aby obsłużyć intensywny ruch.

3. Dlaczego przepustowość serwera nie jest odpowiednio skalowana do obsługi intensywnego ruchu?

• Odpowiedź: Zespół nie prowadził monitorowania prewencyjnego i testowania obciążenia podczas tworzenia aplikacji. 

4. Dlaczego podczas tworzenia aplikacji nie prowadzono monitorowania prewencyjnego i testowania obciążenia?

• Odpowiedź: Zespół programistyczny nie miał narzędzi i wiedzy specjalistycznej niezbędnych do testowania obciążenia.

5. Dlaczego zespół programistyczny nie miał narzędzi i wiedzy specjalistycznej niezbędnych do testowania obciążenia?

• Odpowiedź: Początkowo zakres projektu nie obejmował testowania obciążenia, a zespół nie miał dostępu do odpowiednich zasobów potrzebnych do testowania obciążenia. 

Główna przyczyna: Awarie oprogramowania w czasie korzystania z niego przez wielu użytkowników są spowodowane brakiem testów obciążenia w początkowym zakresie projektu oraz brakiem dostępu do niezbędnych zasobów i wiedzy specjalistycznej w zakresie testowania obciążenia.

Rozwiązanie: Aby zapobiec przyszłym awariom w czasie korzystania z oprogramowania przez wielu użytkowników, zespół powinien wprowadzić testy obciążenia jako standardowy element procesu tworzenia oprogramowania oraz zapewnić dostęp do wymaganych zasobów i wiedzy specjalistycznej potrzebnych do testowania obciążenia. Pozwoli to rozpoznawać i rozwiązywać problemy z zakresu wydajności na początku cyklu tworzenia oprogramowania, zapewniając lepsze wrażenia użytkowników po jego wdrożeniu.

W tym przykładzie analiza „5 × dlaczego” wykazała, że główną przyczyną częstych awarii oprogramowania podczas obciążenia przez ruch dużej liczby użytkowników był brak testów obciążenia w początkowym zakresie projektu oraz brak zasobów do przeprowadzenia testów obciążenia podczas tworzenia oprogramowania. 

Rozwiązanie skupia się bezpośrednio na problemie, co pozwala stworzyć efekt domina, który eliminuje objawy i ostatecznie także problem zdefiniowany na początku. 

Wprowadzenie testów obciążeniowych jako standardowego elementu procesu tworzenia oprogramowania i zapewnienie dostępności wymaganych zasobów i wiedzy specjalistycznej pozwoli zapobiec przyszłym awariom. Pomoże także zespołowi poprawić wrażenia użytkownika.