Jakość za wszelką cenę. Czy to się opłaca?

W moim domu rodzinnym cały czas trwał remont. Pewnie wielu posiadaczy domów, szczególnie z nieco większym metrażem, zna tę starą historię: zaczynasz od kuchni, za jakiś czas udaje Ci się odłożyć nieco grosza na łazienkę, potem współmałżonek namawia na odświeżenie sypialni… a kiedy już w końcu ukończysz wszystkie pomieszczenia, okazuje się, że moda się zmieniła, czas nadgryzł swym zębem ściany i nim się obejrzałeś – stoisz w IKEA i wybierasz uchwyty do systemu METOD. Taki system renowacji był dla nastoletniej dziewczyny utrapieniem: mycie włosów w zimnej wodzie (akurat wysiadł boiler), wiecznie zakurzone ubrania (to gładzie w przedpokoju) czy mimowolne polubienie muzyki techno (jako jedyna dość dobrze komponuje się z dźwiękiem wiertarki) potrafią nieźle dokopać człowiekowi w momencie życia, w którym burza hormonów i bez tego intensywnie go doświadcza. W związku z tymi, jak mi się wtedy wydawało, traumatycznymi przeżyciami, bardzo wcześnie obiecałam sobie, że kiedy w końcu przyjdzie mi wyprowadzić się od rodziców, to tylko do w stu procentach ukończonego lokum. Jak zaplanowałam, tak zrobiłam. Mój dom był zupełnie ukończony w środku. Co prawda wymagał nieco prac na zewnątrz, nie budziło to we mnie jednak niepokoju, ponieważ moje nastoletnie postanowienie dotyczyło wnętrza mieszkania, a nie jego obejścia. Aż pewnego dnia usłyszałam: „Magda, musimy wymienić okna. Wnęki są niedocieplone”. A wymiana okien oznacza kucie, klejenie, gładzie w kuchni, łazience, sypialni… i tak oto stoję i wybieram uchwyty do systemu METOD.

Pewnie wielu z czytających już zastanawia się, czemu służy ten nieco dłużący się wstęp. Będziecie musieli jednak uzbroić się w cierpliwość, ponieważ nie zamierzam wyjawić jego związku z treścią aż do samego końca.

NIE DA SIĘ PRZETESTOWAĆ WSZYSTKIEGO

Niemalże każdy tester na swojej ścieżce kariery dochodzi do takiego momentu, kiedy przynajmniej rozważa przystąpienie do certyfikacji z ISQTB. Jednym z pierwszych zagadnień, jakie wówczas poznaje, jest siedem zasad testowania. Pamiętam, gdy sama przygotowywałam się do egzaminu i prawie każda z tych arbitralnie wybranych zasad, które „dostarczają ogólnych wskazówek, mających zastosowanie do wszystkich rodzajów testowania” (Certyfikowany tester Sylabus poziomu podstawowego ISTQB®) zdawała mi się mocno dyskusyjna, skomponowana jakby trochę na siłę i nie poparta żadnym sensownym argumentem. W dodatku nijak ze sobą nie powiązana, bo nie, nie uważam, żeby wrzucenie słowa testowanie w każde dowolne zdanie tworzyło dostatecznie silną więź. Ogółem siedem zasad testowania wygląda tak, jakby ktoś bardzo chciał stworzyć listę porad w liczbie odpowiadającej jego szczęśliwemu numerkowi, ale po dwóch pierwszych punktach skończyły mu się pomysły, więc wrzucał tam co popadnie. I wcale że dążę do tego, by pastwić się nad paradoksem pestycydów, chyba najśmieszniejszej zasadzie, która mówi o tym, że testy są jak pestycydy, a oprogramowanie jak pole usiane robakami – po pewnym czasie robaki uodparniają się na działanie chemicznego środka. Choć bardzo kusząca to perspektywa, to jednak nie mam zamiaru kopać leżącego. Wręcz przeciwnie, dążę do tego, że jedna z tych zasad (choć na pierwszy rzut oka wydaje się łatwa do obalenia) finalnie jest całkiem prawdziwa. A mam myśli zasadę, która mówi, że testowanie gruntowne jest niemożliwe. Według niej możliwe jest przetestowanie wszystkiego (to znaczy: wszystkich możliwych kombinacji danych wejściowych i warunków wstępnych) tylko w trywialnych przypadkach. Już nawet prosta funkcja, na którą składa się instrukcja warunkowa if, zagnieżdżona w pętli for, przyjmującej X o wartości od 1 d0 100 (czyli mogącej wykonać się maksymalnie sto razy), generuje ponad dwa i pół kwintyliona możliwych ścieżek, jak zaznaczył Adam Roman w pozycji Testowanie i jakość oprogramowania. Modele, techniki, narzędzia. Tylko przypomnę, że kwintylion to trzydzieści zer poprzedzonych jedynką. I choć jestem typową milenialką, wychowaną w duchu filozofii „sky is not the limit” oraz w przekonaniu, że nie ma rzeczy niemożliwych, to mam takie przeczucie graniczące z pewnością, że przetestowanie kwintyliona ścieżek leży całkiem blisko niemożliwości. Może być tak, że wrażenie to pogłębia świadomość, że nawet wykonując tysiąc testów na milisekundę, przetestowanie tej prostej funkcji zajmie 80 biliardów lat… Pracuję w IT nie od dziś i zdaję sobie sprawę, że znalazłoby się parę osób, które z chęcią sporzytkowałyby 80 biliardów lat na oczekiwanie na wynik testów. Być może warto, ale kluczowe pytanie brzmi:

CZY TO SIĘ OPŁACA?

Zanim przejdziemy do odpowiedzi na to pytanie, musimy najpierw wiedzieć, w jaki sposób mierzyć koszty jakości. To, co leży u podstaw każdej organizacji, to rachunek zysków i strat, nikogo więc raczej nie zdziwi, że i w kategorii zarządzania jakością udało się wypracować metody, pozwalające na całkiem precyzyjne oszacowanie, czy przypadkiem nie dokładamy do interesu. Całkiem sporo metod, dodam. Ale na potrzeby naszego artykułu wystarczy nam omówienie jednej techniki. I choć jest ona całkiem prosta, to i tak uważam, że na jej sukces składa się przede wszystkich chwytliwa nazwa: koszt jakości. Joseph M. Juran, który technikę opisywał, ewidentnie musiał mieć smykałkę do marketingu, cóż bowiem innego człowiek może wpisać w Google, chcąc dowiedzieć się, jak oszacować koszty jakości. Przejdźmy jednak do sedna: ta prosta technika mówi, że na całkowity koszt jakości składają się koszty kontroli (na te składają się nakłady poniesione na prewencję oraz wykrycie ewentualnych awarii) oraz koszty awarii (te z kolei dzielimy na koszty awarii wewnętrznych i zewnętrznych), jak to opisała Juran w Quality control handbook. Myślę, że intuicja i doświadczenie już podpowiadają Wam ogólną zasadę: im więcej środków przeznaczamy na kontrolę (czyli testowanie, audyty, szkolenia, ulepszanie procesu, weryfikację i walidację itd), tym niższe koszty poniesiemy wtedy, gdy dojdzie do awarii.

Wiedząc, że nasze 80 biliardów lat to koszty prewencji, wróćmy do pytania o opłacalność. Według powyższej techniki sprawa wydaje się prosta: wystarczy poczekać tę może nieco dłuższą chwilę, ale dzięki temu nie poniesiemy kosztów awarii. Sam zysk, prawda? Niestety, rzeczywistość nie rozpieszcza. Ekonomiści nie próżnują i wymyślają te swoje prawa, a wśród nich prawo malejących przychodów: coraz większe nakłady na kontrolę dają coraz to mniejsze zyski z zapobiegania awariom, jak wynika z prawa malejących przychodów. A mówiąc prościej: w pewnym momencie może okazać się, że nakłady na zapobieganie przewyższają koszty ewentualnej awarii. Oznacza to, że czasami firmie zwyczajnie opłaca się dopuścić do awarii. Trzeba przy tym jednak pamiętać, że w praktyce wyznaczenie optymalnego poziomu kosztów może być bardzo trudne – wiele kosztów awarii, zwłaszcza zewnętrznej, takich jak na przykład utrata zaufania klientów, ciężko jest oszacować. W związku z tą trudnością mierzalności możemy założyć, że część decyzji związanych z optymalizacją kosztów opiera się w mniejszym lub większym stopniu na intuicji. A kiedy mowa o intuicji, to warto wspomnieć o zasadzie ETTO.

ZASADA ETTO

Być może część z Was zna ten niemalże już memiczny trójkąt, w którym możliwe jest wybranie tylko dwóch z istniejących trzech opcji (tanio, dobrze, szybko).

Kiedy przyjrzymy mu się bliżej, dostrzeżemy pewną logiczną nieścisłość. Autor zakłada, że czynność (praca, projekt, produkt) wykonana dobrze i w niskiej cenie zajmie dużo czasu. Z tym, że każdy kto pracował w trybie projektowym, także w zwinnym środowisku, wie, że coś, co zajmuje dużo czasu, po prostu nie może być tanie. Tanio i szybko oznacza po prostu źle. Więc kiedy wyeliminujemy czynnik ceny, zakładając, że projekty mogą być wykonane tylko albo dobrze, albo szybko, w zasadzie uzyskamy zasadę ETTO. Zasada ETTO (The Efficiency-Thoroughness Trade-Off) oznacza kompromis między wydajnością a dokładnością, czyli w telegraficznym skrócie: zakłada, że na co dzień balansujemy pomiędzy efektywnością a dokładnością. Autor tej koncepcji, Erik Hollnagel, uważa, że podstawową cechą ludzkiej wydajności, zarówno indywidualnej, jak i zbiorowej, jest to, że zasoby potrzebne do zrealizowania jakiegoś celu są często (o ile nie zawsze) po prostu zbyt małe. Najczęściej brakuje nam czasu (pamiętajcie, 80 bilardów lat), ale także innych zasobów, takich jak: informacje, materiały, narzędzia, energia. Niemniej jednak zazwyczaj udaje nam się spełnić wymagania do akceptowalnej wydajności, przy dostosowaniu sposobu działania, aby sprostać wymaganiom i aktualnym warunkom (innymi słowy: aby zrównoważyć zapotrzebowanie i zasoby). Dzieje się tak, ponieważ w swoich codziennych czynnościach, nie tylko w pracy, ale i poza nią, ludzie (a wraz z nimi całe organizacje) rutynowo dokonują wyboru między skutecznością a dokładnością, ponieważ rzadko można spełnić oba jednocześnie. Jeśli wymagania dotyczące produktywności czy wydajności są wysokie, wtedy dokładność jest redukowana – aż do osiągnięcia optymalnej produktywności. Jeśli wymagania dotyczące jakości są bardzo wysokie, wtedy redukowana jest wydajność.

