czwartek, 19 lutego 2009

Przyczyna źródłowa

Pisząc o koncepcji Jidoka napisałem tak “[pracownik ma obowiązek] znaleźć przyczynę takowego niepożądanego stanu rzeczy, wyeliminować ją i dopiero potem [podjąć z powrotem pracę]”. Po zastanowieniu dochodzę do wniosku, że to jest świetny materiał na rozważania o tym, co powinno być elementem sesji retrospekcji i co leży w obowiązku kierownika projektu, zwłaszcza realizowanego metodami agile. Chodzi o to znajdowanie i eliminowanie przyczyn źródłowych problemów.

Jak się popatrzy na obecne środowisko pracy w wielu organizacjach to jedyną reakcją na problemy stosowaną przez wyższe kierownictwo jest coraz większy nacisk na to, aby problemów nie było. Jeżeli projekt przekracza deadline’y to kierownictwo wyznacza większe bonusy za dotrzymanie deadline’ów. Jeżeli jest za dużo błędów to grozi się obcięciem pensji za ponowne wypuszczenie błędnej wersji oprogramowania. Problem w tym, że takie podejście tak naprawdę konserwuje to, co jest. Bo zakłada, że wszystko robiliśmy dobrze, tylko się nie staraliśmy wystarczająco dobrze. Więc jeżeli następnym razem się postaramy bardziej to będzie dużo lepiej. Hmm, bardzo odważne założenie. W rzeczywistości będzie zapewne tak, że jak teraz przy tych metodach które mamy trochę nam nie wyszło to jak je zastosujemy jeszcze bardziej dokładnie to jeszcze bardziej nam nie wyjdzie.

Tak naprawdę rzadko kto podejmuje się zadania proponowanego przez Japończyków (choć nie tylko ich) czyli znalezienia przyczyny źródłowej takiego a nie innego stanu rzeczy. Wysiłek ten podejmowany jest rzadko, bo nie jest to zadanie proste. Przyczyna źródłowa oznacza zadawanie pytania “dlaczego” tak długo aż dojdziemy do odpowiedzi, której już dalej nie da się podzielić. Co więcej bardzo często znajdowanie przyczyny źródłowej polega na odkrywaniu i kwestionowaniu podstawowych założeń, na których oparta jest nasza organizacja i jej sposób działania.

Jeżeli popatrzyć na metodyki agile to najodpowiedniejszym miejscem do znajdowania przyczyn źródłowych problemów wydaje się być retrospekcja. Wówczas poza zastanowieniem się co się stało warto by też zastanowić się nad przyczynami źródłowymi problemów. Ponieważ nie jest to łatwe ani proste nie można się zastanawiać nad wieloma przyczynami źródłowymi jednocześnie. Raczej spośród wielu problemów nękających projekt należałoby wybrać jeden, który najbardziej boli i skupić się na jego rozwiązaniu. Czyli najpierw znaleźć jego przyczynę źródłową a dopiero potem wdrożyć rozwiązanie.

Aha i tutaj jedna uwaga. Przyczyny źródłowe problemów w projektach mają to do siebie, że często są tzw. przyczynami systemowymi. Czyli wynikają wprost z tego jak skonstruowany jest system, w tym wypadku system zarządzania w danej organizacji. Jeżeli przyczyna jest przyczyną systemową to aby permanentnie ją wyeliminować należy zmienić system. A to niestety często jest poza zasięgiem kompetencyjnym osób pracujących w projektach. Jedyne logiczne rozwiązanie w takiej sytuacji to rzeczony przypadek udokumentować oraz przedstawić odpowiednio wysokim menedżerom w firmie. A następnie mieć nadzieję, że zależy im na tym, aby ich system zarządzania działał sprawnie.

Dwa narzędzia, które mogą pomóc w znajdywaniu przyczyn źródłowych to na przykład A3 Problem Solving Method (bazująca na rozwiązaniach Toyoty) oraz Current Reality Tree (bazująca na narzędziach myślowych teorii ograniczeń).

Brak komentarzy: