Częste pułapki, których należy unikać
Do tej pory omówiliśmy poszczególne kroki przeglądu po zdarzeniu, które pomogą Ci rozpocząć ten proces. Warto również znać przynajmniej niektóre z przeszkód, które możesz napotkać podczas wykonywania go.
W tej lekcji dowiesz się więcej o niektórych typowych pułapkach, które inne wpadły podczas procesu przeglądu po zdarzeniu i jak ich uniknąć.
Pułapka 1: Przypisanie do "błędu ludzkiego"
Może pamiętasz, że osoby wstępnie badające wypadki samolotów B-17, o których wspominaliśmy w module wprowadzającym, przypisały całą sprawę „błędowi pilota” (czyli „błędowi ludzkiemu”). Wróćmy do tej historii.
W tym intro zasugerowaliśmy, że wnioski osiągnięte mogą być niezadowolenie z ciebie. Z pewnością nie satysfakcjonował Alphonse’a Chapanisa, wojskowego psychologa, który badał te wypadki na prośbę sił powietrznych USA. Chapanis zauważył między innymi, że wypadki przydarzały się tylko modelowi B-17 i niewielkiej liczbie innych samolotów. W Europie Zachodniej używano wtedy tysięcy samolotów transportowych C-47, ale żaden z nich nie brał nigdy udziału w podobnym wypadku.
Więc przeprowadził wywiady z pilotami i w oparciu o to, co usłyszał od nich, poszedł i spojrzał na kokpity B-17. W kokpicie zobaczył dwa przełączniki: jeden sterujący podwoziem, a drugi klapami. Były od siebie oddalone o niecałe 10 cm. Ich tryb działania był identyczny. Po prostu zbyt łatwo było je pomylić — i właśnie to było przyczyną wszystkich wypadków. Jeśli właśnie wylądowałeś samolot, klapy zostaną przedłużone, a zanim zaparkowasz, wycofasz je. Chapanis spróbował więc czegoś innego.
Do przełącznika sterującego podwoziem przykleił małe gumowe kółko, a do przełącznika sterującego klapami twardą, kanciastą „klapkę”. I faktycznie — nie było więcej wypadków.
Obecnie jest znany jako jeden z założycieli dziedziny anatomii — badania czynników projektowych w ludzkiej wydajności — i miał prostą obserwację: projekt kokpitu może mieć wpływ na prawdopodobieństwo błędu ludzkiego. Takie podejście stosuje się teraz podczas projektowania wszystkich nowoczesnych samolotów. Dwa przełączniki w obecnych samolotach są teraz bardzo odrębne, jak nakazuje prawo federalne w USA.
Dlaczego więc opowiedzieliśmy ci tę historię?
Ludzie popełniają błędy. Jednak błąd ludzki nie jest przyczyną; jest to objaw. Gdy uznamy błąd ludzki za przyczynę awarii, przestajemy dalej analizować zdarzenie.
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 "błędu ludzkiego" w badaniach jest to, że powoduje utratę z oczu faktu, że to, co ludzie zrobili sens dla nich w tym czasie. 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ę czegoś dowiedzieć, nie możemy przerywać badań w momencie wykrycia błędu ludzkiego, jak to się często zdarza. Jak pokazuje historia B-17, za błędem ludzkim kryją się interesujące wiadomości o naszym systemie, które możemy poznać.
Pułapka 2: Rozumowanie counterfactual
Counterfactual oznacza "sprzeczne z faktami", a rozumowanie counterfactual odnosi się do opowiadania historii o wydarzeniach, które nie miały miejsce w celu wyjaśnienia wydarzeń, które to zrobiły. Nie ma to większego sensu, ale ludzie i tak mają tendencję do myślenia w ten sposób.
Alternatywne stwierdzenia można rozpoznać po frazach-kluczach:
- Mogliśmy
- Powinniśmy
- Mogło by
- Nie udało się
- Nie
- Jeśli tylko
Oto parę przykładów alternatywnych stwierdzeń związanych 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ć odebrane w środowisku kanarowym."
Problem z tego typu rozumowaniem w przeglądzie po zdarzeniu polega na tym, że mówisz o rzeczach, które nie miały czasu, aby zrozumieć, jak się stało, stał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 adverbs, takie jak "odpowiednio", "nieostrożnie", "pospiesznie", i tak dalej.
Normatywne myślenie sprawia, że oceniamy decyzje na podstawie ich konsekwencji. 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.
Normatywny język może działać również w drugą stronę. Można na przykład chwalić pracowników za „właściwą” reakcję. Ale znowu, często ten wyrok jest dokonywane z korzyścią informacji, których nie mieli ludzie, o których mowa.
Problem z normatywnym językiem jest podobny do problemu z przeciwstawnym rozumowaniem: jeśli osądzamy po tym, jak informacje, które były niedostępne dla ludzi zaangażowanych podczas incydentu, zaniedbujemy zrozumieć, w jaki sposób działania operatorów mają sens w tym czasie.
Pułapka 4: Rozumowanie mechanistyczne
Rozumowanie mechanistyczne oznacza koncepcję, że interwencja sugeruje konkretny 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 zdarzeniu, tworzysz wnioski na temat fallacycy, z którymi pracujesz, systemy, z którymi pracujesz, działają w zasadzie prawidłowo, a jeśli tylko te "wtrącające się dzieci" nie zrobiły tego, co zrobili, awaria nie miała miejsca.
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. Żadnych wdrożeń, żadnych działań w płaszczyźnie sterowania, nic.
Jak myślisz, czy po jednym dniu Twoja usługa nadal działałaby zgodnie z oczekiwaniami? Po tygodniu? Po miesiącu? Po roku? Jak długo można realistycznie oczekiwać, że usługa będzie działać bez ludzkiej interwencji? W większości przypadków nie będzie to możliwe.
To ćwiczenie myślowe prowadzi do ważnych wniosków:
Ludzka umiejętność adaptacji jest konieczna do utrzymywania działania naszych systemów.
Jedynym powodem, dla których systemy w ogóle działają, są czynności ludzi, którzy je kontrolują. Jest to tylko poprzez działania człowieka i zdolność do dostosowania się do zmieniających się okoliczności, które system nadal działa.
Dlatego błędne jest stwierdzenie, że system "w zasadzie działa... gdyby nie dla tych wtrącających się dzieci." 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.
Myślenie mechanistyczne jest problemem, ponieważ prowadzi do przekonania, że znalezienie człowieka odpowiedzialnego za problem jest równoznaczne ze znalezieniem problemu. Jednak ten sam człowiek całe tygodnie i miesiące improwizował i zmieniał system, by zapewnić jego działanie. Jego rola może być wystarczająco ważna, by zastanowić się nad nią podczas przeglądu po zdarzeniu.
Teraz znasz już niektóre błędy, których należy unikać podczas przeprowadzania przeglądu po zdarzeniu. Możemy przejść do kolejnej lekcji, w której poznamy kilka przydatnych wskazówek.