Warto mieć w pamięci tę zasadę na wypadek, gdyby przyszło nam do głowy próbować być jednocześnie bardzo wydajnym (czyli szybko realizować projekty) i utrzymać stuprocentową jakość za wszelką cenę. Nawet w zwinnych środowiskach, które teoretycznie sprzyjają zarówno szybkości, jak i dokładności, dług technologiczny jest zjawiskiem tak naturalnym, że sam doczekał się memów i żartów. Często już po wdrożeniu idealnie (wydawałoby się) wykończonego produktu, szybko okazuje się, że utrzymanie go nie jest tak proste, jak powinno być przy tak doskonale dopracowanym oprogramowaniu. Dodawanie nowych funkcjonalności jest koszmarem powodowanym zaniedbaniami w dobrych praktykach na etapie wytwarzania, pojawiają się problemy z wydajnością czy stabilnością naszego produktu – a więc w praktyce przekonujemy się, że jednak „szybko” nie idzie w parze z „dokładnie”.

KIEDY WARTO POCZEKAĆ 80 BILIARDÓW LAT?

Kiedy byłam na studiach, jeden z naszych nauczycieli akademickich uznawał wyłącznie dwustopniowy system oceniania: można było albo dostać piątkę, albo nie zdać. Były to studia z zakresu bezpieczeństwa, a nauczyciel tłumaczył swoje podejście mniej więcej tymi słowami: „Według oficjalnego systemu oceniania, aby dostać czwórkę, należy udzielić 75% poprawnych odpowiedzi. Czy chcieliby państwo lecieć samolotem zaprojektowanym w 75% dobrze?”.

Myślę, że ta krótka anegdota dość dobrze oddaje sytuację, w której bezwzględnie powinniśmy maksymalizować koszty poniesione na działania zapobiegawcze tak, aby nie dopuścić do awarii. Historia zna wiele przypadków, gdy prosty błąd czy niedopatrzenie na poziomie testów doprowadziły do poważnych w skutki i nieodwracalnych szkód. Kosztowny NASA Mars Climate Orbiter obrócił się w proch z powodu trywialnego błędu: niespójności jednostek metrycznych. Ale wtedy nie zginęli ludzie. Niestety, tyle szczęścia nie mieli pacjenci poddani naświetlaniu aparatem Therac-25, których dosięgła choroba popromienna… z powodu brakującej jednej linii kodu. Z kolei niedokładność obliczeń zmiennoprzecinkowych doprowadziła do tego, że system obrony przeciwrakietowej Patriot nie zadziałał prawidłowo i tym samym doprowadził do śmierci 28 osób i poważnych obrażeń u ponad 100 kolejnych! Wszystkie powyższe sytuacje cechują się przynajmniej jedną z dwóch opcji: koszty pomyłki są gigantyczne albo koszty pomyłki są bardzo trudne lub niemożliwe do odwrócenia.

ZAKOŃCZENIE

W tamtym momencie, gdy przez los zostałam zmuszona do wzięcia udziału w odwiecznej niekończącej się remontowej odysei, przy okazji odebrałam też lekcję, która okazała się być jedną z najważniejszych w moim zawodowym życiu: jakość nie jest sama w sobie celem, jakość jest drogą, w dodatku nigdy niekończącą się drogą! Nie jesteśmy w stanie osiągnąć satysfakcjonującego poziomu jakości z bardzo prostej przyczyny: zawsze można zrobić coś lepiej. Natomiast lepiej zawsze obarczone jest kosztem, który – jak sama jakość – dąży do nieskończoności. Zbyt duże nakłady na jakość mogą oznaczać, że nie przeznaczymy ich na nowe funkcjonalności czy po prostu docenienie ludzi, którzy tworzą oprogramowanie. Poza tym taka pogoń, zarówno na poziomie indywidualnym, jak i organizacyjnym, za (co do zasady) nieosiągalnym celem i bez świadomości jego nieosiągalności, nie może stać się niczym innym, jak źródłem niezadowolenia i frustracji. To z kolei odbiera całą przyjemność, jaka wynika z dbania o jakość.