Czynniki zwinności i ich odzwierciedlenie w umowach na agile

Rola dobrego kontraktu w projekcie realizowanym w modelu Agile jest znacznie większa niż w tradycyjnych projektach IT. Poza adresowaniem standardowych obszarów kontraktowych (np. odpowiedzialność, poufność, dane osobowe), koniecznie jest zawarcie w nim dodatkowych mechanizmów kontraktowych, gwarantujących spójność pomiędzy umową a rzeczywistością projektową.

W pierwszym artykule cyklu „Agile w sektorze publicznym” pisaliśmy o znaczeniu, genezie i zaletach metodyk zwinnych w stosunku do projektów realizowanych w metodyce kaskadowej. Wykazaliśmy, że w Stanach Zjednoczonych i krajach Europy Zachodniej Agile jest powszechnie wykorzystywany – nie tylko na rynku prywatnym, ale i na publicznym. Dotyczy to także Polski, choć najczęściej sektora prywatnego.

Wśród „głośnych” przedsięwzięć realizowanych zgodnie z metodologią agile na szczególną uwagę zasługuje projekt „Everest” realizowany przez PZU. W jego ramach wdrożono system wspierający proces sprzedaży, rozliczania oraz obiegu dokumentacji, związanych z dystrybucją produktów i usług oferowanych przez spółki z Grupy PZU. Nowe rozwiązanie zastąpiło 21 używanych wcześniej systemów IT. Z powodzeniem projekt zwinny przeprowadził także ING Bank Śląski, którego efektem jest platforma usług mobilnych – „Moje ING”. Natomiast Allegro, postanowiło przeobrazić całą strukturę tak, aby funkcjonowała zwinnie. Wiązało się to z kompletną rewolucją całej organizacji, ale przyniosło wymierne efekty. Dzisiaj Allegro uzyskuje produkty IT o wiele szybciej i efektywniej niż przed zmianami.

Wymienione wyżej projekty nie były realizowane identycznie. Każdy z nich miał swoją specyfikę. Jednocześnie jednak projekty te mają wspólny mianownik, którym jest zdolność do adaptacji do dynamicznych zmian, rozwój produktu przy ciągłym i czynnym udziale zamawiającego oraz iteracyjny przyrost produktu – wymierny i widoczny dla obu stron. Te punkty wspólne to tzw. czynniki zwinności, czyli elementy charakterystyczne dla metodyk zwinnych, które warunkują zwinność projektu. Znajdują one też swoje odbicie w umowach na projekty IT. O tym właśnie jest kolejna część naszego cyklu.

Zapisy kontraktów Agile a czynniki zwinności

Umowa w projekcie realizowanym w modelu Agile powinna zawierać takie, dodatkowe mechanizmy kontraktowe – odpowiednio zaprojektowane i zabezpieczone w umowie – które umożliwiają przyjęcie zwinnego podejścia do realizacji produktu IT. Określa się je mianem czynników zwinności (agility factors). Zalicza się do nich przede wszystkim:

1. 1.     proces iteracyjnego wykonania produktu;
2. 2.     elastyczny mechanizm rozliczeń zagregowany z iteracyjnym modelem realizacji produktu;
3. 3.     elastyczną procedurę kontroli zmian umowy;
4. 4.     zwinny model współdziałania stron;
5. 5.     odpowiednie ujęcie obszaru zarządzania personelem zamawiającego i dostawcy;
6. 6.     mechanizmy „wyjścia z umowy” i tzw. scenariusze wyjścia (exit plan).

Zaimplementowanie w kontrakcie czynników zwinności zdecydowanie zwiększa szansę powodzenia przedsięwzięcia IT, powodując, że umowa nie jest już tylko straszakiem wyjmowanym z szuflady na wypadek wojny, ale przede wszystkim narzędziem mającym zwiększyć szansę na realizację projektu. Staje się narzędziem wyposażonym w mechanizmy mające na celu optymalizację kosztową, czasową i jakościową projektu IT. Poniżej opiszemy każdy z sześciu wymienionych wyżej mechanizmów kontraktowych.

1.     Proces iteracyjnego wytwarzania produktu

