Każdy, kto kiedykolwiek uczestniczył w jakimkolwiek projekcie (nie tylko informatycznym), wie, że nie zawsze wszystko idzie łatwo i przyjemnie. Realizacja przedsięwzięć nie przebiega w próżni i należy pamiętać o środowisku, w którym znajduje się zespół. Istnieją różne ograniczenia - zasobowe, techniczne, a także prawne. Wszystkie trzeba wziąć pod uwagę i opracować plan, który pozwoli pracować mimo pewnych limitów. Mało tego - czasem trzeba przygotować się na coś, czego nie widać na pierwszy rzut oka, ale nauczeni doświadczeniem wiemy, że może wystąpić, zgodnie zresztą z prawami Murphy'ego. Jest to jeden z obowiązków kierownika projektu (ang. project manager) i coś, co nazywamy analizą ryzyka.

W dzisiejszym tekście przedstawimy sobie, czym ona właściwie jest i jak się do niej podchodzi.

Czym jest ryzyko?

Na początku mała niespodzianka - o ile praktycznie wszyscy (choćby intuicyjnie) wiedzą, czym jest czynnik ryzyka, o tyle nie każdy wie, że nie musi być on negatywny. Owszem, zwykle tak się dzieje, ale generalnie czynnik ryzyka to potencjalna sytuacja, która może wpłynąć na proces realizacji projektu i równie dobrze może stać się szansą na większy sukces (i to nawet bez pana Wojciecha Manna). Aby daleko nie szukać, wystarczy przywołać pandemię COVID-19 mającą miejsce mniej więcej od pierwszego kwartału 2022 r. i której jednym ze skutków ubocznych było masowe zainteresowanie metodami pracy zdalnej. Rozprzestrzenienie wirusa, poza oczywistym zagrożeniem dla ludzkości, była także okazją dla firm produkujących aplikacje pomagające w pracy lub edukacji na odległość. Jeśli ktoś był przygotowany na taki rozwój sytuacji lub odpowiednio wcześnie zareagował, to jest szansa, że jego akcje poszybowały do góry.

Jednak faktycznie, zazwyczaj czynniki ryzyka są zjawiskiem negatywnie wpływającym na rozwój projektu IT. Zwykle szuka się ich w kilku obszarach:

1. Czynniki techniczne - związane z kwestiami technicznymi, jak np. brak możliwości wykonania czegoś w danej technologii, a z czego nie zdawano sobie na początku sprawy. Jednak bardziej sensowne są tutaj zagrożenia związane np. z wykupieniem nieodpowiedniej usługi serwerowej, zmiany wersji oprogramowania, brak umiejętności użycia danej technologii, zbyt wysokie wymagania sprzętowe, kończące się wsparcie dla wybranego frameworka czy bardzo niska wydajność będącą konsekwencją pewnych decyzji.
2. Czynniki organizacyjne - zazwyczaj rozdziela się tę kategorię na kilka innych, jednak proponowałbym (przynajmniej na początku) to połączyć. A jest to zbiór czynników ryzyka związanych z np. harmonogramem projektu (a raczej niewystarczającymi buforami na prace), niedopiętym budżetem, brakiem wykwalifikowanej kadry czy powstaniem różnic nie do pogodzenia podczas negocjacji. Są to wszystkie zagrożenia wynikające z zarządzania czy omawiania formalności i warunków realizacji.
3. Czynniki prawne - istnieją projekty bezpośrednio podlegające danym regulacjom prawnym, np. aplikacje księgowe czy dydaktyczne. Do tej kategorii wpada ryzyko związane z audytami i zmianami np. w przetwarzaniu danych osobowych, zabezpieczeniach informatycznych czy zasadach podatkowych.
4. Inne - ulubiona kategoria studentów, w której znajdują się wszelkie nieprawdopodobne zdarzenia typu "tsunami w serwerowni". Żarty żartami, ale w pewnych przypadkach tego typu zdarzenia również warto rozważyć, co pokazał nam np. pożar w serwerowni OVH w wyniku którego wielu nieprzygotowanych dostawców stron po prostu przestało świadczyć swoje uslugi.

