Pół roku temu artykuł o roli Product Ownera kończyłem słowami:
Tak więc nasuwa się wniosek, że rolę PO powinien pełnić ten człowiek, który właśnie skończył analizę biznesową i napisał raport z niej. Raport, który zawiera specyfikacją wymagań (najlepiej w formie jak opisana powyżej). W zasadzie nadzór autorski nad realizacją taktyki wdrożenia systemu ERP (oprogramowania w ogóle) to nic innego jak ?bycie product ownerem? w projekcie na etapie jego realizacji a SCRUM faktycznie, na dzisiejsze czasy, wydaje się być najlepszą metodą zarządzania takimi projektami a utrzymywanie aktualności dokumentu analizy biznesowej i wymagań w toku projektu prowadzi do tego, że po zakończeniu projektu mamy ?niechcący? kompletną i aktualną dokumentacje stanu uzyskanego w toku wdrożenia. (Źródło: Kim jest product owner? | Jarosław Żeliński IT-Consulting)
Dzisiaj kilka słów na temat kwestii finansowych, to jest porównania kosztów projektu z “tradycyjną” analizą wymagań i analizą “zwinną”. Dotyczy przede wszystkim podejścia do wdrożeń systemów ERP. Dwa lata temu pisałem:
Zarządzanie zmianą wymagań. To kolejne niechciane dziecko w projektach. Jeżeli zgodzimy się, że zmiana wymagań jest ?normą? to brak wiedzy (zapisów) o tych zmianach potrafi zabić projekt. Problem, który ja widzę w wielu projektach to: im łatwiej zgłosić i egzekwować zmianę w wymaganiach tym więcej tych zmian jest. Nie chodzi o to by tych zmian zakazywać, chodzi o to by były one za każdym razem przemyślane, a chodzi głównie o wpływ zmian na termin i budżet projektu. (Źródło: Zarządzanie wymaganiami | Jarosław Żeliński IT-Consulting)
Mam za sobą dwa projekty, które pokazały, że należy szukać rozwiązania problemu “niewiedzy” o przyszłości, jaką mamy w czasie gdy projektujemy rozwiązanie. W tych dwóch projektach wdrożyłem nowe podejście, które się doskonale sprawdza (ćwiczę to w kolejnych). Powodem było to, że obie firmy (moi klienci) chciały jak najszybciej rozpocząć prace nad projektem wdrożeniowym by nie opóźniać momentu zastąpienia starego systemu nowym. Obie firmy miały za sobą porażki poprzedniego wdrożenia, które pokazały, że rozpoczynanie projektu od wyboru produktu i jego dostawcy rodzi ogromne ryzyko zarówno przepłacenia za analizę wymagań (przed-wdrożeniową u dostawcy) jak i utraty panowania nad zakresem własnego projektu, bo od podpisania umowy z dostawcą zarządzał on zakresem jako autor analizy wymagań.
Niedawno napisałem o tym, że warto mieć model architektury biznesowej, która:
…staje się standardem w dobrze zarządzanych firmach, kontynuujących aktualizację dokumentacji powstałej na etapie analizy biznesowej jako nadzoru autorskiego w toku projektu wdrożeniowego. Powoli przybywa także firm, widzących powyższe korzyści w bieżącym zarządzaniu, dostrzegają także to, że posiadanie aktualnej Architektury Biznesowej jest efektywniejsze niż zlecane ?z doskoku? analizy biznesowe i analizy przedwdrożeniowe. (Źródło: Architektura Biznesowa jako wartość dodana firmy | Jarosław Żeliński IT-Consulting)
W czym problem?
W kosztach i czasie trwania tego co nazywamy analizą biznesową kończąca się specyfikacją wymagań oraz kosztach aktualizacji specyfikacji wymagań.
W ogromnej części projektów, to co było opisane jako wymagania nie ma nic wspólnego z tym co w końcu faktycznie powstało i zostało oddane do użytku. Oznacza to, że powstanie tych specyfikacji wymagań w ich ówczesnej postaci, nie miały żadnego sensu…
Najczęściej spotykane “typowe” podejście do wymagań polega na tym, że analiza wymagań bazująca na wielodniowych warsztatach obfitujących w zapisywane szczegóły, kończy się detaliczną, obszerną Specyfikacją Wymagań na system ERP (systemy dedykowane także cierpią na tę chorobę), która staje się załącznikiem do umowy na wdrożenie, dostawca zaś restrykcyjnie realizuje tak spisane wymagania, w toku projektu nie raz zamawiający żąda zmiany, jeżeli okaże się, że zmieniły się realia. Bardzo często proponuje wykonawca z powodu trudności na jakie napotyka. Biorąc pod uwagę także zmiany na rynku, tych zmian jest w projektach relatywnie dużo. Bardzo często zwolennicy agile mówią: skoro te wymagania się zmieniają a klient i tak nie wie czego chce to nie róbmy żadnej dokumentacji, róbmy często spotkania i notatki z nich. To jest jednak jeszcze gorsze, bo rozpoczynając projekt nikt nie wie co powstanie, zakres projektu to chaos, więc nikt nie wyceni tego, a biznes dąży jednak do umów o planowanych budżetach, czyli fixed-price. Kwadratura koła?
Nie. Można, zamiast szczegółowo spisywać (zbierać w ramach wywiadów i warsztatów) wymagania, skupić się na architekturze i logice biznesowej oraz jej odwzorowaniu w systemie ERP.
Na powyższym diagramie pokazano (linia obrazuje koszty narastająco, koszty uwzględniają także zaangażowanie pracowników zamawiającego):
- linia czerwona: najpierw opracowanie szczegółowej specyfikacji wymagań, po rozpoczęciu realizacji, w toku projektu, każda wymagana zmiana w stosunku do stanu z czasu powstania specyfikacji (lub od ostatniej aktualizacji), wymaga refaktoryzacji dokumentu specyfikacji (aktualizacji wymagań, kolejna linia wzrostowa),
- linia zielona, na początku zamiast szczegółowej specyfikacji, powstaje model biznesowy i tylko architektura przyszłego rozwiązania (trwa to krócej i jest tańsze), szczegóły wymagań ustalane są na bieżąco (linia kosztów stale rośnie jednak znacznie wolniej), robi to Product Owner reprezentujący zamawiającego (zakres projektu powinien być zarządzany przez kupującego); jednak architektura i logika biznesowa pozostają praktycznie niezmienne bo stanowią fundament całego systemu.
Co ciekawe wymagania jako architektura i lista reguł i usług biznesowych, pozwalają dostawcy na wycenę, opracuje on “koncepcje wdrożenia”. Całkowity nakład pracy i koszty po stronie kupującego poświęcone na prace analityczno-projektowe są łącznie znacznie niższe. W wersji “czerwonej” dostawca przejmuje zarządzanie wymaganiami od analityka po zakończeniu pierwotnej analizy (w dniu podpisania umowy). W wersji zielonej zakres projektu cały czas ma w ręku zamawiający, reprezentuje go merytorycznie analityk, który najpierw opracowuje analizę a potem sprawuje nadzór autorski (jako [[product owner]]). Komunikacja polega na uzupełnianiu specyfikacji o kolejne szczegóły, w miarę jak są one potrzebne firmie wdrażającej (realizator żąda tych szczegółów porcjami w toku projektu). Żadne prace nad specyfikacją nie idą na marne (niższe koszty).
Porównanie tradycyjnej zwinnej metody tworzenia wymagań i zarządzania nimi:
A tu procedura zarządzania zmianą:
Zmiany może zgłaszać zarówno Wykonawca jak i Zamawiający, a zgłasza je właśnie do Product Ownera, który ocenia ich wpływ na całość i referuje skutki Zamawiającemu, ten – po analizie – akceptuje lub odrzuca propozycję.
P.S.
Polecam świetny artykuł Pana Mecenasa Łukasza Węgrzyna na temat tego jak to zawrzeć w umowie.
