Redakcja
"Nie możesz w 100% polegać na profilaktyce"
Oczywiście nie da się zapobiec wszystkim defektom i uchronić się przed każdą awarią, ale we współczesnym IT nie chodzi o to, aby to zrobić. Nową miarą skuteczności jest nie to, ile defektów udało nam się wyeliminować, ale jaką stratę dane defekty wywołały. Jeśli więc strata jest niewielka, nie warto inwestować w prewencję, a skupić się na gaszeniu (niewielkiego?) pożaru kiedy ten już wybuchnie. Takie podejście powoduje, że firmy coraz mocniej przesuwają granicę złej jakości oprogramowania z przekonaniem, że użytkownik wytrzyma.
"Możesz uczyć się na błędach, przeprowadzając przeglądy incydentów po ich wystąpieniu"
Czym jest przegląd incydentu: "Przegląd incydentu to spotkanie, które odbywa się po rozwiązaniu incydentu, które sprawdza, dlaczego dany incydent miał miejsce i co można zrobić, aby być lepiej przygotowanym na nie w przyszłości. Celem nie jest wskazywanie palcami i obwinianie kogoś; chodzi o wspólne znalezienie rozwiązania jako zespół. Niektórzy mogą nazywać to post mortem, ale nie sądzę, aby ten termin był trafny, ponieważ "mortem" odnosi się do śmierci. W większości przypadków system lub oprogramowanie będzie nadal działać po wystąpieniu incydentu." – pisze Kasia.
Dalej czytam, że najważniejszym elementem jest nauka na popełnionych błędach. Jednak Kasia zakłada, że nie każdy przegląd musi kończyć się „action points” bo albo generują zbyt wysokie koszty lub nasza organizacja nigdy nie ich nie wdroży. Ciężko się z tym zgodzić. Wyciągnięta nauka musi mieć swoją wynikową. Są to poprawki, które wdrożymy w edukacji czy też procesie, aby eliminować problemy w przyszłości. Nie ma sensu prowadzić rozbudowanych analiz incydentów jeśli nie doprowadzi to do powstania mechanizmu, który zapobiegnie im w przyszłości. Nie możemy mówić, że blokerem przed wyeliminowaniem awarii w przyszłości są wysokie koszty zmiany organizacji pracy. Ta zmiana zawsze będzie miała swoje tańsze i droższe alternatywy. Może to być oczywiście wdrożenie nowego narzędzia, ale może być to prosty wpis na listę kontrolną.
"Nie istnieje jedna główna przyczyna"
Z tym trudno się nie zgodzić. Zawsze dany incydent to zbieg wielu niesprzyjających okoliczności. Jednak często jesteśmy w stanie łatwo dotrzeć do przyczyny dominującej.
"Nie zwiększamy naszego sukcesu poprzez zapobieganie niepowodzeniu. Robimy to, upewniając się, że wszystko idzie dobrze"
Nie da się tych dwóch aspektów rozdzielić. Wszystko pójdzie dobrze pod warunkiem, że wiemy co może pójść źle. To "źle" wynika ze wszystkich naszych wcześniejszych doświadczeń i niepowodzeń.
"Każdy, kto mówi, że porażka nie wchodzi w grę, jest albo arogancki, albo nieświadomy"
Porażka (a bardziej awaria), która nie powinna się pojawić, to raczej definiowanie pewnego celu. W pewnym sensie mierzalnego, bo każda awaria jest dowodem na to, że nie udało się tego celu osiągnąć. Za każdym razem kiedy mówimy, że chcemy osiągnąć zerową ilość defektów krytycznych i ważnych, określmy pewien mierzalny cel i nie wynika on ani z arogancji, ani też braku świadomości, a ze zwykłej troski o odbiorców naszego oprogramowania.
Podsumowanie
Firmy produkujące oprogramowania coraz bardziej przekonują nas, że awarie muszą się zdarzać. Takie podejście to brak szacunku dla użytkownika, jego czasu i pieniędzy, które wykłada na oprogramowanie. Dobrze gdy wytwórca dla danej awarii dostarczy poprawkę, gorzej gdy zaczyna nas przekonywać, że to nasza wina lub zachęca do zakupu łatki. Nowa kultura testowania na produkcji i przekonywanie, że musimy się przyzwyczaić do incydentów to walka ze wszystkimi, kosztownymi metodami zapewnienia i kontroli jakości oraz próba przerzucenia odpowiedzialności za jakość na końcowego użytkownika.
[Aktualizacja]
Kasia odpowiedziała na naszą polemikę w TestITka 6,5 Vacation Edition
Warto obejrzeć i warto posłuchać odpowiedzi na zarzuty z naszego artykułu.
Przy okazji jest jeszcze konkurs.
