Przejdź do głównej zawartości

"Nie musisz zarządzać ryzykiem. Przetrwanie nie jest obowiązkowe!"

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

Popularne posty z tego bloga

Jak Pani przeprowadza analizę? Pytania rekrutacyjne na Analityka Biznesowego

Na moim ulubionym  blogu o analizie znajduje się post z 99 pytaniami, które mogą pojawić się na rozmowie kwalifikacyjnej na stanowisko analityka biznesowo/systemowego. Przejdź do pytań   Od dziś będę opracowywać pytania znajdujące się na tej liście, co w konsekwencji pozwoli mi na sporządzenie obszernego materiału, który ułatwi przygotowanie się do skomplikowanego procesu rekrutacyjnego.   Oczywiście zdaje sobie sprawę z tego, że ile firm tyle różnych procesów i pytań kwalifikacyjnych, ale zagadnienia znajdujące się na liście „99 pytań” są na tyle uniwersalne, że można z dużym prawdopodobieństwem założyć, że część z nich zostanie użyta w trakcie rozmów wstępnych. No to lecimy :) pytanie na dziś to     Jak Pani przeprowadza analizę? Pierwsze co mi się nasunęło na myśl: „ To zależy ” 😉 , ale żeby na tym nie kończyć, to może napiszę od czego to tak naprawdę zależy. Ostatnio miałam przyjemność być na warsztatach Przewodnik po analizie dla zdezorientowanych- J

Jakie znasz rodzaje diagramów UML – lista 99

Dziś post krótki ale treściwy! Takie podobno cieszą się największym zainteresowaniem 😊 Jakie Pani zna rodzaje diagramów UML ? No i może ktoś się zdziwi, ale wszystkich diagramów UML jest 13 😉 ale oczywiście korzystanie ze wszystkich na raz często mija się z celem, bo projekt np.: nie zakładał tworzenia diagramu rozlokowania, albo wymagane były tylko diagramy przypadków użycia, klas i sekwencji.  Ale ! ale! ale ! to nie jest do końca tak, że jak czegoś na co dzień nie używamy to jest nieistotne i mało ważne.   Bo jeśli np.: okaże się, że w ramach dokumentacji ma powstać jakiś „rysunek” obrazujący relacje pomiędzy odpowiednimi częściami systemu to nie zaczniemy tworzyć nowego typu diagramu tylko skorzystamy z diagramu Struktur Połączonych (bo na kiego grzyba koło na nowo wymyślać). A dlaczego z niego skorzystamy ? bo wiemy, że istnieje i do tego właśnie powinien zostać użyty. A gdybyśmy o nim nigdy nie słyszeli to prawdopodobnie tworzylibyśmy nowe, nikomu

User Stories i Przypadki Użycia na liście 99

Dziś połączymy odpowiedź do trzech pytań z listy 99 😊 Proszę napisać wymganie w formie user stories.  Proszę zapisać wymaganie w formie przypadku użycia. Czym są sytuacje wyjątkowe w opisie przypadków użycia ? No to może zanim zabierzemy się za konkretną odpowiedź, musimy wiedzieć (chociaż tak pokrótce), czym jest User Stories , a czym Use Case . User Stories (US) – inaczej historyjki użytkownika (po angielsku zawsze lepiej to brzmi), są krótką notatką z konwersacji/wywiadu na temat działania systemu. Dzięki User Stories doprecyzowujemy wymagania z rozmowy z klientem. Tylko pamiętajmy, że nie są one po to, aby szukać winnych w razie ewentualnych niedomówień i nie powinny stanowić dowodów w „kwitach” na naszych klientów 😉. [2] User Stories mają w sposób syntetyczny opisywać warunki, jakie powinny zostać spełnione z perspektywy użytkownika i cel, w jakim ta funkcja ma zostać przygotowana.  (definicję tę znalazłam w kursie Specjalistów Analizy )[3]. Ważne jest to,