Jak pisać umowy dla projektów IT realizowanych w modelu agile

Metoda agile powstała jako odpowiedź na problemy związane z realizacją projektów IT w modelu kaskadowym. Jest wspólnym zbiorem zasad dla tzw. zwinnych (agile) metodyk wytwarzania oprogramowania (np. Scrum, eXtreme Programming, DSDM, czy Feature Driven Development).

Podstawowe założenia modelu Agile zostały opracowane w 2001 roku i ogłoszone w tzw. manifeście agile. Jego twórcy zgodnie uznali, że na podstawie własnych doświadczeń, wytwarzając oraz pomagając innym wytwarzać oprogramowanie, przedkładają: ludzi i interakcje ponad procesy i narzędzia; działające oprogramowanie ponad obszerną dokumentację; współpracę z klientem ponad formalne ustalenia oraz reagowanie na zmiany ponad podążanie za planem. Autorzy Manifestu dodali równie, że jakkolwiek doceniają to, co wymieniono po prawej stronie, to jednak bardziej cenią to, co zostało wskazane po stronie lewej.

Zastosowanie agile w praktyce

W praktyce metoda – a bardziej właściwe filozofia – agile sprowadza się do dostarczania zamawiającemu działającego oprogramowania, wytwarzanego w krótkich iteracjach. Powyższe założenie to kładzie znacznie większy nacisk na interdyscyplinarność zespołów developerskich oraz wzajemną współpracę pomiędzy zamawiającym a dostawcą rozwiązania informatycznego. Co istotne agile zakłada, że na samym początku projektu nie mamy precyzyjnego opisu rezultatu, jakim ma zakończyć się projekt. Często nie mamy również sztywnych ram czasowych oraz kosztowych związanych z realizacją przedsięwzięcia.

To na czym koncentruje sią agile to elastyczny proces powstawania rozwiązania informatycznego powalający na bieżące testowanie dostarczanych produktów i szybką reakcję na ewentualne niepożądane okoliczności, jakie mogą pojawić się w ramach realizacji wdrożenia. Element kluczowy to także sygnalizowana już wcześniej współpraca pomiędzy dostawcą rozwiązania a jego zamawiającym. Przenosząc to na realia kulinarne, o ile w waterfall przychodzimy do restauracji, zamawiamy obiad i czekamy na niego przy stoliku, to w modelu agile idziemy z kucharzem do kuchni i gotujemy obiad razem. Z czasem liczba zwolenników modelu agile zaczęła się istotnie powiększać, a sama metoda stała się realną konkurencją dla metodyk kaskadowych, zrywając ostatecznie z łatką partyzanckiej metody, jaką próbowali jej w początkowych latach istnienia nadać zwolennicy bardziej tradycyjnych metod realizacji projektów IT.

Dowodem na sukces metodyk zwinnych jest chociażby uznanie przez The Standish Group modelu agile za główny czynnik sukcesów projektów informatycznych w 2012 r. Potwierdzają to również publikowane przez tę organizację statystyki wskazujące na wyraźną przewagę metody Agile nad metodą Waterfall, a tym samym jej wpływ na powodzenie realizacji projektów informatycznych.

The Standish Group Report “CHAOS Manifesto 2014: Value versus Success & Orthogonal”

The Standish Group Report “CHAOS Manifesto 2014: Value versus Success & Orthogonal”

Rola prawnika w projekcie

Obserwując funkcjonujące na rynku umowy wdrożeniowe można niejednokrotnie odnieść wrażenie, że piszący je autor za punkt honoru postawił sobie zmaksymalizowanie szans klienta na wypadek procesu sądowego. Cóż, na pierwszy rzut oka wydaje się, że nie wolno mieć pretensji. Tylko czy właśnie o to w umowach wdrożeniowych chodzi? Czy to ma być jej zasadniczy cel?

Znany jest pogląd o tym, że umowy pisze się na złe czasy, bo jak są tzw. „dobre” czasy – tj. dogadujemy się – to nikt przecież umowy nie potrzebuje. Problem w tym, że taki pogląd ma się nijak do umów wdrożeniowych. Złożoność i stopień skomplikowania wdrożeń IT, wymuszający konieczność precyzyjnego opisania praw i obowiązków stron oraz zasad ich wzajemnej współpracy w ramach przebiegu projektu wdrożeniowego to tylko niektóre elementy kontraktów wdrożeniowych, konieczne właśnie po to, żeby strony się mogły w ramach projektu dogadać. We wdrożeniach nie chodzi o to, aby wyeliminować wszystkie ryzyka prawne.

We wdrożeniach chodzi o to, aby się udały. Ryzyka będą zawsze. Przy tej skali przedsięwzięcia nie da się ich całkowicie wyeliminować. Rolą prawnika jest zmaksymalizowanie szans powodzenia projektu przy wykluczeniu ryzyk nieakceptowalnych. Nie chodzi zatem o to, aby zmaksymalizować szanse klienta na wypadek procesu sądowego, ale raczej o zmaksymalizowanie szans na to, aby do takiego procesu nie musiało w ogóle dojść, czytaj wdrożenie się powiodło. Jeśli już mowa o ryzykach to przyjrzyjmy się, które z nich łączą się z modelami umów wdrożeniowych odpowiadających poszczególnym metodykom.

