Skip to content

Kręta droga do odpowiedzialności na podstawie Responsibility Process

Ile razy w sytuacji kryzysowej mówiłeś lub słyszałeś „to na pewno ich wina”, “nic nie mogliśmy zrobić, to tak działa” lub “ale to zawaliliśmy”? Bardzo często, zanim zaczniemy szukać rozwiązania, wykazując odpowiedzialność, usprawiedliwiamy swoje działania, obwiniamy za porażkę innych, siebie lub system. Fazy te opisał Christopher Avery w Responsibility Process.

Czym jest Responsibility Process?

W największym skrócie Responsibility Process opisuje, w jaki sposób mentalnie przechodzimy do unikania lub brania za coś odpowiedzialności. Często, zanim podejmiemy konkretne działania, skupiamy naszą uwagę za zupełnie innych rzeczach. Dotyczy to zarówno poważniejszych, jak i całkiem błahych sytuacji.

Wyobraź sobie, że właśnie wychodzisz z domu i szukasz kluczy. Jeśli nie znajdziesz ich w miejscu, gdzie zazwyczaj są, mogą się pojawić różne myśli. Może ktoś je przełożył? A może jesteś takim bałaganiarzem, że ciężko cokolwiek znaleźć? Nie, to na pewno wina tego, że nie masz w wieszaka na klucze. Aby dotrzeć do momentu, w którym zaczniesz odkładać je zawsze w jednym miejscu i problem zniknie, może minąć trochę czasu.

Przechodzenie przez poszczególne fazy procesu odpowiedzialności dotyczy praktycznie każdego. W niespodziewanej sytuacji nasz umysł bardzo aktywnie ją analizuje, chcąc jak najszybciej, a więc i najmniejszym nakładem sił, znaleźć rozwiązanie. To powoduje, że droga do wzięcia odpowiedzialności może być kręta lub możemy w ogóle nie dotrzeć do celu.

Responsibility Process

Poszczególne fazy w procesie mogą trwać dłużej lub krócej. Zależy to od samego problemu, naszego nastawienia i umiejętności radzenia sobie w sytuacjach kryzysowych. Jest to proces mentalny, w którym zmienia się nasze postrzeganie sytuacji.

No to mamy Problem…

Wspomniane wcześniej zgubione klucze od mieszkania mogą stanowić sytuację kryzysową, jednak przeanalizujmy Responsibility Process na innym, równie popularnym przykładzie. Wyobraź sobie, że pracujesz w jednym z kilku zespołów, które wspólnie tworzą pewną Aplikację. Mamy więc trzy zespoły scrumowe w różnych krajach, które tworzą oprogramowanie, dodatkowe osoby odpowiedzialne za wypuszczenie aplikacji, management i innych. 

Jest środa, prawie koniec całkiem spokojnego dnia. Nagle widzisz, jak w powiadomieniach pojawia się tytuł nowego maila “[Pilne] Problemy z wydajnością na produkcji!”. Po szybkim przeczytaniu wiadomości okazuje się, że po wypuszczeniu dzisiejszych zmian część funkcjonalności aplikacji nie działa poprawnie.

A może nic się nie stało?

Zaprzeczenie (ang. Denial), nie występuje zawsze. Może być jednak całkiem łakomym kąskiem w przypadku kryzysowej sytuacji, która wystąpiła. Problemy ze stabilnością? Pewnie to tylko tymczasowe, albo ktoś coś źle sprawdził. A może to wina połączenia zgłaszających i tak na prawdę Aplikacja działa jak powinna? Nie ma sobie co tym zaprzątać głowy.

Zaprzeczenie eliminuje problem i powoduje, że nie musisz podejmować żadnych działań. Oszczędzasz czas i nerwy, więc dlaczego z tego nie skorzystać? Uwalniasz swój umysł od problemu w najprostszy możliwy spsób.

Biorąc pod uwagę, że nie podejmujesz w tym momencie żadnej akcji, krok ten jest fazą wstępną i według opisywanego modelu nie stanowi rozpoczęcia procesu brania odpowiedzialności.

To na pewno ich wina!

Bardzo często pierwszym działaniem, jakie podejmujemy na drodze do wzięcia odpowiedzialności jest Zrzucanie Winy (ang. Lay Blame). Skoro Aplikacja nie działa poprawnie, to pewnie zepsuł coś zespół odpowiedzialny za jej wypuszczenie. Czy przeczytali, że w wyniku ostatnich zmian trzeba przeindeksować dane? Albo pewnie drugi zespół deweloperów wprowadził jakiś problem. Zresztą to by był nie pierwszy raz, miesiąc temu wprowadzili niezłą regresję. Ale nie ma się co dziwić, w końcu nie mają takich umiejętności jak my. A może to wina managera? Ciągle tylko pytał “kiedy to będzie na produkcji?”, więc trzeba było trochę przyspieszyć z programowaniem. W takich warunkach wiadomo, można się pomylić.

Ile razy byłeś świadkiem takich rozmów w zespole po wykryciu poważnego problemu? Problem ze zrzuceniem winy polega na tym, że oczekujemy działania od kogoś innego. Może to potrwać kilka minut, godzin, lub znacznie dłużej, ale przynajmniej nic nie musisz robić. W końcu to nie twoja wina.

W trakcie tego etapu po prostu narzekasz i się frustrujesz, ale właściwy problem pozostaje poza kręgiem twojego zainteresowania.

To wszystko wina systemu!

