Zwinne budżetowanie projektów agile

Ostatecznym koszmarem każdego project managera jest sytuacja, w której jednocześnie przedwcześnie przekraczamy budżet projektu, nie jesteśmy w stanie oddać go w należytym stanie w terminie określonym w umowie, a wykonane funkcjonalności nie odpowiadają potrzebom klienta. Przyczyn takiego smutnego stanu rzeczy może być wiele. Teoretycy i praktycy zarządzania przelali na ten temat wiele atramentu. Znalezienie łatwej i zawsze skutecznej recepty na uniknięcie tej pułapki byłoby wyczynem, który postawiłby mnie w rzędzie tegorocznych kandydatów do Nobla z ekonomii.

Kto utonie w wodospadzie ?

Nie należy jednak tracić nadziei. Przeciwnie – praktyka zarządzania projektami IT w ostatnich dekadach przesunęła się z podejścia typu waterfall, w stronę metodyk zwinnych. Podstawowym założeniem podejścia waterfall jest idea big design up front. W najprostszych słowach chodzi tu o podejście do projektu rodem z tradycyjnych metod pracy architekta lub konstruktora maszyn. Spędzamy wiele czasu na dokładnym zbadaniu wymagań klienta (czy musimy przypominać, że „czas” to tutaj synonim „pieniędzy”?). Następnie analitycy, projektanci i architekci systemów tworzą szczegółowe specyfikacje, których celem jest opisanie projektowanego systemu w każdym, istotnym detalu. Szczegółowy, udokumentowany projekt jest następnie przekazywany do wykonania zespołowi deweloperskiemu, który zamyka się na przysłowiowie cztery spusty na czas potrzebny do dopracowania każdego detalu, i oddaje w ustalonym terminie, zadowolonemu klientowi, swoje lśniące dzieło. W idealnym świecie, lepszym i prostszym od tego, w którym żyjemy, zawsze tak jest.

Baśń o wielkim designie

Doświadczenie pokazuje nam jednak, że opisana sytuacja, jakkolwiek możliwa, będzie raczej wyjątkiem niż regułą, jeśli podejmujemy się realizacji złożonego projektu e-commerce w metodologii waterfall. To nie wina naszych klientów, project managerów, designerów, deweloperów ani technologii, których używamy. Przyczyną jest natura rozwoju i cykli życia projektów w otoczeniu biznesowym. Czy dla decydentów w jakiejkolwiek firmie nazwanie jej statyczną lub nietolerującą zmiany, byłoby komplementem? Oczywiście nie! Nikt nie zaprzeczy, że istotą sprawnego przedsiębiorstwa jest umiejętność dostosowania się do zmieniającej się rzeczywistości rynku, potrzeb klientów i stałe doskonalenie własnych sposobów działania. Dlaczego, wobec tego, systemy e-commerce miałyby być wyjątkiem? Zastygłym, raz zaprojektowanym i statycznym monolitem? Kto z nas ma pełną widzę o tym, jak będzie wyglądał rynek za rok? Czy system zaprojektowany w maju 2016 będzie spełniać dobrze swoje potrzeby w maju 2017 lub 2018? Czy na etapie analizy wymagań projektowania jesteśmy w stanie wystarczająco zmobilizować wszystkie działy i interesariuszy projektu, przekazać im pełną widzę o założeniach oraz celach biznesowych i funkcjonalnych projektu tak, by system powstały za rok spełnił potrzeby wszystkich?
Próba takiego podejścia do realizacji systemu e-commerce jest dziś jednoznaczna z automatycznym wystawieniem projektu na następujące czynniki ryzyka:

  • niekompletne, nietrafne lub nieaktualne w momencie oddania systemu zdefiniowanie potrzeb i oczekiwań na etapie projektowania. Skutek to oddanie klientowi systemu, który nie spełnia rzeczywistych potrzeb.
  • tendencja do przeładowania projektu funkcjami i cechami, których prawdopodobnie realnie nie potrzebujemy, lub nie jesteśmy pewni, czy są na pewno potrzebne w swoim kształcie. Bez próby rzeczywistości nie umiemy tego zweryfikować, więc dla pozornego bezpieczeństwa rozszerzamy zakres projektu.
  • przedwczesne wykorzystanie budżetu przez wykonawcę, związane z trudnością precyzyjnego oszacowania kosztu własnego wykonania prac o bardzo szerokim zakresie, czego skutkiem może być niechęć do kontynuacji nierentownego projektu.

Teamwork makes the dream work

