Proces, który wymaga bohatera, jest źle zaprojektowany

Wdrożenie znów się udało, bo jedna osoba pamiętała o dodatkowym kroku, którego nie ma w instrukcji. Przy poprzednim uratowała konfigurację, przy kolejnym pewnie też odbierze telefon. Zespół jest wdzięczny, manager chwali zaangażowanie, klient nie widzi problemu. Wynik się zgadza, więc trudno znaleźć czas na poprawienie sposobu pracy.

Taki wynik wygląda dobrze, dopóki koszt interwencji pozostaje poza oceną procesu. Wdrożenie się odbyło, klient pracuje, więc można zamknąć temat. Tyle że następne znów będzie wymagało tej samej pamięci i dostępności. Jeśli uznamy ratunek za dowód sprawności całego rozwiązania, firma nie dostanie powodu, żeby cokolwiek poprawić. Dodatkowy wysiłek człowieka zasłonił brak, który nadal istnieje.

Jednorazowa interwencja eksperta jest normalna. Złożone systemy potrafią zaskoczyć, a doświadczenie ma wtedy ogromną wartość. Problem pojawia się, gdy ten sam rodzaj interwencji staje się stałym warunkiem wykonania rutynowej pracy. Wówczas ratowanie sytuacji zaczyna zastępować usunięcie przyczyny.

Udany wynik może ukrywać słaby proces

Demingowi przypisano w notatkach z seminarium w Phoenix w 1993 roku zdanie: „A bad system will beat a good person every time”. Instytut Deminga przytacza je właśnie z tego źródła. Odczytuję je jako ostrzeżenie przed oczekiwaniem, że kompetencja i wysiłek człowieka bez końca zrekompensują wady organizacji. (The W. Edwards Deming Institute)

Jeśli przy każdej zmianie ktoś musi pamiętać o nieopisanym wyjątku, polecenie „uważajcie bardziej” niewiele daje. Najpierw trzeba ustalić, dlaczego wyjątek istnieje i jak można go wykryć. Przy jednej konfiguracji wystarczy kontrola przed wdrożeniem, przy innej trzeba ograniczyć liczbę wariantów. Automatyzacja też wymaga namysłu. Skrypt, którego nikt poza autorem nie potrafi uruchomić i sprawdzić, może jedynie przenieść zależność w inne miejsce.

Po incydencie trzeba odtworzyć informacje dostępne wykonawcy i zabezpieczenia, które miały zadziałać. Świadome pominięcie znanej kontroli wymaga rozmowy o decyzji człowieka. Brak kontroli wymaga pracy nad sposobem wdrażania. Czasem występują oba problemy. Wskazanie autora błędu nie wyjaśnia jeszcze, dlaczego organizacja dopuściła, żeby ten błąd dotarł do klienta i był trudny do wycofania.

Podobnie trzeba przyjrzeć się nagrodom. Jeżeli publiczne uznanie dostaje wyłącznie osoba, która pracowała w nocy, a przygotowanie bezpiecznej procedury pozostaje niewidoczne, zapobieganie awariom przegrywa w ocenie osiągnięć. Nie znaczy to, że ktoś zacznie celowo wywoływać incydenty. Wystarczy, że przy wyborze pracy łatwiej uzasadnić bieżącą interwencję niż koszt usunięcia jej przyczyny. Manager powinien pokazać wartość także tej pracy, dzięki której nikogo nie trzeba później budzić.

Przy przejmowaniu zespołu pytałbym więc o przebieg ostatnich wdrożeń, nie tylko o ich wynik. Ile razy potrzebna była nieplanowana pomoc? Które zadania czekały na konkretną osobę? Co trzeba było zrobić poza zwykłymi godzinami? Zielony status nie pokaże tego sam.

Sprawdź, czy ktoś inny potrafi wykonać pracę

Dobry pierwszy krok to bezpieczna próba zastępstwa. Druga osoba przeprowadza typowe zadanie w środowisku testowym albo w uzgodnionym oknie, a ekspert obserwuje. Każde zatrzymanie pokazuje konkretny brak: dostęp, niejasny krok, niezapisane kryterium decyzji. Nie trzeba zaczynać od projektu dokumentacyjnego obejmującego cały system.

Następnie poprawiamy najistotniejsze braki i ponawiamy próbę. Chodzi o samodzielne wykonanie oraz rozpoznanie sytuacji, w której trzeba przerwać. Instrukcja opisująca wyłącznie udany przebieg może dawać fałszywe poczucie bezpieczeństwa. Zastępca powinien wiedzieć również, jak sprawdzić wynik i kiedy nie kontynuować pracy.

W kodzie podobny sprawdzian może dotyczyć niewielkiej zmiany w module. Czy inna osoba rozumie jego granice, potrafi uruchomić testy i wie, jakie zachowanie trzeba zachować? Miejsca wymagające prywatnego objaśnienia pokazują, co utrudnia przejęcie odpowiedzialności. Nie każdą trudność należy usuwać, ale warto wiedzieć, która wynika ze złożoności problemu, a która z zaniedbania.

Wiedza skupiona u jednego eksperta wymaga czasu na przekazanie. Manager powinien uwzględnić go w planie i ograniczyć inne zobowiązania. Jeśli przy każdej pilnej sprawie przerywa tę pracę, sam utrwala zależność, którą deklaruje jako ryzyko. Ekspert nie rozwiąże tego samą lepszą organizacją dnia.

Nie potrzebujemy zastępstwa na identycznym poziomie we wszystkim. Najpierw warto zabezpieczyć rutynę i działania, których przerwanie ma największe konsekwencje. Rzadki, złożony przypadek może nadal wymagać specjalisty. Istotne, żeby nie angażować go bez przerwy do rzeczy, które można bezpiecznie wykonać według znanych zasad.

Zabezpieczenie również ma koszt. Nowa kontrola może spowalniać każdą zmianę, a automatyzację trzeba utrzymywać. Dlatego po poprawce sprawdzamy, czy druga osoba potrafi wykonać zadanie oraz rozpoznać błąd, zanim szkoda urośnie. Mniejsza liczba telefonów do eksperta jest dobrym sygnałem, dopóki nie wynika z tego, że ludzie przestali zgłaszać problemy. Wynik trzeba obejrzeć razem z przebiegiem pracy.

Po kolejnym uratowanym wdrożeniu chcę więc zobaczyć zadanie dotyczące przyczyny, właściciela i zarezerwowany czas. Jeśli firma świadomie uzna, że poprawka się nie opłaca, powinna uwzględnić koszt dalszych interwencji i zastępstwa. Najgorszy wariant to korzystać z dostępności jednej osoby jak z bezpłatnego zabezpieczenia, a później zarzucać jej brak zaangażowania, gdy w końcu nie odbierze telefonu.