Kolejnym krokiem w procesie jest Usprawiedliwianie (ang. Justify). Jest on bardzo podobne do Zrzucania Winy, jednak nie odnosi się do ludzi, lecz okoliczności lub systemu. W zależności od konkretnej sytuacji może dotyczyć istniejących procesów, narzędzi, managementu, a także rządu lub pogody.

Aplikacja działa niepoprawnie? No wiadomo, pewnie coś poszło nie tak w trakcie wypuszczania na produkcję. Nasz proces jest tak skomplikowany, że prawdopodobieństwo błędu jest ogromne, nie ma się co dziwić. Zresztą narzędzia, których używamy, też są do wymiany. Jak w ten sposób pracować?

W tym kroku oczekujemy, że zmiana nastąpi nie w naszym postępowaniu, lecz gdzieś na zewnątrz. Z tego względu nadal nie zbliżamy się do rozwiązania problemu.

Ale to zawaliliśmy…

Opuszczając mentalny stan usprawiedliwienia, wkraczamy we Wstyd (ang. Shame). Jest to pierwszy etap skoncentrowany na nas, w odróżnieniu od dwóch poprzednich, skupiających się na naszym otoczeniu.

Zauważamy więc, że sami jesteśmy sobie winni, gdyż nie pilnowaliśmy odpowiednio wszystkiego. Pewnie ta ryzykowna poprawka, na którą się zespołowo zdecydowaliśmy, jednak spowodowała więcej problemów. Pamiętasz, jak wspólnie analizowaliśmy te wszystkie zależności i jaki mogą mieć wpływ na Aplikację. Pewnie na coś nie zwróciliśmy uwagi. 

W dodatku code review, które robiłeś, powinno być dokładniejsze. To już nie pierwszy raz, jak przepuściłeś potencjalny błąd.

Wstyd nadal nie prowadzi do rozwiązania problemu. Jest jednak krokiem w dobrym kierunku, uwaga skupia się na nas samych, a nie na otoczeniu.

Powinniśmy zrobić to w inny sposób

W końcu docieramy do czegoś pozytywnego, zaczynamy szukać rozwiązań. Zobowiązanie (ang. Obligation) generuje pomysły na konkretne akcje, ale jeszcze nie powoduje zmiany. Często zdarza się, że czujemy się zobligowani do jakiegoś działania, ale nie chcemy się go podjąć. Czujemy się jak w pułapce, ale ciężko znaleźć wyjście z sytuacji. Mówimy o tym, co trzeba zrobić, ale nie czujemy się na siłach, aby tego dokonać.

Żeby ustrzec się problemów z błędami w Aplikacji, powinniśmy robić dokładniejsze code review. Może zapraszać do niego członków drugiego zespołu, jeśli wprowadzamy zmiany w miejscu, które lepiej znają? Przed jej wypuszczeniem trzeba zacząć puszczać dodatkowe testy, a wcześniej odpowiednio je przygotować. Tylko jak to wszystko zrobić?

To i tak nic nie da, dajmy sobie spokój

W przypadku Wstydu i Zobowiązania istnieje bardzo kusząca możliwość odrzucenia odpowiedzialności. Jest nią Rezygnacja (ang. Quit), czyli porzucenie faktycznych akcji mających na celu poprawę sytuacji. Możemy co najwyżej doraźnie rozwiązać sytuację, ale unikamy systemowego rozwiązania. Dzięki temu mentalnie uwalniamy się od nieprzyjemnego problemu, parkując go gdzieś w naszym umyśle.

Aplikacja nie działa poprawnie, ale tym razem udało się znaleźć błąd. Wypuściliśmy poprawkę i problem będzie rozwiązany. Co innego możemy jeszcze zrobić? W końcu to była specyficzna sytuacja, pewnie już więcej nie wystąpi. Zresztą i tak trudno by było to rozwiązać całkowicie, to w ogóle możliwe?

Czas na zmianę

Na końcu drogi czeka na ciebie prawdziwa Odpowiedzialność (ang. Responsibility). W tym momencie poczujesz, że to ty masz przewagę nad problemem i możesz go pokonać. To nie mówienie o tym, co trzeba zrobić, ale podejmowanie konkretnych działań. Rozumiesz, że możesz tego dokonać, a sukces zależy to tylko i wyłącznie od ciebie.

W przypadku problemu z Aplikacją to faktyczne działania, mające na celu uniknięcie ich w przyszłości. Stosowanie odpowiednich testów przed wypuszczeniem kolejnej wersji, wprowadzenie dodatkowych zasad podczas code review lub statycznej analizy kodu. Krok po kroku wprowadzamy więc usprawnienia, współpracujemy w tym celu z innymi, dokonujemy pozytywnej zmiany.

Jak znajomość Responsibility Process może ci pomóc?

Dzięki temu, że rozumiesz poszczególne fazy Responsibility Process, być może łatwiej będzie ci przez nie przejść, gdy natrafisz na problem. Identyfikując krok, na którym się zatrzymałeś, będzie ci prościej ruszyć w stronę odpowiedzialności. Bez niepotrzebnego marnowania czasu na obwinianie innych, systemu lub siebie.

Bardzo ważne jest to, że musisz ten proces zrozumieć i zastosować samodzielnie. Łatwiej jest zwracać uwagę na błędy innych i dawać im rady, jak powinni postępować. Bez samoświadomości swoich działań będzie ciężko wziąć za coś odpowiedzialność.

Opublikowano wAgile

Dodaj komentarz

avatar
  Subskrybuj  
Powiadom o