„Dlaczego znowu to samo?” – Sztuka docierania do sedna problemów z techniką „5 Why?”

Znasz to uczucie, kiedy patrzysz na coś po raz kolejny i myślisz: „Dlaczego znowu to samo?”. Może to być błąd w oprogramowaniu, który powraca mimo naprawy, spóźniający się projekt, który miał być już dawno zamknięty, a może po prostu bałagan na biurku, który magicznie pojawia się ponownie kilka godzin po generalnym sprzątaniu. W Agile i w życiu, te powtarzające się „dlaczego” są jak denerwująca piosenka, która utknęła w głowie – i dopóki nie zrozumiesz, co naprawdę ją wywołało, będzie Ci brzęczeć bez końca.

Jako Agile Coach, widziałem zespoły, które tonęły w morzu powierzchownych poprawek, skupiając się na symptomach problemów, a nie na ich przyczynach. To jak leczenie gorączki bez diagnozowania infekcji – na chwilę ulży, ale problem wraca ze zdwojoną siłą. Pamiętam zespół developerski, który walczył z uporczywym błędem w module płatności. Przez tydzień dzień i noc poprawiali kod, testowali, wdrażali, a błąd… wracał jak bumerang. Frustracja sięgała zenitu, atmosfera gęstniała, a nikt nie rozumiał, dlaczego te poprawki są tak nieskuteczne.

W końcu, podczas retrospektywy, jeden z developerów, z desperacją w głosie, rzucił: „Może powinniśmy przestać gasić pożary i w końcu dowiedzieć się, dlaczego ten błąd w ogóle się pojawia?”. I to było kluczowe zdanie. Wtedy przypomniałem im o prostej, ale potężnej technice – „5 Why?”.

Czym jest to „5 Why?” i dlaczego miałoby nas interesować?

Wyobraź sobie, że jesteś detektywem. Nie śledzisz podejrzanych w ciemnych uliczkach, ale tropisz przyczyny problemów w swoim zespole, projekcie, procesie. „5 Why?” to Twoje detektywistyczne narzędzie – prosta technika, która pomaga dotrzeć do przyczyny źródłowej problemu poprzez zadawanie pytania „dlaczego?” – i to nie raz, ale idealnie… pięć razy.

Nie, to nie jest jakaś magiczna liczba. Pięć to po prostu dobra średnia, która pozwala zanurzyć się głębiej niż tylko na powierzchni problemu. Czasem wystarczą trzy pytania, a czasem trzeba ich zadać siedem, osiem, żeby naprawdę zrozumieć sedno. Kluczem jest ciągłe drążenie tematu, aż do momentu, kiedy „dlaczego?” zaczyna prowadzić do fundamentalnych przyczyn, a nie tylko do kolejnych symptomów.

Wróćmy do naszego zespołu z modułem płatności. Zaczęliśmy od problemu, który zdefiniowali jako: „Błąd w module płatności powoduje, że użytkownicy nie mogą dokończyć transakcji.”

Zadaliśmy pierwsze „Dlaczego?”: „Dlaczego użytkownicy nie mogą dokończyć transakcji?” Odpowiedź: „Ponieważ system generuje nieprawidłowy komunikat błędu.”

Drugie „Dlaczego?”: „Dlaczego system generuje nieprawidłowy komunikat błędu?” Odpowiedź: „Ponieważ moduł weryfikacji danych przesyła nieprawidłowe dane do modułu płatności.”

Trzecie „Dlaczego?”: „Dlaczego moduł weryfikacji danych przesyła nieprawidłowe dane?” Odpowiedź: „Ponieważ algorytm weryfikacji danych zawiera błąd logiczny.”

Czwarte „Dlaczego?”: „Dlaczego algorytm weryfikacji danych zawiera błąd logiczny?” Odpowiedź: „Ponieważ developer, który implementował algorytm, nie do końca zrozumiał specyfikację.”

Piąte „Dlaczego?”: „Dlaczego developer nie do końca zrozumiał specyfikację?” Odpowiedź: „Ponieważ specyfikacja była niejasna i niekompletna, a developer nie poprosił o jej doprecyzowanie.”

Bingo! Dotarliśmy do sedna. Problemem nie był błąd w kodzie per se, ale niejasna specyfikacja i brak komunikacji. Naprawa błędu w kodzie była tylko powierzchownym rozwiązaniem. Prawdziwym rozwiązaniem było ulepszenie procesu tworzenia specyfikacji i zachęcenie developerów do aktywnej komunikacji i dopytywania w przypadku wątpliwości.

Widzisz? „5 Why?” to nie tylko zadawanie pytań dla samego zadawania. To proces myślowy, który zmusza do głębszego zastanowienia się nad problemem. To jak obieranie cebuli – warstwa po warstwie, aż do samego środka. I często okazuje się, że prawdziwa przyczyna problemu kryje się znacznie głębiej niż początkowo myśleliśmy.

Jak skutecznie stosować „5 Why?” w praktyce?

