Wraz z ogromnym postępem technologicznym ostatnich lat, mamy równolegle do czynienia z postępującą złożonością problemów. Wiele katastrof komunikacyjnych, kryzys finansowy, czy nieoczekiwane błędy w oprogramowaniu komputerowym, można by do takich problemów zaliczyć. Wiemy bardzo dużo, ale nie wszystko, a niepowodzenia w złożonych sytuacjach zdarzają się często i to raczej pomimo ogromnych wysiłków niż z powodu celowych zaniedbań.
“Dlaczego nie zawsze udaje nam się zrobić to, czego chcemy i jak tego chcemy?”, tak sformułowane pytanie zadali sobie w latach 70 XX wieku Samuel Gorovitz i Alasdai MacInyre. Swoją obserwację nazwali jako „omylność konieczna”.
Nawet wspomagane przez technologię nasze możliwości fizyczne i umysłowe są ograniczone. Problem ten dotyka szczególnie te branże, z których gwałtownym rozwojem mamy obecnie do czynienia (medycyna, informatyka, bankowość itp.) gdzie niemal codziennie pojawia się nowa porcja informacji do przyswojenia i umiejętności, które należy wyćwiczyć, a następnie przetestować. Jednym z pierwszych, udokumentowanych przypadków radzenia sobie z tego typu sytuacjami, był ten, wypracowany przez lotnictwo.
Historia Boeinga model 299
Rok 1935 Dayton w stanie Ohio. Korpus Powietrzny Armii Stanów Zjednoczonych przeprowadza właśnie decydujący etap konkursu między producentami samolotów.
Stawką jest lukratywny kontrakt na produkcję wielozadaniowego bombowca dalekiego zasięgu. Niekwestionowanym faworytem jest Boeing, który stworzył “Latającą fortecę”, samolot ze stopu aluminium, technologicznie znacznie wyprzedzający swoje czasy. Za sterami major Hill, najbardziej doświadczony dowódca eskadry pilotów oblatywaczy. Samolot wznoszą w powietrze cztery potężne silniki, które na wysokości 91 metrów nad ziemią milkną… Maszyna rozbija się i staje w płomieniach na oczach komisji wojskowej, w wypadku ginie pilot major Hill i jeden członek pięcioosobowej załogi.
Ciężko wyobrazić sobie gorszy scenariusz dla prezentacji owoców swojej ciężkiej pracy, mimo wszystko dalszy przebieg wydarzeń jest jeszcze bardziej zaskakujący. Po wnikliwym śledztwie okazało się, że przyczyną wypadku był błąd pilota, który nie wykonał jednej rutynowej procedury. W sprostowaniu udowodniono natomiast, że maszyna jest tak skomplikowana, iż do jej bezpiecznego pilotażu potrzeba dwóch pilotów. Był to właśnie wspomniany wcześniej problem ze “skrajną złożonością”
Zadaniem drugiego pilota nie miało być jednak pilotowanie samolotu, a pilnowanie check listy. Czyli środka zaradczego na “omylność konieczną”, jaką wprowadził Boeing do całej procedury obsługi samolotu. Check lista była to zwykła kartka A4 posiadająca wszystkie punkty od startu do lądowania obejmująca takie oczywiste rzeczy jak sprawdzenie czy zwolniono hamulce, zamknięto drzwi, okna itp., które to załoga ma wykonać i potwierdzić ich wykonanie z listą.
Boeing dostał swoją drugą szansę. Przeprowadzono testy, w trakcie których mało doświadczeni piloci pokonali 3 miliony kilometrów bez najmniejszej awarii. Osiągi samolotu były zdumiewające, dlatego armia zamówiła 13 000 maszyn, które miały znaczący wpływ na przebieg II wojny światowej. Co bardziej istotne, poradzono sobie z problemem skrajnej złożoności w skrajnie prosty sposób. Check lista została wdrożona na szeroką skalę w lotnictwie, jest uaktualniania i testowana w symulatorach przez zespół badawczy za każdym razem, gdy dochodzi do awarii samolotu również obecnie.
Checklisty w medycynie
Faktów na to, że tak proste narzędzie, jak check lista działa na skrajną złożoność, przybywa z każdym rokiem. Niepodważalnych dowodów dostarczył chirurg Atul Gawande w swojej książce “potęga checklisty”, w której opisuje zarówno przypadek boeinga, jak i wdrożenie tego rozwiązania na dużą skalę przez światową organizację zdrowia. Opracowana pod jego przewodnictwem 19-punktowa lista kontrolna z zakresu przygotowania i przeprowadzania operacji na oddziałach Oiom została wdrożona przez WHO w 8 placówkach na świecie. Do testów wybrano po cztery szpitale z krajów wysoko i nisko rozwiniętych. Założona próba badawcza to miesiąc na wdrożenie i szkolenia oraz 3 miesiące faktycznego badania rezultatów.
W październiku 2008 roku spłynęły pierwsze oficjalne wyniki, które zaszokowały cały świat medycyny. Okazało się, że łączny wskaźnik poważnych powikłań pooperacyjnych we wszystkich ośmiu badanych szpitalach spadł o 36%, a odsetek zgonów aż o 47%. W konsekwencji podczas tego okresu lista kontrolna uratowała ponad 150 pacjentów przed powikłaniami i 27 przed śmiercią. Kilkakrotnie sprawdzono, czy w szpitalach nie zmieniły się w tym czasie warunki sanitarne, liczba operacji i ich złożoność. Nie stwierdzono jednak rozbieżności. Co ciekawe, nie miało również wpływu to czy szpital był dobrze, czy źle wyposażony. Choć wyjściowy wskaźnik powikłań był wyższy w 4 szpitalach o gorszym standardzie, wprowadzenie karty zmniejszył ten wskaźnik o 1/3. Po upewnieniu się że wyniki nie są dziełem przypadku zespół wiedział, że karta kontrolna naprawdę działa !
Czy to działa w branży IT?
Współcześni młodzi przedsiębiorcy, startupy i wiele zawodów powiązanych z IT są na etapie Boeinga 299. Mają świetny produkt, wiedzę, kompetencje i możliwości realizacji, ale gdy przychodzi godzina zero, ktoś pod wpływem różnych niespodziewanych czynników popełnia błąd, który kosztuje nas kontrakt, inwestora, klienta. Jeśli mamy szczęście i argumenty jest nadzieja, że podobnie jak Boeing dostaniemy drugą szansę. Od nas jednak zależy czy wyciągniemy wnioski i wdrożymy środki zaradcze.
Skrajna złożoność w informatyce jest szczególnie trudna do rozwiązania. Bardzo często działamy pod wpływem niekorzystnych czynników, takich jak pośpiech, rutyna, różnego rodzaju rozpraszacze, a na końcu nasz najgorszy wróg, jakim jest nasze własne EGO. Bo przecież innym check lista może i jest potrzebna, ale nie mi, ja wiem co chcę osiągnąć i wiem jak to zrobić, a projekt musi być oddany na wczoraj.
Ile błędów popełniają programiści?
Problem ten poruszył Steve McConnelly w swojej książce “Code Complete”. Przebadał systemy różnych firm sprawdzając ile błędów popełniają programiści na 1000 linii kodu. Wyróżnił tym samym 3 grupy.
– Programista przeciętnej korporacji popełnia od 15 do 50 błędów na 1000 linii kodu.
– Programista Microsoftu popełnia od 10 do 20 błędów na 1000 linii pisanego kodu i około 0,5 błędu na 1000 linii kodu w produkcie finalnym.
– Programista pracujący dla NASA popełnia poniżej 3 błędów na 1000 linii pisanego kodu i około 0,1 błędu na 1000 linii kodu w produkcie finalnym.
Z obserwacji McConnella na ilość błędów w badaniu wpływały dodatkowo takie czynniki jak np. szybkość pisania kodu, oraz cały proces jaki zespół deweloperów wypracował sobie wewnętrznie. Czyli, mówiąc inaczej, kryje się tutaj zagadnienie check listy, którą każdy członek zespołu programistów jest zobowiązany sprawdzić przed oddaniem kodu.
Wyniki badania pokazują, że przy odpowiednim podejściu i doświadczonym zespole możemy uniknąć sporej części błędów. W sytuacjach, w których jeden błąd w kodzie źródłowym oznacza niepowodzenie wielomilionowego projektu, np. podróży sondy kosmicznej, taka nadzwyczajna dbałość o najmniejsze detale jest uzasadniona. Co jednak ze wszystkimi przypadkami, gdzie nie stać nas na kosztowne symulacje lub też złożoność jest tak duża, że nie mamy możliwości przetestowania tego w rozsądnym czasie ?
Jak znajdować błędy w oprogramowaniu?
Ciekawe rozwiązanie problemu z błędami w oprogramowaniu znalazła branża gier. Faktycznym środowiskiem testowym produktu stali się sami konsumenci. Obecnie obserwujemy dwie wyróżniające się strategie. Możemy stać się beta-testerem i grać w grę w czasie testów za darmo lub możemy kupić grę wcześniej jako preorder. Tym samym zgadzamy się na zakup gry, która nie jest w 100% ukończona, mamy jednak prawo do darmowych uaktualnień. Pozwala to producentowi na zdecydowanie tańsze i szybsze wychwycenie błędów utrudniających rozgrywkę.
Pomimo takich zabiegów, bardzo często produkt finalny ciągle nie jest wolny od błędów. Dowodem mogą być wielokrotne patche najnowszych gier wydawane jeszcze długo po oficjalnej premierze. Co ciekawe, takich problemów nie było (lub było ich znacznie mniej) jeszcze parę lat temu, gdy deweloperzy wypuszczali swoje produkcję na konsole bez dostępu do internetu i fizycznie nie mieli możliwości swobodnie udostępniać aktualizacji. Trzeba jednak pamiętać, że złożoność gier obecnie jest dużo większa. Oferując graczom ogromny wirtualny świat, producenci liczą się z tym, że nie uwolnią go od wszystkich bugów, eliminują więc w pierwszej kolejności te, które są krytyczne.
Złożony system B2B
W sytuacjach o dużej złożoności, w których musimy wyeliminować wszystkie możliwe błędy, kluczowe stają się wewnętrzne procedury firmy. Podobnie jak w budownictwie, doświadczony zespół wybuduje dom jednorodzinny nawet bez szczegółowego harmonogramu. Jednak, jeśli ten sam doświadczony zespół ma wybudować wieżowiec, projekt zaczyna się znacznie komplikować i samo doświadczenie tu nie wystarczy. Analogiczną sytuacje mamy z oprogramowaniem. W przypadku prostej strony internetowej złożoność jest mała, ryzyko niewielkie. Jeśli jednak naszym celem jest system B2B lub dedykowany sklep internetowy, mamy już do czynienia ze złożonością skrajna. W takich sytuacjach konieczny jest szczegółowy harmonogram pokazujący zależności poszczególnych etapów projektu.
(przykład harmonogramu – system B2B firmy i-systems)
Harmonogram prac, pozwala zaplanować działania i wykryć konflikty na bardzo wczesnym etapie. Jest główną listą kontrolną projektu, którą zespół odczytuje i uaktualnia za każdym razem, gdy system B2B się zmienia. Taki sam proces weryfikowania powinien być wypracowany wewnętrznie przez każdy dział w firmie.
„Każda organizacja potrzebuje dyscypliny, która pomoże jej stawić czoła rzeczywistości”
Peter F. Drucker
Podsumowanie
Posiadanie listy kontrolnej nie jest celem samym w sobie. Fakt jej istnienia w firmie nie ma żadnej wartości, jeśli nie będzie się to wiązało, z konsekwentnym jej stosowaniem i rozwijaniem. Nawet jeśli przekonamy wszystkich, że wdrożenie takiego rozwiązania przyniesie wszystkim korzyści, musimy być gotowi na nieuzasadniony opór.
Taką sytuację bardzo dobrze obrazuje wspomniany przykład karty kontrolnej w chirurgi. Po publikacji rewelacyjnych efektów check listy przeprowadzono ankietę wśród lekarzy we wszystkich 8 testowanych szpitalach. Wykazano że 79% lekarzy uznała listę kontrolną za “świetne rozwiązanie, które nie przysparza problemów”. Pytanie co z pozostałymi 21%?
Zadano więc ostanie pytanie które brzmiało. „Jeżeli miałby Pan być operowany, czy chciałaby Pan, żeby lekarze korzystali z karty kontrolnej?” 93 % odpowiedziało, że tak.
Wypracowanie własnego, efektywnego sposobu eliminacji źródeł występowania błędów jest wyzwaniem firm, dla których priorytetem jest najwyższa jakość.