Budujemy samochód #1 – model wodospadu

Model wodospadu (ang. Waterfall) jest najczęściej stosowanym podejściem prowadzenia projektów w branży IT. W skrócie polega on na podzieleniu projektu na fazy, do których dołączamy dane wejściowe i opisujemy półprodukt końcowy (np. analiza, implementacja, testy, wdrożenie). Na koniec otrzymujemy oczywiście gotowy produkt.

Powyższy opis wygląda całkiem nieźle. Mamy dobrze opisany proces — wiemy, czego i kiedy się spodziewać. Z drugiej strony często można usłyszeć o nietrafionych albo niedokończonych inwestycjach. Jeśli na myśl przychodzą Ci zamówienia publiczne – brawo! To najlepszy przykład, że zamiast o rozwoju, mówimy o marnotrawieniu pieniędzy.

Prawda jest taka, że (poza kilkoma wyjątkami) zazwyczaj takie przedsięwzięcia wydają się całkiem niezłe na papierze. Nie przypominam sobie sytuacji, w której czytając SOPZ, byłem krytycznie nastawiony do samego projektu. Co takiego zatem dzieje się w trakcie, że z całkiem sensownej dokumentacji wychodzi coś tego sensu pozbawione?

W ramach pobudzenia umysłów prześledzimy dzisiaj ten proces. Mianowicie, zajmiemy się zaprojektowaniem i zbudowaniem samochodu marzeń. Nie bez powodu wybrałem taki projekt – większość z nas ma wyobrażenia dotyczące idealnego modelu, parametrów, czy wyglądu. Mój pewnie byłby czerwony, sportowy i wyjątkowo szybki.

Aktorzy

W naszej historii (oczywiście w uproszczeniu w stosunku do rzeczywistości) wystąpią:

• Product owner – pewnego dnia Ty i ja, a dzisiaj osoba, która wyda za chwilę pieniądze, oczekuje samochodu marzeń i nie może doczekać się wyniku,
• Project manager – głównodowodzący po stronie wykonawcy realizującego projekt, odpowiedzialny za wyniki, najbardziej zapracowana osoba w firmie – nikt nie wie, czy w ogóle jeszcze sypia,
• Senior designer – najkrócej mówiąc “fachowiec”, osoba (częściej zespół), która fizycznie realizuje Twój projekt,
• Asystent – jakikolwiek projekt bez asystenta? Serio?

Akt pierwszy – przygotowania do zakupu

Projekt waterfallowy i specyfikacja to elementy niemal nieodłączne – po prostu musi być. Najczęściej „obecność” jest definiowana zupełnie inaczej przez analityków i klienta. Różnica wyrażona w rozmiarze dokumentu koniecznego do określenia kosztorysu często sięga kilku tysięcy procent.

Na potrzeby dzisiejszych rozważań możemy uznać, że specyfikacja jest, a główny cel projektu można opisać trzema punktami:

• czerwony kolor,
• sportowe nadwozie,
• od 0 do 100km/h w 3s.

Kolejnym naturalnym krokiem jest wybór firmy wdrożeniowej. Czas poświęcony na ten etap jest najczęściej proporcjonalny do rozmiaru inwestycji. Będziesz przeglądał realizacje, wyliczał współczynnik cena/jakość, określał ryzyka, etc. To też czas wysłuchiwania prezentacji przygotowanych przez business developerów i zbierania ofert. W tym procesie najczęściej uczestniczę, będąc po drugiej stronie.

Właściwy bieg projektu rozpoczyna się po podpisaniu kontraktu. W metodzie waterfallowej kontrakt powinien być przygotowany w myśl zasady „co, na kiedy, za ile”, czyli powinien się składać przynajmniej z:

• specyfikacji (jako kryterium odbioru),
• terminu realizacji (często podzielony na etapy),
• budżetu.

Na tak przygotowanym dokumencie (często naprawdę opasłym) brakuje tylko Twojego podpisu. Akt podsumujemy stanowczym uściskiem dłoni – czas zabrać się do pracy.

Akt drugi – realizacja projektu

O ile w pierwszej części główna narracja przebiegała po Twojej stronie, czas realizacji najczęściej określany jest mianem “czasu dla nas”.

Nie jest moją intencją opisywanie procesu produkcji, tym bardziej że każdy projekt wymaga pewnych adaptacji utartych praktyk. Odnosząc się jednak do samego kontraktu:

• dział techniczny realizuje zakres,
• project manager pilnuje budżetu,
• testerzy dbają o jakość i spójność ze specyfikacją.

Warto podkreślić, że nie masz zbyt dużego wpływu na proces produkcji. Powinieneś za to spodziewać się gotowego produktu, w takim terminie i za tyle, ile widnieje w kontrakcie. Jest w tym wszystkim trochę uogólnienia (bo na przykład kontrakt może przewidywać etapy), ale najważniejsze jest to, że podczas realizacji możesz nie mieć żadnego wpływu na zakres projektu.