Umowy w projektach kaskadowych traktują po macoszemu kwestię mechaniki wytwarzania produktu – wychodząc z założenia, że zamawiającego interesuje rezultat końcowy, a nie sposób, w jaki jest on dostarczany. Kontrakty Agile – przeciwnie do tradycyjnych umów – zawierają obszerne i szczegółowego opisy struktury, przebiegu i sposobu wytwarzania, wychodząc z założenia, że nie jest ważne tylko „CO” ale również „JAK”.

Umowa powinna wprowadzać podział projektu na krótkie fazy – iteracje. Z uwagi na charakterystyczną dla metodyk zwinnych dyscyplinę, umowa musi ściśle określać maksymalny czas trwania iteracji (tzw. timebox) oraz poszczególnych, charakterystycznych dla Agile spotkań zespołu realizującego projekt. Szczególnie istotne jest właściwe zaprojektowanie sposobu ustalania backlogu iteracji (tj. w uproszczeniu: listy zadań do realizacji w jej ramach), estymacji czasowych i finansowych jego elementów oraz kryteriów akceptacji, względem których będzie weryfikowana prawidłowość ich wykonania.

Przy projektowaniu opisywanych wyżej postanowień kontraktowych warto sięgnąć do rozwiązań wypracowanych w ramach już istniejących metodyk zwinnych. Najbardziej popularną z nich jest Scrum, oferujący zestaw niemal gotowych rozwiązań dla mechaniki przebiegu projektu IT. Trzeba jednak pamiętać, aby korzystać z dorobku metodyk w sposób przemyślany i twórczy. Tak np. Scrum Guide proponuje bardzo dobre rozwiązania – ale często w sposób niewyczerpujący i wielowariantowy – dlatego w umowie trzeba je „domknąć” we właściwy sposób i wybrać odpowiednie rozwiązania. Bezrefleksyjne przepisanie Scrum Guide’a – albo odwołanie do niego – nie wprowadzi oczekiwanego porządku, ale chaos.

2.     Elastyczny mechanizm rozliczeń zagregowany z iteracyjnym modelem realizacji produktu

Kwestia rozliczeń jest newralgiczna dla projektu zwinnego. Przyjęte w jej ramach rozwiązania muszą być spójne z iteracyjnym modelem realizacji produktu i jednocześnie motywować strony do dobrej pracy w dobrym tempie. Mają także zapewnić równowagę kontraktową umożliwiającą zachowanie partnerskiej relacji stron.

Bardzo przyjaznym zwinności rozwiązaniem jest bieżące rozliczanie się po każdej iteracji – za wykonaną pracę lub dostarczone w jej ramach produkty. Wzmacnia to kontrolę nad przebiegiem projektu i jest atrakcyjne dla wykonawcy. Może być jednak operacyjnie niewygodne dla zamawiającego (zwłaszcza przy krótkich iteracjach). Rozwiązaniem w tej sytuacji jest oparcie mechanizmu rozliczeń na punktach kontrolnych (check-points) – występujących periodycznie po zakończeniu pewnej liczby iteracji (często po trzech iteracjach – których czas trwania wynosi około miesiąca). Check-point jest także zazwyczaj związany z dodatkową weryfikacją produktu, przeniesieniem praw autorskich czy przekazaniem kodów źródłowych i dokumentacji. Dotyczy to więc rezultatów prac dostarczanych obok funkcjonującego oprogramowania, a których dostarczanie w każdej iteracji może być dla dostawcy uciążliwe i niewygodne.