Odpowiedzią na te kłopoty są metodyki zwinne. Są to modele pracy wewnętrznej, ale przede wszystkim współpracy, które kładą nacisk na minimalizację wymienionych czynników ryzyka. Stosując je dążymy przede wszystkim do maksymalnie sprawnego i efektywnego kosztowo dostarczenia na rynek systemu, który od strony swoich funkcjonalności jest tworzony tak, by dawać użytkownikowi maksymalną wartości biznesową. Metodyki zwinne to inaczej podejście agile. Jeśli agile skontrastujemy z waterfall, to big design up front ma swój zwinny odpowiednik w postaci idei emergent design. U podstaw tego pojęcia leży założenie pracy w środowisku, które ewoluuje, uczy i reaguje na zmiany w swoim otoczeniu. Oznacza to w praktyce znaczne przesunięcie akcentów wartości realizowanych przez poszczególne zespoły w toku współpracy. Mamy przy tym na myśli nie jedynie współpracę między klientem a dostawcą, lecz także w ramach zespołu dostawcy oraz, o czym często zapominamy, wewnątrz zespołu w organizacji klienta. Wartości te definiuje tzw. manifest agile, z którego najważniejszy wyimek wygląda tak:

  • Ludzie i interakcje ponad narzędzia i procesy
  • Działające oprogramowanie ponad ekstensywną dokumentację
  • Reagowanie na zmianę ponad realizowanie planu
  • Współpraca z klientem ponad negocjacje umów

Dla celów tego artykułu zajmiemy się tylko ostatnią z tych wytycznych, czyli wątkiem umowy i rozliczenia projektów realizowanych w metodykach zwinnych. „Współpraca z klientem ponad negocjacje umów”. Brzmi to pięknie, jednak umowy są niezbędną ramą prawną współpracy. Nie jesteśmy w stanie zrealizować projektu o wysokiej wartości na zasadzie pracy bezumownej – pomijając oczywisty aspekt, że byłoby to nielegalne. Praca bez formalnej umowy przy realizacji dużych projektów zdarza się w praktyce jedynie w przypadku projektów wewnętrznych, tworzonych na potrzeby własne i własnymi siłami przedsiębiorstwa.

Większość umów w modelu tradycyjnym podkreśla przede wszystkim aspekt karny i dyscyplinujący. Ich celem nie jest z reguły zapewnienie należytej jakości współpracy i końcowego rezultatu, ale uzyskanie przewagi prawnej i narzędzia przymusu finansowego w przypadku braku realizacji interesów jednej ze stron. Umowa jest ostatecznym narzędziem zarządzania ryzykiem projektu. W teorii układające się strony są równe, a treść umowy ma ułatwiać zapewnienie warunków realizacji projektu. Jenak praktyka pokazuje że warunkiem rozpoczęcia współpracy z klientem jest zaakceptowanie przez wykonawcę standardowych warunków umownych, które zazwyczaj stawiają wykonawcę na słabszej pozycji. Pole do negocjacji jest tu niewielkie. Sama idea negocjacji umowy przywodzi na myśl raczej rokowania palestyńsko-izraelskie niż dążenie do wypracowania najlepszych reguł współżycia dla obu stron i sytuacji typu win-win (nie zaś „moja wygrana to twoja przegrana”).

Ryzyko projektowe nie jest jedynym aspektem, który zazwyczaj reguluje umowa między dostawcą i klientem. Równie istotne to sposób wynagradzania dostawcy, zakres projektu i sposób zarządzania nim oraz określenie sposobu prowadzenia współpracy. W praktyce istnieje wiele modeli umowy regulującej współpracę w modelu agile. Rozmaicie rozkładają one między dostawcę a zamawiającego ryzyko projektowe, sposób zarządzania zmianą oraz skutki wcześniejszego lub późniejszego zakończenia projektu. Musimy bowiem pamiętać, że nie jest wykluczona sytuacja, w której wypracujemy produkt o wystarczającej wartości biznesowej niższym kosztem i w krótszym czasie, niż zakładaliśmy.

Należy jednak zwrócić uwagę, że modele agile nie zakładają jako pożądanej sytuacji, w której mielibyśmy wydłużyć czas realizacji projektu, nawet na rzecz realizacji funkcjonalności, której potrzeba pojawiła się w uzasadniony sposób na późnych etapach realizacji projektu. Wytyczne agile sugerują w takiej sytuacji ponowną ocenę istotności i priorytetyzacji elementów projektu. Ich celem jest wtedy zachowanie terminu realizacji projektu, wykonanie nowej, ważnej funkcji, przy jednoczesnym usunięciu z aktualnego zakresu prac innych, mniej istotnych biznesowo elementów. Nie oznacza to porzucenia ich na zawsze, a jedynie przesunięcie do kategorii zadań o niższym priorytecie, których odsunięcie, na rzecz nowej funkcji, per saldo podniesie wartość biznesową systemu w momencie jego uruchomienia.

Money for Nothing, Changes for Free