Oczywiście, to tylko podstawowy podział, który można jeszcze bardziej posegmentować. Ważne jest to, aby mieć początkowe narzędzie, które ułatwi nam dalszą pracę.

Z czego składa się czynnik ryzyka?

Taki niepozorny, a jednak ma swoje atrybuty, których musimy być świadomi. Są to:

• Opis - cóż, czym byłby czynnik bez choćby jednego zdania, który go opisuje.
• Prawdopodobieństwo (ang. probability) - istnieją czynniki, których wystąpienie jest bardziej oraz mniej prawdopodobne i to również należy wziąć pod uwagę w analizie. Zazwyczaj stosuje się tutaj skalę trójstopniową (H - High, M - Medium, L - Low), czasami dodając skrajne wartości (VH - Very High, VL - Very Low).
• Znaczenie (ang. impact) - ta cecha podaje poziom zagrożenia (lub szansy) w momencie, kiedy dane ryzyko się urzeczywistni i stanie się prawdziwe. Także tutaj zazwyczaj wybiera się skalę opisaną przy prawdopodobieństwie.
• Bliskość (ang. proximity) - dwie poprzednie cechy to nie wszystko, gdyż brakuje nam jeszcze jednego atrybutu. Istnieją czynniki, które są prawdopodobne i nawet bardzo wpływają na realizację, ale niekoniecznie wystąpią od razu. Ta informacja również może posłużyć do ustalenia planu radzenia sobie z ryzykiem.
• Odpowiedź - to, że czynnik ryzyka zostanie zidentyfikowany to tylko wstęp, który służy do przygotowania się na wystąpienie danego zagrożenia i zareagowania na niego.

Tak, jak wyżej napisałem, to proponowana odpowiedź (lub odpowiedzi) jest sednem, dla którego omawia się analizę ryzyka. Tak, jak w szachach zawodnicy mają w głowie przygotowane różne reakcje na poszczególne posunięcia rywala, tak w dobrze prowadzonym projekcie kierownicy również dość szybko realizują określony scenariusz, który wcześniej przemyśleli. Typy zachowań w odpowiedzi na czynnik ryzyka to:

• Unikanie - najprostsza możliwość, która polega na podjęciu takich decyzji, aby dane zagrożenie nigdy się nie zmaterializowało. Przykładem niech będzie założenie braku możliwości zainstalowania Javy na serwerze, który w przyszłości udostępni nam klient i decyzja o skorzystaniu z PHP, który jest dostępny w większości usług hostingowych.
• Redukcja - w tym przypadku staramy się opracować odpowiedź, w której nie unikniemy całkowicie skutków niepożądanej sytuacji, ale zminimalizujemy je. Przykładowo, jeśli podejrzewamy, że nie zdążymy z realizacją całego projektu do umówionego terminu, możemy założyć manewr z odpowiednio wczesnym outsource'owaniem części prac, co niekoniecznie w pełni rozwiąże nasz problem, ale pozwoli zwiększyć liczbę wymagań dostarczonych do danego momentu.
• Przeniesienie - w tym przypadku sytuacja jest dość prosta do wyjaśnienia, gdyż chodzi o przetransferowanie odpowiedzialności (choćby finansowej) na inny podmiot. Oczywistą sytuacją tego typu jest wykupienie ubezpieczenia pomagającego nam w radzeniu skutków np. pożaru serwerowni.
• Plan awaryjny - istnieją sytuacje, w których nagle trzeba szukać innej drogi dojścia do celu i mieć "plan B". Czymś takim może być przygotowanie scenariusza, w którym w wypadku problemu z zasobami ludzkimi w danym projekcie wiemy, których członków iinych zespołów przenosimy, aby wypełnić lukę.
• Akceptacja - "jeśli nie możesz pokonać wroga, to go polub". Czasami po prostu nie można niczego zrobić i trzeba pogodzić się z tym, że w przypadku wystąpienia czynnika ryzyka musimy z nim żyć. Tak jest na przykład ze zmianami w prawie podatkowym w momencie, kiedy tworzymy aplikację dla księgowości - w tym wypadku musimy być świadomi, że to może wystąpić i trzeba się na to przygotować psychicznie. Często może być połączone z innymi działaniami prewencyjnymi, jak np. zaoferowaniem umowy serwisowe, pozwalającej na dodatkowe działania w takiej krytycznej sytuacji lub przygotowujące do niej.

