Kolejny post z cyklu przygotowań do certyfikatu REQB
Coś jest w tym tytułowym cytacie 😉
Czy warto jest analizować ryzyko ? czy w ogóle jest to komuś
do czegoś potrzebne ?
Mam nadzieje, że większość osób, która czyta to pytanie, odpowie
sobie NO JASNE, ŻE TAK! 😉
a skoro już wiemy, że warto to zastanówmy się jak do podejść
do tego tematu.
Jeśli po raz kolejny w swoim projekcie usłyszysz stwierdzenie,
że coś się wywaliło ze znanych wszystkim przyczyn albo czegoś można byłoby uniknąć
gdyby… to oznacza, że ktoś nie odrobił poprawnie swoich zadań pracowych – ktoś,
a konkretnie Ty Analityku!
Ale tak szczerze, z ręką na sercu, pracując w nawale różnych
projektów, zadań, zadanek czy ktokolwiek się przejmuje czymś takim jak „ryzyko”.
Śmieszki powiedzą „jest ryzyko, jest zabawa” ale myślę, że
Biznes nie będzie zadowolony jak przez błąd Pani Analityk (Pana Analityka) straci
swoje pieniądze, reputację albo znaczną grupę klientów.
Od czego należałoby zacząć?
Od Identyfikacji
Ryzyka, bo to niestety nie jest tak, że przyjdzie do nas takie Ryzyko jedno
z drugim i powie: „hej, dziś
prawdopodobnie się uaktywnię, więc bądź czujny Analityku”, żeby móc
efektywnie walczyć ze swoim wrogiem, trzeba go dobrze poznać, dowiedzieć co
złego może się wydarzyć dla wdrażanego systemu. Może warto spotkać się z Mądrymi
Ludźmi, zorganizować burze mózgów, przejrzeć dokumenty, pogadać o tym co nam
się wydaje niepokojące i skorzystać z tzw. analizy historycznej.
Jak już uda się namierzyć się większość Ryzyk to należałoby
się zastanowić co właściwie teraz z nimi zrobić. Może warto byłoby je jakoś spisać,
zrobić rejestr, nazwać, skategoryzować. Myślę, że to dobry kierunek, który powinien
obrać każdy analityk.
Tylko co dalej?
Teraz następuje część Analityczna -Analiza Ryzyka, trzeba stwierdzić jaki
wpływ na prowadzenie projektu mają zdefiniowane przez nas ryzyka. Pomocna może
okazać się macierz oceny ryzyka. Technika ta polega na porównaniu wszystkich
zidentyfikowanych ryzyk z zawartością macierzy.
I tak dla przykładu, jeśli uznamy, że prawdopodobieństwo zmaterializowania
się ryzyka jest śladowe, ale ma krytyczny wpływ na działanie systemu to ocenimy
je jako wysokie, mimo że może prawie w ogóle nie wystąpić.
Drugim sposobem jest określenie poziomu ryzyka. Tu należy
wykorzystać znienawidzoną w liceum regułę mnożenia (kombinatoryka i prawdopodobieństwo
jest jednym z najbardziej nielubianych
działów w LO- sprawdzone na kilkudziesięciu licealistach 😉
).
Należy sprawdzić co jest bardziej niepożądane 70 % szans
wystąpienie ryzyka o skutkach np.: 1/16 czy 10% szans wystąpienia ryzyka o
skutkach ¾.
Przykładowa tabela:
Jak już wiemy jakie ryzyka w jakim stopniu mogą zagrozić
naszemu systemowi musimy wziąć się za działanie 😉
Wg inżynierii wymagań ostatnim krokiem jest Łagodzenie Ryzyka,
natomiast kurs Analiza dla Specjalistów z bloga IT wyróżnia jeszcze dwa, Ocenę Ryzyka i Zarządzanie Ryzykiem. I do tego podejścia jest mi troszkę bliżej. Dlaczego
? bo praca z ryzkiem nie opiera się tylko na jego łagodzeniu, można przecież stwierdzić,
że nic nie będziemy robić z zidentyfikowanym ryzykiem, warto tylko przygotować sobie
w takiej sytuacji jakiś plan awaryjny lub dodatkowy budżet na ewentualne skutki
zmaterializowania się danego zagrożenia, można też podbijać ryzyko w nadziei na
większe korzyści biznesowe.
Prócz tych dwóch technik „obsługi” ryzyka można wyróżnić
Dzielenie/Przenoszenie – czyli przerzucenie części odpowiedzialności na inne
barki oraz Redukcję. Redukcja mówi o usunięciu czynnika powodującego zagrożenie.
Na sam koniec musimy jakoś zarządzić tym naszym ryzykiem.
Prawdopodobnie powstanie dokument, w którym wszystko zostanie pięknie opisane i
warto dbać o ten produkt. Niech nie leży nieużywany pod stertą innych nikomu
niepotrzebnych złogów makulatury 😉 Warto przeglądać te ryzyka, weryfikować czy już
nie występują, jeśli tak jest to można je zamknąć i spróbować przygotować sobie
zbiór zagrożeń, które mogą się powtarzać. Będzie to duża pomoc przy kolejnych
projektach. Należy pamiętać, że mimo różnorodności branży dla których tworzone
są systemy informatyczne jest pula ryzyk, które będą się powtarzać w każdym,
wiec warto korzystać z wiedzy, którą zdobyliśmy przy okazji jednego z
projektów.
Literatura:
[1] Analityk systemów
Przygotowanie do egzaminu z inżynierii wymagań
[2] Kurs Specjalistów
Analizy
Komentarze
Prześlij komentarz