Tradycyjny model kontraktowy

Model kontraktowy, tradycyjny odpowiadający metodyce waterfall koncentruje uwagę na precyzyjnym opisaniu przedmiotu wdrożenia. Innymi słowy w sposób jednoznaczny i precyzyjny (przynajmniej w teorii) określa co w ramach wdrożenia ma zostać zrobione. Poza tym, że kontrakt określa nam „co” ma zostać zrobione, opisuje nam również „kiedy” (harmonogram wdrożenia) i „za ile” (sztywne wynagrodzenie). Wcześniej napisałem czym najczęściej w praktyce kończy się „zamrażanie” wymagań i funkcjonalności zawartych w analizie przedwdrożeniowej. Pytanie jak to wygląda z perspektywy umowy?

W tradycyjnym modelu kontraktowym to „coś”, co dostawca ma dostarczyć w ramach wdrożenia to nic innego jak opis dzieła. Lepiej lub gorzej opisane, ale wciąż dzieło. Czym to skutkuje? Tym, że, co do zasady, dostawca rozliczany będzie z tego, czy owe dzieło dostarczył. Innymi słowy, jeżeli dostarczy zgodnie z założeniami z umowy to dostanie wynagrodzenie, jeżeli nie dostarczy to nie dostanie, a może i naliczone zostaną mu jeszcze kary umowne. To bardzo prosta droga do tego, aby w ramach projektu dostawca nie dbał o absolutnie nic innego poza tym, żeby dzieło na czas i wyznaczone miejsce „dowieźć”. Nie ważne więc zatem, że w tzw. międzyczasie potrzeby biznesowe zamawiającego mogą się istotnie zmienić, a zawarte w analizie przedwdrożeniowej wytyczne dla dzieła będą już w połowie niekatulane – dzieło jest dziełem i musi zostać dostarczone na czas.

Czym to grozi? Tym, że w dobrym scenariuszu faktycznie dostaniemy na czas to co zamówiliśmy, przy czym być może dopiero na testach wyjdzie, czy to co udało się do tej pory wyprodukować (choćby bez wad) do czegokolwiek jest przydatne. Na tym etapie wprowadzanie istotnych zmian do (z)budowanego sytemu jest bardzo trudne, tak z technicznego, jak i prawnego punktu widzenia. W złym, spór co do przydatności przełoży się na spór czy umowa została należycie wykonana, i sprawa skończy się w sądzie.

Z modelem waterfall wiążę się jeszcze jedno ryzyko. Jeśli już na samym początku projektu, na etapie analizy przedwdrożeniowej, zawrzeć mamy takie wymagania i funkcjonalności, jakie spodziewamy się otrzymać na końcu wdrożenia, to mając w tyle głowy, że ewentualne zmiany „zamrożonej” analizy (dzieła) w toku wdrożenia mogą skutkować ryzkiem związanym z procedurą kontroli zmian umowy, umieszczamy w analizie wszystko co przyjdzie nam do głowy – jak w powiedzeniu „na pewno nie zaszkodzi, a może nawet się przyda”. Prowadzi to do nadmuchania analizy przedwdrożeniowej, odbijając się jednocześnie na kosztach oraz harmonogramie realizacji projektu. Dodatkowo, jeśli to dostawca zobowiązany będzie do sporządzenia analizy przedwdrożeniowej, nawet się nie spostrzeżemy, kiedy podczas negocjacji będziemy grać w grę o nazwie „mniej<>więcej”. Na czym ta gra polega?

Zakładając, że umówiliśmy się już z naszym dostawcą na stałą cenę za przeprowadzenie wdrożenia, termin końcowy oraz, że dostawca będzie rozliczany z „zamrożonych” w analizie wymagań – a takie właśnie zapisy można spotkać najczęściej w tradycyjnym modelu kontraktowym – nasz dostawca zrobi wszystko, aby możliwie jak najmniej w tej analizie pomieścić. Z drugiej strony, zamawiający chcąc wykazać się wyjątkowymi zdolnościami negocjacyjnymi prowadzącymi do zwiększenia efektywności kosztowej projektu zrobi wszystko, aby do owej analizy możliwie jak najwięcej upchać. Jeśli dodatkowo zobowiążemy dostawcę w umowie, aby w ramach analizy przedwdrożeniowej zwymiarował nam jeszcze środowisko, możemy być wtedy pewni, że zwymiaruje je z pewnością na wyrost, próbując uniknąć odpowiedzialności związanej z ryzykiem niewystarczającego zwymiarowania.

