Zarządzanie ryzykiem to proza życia kierowników projektów. Z jednej strony doświadczony kierownik projektu powinien doskonale radzić sobie z ryzykiem, z drugiej zaś strony praktyka projektów pokazuje, że efekty są niestety słabe bo ok. 90% IT na świecie ma przekrocozne budżety i terminy .
Jednym z ciekawszych narzędzi zarządzania ryzykiem jest mało popularny tak zwany stożek niepewności. Ogólna zasada planowania mówi, że im bardziej w przyszłość wybiegają prognozy tym bardziej są one niepewne. Jest nie tylko intuicyjne ale i udowodnione matematycznie. Stożek niepewności to wykres pokazujący związek pomiędzy kosztami projektu a posiadaną wiedzą na etapie inicjacji projektu np. implementacji (dostarczenia) oprogramowania. Poniżej jeden z przykładów jego zobrazowania:
Stożek ten (stożek niepewności) to narzędzie empiryczne (!), obrazuje spodziewane konsekwencje jakimi są koszty, generowane przez niepewność (przedwczesne, nieudane prototypy, wprowadzanie zmian po przedwczesnym rozpoczęciu prac implementacyjnych i wdrożeniowych, itp.).
Na powyższym wykresie, czerwona linia obrazuje koszty etapu prac bez analiz i projektowania (agile) a zielona koszty prac poprzedzonych analizami i projektowaniem. Linie te spotykają w punkcie, w którym wiedza o ostatecznej wersji produktu jest już taka sama. Punkty oznaczone “diamentem” to kamienie milowe projektu. Wartość kosztu odniesienia 1.0 to sytuacja, w której w momencie rozpoczęcia projektu nie byłoby żadnych niewiadomych (ryzyko zakresu projektu = zero). Całkowity koszt projektu to pola pod krzywymi (pomiędzy daną krzywą a poziomem zero lewej osi). Praktyka pokazuje więc, że brak planowania i projektowania podnosi koszty projektu średnio czterokrotnie.
W przypadku aplikacji będącej monolitem wykres reprezentuje cały projekt (“water fall”, metoda wodospadowa), czyli projekt trwający nie raz kilka lat. Prawdopodobieństwo, że realizacja detalicznie zaplanowanego np. na 5 lat projektu będzie wymagała korekty planów lub wprowadzania zmian do projektu, graniczy obecnie z pewnością:
W przypadku zastosowania metod obiektowych, zorientowanych na komponenty/mikroserwisy, wykres Stożek niepewności reprezentuje dostarczenie jednej usługi aplikacyjnej (przypadek użycia, implementowanej jako komponent, patrz także iteracyjno-przyrostowe dostarczanie oprogramowania jako kolejnych usług aplikacyjnych, MVP: Minimum Value Product). Implementacja jednej takiej usługi z reguły mieści się w jednym kwartale. W efekcie praktycznie eliminujemy skutki niepewności, planując realizację projektu tak, by żadne plany nie wybiegały zbyt daleko w przyszłość (z reguły granica jest rok budżetowy). Jest to możliwe dzięki odejściu od monolitycznej architektury aplikacji. Realizacja projektu wytwarzania aplikacji o komponentowej (np. mikroserwisy) architekturze wygląda jak poniżej:
Warto tu zwrócić uwagę, że aplikacje zbudowane w oparciu o jedną i centralną bazę danych w modelu relacyjnym (RDBMS) są właśnie typowymi monolitami, np. większość powszechnie znanych dużych systemów ERP. Duże systemy relacyjnych baz danych są z tego powodu od dawna krytykowane:
W tym przypadku oferty (obietnice) dostawców tego typu systemów (monolity) to zielona linia na diagramie Stożek niepewności, a faktyczne koszty tych wdrożeń, polegające na bieżącej, prowadzonej ad-hoc adaptacji, to linia czerwona, co potwierdzają statystyki .