Jak zostało zaznaczone, strony mogą rozliczać się zarówno w oparciu o czas pracy dostawcy, jak i o rezultaty tej pracy. Inaczej mówiąc, Agile jest do zastosowania zarówno w modelu Time&Material, jak i modelu ryczałtowym. Oba rozwiązania mają zalety, ale także wady. Time&Material nie działa dostatecznie motywująco na wykonawcę. Opłaca się pracować, pracować, pracować… Z kolei ryczałt jest mało elastyczny i utrudnia podejmowanie śmiałych decyzji w trakcie wykonywania projektu. Grożą one dodatkowymi kosztami. Stanowią więc ryzyko dla wykonawcy. Chociaż mogłyby wiązać się ze znacznymi korzyściami dla zamawiającego. Z naszego doświadczenia wynika, że optymalnym rozwiązaniem jest oparcie rozliczeń o wartość poszczególnych rezultatów projektu. Polega to na przypisaniu konkretnych wartości pieniężnych do realizacji poszczególnych zadań – a następnie na wypłacie (w ustalonym terminie) wynagrodzenia stanowiącego sumę takich wartości. Wskazany model pozwala wykonawcy nie obawiać się, że podejmowanie się dodatkowych lub ryzykownych zadań wpłynie negatywnie na jego sytuację finansową. Zamawiający może zaś być spokojny, że wynagrodzenie nadal jest uzależnione od dostarczenia konkretnej wartości biznesowej – niezależnie od nakładu pracy wykonawcy. Jednak lojalnie uprzedzamy, że opisany model wymaga wysokich kompetencji z obu stron – w szczególności ze strony dostawcy, który musi być zdolnym do oszacowania czaso- i pracochłonności poszczególnych zadań. Następnie zaś dokonania – w oparciu o te szacunki – wyceny.

Istnieją także specyficzne dla Agile modele wynagrodzenie, takie jak Target Cost Contract. Zgodnie z nim, zakłada się dla projektu konkretny budżet. W razie realizacji przedsięwzięcia w kosztach poniżej tego budżetu, dostawca – w ramach premii – otrzymuje połowę kwoty stanowiącej różnicę pomiędzy założonym budżetem a faktycznymi kosztami przedsięwzięcia. Natomiast w razie przekroczenia budżetu – dostawca ponosi 50% kosztów wykraczających ponad ten budżet (czyli pracuje po obniżonych stawkach). Dochodzi w ten sposób do równego rozkładu skutków sukcesu i porażki projektu.

3.     Elastyczna procedura kontroli zmian umowy

Jak wyjaśnialiśmy w poprzednim artykule (opublikowanym w numerze ITwiz 11-12/2016), w projekcie IT, zmiany zakresu, harmonogramu lub budżetu są nieuniknione. Zwinna umowa musi przygotować do tego strony i dać im narzędzia umożliwiające sprawne dokonanie zmiany w ramach jasnej i możliwie prostej procedury. Procedura zarządzania zmianą musi być prosta, a więc odformalizowana. W praktyce oznacza to rezygnację z wymogu zachowania dla zmian (przynajmniej tych drobniejszych) formy pisemnej pod rygorem nieważności, powtarzanego w umowach niczym mantra. W formie pisemnej – samej w sobie – nie ma oczywiście nic złego. Jednak oznacza ona, że pod treścią oświadczenia podpis muszą złożyć osoby uprawnione do reprezentowania danego podmiotu. Są to zwykle osoby na stanowiskach kierowniczych. Zabieganie o ich podpisy jest zazwyczaj bardzo czasochłonne i dlatego z takiego trybu trzeba zrezygnować. Lepiej umówić się na rodzaj elektronicznej komunikacji np. za pośrednictwem e-mail.

Upoważnienie (pełnomocnictwo) do dokonywania zmian wynikających z day-to-day work powinno spoczywać na osobach bezpośrednio zaangażowanych w projekt. Ze strony zamawiającego taką osobą powinien być Product Owner. Przynajmniej do pewnego pułapu budżetu, to on powinien decydować o zmianach zakresu, budżetu i harmonogramu projektu. Taka konieczność wynika z charakteru zmian w projekcie zwinnym – które zazwyczaj mają niewielkie rozmiary, ale zdarzają się często. Potrzeba eskalacji za każdym razem do organów kierowniczych organizacji czy komitetu sterującego niepotrzebnie wydłużają obieg decyzyjny. Osoby piastujące ww. funkcje i tak zazwyczaj opierają decyzje na zdaniu osób „z frontu”. Warto pamiętać, że przyczyną klęsk wielu projektów waterfallowych były właśnie przestoje i klincze decyzyjne wynikające z przesadnego formalizmu.

Procedura kontroli zmian powinna być – jak wiele innych procedur w Agile – zdyscyplinowana, przebiegać dynamicznie i wręcz nieco mechanicznie, precyzyjnie określając mechanizm podjęcia decyzji o zmianie, osoby uprawnione i formy komunikacji. Warto zadbać o nadanie jej z góry określonych ram czasowych (timebox).

