Kiedy analiza przyczyn źródłowych ma sens
Pewnego ranka miałem przebitą oponę w samochodzie. Na szczęście mogłem szybko wymienić koło. Lubię jednak przenosić rzeczy, których nauczyłem się w pracy, na swoje codzienne życie. Postanowiłem więc przeprowadzić analizę przyczyn źródłowych (root cause analysis). Miałem nadzieję, że pozwoli mi to unikać przebitych opon w przyszłości. W końcu czas poświęcony na wymianę opony mogłem lepiej wykorzystać.
Metoda „Pięć Dlaczego" w analizie przyczyn źródłowych
Metoda „Pięciu Dlaczego" dobrze nadaje się do tego rodzaju analizy przyczyn. Wystarczy pięć razy z rzędu zapytać „Dlaczego?" – moje dzieci szczególnie dobrze radziły sobie z tym w wieku około czterech lat! Poszukiwanie przyczyny zaczęło się zatem:
Dlaczego miałem przebitą oponę?
– Bo gwóźdź tkwił w oponie.
Dlaczego gwóźdź tkwił w oponie?
– Bo najwyraźniej przejechałem po nim poprzedniego dnia.
Dlaczego przejechałem poprzedniego dnia po gwoździu?
– Bo parking mojego klubu fitness (jedyne miejsce, do którego tego dnia pojechałem) był właśnie remontowany.
Dlaczego parking był remontowany?
– Z powodu licznych dziur.
Dlaczego na parkingu były dziury?
– Z powodu deszczu.
Przyczyną mojej przebitej opony był więc deszcz. A zatem nie może już padać.
Niestety to nie leży w mojej mocy. Normalnie mógłbym przekazać coś takiego mojemu Scrum Masterowi, ale nawet Scrum Master nie jest w stanie zmienić pogody.
Wnioski z analizy przyczyn źródłowych
Co chcę przez to powiedzieć? Czasem po prostu nie warto przeprowadzać analizy przyczyn źródłowych. Jak każda inna metoda czy technika, nie zawsze ma ona sens. Wiele rzeczy w tworzeniu oprogramowania jest zupełnie nowych, tzn. są wykonywane po raz pierwszy (przynajmniej przez daną osobę lub zespół). Analiza przyczyn źródłowych jest najbardziej sensowna w przypadku sytuacji powtarzających się – np. w produkcji. Jest mniej przydatna w przypadku rzeczy nowatorskich i złożonych, takich jak te pojawiające się przy tworzeniu oprogramowania (czy rozwoju produktu w ogóle).
Nie mówię, że powinieneś całkowicie rezygnować z analizy przyczyn źródłowych i metody Pięciu Dlaczego. Pamiętaj tylko, że nie ma metody, którą można stosować zawsze i wszędzie.
Ten tekst pochodzi z bloga Mike'a Cohna i został przez nas przetłumaczony na język polski.
Zostań certyfikowanym Scrum Masterem!
Dla Scrum Masterów oferujemy następujące szkolenia i bezpłatne możliwości doskonalenia:
