Wprowadzenie

Na LinkedIn rozgorzało kilka dyskusji na temat ról w projektach na etapie zawierania umowy i trakcie jej realizacji (tu jedna z nich). Cały czas jednak moim celem jest szukanie przyczyn poniższego stanu rzeczy:

Jak widać, ponad 90% projektów średnich i większych, to projekty problematyczne (w tym ok. w ćwierci to projekty zarzucone przed ukończeniem). Projekty problematyczne to przekroczony budżet i niedotrzymany termin. Standardową przyczyną przerwania prac jest wyczerpanie planowanego (dostępnego) budżetu .

Nieskromnie napiszę, że od lat jestem w zielonej kolumnie. Bywam też biegłym i ekspertem audytującym dokumenty projektowe, więc podzielę się zdobytą wiedzą i doświadczeniem.

Projekt czyli co?

Jednym z najczęściej przytaczanych opisów projektów jest tak zwany trójkąt projektowy zwany także “żelaznym trójkątem”:

Powyżej cytowany autor pisze:

Zakres projektu. Element zakresu trójkąta odnosi się do rozmiaru realizowanego projektu. Rozmiar jest mierzony pod względem jakości projektu, złożoności, ilości lub wielkości produktu(ów), szczegółowości, liczby funkcji i pojemności produktu(ów) (takich jak liczba użytkowników, których może obsługiwać oprogramowanie). Niezarządzany i niezamierzony rozrost zakresu (pełzanie zakresu) – negatywny wzrost wymagań projektu – musi być unikany, aby utrzymać koszty i czas projektu pod kontrolą.

https://www.forbes.com/advisor/business/project-management-triangle/

Pełzanie zakresu:

…ma miejsce, gdy wymagania dotyczące ukończenia projektu wykraczają poza planowane wymagania projektu. W takim przypadku istnieje ryzyko, że projekt zostanie ukończony z opóźnieniem, przekroczy budżet i będzie niskiej jakości.

https://www.forbes.com/advisor/business/scope-creep/

Jak widać problemem w zarządzaniu projektami jest tak na prawdę zarządzanie zakresem projektu.

Pełzający zakres projektu

Tak więc kluczem jest zakres projektu, czyli to jaką prace (ile) należy wykonać, bo to determinuje jej koszt i czas trwania. Tak więc kolejność powstawania kolejnych wierzchołków tego trójką to kolejno:

1. zakres czyli to co ma powstać,
2. harmonogram dostarczania produktów projektu,
3. wycena realizacji to konsekwencja czasu trwania (koszt pracy jest głównym kosztem większości projektów, zakup licencji nie jest projektem a zakupem).

Jakość projektu mierzymy porównując wartości planowane do wartości rzeczywistych.

Skupimy się więc na tym czym jest zakres.

Nadal wiele projektów jest realizowanych metodą JAD lub pokrewnymi metodami:

Czym jest wspólne tworzenie aplikacji (JAD, Joint Application Development)?
Wspólne tworzenie aplikacji, często skracane do JAD, to metodologia, która angażuje klienta lub użytkownika końcowego w projektowanie i rozwój aplikacji poprzez szereg wspólnych warsztatów zwanych sesjami JAD. Jej celem jest zaangażowanie klienta (lub użytkownika końcowego) w definiowanie potrzeb biznesowych i opracowanie rozwiązania opartego na tych potrzebach. […]

Chuck Morris i Tony Crawford, obaj z IBM, opracowali JAD pod koniec lat 70-tych. Ich celem było znalezienie sposobu na przyspieszenie zbierania wymagań dla systemów rozproszonych geograficznie. Morris i Crawford rozpoczęli nauczanie podejścia JAD poprzez warsztaty w 1980 roku. W mniej niż 10 lat wiele firm z różnych branż przyjęło JAD i wdrożyło warsztaty ułatwiające zbieranie wymagań, analizę i projektowanie produktów.

https://www.techtarget.com/searchsoftwarequality/definition/JAD

Co to oznacza w praktyce? Narysujmy to:

Sponsor projektu ma swoje cele: cele biznesowe. Są to z reguły określone wskaźniki mierzące efektywność firmy, organizacji czy urzędu. Np. poprawa terminowości realizacji projektów czy wydawania decyzji administracyjnych, obniżenie liczby reklamacji, obniżenie kosztów ofertowania czy produkcji itp.