To proste narzędzie, ale jak każde narzędzie, wymaga wprawy i świadomego podejścia. Oto kilka wskazówek, które pomogą Ci skutecznie stosować „5 Why?” w Twoim zespole:

• Zacznij od konkretnego problemu: „5 Why?” najlepiej sprawdza się, gdy masz jasno zdefiniowany problem. Unikaj ogólników typu „Nasz projekt idzie źle.” Skonkretyzuj: „Nie dowieźliśmy funkcjonalności X na czas.”
• Zbierz zespół: „5 Why?” to praca zespołowa. Zaangażuj osoby, które są bezpośrednio związane z problemem. Różne perspektywy pomogą szybciej dotrzeć do sedna. Pamiętaj o atmosferze bezpieczeństwa i otwartości – nikt nie powinien bać się wyrażać swoich opinii i zadawać pytań.
• Zadawaj „Dlaczego?” w sposób otwarty i dociekliwy: Unikaj pytań oskarżycielskich. Celem nie jest znalezienie winnego, ale znalezienie przyczyny. Ton pytania powinien być neutralny i nastawiony na zrozumienie. „Dlaczego tak się stało?” brzmi lepiej niż „Kto jest za to odpowiedzialny?”.
• Notuj odpowiedzi: Zapisuj odpowiedzi na każde „Dlaczego?”. To pomaga utrzymać strukturę i śledzić tok myślenia. Możesz użyć flipcharta, tablicy, czy nawet zwykłego dokumentu tekstowego. Ważne, żeby mieć wizualny zapis całego procesu.
• Nie zatrzymuj się na pierwszej lepszej odpowiedzi: Często pierwsza odpowiedź na „Dlaczego?” jest tylko powierzchowna. Drąż dalej! Pytaj „Dlaczego?” do skutku, aż poczujesz, że dotarłeś do fundamentalnej przyczyny, na którą masz realny wpływ.
• Szukaj przyczyn systemowych, a nie tylko ludzkich błędów: Często łatwo jest obwinić pojedynczą osobę za problem. Ale „5 Why?” ma na celu odkrycie systemowych problemów. Może to być niejasny proces, brak odpowiednich narzędzi, nieefektywna komunikacja, czy braki w szkoleniu. Naprawiając system, eliminujesz przyczynę problemu na przyszłość, a nie tylko karzesz winnego.
• Sprawdź poprawność przyczyn źródłowych: Kiedy już dotrzesz do „przyczyny źródłowej”, upewnij się, że jest ona rzeczywiście przyczyną problemu. Zadaj sobie pytanie: „Czy gdybyśmy usunęli tę przyczynę, problem by zniknął?”. Jeśli odpowiedź brzmi „tak”, to prawdopodobnie jesteś na dobrej drodze.

Pamiętam historię z innego zespołu, który miał problem z niską jakością kodu. Po serii „5 Why?” okazało się, że przyczyną nie byli leniwi developerzy, jak początkowo sądzono, ale … brak automatycznych testów. Zespół pracował w pośpiechu, skupiając się na dostarczaniu funkcjonalności na czas, zaniedbując testowanie. Wprowadzenie automatycznych testów nie tylko poprawiło jakość kodu, ale też przyspieszyło proces developmentu w dłuższej perspektywie. „5 Why?” pomogło im zrozumieć, że rozwiązaniem nie jest „przyspieszenie pracy developerów”, ale usprawnienie procesu.

„5 Why?” w Agile – narzędzie retrospektyw i nie tylko.

W Agile „5 Why?” jest nieocenione podczas retrospektyw. Pomaga zespołom analizować niepowodzenia i sukcesy sprintu, wyciągać wnioski i planować usprawnienia na przyszłość. Ale „5 Why?” można stosować nie tylko na retrospektywach. Jest przydatne w każdej sytuacji, kiedy chcemy zrozumieć przyczynę problemu – podczas rozwiązywania incydentów, analizy ryzyka, planowania usprawnień procesów, a nawet w codziennej pracy zespołowej.

Pomyśl o „5 Why?” jako o narzędziu do ciągłego doskonalenia. To nie jest jednorazowe rozwiązanie, ale nawyk myślowy, który warto wyrobić w sobie i w swoim zespole. Im częściej będziesz pytać „Dlaczego?”, tym lepiej będziesz rozumieć mechanizmy działania Twojego zespołu, projektu, procesu. I tym skuteczniej będziesz rozwiązywać problemy u ich źródła, zamiast tylko maskować symptomy.

Więc następnym razem, kiedy znów zobaczysz ten „powracający bałagan na biurku” lub inny uporczywy problem – nie denerwuj się. Weź głęboki oddech, zbierz zespół i … zacznij pytać „Dlaczego?”. Może się okazać, że odpowiedź jest bliżej, niż myślisz, ukryta tylko pod powierzchowną warstwą symptomów. A „5 Why?” pomoże Ci ją odkryć. I zmienić „Dlaczego znowu to samo?” na „Aha! Teraz rozumiem!”.