Należy mieć na uwadze, że zakres przedmiotowy, budżet i harmonogram to naczynia połączone – zmiana któregokolwiek z nich bezpośrednio wpływa na pozostałe. Umowa musi przewidywać mechanizmy, które każdorazowo zmuszają strony do refleksji, jak dana zmiana określonego elementu projektu wpłynie na inne jego elementy i jakich zmian należy w nich z tego powodu dokonać.

4.     Zwinny model współdziałania stron

Współdziałanie stron ma fundamentalne znaczenie w Agile. W wymiarze kontraktowym wiążą się z nim w szczególności trzy aspekty: wspólna koordynacja prac; przepływ wiedzy; zarządzanie ryzykiem związanym z pojawiającymi się problemami. Umowa powinna konstruować narzędzia adresujące te kwestie.

Podchodząc do sprawy bardziej niskopoziomowo, w kontekście współpracy umowa musi określać liczebność (optymalnie niewielką) zespołu deweloperskiego, kluczowe role w jego ramach, lokalizacje w których realizowany będzie projekt, zakres decyzyjności i odpowiedzialności poszczególnych ról projektowych, modelowe mechanizmy współpracy w ramach procedur testowo-odbiorowych oraz poszczególnych spotkań zespołu projektowego, charakterystycznych dla metodyk zwinnych (np. Planowanie Sprintu, Przegląd, Retrospektywa).

W zaawansowanych projektach pojawiają się projekty, w których współpraca stron jest tak daleko posunięta, że produkt jest realizowany przez zespoły składające się zarówno z członków personelu zamawiającego, jak i wykonawcy. Z biznesowego punktu widzenia ta sytuacja faktycznie wydaje się wysoce pożądana, ale z punktu widzenia prawnika to wielkie ryzyko – w razie niepowodzenia projektu, bardzo trudno byłoby wskazać zakres odpowiedzialności stron (trudno byłoby wskazać, czyj personel zawinił).

5.     Odpowiednie ujęcie obszaru zarządzania personelem zamawiającego i dostawcy

Jest to bezpośrednia, kontraktowa emanacja szczególnego znaczenia czynnika ludzkiego dla projektów zwinnych. Umowa powinna wprost opisywać oczekiwania zamawiającego względem kompetencji personelu wykonawcy. Poza tym, w kontrakcie powinny zostać zagwarantowane samowystarczalność i – o ile to możliwe – międzyfunkcjonalność zespołu lub zespołów deweloperskich.

Samowystarczalność (interdyscyplinarność) oznacza wymóg posiadania przez członków danego zespołu wszystkich kompetencji potrzebnych do realizacji przypisanych w projekcie zadań – bez korzystania (co do zasady) z zasobów zewnętrznych (podwykonawców). Obecność w zespole analityków, architektów, deweloperów, designerów, testerów etc. z odpowiednimi kompetencjami zapewnia sprawną realizację przedsięwzięcia i dogłębną znajomość produktu przez zespół. Natomiast zbyt częste sięganie po zasoby zewnętrzne dezorganizuje pracę i powoduje, że dynamika jego realizacji spada. Międzyfunkcjonalność to parametr oznaczający istnienie możliwości płynnego zastępowania się wzajemnie przez członków zespołu – czyli posiadanie przez jedną osobę więcej niż jednej kompetencji potrzebnej w projekcie. Należy jednak zaznaczyć, że w realiach rynkowych rzadko udaje się spełnić ten wymóg.

Zabezpieczenie w umowie odpowiednio kompetentnego i współpracującego z zamawiającym zespołu nie jest jednak wystarczające. Koniecznie jest jeszcze utrzymanie w ciągu całego projektu takiego statusu. Z tego względu w umowach przewiduje się postanowienia gwarantujące niezmienność personelu (poza przypadkami niezależnymi od stron, jak np. śmierć czy choroba), a w razie konieczności dokonania w nim zmian – zapewnienia zastępców dysponujących nie mniejszymi umiejętnościami i doświadczeniem.

6.     Mechanizmy „wyjścia z umowy” i exit plan