Sponsor podpisuje umowę z Deweloperem, który w umowie ma wpisane zbieranie wymagań i wytworzenie aplikacji. Wymagania przesyłają (przekazują na warsztatach) pracownicy, przyszli użytkownicy tego oprogramowania. Deweloper, zgodnie z najczęściej zawieraną umową, pracuje nad implementacją otrzymanych wymagań i wystawia faktury za raportowaną pracochłonność. Kierownik Projektu to tu standardowo pracownik Dewelopera koordynujący cały ten proces. Milczące założenie: user wie co ma ostatecznie powstać…

Co widzimy na diagramie? Sponsor nie ma żadnego wpływu na wymagania ale opłaca faktury. Użytkownicy, nie będąc sponsorem (wydatki na projekt są poza zakresem ich odpowiedzialności) zgłaszają kolejne wymagania, Deweloper je przyjmuje do realizacji, użytkownicy “dostają to co chcą” i mają kolejne wymagania. To jest pętla dodatniego sprzężenia zwrotnego: potrzeby wyrażane przez użytkowników napędzają pracochłonność (przychody) dewelopera, który spełniając potrzeby użytkowników napędza ich zgłaszanie.

W efekcie Sponsor dostaje strumień faktur i biernie obserwuje efekty uzyskiwane jako firma. Nad tym procesem praktycznie nikt nie panuje poza topniejącym budżetem, który po wyczerpaniu powoduje wstrzymanie projektu.

nieco później, po JAD:

Szybkie tworzenie aplikacji (RAD, ang. Rapid Application Development) jest odmianą JAD. Opracowane w 1991 roku podejście pomaga tworzyć aplikacje szybciej niż starsze metody rozwoju, takie jak model kaskadowy. RAD wykorzystuje mniej formalnych metodologii i koncentruje się na ponownym wykorzystaniu komponentów oprogramowania. Wykorzystuje również strategie takie jak prototypowanie, iteracyjny rozwój i timeboxing.

https://www.techtarget.com/searchsoftwarequality/definition/JAD

Co to oznacza? Prototypowanie to nie tylko kodowanie, to przede wszystkim modelowanie, czyli testowanie pomysłów na modelach systemu a nie na realnym systemie. Efekt? Dochodzenie do “właściwej wersji” szybciej i taniej. Ten proces także jest jednak pętlą tak jak wyżej. Zaletą jest użycie modeli i gotowych komponentów (w tym czasie, połowa lat 90-tych, powstał też UML jako zunifikowana notacja).

Niestety metody te nie sprawdzają się: “268% Higher Failure Rates for Agile Software Projects, Study Finds” .

Czy mamy lekarstwo?

Model-based System Engineering czyli MBSE (inżynieria systemów zorientowana na modele):

Inżynieria systemów oparta na modelach (MBSE) to sformalizowana metodologia wykorzystywana do wspierania wymagań, projektowania, analizy, weryfikacji i walidacji związanych z rozwojem złożonych systemów. W przeciwieństwie do inżynierii skoncentrowanej na dokumentach, MBSE stawia modele w centrum projektowania systemu.

Kluczowe są tu etapy: zbieranie i analiza wymagań, projektowania, weryfikacji i walidacji związanych z rozwojem złożonych systemów (patrz artykuł o V-model). Projekt realizowany tą metodą zakłada zbieranie wymagań ale na ich podstawie początkowo powstaje model rozwiązania, a nie od razu próba jego zbudowania. Na bazie modelu oceniana jest jego wykonywalność, a Sponsor pierwszy dostaje Raport na ten temat. Jak tylko powstający model (już na etapie HLD, High-level Design, ang. Architektura Wysokiego Poziomu) pozwoli nawet na wstępną wycenę, angażowany jest Deweloper. Od tego momentu mamy także pętlę, jednak tu jest ona nadzorowana przez sponsora, w jego imieniu działa projektant, który raportuje do sponsora:

W tej wersji zakres projektu jest w 100% pod nadzorem, a pętla dodatniego sprzężenia (pełzający zakres) jest przerwana rolą projektanta, który nadzoruje zarówno treść wymagań jako i zakres prac dewelopera: deweloper nie jest tu projektantem.

Jeżeli architektura jest monolitem (np. system ma jedną centralna bazę RDBMS/SQL), będzie to klasyczny kaskadowy projekt. Jednak jeżeli architektura HLD jest komponentowa (obiektowy paradygmat, wzorce projektowe Saga, mikroaplikacje/mikroserwisy) projekt jest realizowany iteracyjnie -przyrostowo w pętli SDLC (V-model).

Tu pętla zawiera rolę projektanta, który reprezentuje interes sponsora projektu. Sponsor na bieżąco jest informowany o wymaganiach i planowanych kosztach ich realizacji: deweloper dostaje model kolejnego elementu systemu, opracowuje koncepcję i koszt implementacji, po jej akceptacji realizuje kolejny etap projektu (tej linii nie ma diagramie).

Dodatkowo Model Logiki Systemu jest w czasie rzeczywistym realną dokumentacją działającego systemu (patrz artykuł Wymagania umarły, liczy się cykl życia systemu). Do tej dokumentacji od samego początku prawa ma Sponsor projektu, więc – niejako z automatu – autorskie prawa majątkowe są po stronie Sponsora.

Negocjacje czyli podsumowanie

Kto i co negocjuje w projekcie? Z perspektywy ról w projekcie mamy:

Na powyższym diagramie pokazano kluczowe role (interesariusze) w projekcie:

• Sponsor projektu: ma wymagania na poziomie celu projektu.
• Kierownik projektu sponsora: zarządza projektem osiągnięcia celów biznesowych, angażuje projektanta.
• Projektant: na bazie wymagań (jakie usługi i jak ma realizować aplikacja) projektuje System Informatyczny (jego logikę biznesową).
• Deweloper, na zlecenia Kierownika projektu biznesowego implementuje Projekt Systemu, Projektant systemu sprawuje nadzór autorski i raportuje do Sponsora (do lub Kierownika projektu biznesowego, który go reprezentuje) wszelkie ingerencje w projekt Systemu.

Warto zaznaczyć, że w projektach skupionych na wdrożeniu oprogramowania Kierownik Projektu Sponsora jest często pomijany, sponsor angażuje jedynie Projektanta, bo w tym przypadku po stronie Zamawiającego wymagany jest wyłącznie nadzór merytoryczny nad pracami Dewelopera a nie zarządzanie nimi.

To ogólny schemat, realizacji projektu w duchu MBSE. Z perspektywy kierownika projektu może on to realizować metodyką PMI czy Price2, nie ma to wpływu na ideę MBSE. MBSE to jedynie inna forma dokumentowania (specyfikowania) systemu (modele a nie opisy) w pętli SDLC zarządzania jakością.

Gdzie tu negocjacje z deweloperami? W zasadzie są realizowane dwa razy:

1. Na bazie Projektu systemu Deweloper składa ofertę, która zawiera harmonogram i koszt (zakresem jest Projekt Systemu wyrażony jako jego model), tu uzgadniana jest ostateczne wersja projektu i oferty jego realizacji (koncepcja implementacji i wdrożenia, która opracowuje Dostawca).
2. Przyjęcie oferty oznacza zawarcie umowy, tu negocjuje się kwestie cywilno-prawne, kary umowne, kwestie praw autorskich, itp.

Jak widać, kluczem jest określenie ról i ich odpowiedzialności. Praktyka pokazuje, że nie tu powstaje “jeden zespół złożony z userów i koderów” (patrz JAD). W projektach tego typu ściśle separuje się rolę dostawcy od odbiorcy oprogramowania, a współpraca ról to asynchroniczna komunikacja pisemna. Spotkania razem mają wyłącznie charakter podsumowań.

Każda rola ma do stworzenia jedną rzecz, dokument. Nie dopuszcza się tu do zbiorowej odpowiedzialności. Każdy dokument ma jednego znanego autora. Ważna rzecz: wyznaczyć w projekcie (zakres i harmonogram) ścisłą granicę między dostarczeniem rozwiązania a jego dalszym utrzymaniem i rozwojem (patrz continuous delivery). .

Źródła