Typowe pułapki, których należy unikać

Plan, który omówiliśmy, ułatwiający rozpoczęcie procesu przeglądu po zdarzeniu jest przydatny, ale warto również wiedzieć o niektórych przeszkodach, które można napotkać podczas tej podróży.

W tej jednostce dowiesz się więcej o niektórych typowych pułapkach, w które inni wpadli podczas procesu przeglądu po incydencie i jak ich unikać.

Pułapka 1: Przypisanie do "błędu ludzkiego"

Można sobie przypomnieć, że "błąd pilota", konkretna forma bardziej ogólnej etykiety "błędu ludzkiego", była początkowym wnioskiem badaczy w historii B-17, którą rozpoczęliśmy we wprowadzeniu modułu. Wróćmy do tej historii.

We wstępie zasugerowaliśmy, że wyciągnięte wnioski mogą być dla ciebie niezadowalające. Zdecydowanie nie byli zadowoleni z Alphonse Chapanis, psycholog wojskowy, który został poproszony przez siły powietrzne ARMII USA (USAAF) o zbadanie tych incydentów. Zauważył między innymi, że wypadki te były wyjątkowe dla B-17 i niewielkiej liczby innych samolotów. W tym samym czasie w Europie Zachodniej były tysiące samolotów transportowych C-47, jednak żaden C-47 nigdy nie doświadczył podobnego incydentu.

Więc przeprowadził wywiady z pilotami i w oparciu o to, co usłyszał od nich, poszedł i spojrzał na kokpity B-17. To, co widział, były dwa przełączniki: przełącznik biegów i przełącznik klapy. Przełączniki były około 3 cali od siebie w kokpicie. Ich tryb działania był identyczny. Były one zbyt łatwe do pomylenia, i to właśnie się wydarzyło w tych incydentach. Jeśli właśnie wylądowałeś samolotem, klapy będą wysunięte, a zanim zaparkujesz, schowasz je. I tak Chapanis próbował coś innego.

Przykleił małe gumowe kółko do przełącznika biegów, a twardą, kanciastą "klapkę" do przełącznika klap i wypadki rzeczywiście przestały się zdarzać.

Jest teraz znany jako jeden z założycieli dziedziny anatomii (badanie czynników projektowych w wydajności człowieka) i miał prostą obserwację: projekt kokpitu może mieć wpływ na prawdopodobieństwo błędu ludzkiego. To podejście wpłynęło na projekt nowoczesnych samolotów. Na przykład w Stanach Zjednoczonych, przepisy dotyczące samolotów transportowych wymagają, aby sterowanie podwoziem było w kształcie koła i różniło się od sterowania klapą.

Dlaczego więc opowiedzieliśmy ci tę historię?

Ludzie popełniają błędy. Jednak błąd ludzki nie jest przyczyną; jest to objaw. Gdy błąd ludzki jest uznawany za przyczynę awarii, ludzie zatrzymują się tam zamiast dalszej analizy incydentu.

Projekt systemu, kontekst organizacyjny i kontekst osobisty mają wpływ na to, kiedy, jak i z jakim wpływem ludzie popełniają błędy. "Błąd ludzki" to etykieta, która powoduje, że kończysz badanie dokładnie w tej chwili, kiedy chcesz odkryć coś interesującego w systemie.

Problem z wnioskiem o "błąd ludzki" w badaniach polega na tym, że prowadzi to do zapomnienia, iż to, co zrobili ludzie, miało sens w danym momencie. Błędy, z definicji, nie są celowe, więc nie zamierzały popełnić błędu.

Gdy widzimy lub słyszymy "błąd ludzki", jest to sygnał, że musimy przyjrzeć się głębiej. Jeśli chcemy się nauczyć, nie możemy przestać badać, kiedy znajdziemy błąd ludzki, tak jak to często robimy. Jak pokazuje historia B-17s, tuż poza błędem ludzkim jest to, gdzie uczymy się ciekawych rzeczy na temat naszego systemu.

Pułapka 2: Rozumowanie kontrfaktyczne

Counterfactual oznacza "sprzeczne z faktami", a rozumowanie kontrfaktyczne odnosi się do opowiadania historii o wydarzeniach, które nie miały miejsca w celu wyjaśnienia wydarzeń, które były. Nie ma to większego sensu, mimo że ludzie mają tendencję do robienia tego przez cały czas.

Zdania kontrfaktyczne można zidentyfikować według kluczowych fraz.

• Mógł mieć
• Powinno być
• Miałby
• Nie można
• Nie
• Tylko jeśli

Niektóre przykłady przeciwnych do faktów stwierdzeń związane z przeglądami po zdarzeniu:

"System monitorowania nie wykrył problemu".