Jak wygląda analiza ryzyka?

Na początku należy zaznaczyć, że analiza ryzyka jest procesem ciągłym - informacja o czynnikach może pojawić się na każdym etapie realizacji projektu, choć faktycznie, największą uwagę należy zwrócić na to na początku. Jednak choćby sama kontrola tego, czy jakiś czynnik jest na horyzoncie, wymaga już stałego monitorowania odpowiedniej osoby w projekcie.

Sam proces identyfikacji takich czynników może być przeprowadzony początkowo przez analityka, ale najlepsze efekty daje burza mózgów (ang. brainstorming), która polega na spotkaniu się w kilka osób i wymianie pomysłów w myśl zasady, że każdy z nich jest dobry. Należy pamiętać, że - podobnie, jak omawialiśmy to w przypadku architektury - ważne jest spojrzenie na problem z różnych perspektyw i ról.

W wyniku takiej wymiany pomysłów powstaje lista, którą należy uporządkować. W tym celu każdemu punktowi przydzielamy prawdopodobieństwo, znaczenia oraz (opcjonalnie) bliskość. Po co to robimy? Aby móc spojrzeć na czynniki pod kątem kolejności opracowywania odpowiedzi. Do tego zadania przydatna jest macierz ryzyka, której przykład znajdziecie pod tym linkiem. Pomoże ona nam ustalić, które czynniki rzeczywiście zasługują na naszą największą uwagę, a które chwilowo możemy pominąć (oczywiście, uprzednio je notując). Pamiętajmy bowiem, że czas specjalistów jest ograniczony, a przetwarzanie każdego punktu w równym stopniu mija się z celem. Stąd konieczność posortowania listy według priorytetów, w czym pomaga rzeczona macierz, zdecydowanie faworyzująca czynniki ryzyka o dużym znaczeniu dla realizacji projektu.

Następnie, zgodnie z porządkiem od najbardziej krytycznego ryzyka, grupa osób opracowuje odpowiedzi na poszczególne kwestie, szukając najlepszych rozwiązań i być może podejmując kluczowe decyzje dla projektu już na tak wczesnym etapie, zabezpieczając zespół przed przykrymi zdarzeniami w przyszłości.

Komu jest potrzebna analiza ryzyka?

Oczywistą odpowiedzią jest "wszystkim", ale nie ukrywajmy - nie jest ona właściwa. Tego typu procesy przeprowadzane formalne są charakterystyczne dla większych firm i szczególnie istotnych, krytycznych projektów, które znajdują się w środowisku bardzo wrażliwym na "bodźce" zewnętrzne. To nie oznacza, że mniejsze zespoły nie powinny przeprowadzać takiej analizy - jest nawet wskazane, aby przeprowadzić ją porządnie co najmniej raz i opracować odpowiedzi na poszczególne zdarzenia w kontekście podobnych problemów w przyszłości także w innych projektach. Natomiast nie ma co ukrywać, że w mniejszych firmach ten proces jest bardziej "ukryty" i prowadzony intuicyjnie, bez dodatkowej dokumentacji. W takim wypadku analiza ryzyka to bardziej ćwiczenie myślowe, pozwalające lepiej przygotować zespół na trudy realizacji projektów informatycznych.

To bardzo ciekawa i ważna koncepcja dla wszystkich zajmujących stanowiska kierownicze - nikt nie lubi być negatywnie zaskakiwany (co do pozytywnych to różnie bywa), a szczególnie w biznesie, w którym liczy się odpowiednie wykorzystanie dostępnych zasobów oraz osiągnięcie celu. Dlatego warto przemyśleć, czy poświęcenie czasu na przeprowadzenie analizy ryzyka nie opłaci się w kontekście rzeczywistych kłopotów, w które może wpaść projekt.

Pozdrawiam i dziękuję - Jakub Rojek.