Partnerskie podejście do projektu i równomierny rozkład ryzyka wymaga, aby zapewnić stronom możliwość kontrolowanego „wyjścia z umowy” – tj. odstąpienia od niej albo jej wypowiedzenia. Wbrew pozorom, to nie stanowi zaplanowanej dywersji, a optymalizuje realizację projektu. W typowych projektach, jeśli któraś ze stron dostrzega, że przedsięwzięcie nie ma realnych szans powodzenia – natomiast formalnie, pod kątem umowy, wszystko przebiega w porządku – to nie może ona wyjść z kontraktu już na tym, stosunkowo wczesnym etapie. Co gorsza, dla takiej strony często jedyną drogą ucieczki okazuje się obstrukcja projektu. Wówczas zazwyczaj zamawiający przestaje udzielać wykonawcy potrzebnych informacji albo wszczyna zmasowane kontrole, a z drugiej strony, wykonawca zaczyna terroryzować zamawiającego coraz to nowymi wymaganiami w zakresie współdziałania. Rolą kontraktu jest zapewnienie w nim takich klauzul umownego prawa odstąpienia lub wypowiedzenia, które w razie zajścia odpowiednich okoliczności pozwolą stronom na „wyjście z umowy” w cywilizowany sposób – bez eskalacji napięcia.

Drugim koniecznym krokiem, oprócz zaprojektowania wyjścia ewakuacyjnego, jest zaplanowanie samego przebiegu i efektów ewakuacji – czyli tzw. exit planu. Umowa musi w przejrzysty sposób określać szczegółowo skutki skorzystania z umownego prawa odstąpienia lub wypowiedzenia – odnośnie produktów już dostarczonych; produktów jeszcze niedostarczonych, ale właśnie realizowanych; produktów jeszcze nierealizowanych; wynagrodzenia i rozliczeń; praw własności intelektualnej; kodów źródłowych; dokumentacji; know-how; informacji poufnych i wrażliwych materiałów. W obliczu przedwczesnego zakończenia trwania umowy strony muszą mieć pełną świadomość co do następstw tego zdarzenia. Jest to tym istotniejsze, że przepisy prawne przewidują bardzo lakoniczną i niejednoznaczną regulację skutków odstąpienia lub wypowiedzenia – co stanowi zarzewie ogromnych, kosztochłonnych i czasochłonnych sporów.

Umowy z Prawem zamówień publicznych w tle

Zaimplementowanie w kontrakcie opisanych wyżej czynników zwinności znakomicie zwiększa szansę na przeprowadzenie projektu zgodnie z modelem Agile. Z punktu widzenia rządzącego rynkiem prywatnym prawa cywilnego i dominującej w nim zasady swobody umów, zaprojektowanie umowy uzbrojonej w czynniki zwinności nie rodzi problemów – zarówno w modelu umowy o świadczenie usług nazywanej potocznie zleceniem (art. 750 Kodeksu cywilnego), jak i w modelu umowy o dzieło (art. 627 Kodeksu cywilnego).

Co z rynkiem publicznym? Także i na nim receptą na przeprowadzenie projektu zwinnego, jest zastosowanie czynników zwinności – takich samych jak dla rynku prywatnego. Jednak ich zaimplementowanie stanowi większe wyzwanie. Wymaga bowiem skorzystania z bardziej złożonych narzędzi – w celu dostosowania do reżimu Prawa zamówień publicznych. W świetle do niedawna obowiązujących przepisów trudno było sobie wyobrazić zwinność w publicu.

Nowelizacja Prawa zamówień publicznych z 22 czerwca 2016 r. istotnie jednak rozszerzyła instrumentarium zamawiających publicznych. Dotyczy to także mechanizmów umożliwiających zbudowanie elastycznego kontraktu – zdolnego zaadaptować czynniki zwinności – i przeprowadzić projekt zwinnie. Jakie to mechanizmy oraz jak je zastosować w celu realizacji projektu w Agile na rynku publicznych opiszemy szczegółowo w kolejnym artykule (w numerze ITwiz 2/2017).

Autorami tekstu są także Michał Bagłaj, Piotr Kaniewski i Jakub Krysa, Praktyka Transformacji Cyfrowych, kancelaria Maruta Wachta sp.j.