Podsumowując, w tradycyjnym modelu kontraktowym odpowiadającym metodologii waterfall, w którym zasadnicza uwaga skupia się na przedmiocie wdrożenia będącym w istocie „zamrożonymi wymaganiami” zawartymi w analizie, za cenę pewności (często pozornej) co do zasadniczych parametrów wdrożenia (przedmiot, czas, cena) przyjmujemy ryzyko, że to co dostaniemy, nie koniecznie musi być tym, czego potrzebujemy. Ryzykujemy także – coraz częstsze – spory już na etapie analizy, kiedy każda ze stron ma inne wymagania i małą chęć do kompromisu, bo rezygnacja z wymagań już w tym etapie oznacza niemożliwość bez aneksu umowy ich ponownego przywrócenia.

Nowy, zwinny model kontraktowy

Na pierwszy rzut oka napisanie dobrej umowy dla projektów realizowanych w modelu agile wydaje się być niemal niewykonalnym zadaniem. Wyobraźmy sobie bowiem klienta, który przychodzi i mówi, że chciałby zlecić nam napisanie umowy wdrożeniowej, problem jedynie w tym, że nie wie konkretnie co będzie jej przedmiotem, jaki będzie jej harmonogram, oraz ile tak naprawdę to całe wdrożenie ma kosztować. I to jeszcze nie byłoby zabójcze, ale klient ma już założony budżet i uzgodnioną (narzuconą) datę startu produkcyjnego. Cóż, najlepiej to nie brzmi, ale mimo wszystko spróbujmy się z tym zmierzyć.

Ile tak naprawdę ryzykujemy? Nie ma co ukrywać, że w ramach umów Agile mamy znacznie mniejszą pewność co do przedmiotu, kosztów oraz harmonogramu projektu wdrożeniowego. Nie oznacza to oczywiście, że kompletnie nic o tych parametrach nie wiemy, ale z pewnością wiemy mniej niż w przypadku modelu waterfall. Pytanie tylko co z tego? Jeżeli ponad połowa problematycznych wdrożeń (tych całkowicie nieudanych lub tych z problemami) wynika z niewłaściwej początkowej analizy wymagań lub zmian potrzeb zamawiającego w toku projektu to jak bardzo zmniejszamy ryzyko wdrożenia dążąc za wszelką cenę do sztywnego opisania jego spodziewanego rezultatu już w samej umowie?

Czy naprawdę jest tak, że pozorna pewność co do wybranych parametrów wdrożenia jest powodem dla którego mamy zrezygnować z bardziej efektywnej metody kontraktowej, która zamiast na samym przedmiocie projektu koncentruje się bardziej na sposobie jego dostarczenia? Nie jest też tak, że w umowach dla projektów Agile nie wiemy nic co do przedmiotu, zakresu, harmonogramu oraz kosztów z takich wdrożeń wynikających. Przeciwnie, dobrze napisana procedura postępowania w ramach poszczególnych iteracji (sprintów) pozwala na wystarczająco bezpieczne określenie podstawowych parametrów (czas, zakres, koszt) dla wytwarzanych w ich efekcie produktów.

Prawidłowo opisany proces wytwarzania (developmentu) oprogramowania, podzielony na względnie krótkie interwały, z jasno określonymi rolami kluczowych postaci projektu, zasadami współdziałania oraz wyraźnym zakresem praw i obowiązków stron to mechanizm, który w sposób skuteczny potrafi ograniczyć ewentualne ryzyka jakie mogą pojawić się w toku wdrożenia. Dodatkowo, skutecznie zapisane mechanizmy elastycznego wyjścia z projektu, połączone z właściwymi klauzulami co do rozliczeń stron po zakończeniu współpracy stwarzają dużo większą szansę na to, że nawet jeśli współpraca nie będzie przebiegała tak pomyślnie jak początkowo zakładaliśmy, jej zakończenie nie będzie zbyt krwawe i pozwoli na względnie spokojne wyjście z projektu i ewentualną kontynuację projektu z innym dostawcą.

Umów wdrożeniowych nie pisze się tylko na złe czasy. Umowy pisze się przede wszystkim po to, aby zwiększyć szanse na sukces przedsięwzięcia i wyposażyć strony w narzędzie pozwalające im lepiej i efektywniej współpracować, przy jednoczesnym zachowaniu przejrzystości co do zakresu ich praw i obowiązków. Z tego względu, coraz częściej niezbędne jest nowe podejście do umów wdrożeniowych, które odpowiadać będą w swoich założeniach filozofii Agile, zwiększając tym samym prawdopodobieństwo powodzenia realizowanych w oparciu o nie projektów wdrożeniowych. A co konkretnie te umowy powinny zawierać, to już temat na kolejny artykuł …

Autorami tekstu są: Marcin Maruta – specjalista w zakresie projektów IT. Doradzał największym krajowym i międzynarodowym dostawcom usług IT oraz odbiorcom tych usług. Koordynuje obsługę prawną międzynarodowych sporów sądowych i arbitrażowych oraz Łukasz Węgrzyn – prawnik w Kancelarii Radców Prawnych Maruta i Wspólnicy. Specjalista z zakresu prawa nowych technologii, własności intelektualnej i mediów. Wcześniej pracował między innymi jako prawnik wewnętrzny dla Agora, MTV Networks oraz członek zespołu TMT kancelarii prawnej „Bird & Bird”.