"Inżynier nie sprawdził ważności konfiguracji przed jego wprowadzeniem".

"To mogło zostać wykryte w środowisku kanarkowym."

Problem z tego typu rozumowaniem w przeglądzie po zdarzeniu polega na tym, że mówisz o rzeczach, które się nie wydarzyły, zamiast poświęcić czas na zrozumienie, jak doszło do tego, co się wydarzyło. Nie uczysz się niczego od tych spekulacji.

Pułapka 3: Język normatywny

Język normatywny często oznacza, że istniał "oczywiście poprawny" kurs działania, który operatorzy powinni podjąć, a ocenia działania tych podmiotów z perspektywy czasu.

Język normatywny może być zwykle identyfikowany przez przysłówki, takie jak "niewłaściwie", "nieostrożnie", "pospiesznie" i tak dalej.

Normatywne myślenie prowadzi do oceniania decyzji w oparciu o ich wyniki. Ten sposób mówienia nie jest logiczny, ponieważ wynik jest jedynym elementem informacji, które nie były dostępne dla tych, którzy podjęli decyzje i wyroki.

Język normatywny może być również używany w odwrotnym sensie. Ludzie mogą chwalić operatorów za to, że działały "odpowiednio", na przykład. Ale ponownie, często ten osąd jest dokonywany mając do dyspozycji informacje, których nie mieli ludzie, których dotyczy.

Problem z językiem normatywnym jest podobny do problemu z rozumowaniem kontrfaktycznym: jeśli dokonujemy osądów po fakcie, korzystając z informacji, które były niedostępne dla ludzi zaangażowanych podczas incydentu, zaniedbujemy zrozumienie, jak działania operatorów miały dla nich sens w tamtym czasie.

Pułapka 4: Rozumowanie mechanistyczne

Rozumowanie mechanistyczne odnosi się do koncepcji, że z interwencji można wywnioskować określony wynik. Czasami nazywa się to zespołem wtrącających się dzieci (ukutym przez Jessica DeVita) w oparciu o założenie, że "Nasz system zadziałałby dobrze... gdyby nie dla tych wtrącających się dzieci."

Jeśli używasz rozumowania mechanistycznego w przeglądzie po incydencie, opierasz swoje wnioski na fałszywym założeniu, że systemy działają zasadniczo poprawnie, a gdyby nie te „wtrącające się dzieciaki", do awarii by nie doszło.

Nie jest to jednak sposób działania systemów.

Aby zilustrować ten punkt, wyobraź sobie następujący scenariusz: Pracujesz nad usługą produkcyjną. Teraz powiedziano Ci, że nie możesz dotykać ani nic robić w tej usłudze. Wszystko poza zespołem jest kontynuowane tak jak wcześniej: klienci nadal korzystają z usługi, zależności zewnętrzne nadal się zmieniają, a Internet działa normalnie.

Nie można jednak wprowadzać żadnych zmian w kodzie ani konfiguracji. Brak wdrożeń, brak operacji w warstwie kontrolnej, nic.

Czy uważasz, że twoja usługa będzie nadal działać zgodnie z oczekiwaniami po dniu? Po tygodniu? Po miesiącu? Po roku? Jak długo można realistycznie oczekiwać, że usługa będzie działać bez interwencji człowieka? W większości przypadków nie.

To ćwiczenie myślowe prowadzi nas do ważnego wniosku:

Zdolność adaptacyjna człowieka jest niezbędna do utrzymania działania naszych systemów.

Jedynym powodem, dla którego systemy w ogóle pozostają działające, jest to, że ludzie są zaangażowani w proces kontrolny. Tylko dzięki działaniom człowieka i jego zdolności do dostosowywania się do zmieniających się okoliczności system może nadal działać.

Dlatego błędne jest stwierdzenie, że system "w zasadzie działa... gdyby nie te wtrącające się dzieciaki." W rzeczywistości niezawodność usługi nie jest niezależna od ludzi, którzy nad nią pracują. Zamiast tego jest to bezpośredni wynik pracy, którą robią ludzie każdego dnia.

Problem z rozumowaniem mechanistycznym polega na tym, że prowadzi Cię ku przekonaniu, że znalezienie człowieka, który popełnił błąd, jest równoważne rozwiązaniu problemu. Jednak ten sam wadliwy człowiek improwizował i dostosowywał się, aby system działał przez tygodnie i miesiące. Być może ta rola jest wystarczająco ważna, aby uwzględnić ją w przeglądzie po incydencie.

Teraz, gdy już wiesz, czego można uniknąć podczas przeglądu po zdarzeniu, możemy przejść do następnej lekcji, w której zapoznamy się z niektórymi przydatnymi rozwiązaniami dotyczącymi tych przeglądów.