Specyficzną, bardzo elastyczną kombinacją kilku podejść jest model o nazwie „Money for Nothing, Changes for Free”. Jego bazą jest podejście typu „Time and Materials”, rozszerzone o graniczny, maksymalny koszt projektu. Z założenia jest to jednak naprawdę koszt maksymalny, którego w normalnych warunkach nie mamy zamiaru w całości pożytkować. Dzieje się tak, ponieważ kierujemy się tu zasadą, że po dostarczeniu klientowi pewnej ilości funkcji, które stanowią już funkcjonalną całość, a system jest już w stanie działać na rynku i generować przychód, decydujemy wspólnie z klientem, że faza rozwoju projektu została zakończona. W takim przypadku dostawcy należy się, oprócz części wynagrodzenia spożytkowanej na rozwój systemu do etapu, w którym decydujemy się na zakończenie fazy rozwoju, także wypłacenie reszty założonego budżetu – w zamian za dostarczenie nie tylko satysfakcjonującej funkcjonalności systemu, lecz także za dokonanie tego przed założonym czasem.

Specyfiką tego modelu umowy jest także równy rozkład ryzyka projektowego. Obydwie strony mają interes w dostarczeniu projektu na rynek tak szybko jak to możliwe. Zamawiający – by wcześnie rozpocząć jego monetyzację, zaś wykonawca – by zwiększyć marżowość projektu. Jeżeli chodzi o zarządzanie zakresem takiego projektu, centralną zasadą jest tu, że funkcje zaplanowane, ale takie, które w toku rozwoju projektu uznano za zbędne, zostaną zastąpione innymi o tym samym koszcie. Koszt można tu rozmieć zarówno jako prostą funkcję pieniądza pomnożonego przez czas potrzebny do wytworzenia funkcjonalności, jak i jako koszt w znaczeniu „Story Pointu”, jeżeli stosujemy opis zakresu projektu w formie User Stories. Z faktycznym rozszerzeniem zakresu projektu możemy mieć do czynienia w przypadku potrzeby wdrożenia takiej zmiany zakresu, której koszt przerasta wszystko, czego na jej rzecz możemy się na danym etapie projektu pozbyć. W takim przypadku stosujemy dodatkową wycenę danej funkcjonalności.

W przypadku przekroczenia budżetu projektu realizowanego w modelu Money for Nothing, Change for Free, możemy znaleźć się w sytuacji, która w pewnym stopniu narusza silnie kooperacyjny charakter umowy. Spotkamy się bowiem z koniecznością negocjacji cen i umowy. W takiej sytuacji w utrzymaniu klimatu współpracy i wzajemnego zaufania może pomóc przejście do realizacji projektu w modelu stałego zysku. Polega on na podziale budżetu (całości projektu lub dodatkowej funkcji) na umowną część marżową (np. 25%) oraz kosztową. Zapłata kosztów przerastających zakładany budżet nie obejmuje wtedy części marżowej – zleceniodawca zobowiązuje się jedynie do pokrycia umownego kosztu dodatkowych prac. Zaleta takiego rozwiązania jest łatwo zauważalna – żadna ze stron nie ma realnego interesu w rozszerzaniu budżetu, przy czym jeśli jest to konieczne, koszta przekroczenia zostaną uczciwe podzielone. Ten model (stałego zysku) może być uzupełnieniem umowy na zasadach Money for Nothing, Change for Free, jednak w wielu przypadkach może to być absolutnie samodzielna forma rozliczenia kosztów i zarządzania ryzykiem projektu, stosowana do niego w całości. Warto zauważyć, że obydwa opisane podejścia zakładają istnienie ogólnego zakresu projektu.

Zarządzanie zakresem jest osobnym, obszernym zagadnieniem, trzeba jednak pamiętać o ogólnej wytycznej metodologii agile – zakres projektu na etapie umowy definiujemy ramowo i wysokopoziomowo, funkcje systemu najczęściej w formie user stories. Ich operacjonalizacja i doszczegółowienie jest zadaniem, które są realizowane w toku rozwoju projektu, iteracyjnie i przyrostowo, w projektach IT z reguły z pomocą modelu SCRUM. Ważne by nie pomylić pojęć z bogatego słownika „eventów”, „artefaktów”i „definicji”i „kontraktów” SCRUMowych z ogólnymi ramami współpracy. Kontrakt (lub umowa) SCRUM nie jest prawną umową między stronami, lecz należy do umownych reguł codziennej współpracy między zespołami wykonawcy i zleceniodawcy. Ich szczegóły nie są przedmiotem negocjacji na poziomie umowy między przedsiębiorcami, ale elementem ładu zarządzania projektem, który powinien zostać wypracowany przy udziale i zgodzie członków zespołów.