Czyli jak oduczyć zespół mówienia o ryzyku
„Nie przynoś mi problemów, przynoś rozwiązania”.
To zdanie brzmi jak całkiem rozsądna zasada zarządzania. Ma zachęcać do samodzielności, a przełożonego chronić przed rozstrzyganiem każdej drobnej sprawy. Kłopot zaczyna się wtedy, gdy pracownik widzi, że coś może pójść źle, ale jeszcze nie wie, jak temu zapobiec. Czy powinien przyjść od razu, czy poczekać, aż przygotuje rozwiązanie wystarczająco dobre, żeby móc zapukać do drzwi?
Wyobraźmy sobie zespół przygotowujący wdrożenie systemu. Do uruchomienia zostały trzy tygodnie. Podczas spotkania analityk zwraca uwagę, że migrację sprawdzono na niewielkiej próbce danych. Wyniki są poprawne, ale część starszych rekordów ma inną strukturę. Przy pełnej migracji mogą pojawić się błędy.
Kierownik pyta, czy mamy potwierdzenie, że te błędy wystąpią.
Nie mamy. Właśnie dlatego analityk porusza temat teraz.
Przyjdź, kiedy będziesz miał pewność
Rozmowa może potoczyć się różnie. Ktoś poprosi o sprawdzenie większej próbki. Ktoś zaproponuje konsultację z osobą, która utrzymywała poprzedni system. Ale może też paść zdanie: „Nie straszmy się na trzy tygodnie przed wdrożeniem. Wróćmy do tego, jeśli testy pokażą problem. Zrobimy hotfix na produkcji”.
Analityk otrzymał właśnie wskazówkę na przyszłość. Z obawami lepiej poczekać.
W zarządzaniu ryzykiem trudno o bardziej niefortunny odruch. Rozmawiamy przecież o czymś niepewnym. Gdybyśmy za każdym razem wymagali dowodu, że niepożądane zdarzenie na pewno wystąpi, znaczną część takich rozmów prowadzilibyśmy już podczas usuwania jego skutków.
Oczywiście nie każda obawa uzasadnia wstrzymanie wdrożenia. Zespół nie może zmieniać planów po każdym „a co, jeśli”. Potrzebuje jednak możliwości spokojnego sprawdzenia, czy za wątpliwością stoi coś konkretnego.
W naszym przykładzie sensowne pytania dotyczą tego, które dane różnią się od testowanych, jak duża może być ta grupa i czego jeszcze musimy się dowiedzieć. Być może wystarczy kilka godzin pracy. Być może sprawdzenie wykaże, że obecny mechanizm radzi sobie również ze starszymi rekordami. To też jest wartościowy wynik.
W M_o_R służy temu między innymi pryncypium wspierającej kultury. Jego praktyczny sens widać właśnie w takich sytuacjach: czy człowiek może powiedzieć „nie wiem, ale widzę powód do sprawdzenia”, zanim będzie dysponował pełnym wyjaśnieniem.
Bohater od pożarów ma łatwiej
Załóżmy, że dodatkowego sprawdzenia nie wykonano. Podczas uruchomienia część danych zostaje odrzucona. Dwie osoby pracują przez weekend, poprawiają mechanizm migracji i przywracają działanie systemu. W poniedziałek słusznie dostają podziękowania.
Tydzień później organizacja pamięta już przede wszystkim, kto uratował wdrożenie.
Teraz wyobraźmy sobie drugi wariant. Wątpliwość analityka potraktowano poważnie. Test ujawnił błąd, poprawka zajęła jeden dzień, a wdrożenie przebiegło spokojnie. Nie było nocnych telefonów, nadzwyczajnych spotkań ani opowieści o walce do ostatniej chwili. Trudniej z tego zrobić efektowną historię sukcesu.
Zapobieganie ma tę niedogodność, że jego najlepszy rezultat często wygląda jak zwykły dzień pracy.
Nie da się uczciwie twierdzić, że każde działanie prewencyjne uratowało projekt przed katastrofą. Można jednak dostrzegać konkretną pracę: zakwestionowanie założenia, sprawdzenie pominiętego przypadku, znalezienie błędu odpowiednio wcześnie. Jeśli uznanie otrzymują wyłącznie osoby radzące sobie z awariami, wysyłamy zespołowi dość osobliwy komunikat o tym, jaka praca jest naprawdę ceniona.
Warto więc czasem zapytać na podsumowaniu etapu, dzięki czemu udało się uniknąć komplikacji. Może się okazać, że za spokojnym przebiegiem projektu stoi ktoś, kto kilka tygodni wcześniej był uznawany za przesadnie ostrożnego.
Siła facylitacji – Czy wszyscy się wypowiedzieli?
Wróćmy do spotkania przed wdrożeniem. Kierownik pyta, czy ktoś widzi jeszcze jakieś zagrożenia. Zapada cisza. Po chwili przechodzimy do kolejnego punktu.
Taką ciszę łatwo uznać za zgodę. Tymczasem jej znaczenie zależy od tego, co działo się na poprzednich spotkaniach. Jeżeli zgłaszający wątpliwości musiał później długo tłumaczyć się ze swojego „negatywnego nastawienia”, pozostali mogli wyciągnąć wnioski. Zwłaszcza gdy termin wdrożenia został już publicznie przedstawiony jako pewny.
Angażowanie interesariuszy, kolejne pryncypium M_o_R, wymaga czegoś więcej niż wysłania zaproszenia na spotkanie. Trzeba jeszcze stworzyć warunki, w których ich wiedza będzie mogła wpłynąć na ocenę sytuacji.
Analityk zna strukturę danych. Administrator wie, ile trwa odtworzenie środowiska. Pracownik obsługi potrafi wskazać wyjątki, które rzadko pojawiają się w dokumentacji, ale regularnie trafiają do niego w piątkowe popołudnie. Każda z tych osób widzi inny fragment przedsięwzięcia.
Zamiast ogólnego „czy są uwagi?” można zapytać: „Którego przypadku jeszcze nie sprawdziliśmy?” albo „Co w tym planie zakłada warunki, których nie potrafimy potwierdzić?”. Takie pytania ułatwiają rozpoczęcie rzeczowej rozmowy. Pomaga również zebranie opinii, zanim najważniejsza osoba na sali przedstawi własną ocenę.
Samo pytanie jednak nie wystarczy. Jeśli po odpowiedzi usłyszymy westchnienie i komentarz, że znowu komplikujemy prostą sprawę, następnym razem możemy dostać mniej informacji.
Co robimy z człowiekiem, który ostrzegał?
Po nieudanym wdrożeniu zwykle przychodzi czas na analizę. Ktoś przypomina, że temat starszych danych pojawił się trzy tygodnie wcześniej. Łatwo wtedy rozpocząć poszukiwanie winnego albo urządzić konkurs na to, kto od początku miał rację.
Dla kolejnego projektu bardziej przydatne będzie odtworzenie przebiegu wydarzeń. Co wtedy wiedzieliśmy? Dlaczego uznaliśmy próbkę za wystarczającą? Czy ktoś miał sprawdzić zgłoszoną wątpliwość? Czy zabrakło czasu, dostępu do danych, czy po prostu temat nie doczekał się dalszego ciągu?
Na tym polega praktyczny wymiar ciągłego doskonalenia. Z analizy powinno wynikać, co zmienimy przy następnym wdrożeniu. W tym przypadku może to być sposób doboru danych testowych albo obowiązek sprawdzenia różnic między kolejnymi wersjami starego systemu.
Otwartość na zgłaszanie obaw idzie przy tym w parze z odpowiedzialnością. Można oczekiwać, że pracownik rzetelnie opisze to, co zauważył, a osoba zobowiązana do sprawdzenia tematu rzeczywiście się nim zajmie. Trzeba natomiast uważać, żeby nie oceniać wcześniejszych decyzji wyłącznie przez pryzmat wiedzy zdobytej po awarii.
Podobnej uwagi wymagają sytuacje, w których ostrzeżenie się nie potwierdziło. Jeśli każdą taką osobę będziemy później przedstawiać jako kogoś, kto niepotrzebnie narobił zamieszania, szybko ograniczymy liczbę zgłoszeń. Wątpliwości zostaną przy biurkach, a na spotkaniach będzie przyjemniej. Przynajmniej do wdrożenia.
Dlatego do zdania „przynoś mi rozwiązania” warto dopowiedzieć: „A jeśli jeszcze ich nie masz, przyjdź i powiedz, co cię niepokoi”.
Zespół powinien usłyszeć to przed pierwszym pożarem.