Przyspieszymy nieco historię aż do samego momentu zakończenia prac i prezentacji.

Akt trzeci – czasami rzeczy wyglądają dobrze tylko na papierze

Dochodzimy do najbardziej ekscytującego momentu – przekazania końcowego produktu. Spróbuj wczuć się w sytuację. Za chwilę odbierzesz swój samochód marzeń. To naprawdę ważny moment. Jakie może być Twoje zdziwienie, gdy zobaczysz następujący efekt:

śli powyższa grafika budzi jakiekolwiek wątpliwości – tak, firma właśnie strzela Twoim samochodem z armaty. Nie ma tu pola na interpretację, jest huk, dużo dymu i samochód, który osiąga 100 km/h bardzo szybko, ale za to w najbardziej idiotyczny z możliwych sposobów.

Nie wygląda to dobrze. Ostatecznie przecież wszystko się zgadza z dokumentacją, kluczowe punkty zakresu zostały spełnione. Jednak zostajesz z produktem, któremu brakuje jednej bardzo kluczowej cechy, o której jeszcze w tym artykule nie mówiłem:

Wartość

To właśnie dostarczona wartość stanowi o sukcesie, bądź porażce dowolnego projektu. W zależności od tego, co robimy, wartość przyjmuje zupełnie różne wymiary – monetarną, praktyczną, estetyczną, etc.

Powyższy przykład jest książkowym zaprzeczeniem praktycznej wartości projektu. Nie trzeba wyjaśniać – samochód odpalany w tak wybuchowy sposób nie dowiezie Cię zbyt daleko.

Akt 4 – retrospekcja

Podczas pisania tego artykułu zostałem dwukrotnie posądzony o dowodzenie przez skrajność. Rzeczywiście, wykreowany scenariusz pewnie nigdy się nikomu nie wydarzy, ale analogiczne sytuacje w projektach IT spotykam na co dzień:

• formularz jest brzydki,
• kontrolki są nieużyteczne,
• nikt nie wspomniał, że po zakończeniu synchronizacji powinna zostać wysłana wiadomość e-mail.

Przykłady można mnożyć, szczególnie w projektach innowacyjnych (a takim powinno być wdrożenie platformy e-Commerce).

Czyja to wina?

W sytuacjach takich jak ta, zawsze przychodzi czas rozliczenia z winy. Najczęściej trzeba coś zrobić jeszcze raz, w ramach tego samego budżetu. Na przykładzie zamówień publicznych, gdzie cena „puka od dołu” to jest być albo nie być dla (i tak często skromnego) zysku wykonawcy.

Ja odpowiem na zadane pytanie zupełnie inaczej – to, czyja to jest wina, nie ma żadnego znaczenia. To, co ma znaczenie, to fakt, że nadal nie masz tego, czego potrzebujesz.

Tak naprawdę co to za różnica, kto zawinił? W ostateczności rozstrzygnięcie tego sporu może trwać kilkukrotnie dłużej niż sam projekt. Nawet jeśli racja z punktu widzenia formalnego będzie po Twojej stronie, to i tak straciłeś mnóstwo czasu, nerwów i – co gorsza – ostatecznie i tak nie masz gwarancji, że dostaniesz coś, co będzie więcej niż tylko “poprawne”.

Cesja odpowiedzialności nie jest remedium na niedostarczoną wartość

W metodzie tradycyjnej prowadzenia projektu zgadzasz się właściwie tylko na zapłacenie pieniędzy za poprawny projekt. Poprawność jest jak najbardziej do zdefiniowania i są sprawdzone praktyki, które z dużym prawdopodobieństwem zapełnią wszystkie potencjalne luki.

Gdybym Ci powiedział, że po roku od rozpoczęcia projektu będziesz patrzył, jak ktoś strzela Twoim samochodem, ale jednocześnie zapewnił Cię, że za te same pieniądze firma naprawi swój błąd, zapłaci karę za przekroczenie terminu, a Ty dostaniesz to, co chciałeś – zgodziłbyś się?

Oczywiście, że nie – nikomu nie są potrzebne emocje związane z drugą lub trzecią szansą. Chcemy, żeby wszystko było takie, jak sobie wymarzymy już za pierwszym razem.

Metoda waterfallowa tego nie gwarantuje. Dlaczego zatem podejmować ryzyko?

Podsumowanie

Projekty realizowane waterfallowo z natury orbitują wokół poprawności produktu. Dostarczona wartość jest jedynie efektem ubocznym, który wcale nie musi wystąpić. I, mimo że ta metoda w branżach usługowych jest szeroko wykorzystywana i potrafi też dawać dobre efekty, warto zastanowić się, zanim założysz się o wartość kontraktu, że projekt zakończy się dla Ciebie sukcesem.

W następnym artykule spróbujemy podejść do zagadnienia inaczej. Ale o tym w kolejnym tekście