W mojej ocenie warto opierać na umowach Agile przy wdrożeniach, zarówno tych dużych, jak i małych. Chyba nawet przy takich mniejszych i średnich jest szersze pole do skorzystania z dobrodziejstw umów Agile, ponieważ jest większa swoboda przy ustalaniu treści kontraktu. Na większe wdrożenia najczęściej ma wpływy szereg czynników zewnętrznych, co znacznie ogranicza zakres swobody kontraktowej pomiędzy stronami.

Krótko mówiąc, w dużych wdrożeniach, zazwyczaj jedna ze stron umowy ma narzucone, przynajmniej częściowo, wymagania lub warunki. W efekcie przy takich wdrożeniach umowa Agile musi posiadać niektóre elementy tradycyjnych umów wdrożeniowych. Inaczej na to patrząc, można również powiedzieć, że przy małych wdrożeniach umowy Agile są niepotrzebne, ponieważ posłużenie się tradycyjną umową jest wystarczające, nawet jeśli projekt prowadzi się w myśl filozofii Agile, gdyż w mniejszych projektach jest więcej możliwości dokonywania częstych zmian w kontrakcie. Może tak być. Ale jeśli można również wtedy posłużyć się lepszym typem umowy, to dlaczego tego nie zrobić od razu?

W tym miejscu drobne wtrącenie odnośnie samego rozumienia Agile. Moje uwagi dotyczą tzw. umowy Agile. Patrzę zatem na Agile przede wszystkim w kontekście prawa. Ale to wciąż chodzi o Agile. Nie chcę w tym wpisie zachęcać do metodologii Agile (choć uważam, że jest najlepsza, w każdym razie ja w pewnym sensie tak mam zorganizowaną swoją pracę zawodową), lecz zwrócić uwagę na konieczność specjalnego potraktowania obsługi prawnej, jeśli już zdecydowano się na taką filozofię wdrożenia. Innymi słowy, może się rodzić wątpliwość czy jest sens angażowania w środków w tworzenia specjalnej umowy Agile, skoro może wystarczyć zwykła umowa wdrożeniowa, pomimo że wdrożenia realizowana jest w myśl metodologii Agile.

Według mnie przede wszystkim trzy argumenty przemawiają za umowami Agile:

1. Pozwalają zrealizować wdrożenie w sposób w najwyższym stopniu satysfakcjonujący obie strony. Umowa zawsze jest kompromisem, ale przy tradycyjnych umowach stronie silniejszej łatwiej narzucić swoje rozwiązanie, co jest konsekwencją okoliczności, że ta zazwyczaj taka strona przedstawia draft umowy, w którym niezbyt jest co zmieniać. W umowach Agile przygotowanie draftu wyłącznie przez jedną ze stron jest z zasady utrudnione i w pewnym sensie niemożliwe, ponieważ jeśli strony nie są w stanie na wstępie współpracy wypracować w drodze kompromisu kontraktu, to niezbyt dobrze wróżyłoby to prowadzeniu projektu w myśl filozofii Agile.
2. Zapisy w tradycyjnycm umowach to często pustosłowie, a jak rodzi się konflikt, to okazuje się, że jednak jedna ze stron w sposób wcześniej „niewyobrażalny” wykorzystuje zapisy na swoją korzyść. W umowach Agile wprawdzie również musi być sporo treści, ale trzeba się w nich kierować konkretami. Czasami spotykam się również z sytuacjami, że dla stron umowy jakieś postanowienie wydaje się jasne, tymczasem dla mnie jest to, jak wspomniałem, pustosłowie, gdyż po głębszym zastanowieniu mógłbym je interpretować na wiele sposobów.
3. Skutkiem ewentualnego niezrealizowania umowy Agile niekoniecznie musi być wieloletni spor sądowy (połączony z położeniem całego projektu), lecz wymiana kontrahenta na lepszego, połączona z wzajemnych, ale realnym. rozliczeniem się dotychczasowych stron.

Osobiście podoba mi się również w filozofii Agile rola prawnika, która nie jest marginalizowana do minimalizacji ryzyk prawnych na wypadek sporów, ale koncentruje się na doradztwie, czasami bardzo aktywnym, co do ułożenia zasad współpracy pomiędzy stronami. Tym samym jest to prewencja.

Z mojego doświadczenia wynika, że najczęściej główni aktorzy projektu (podmiot biznesowy i podmiot developerski) nie rozumieją się wzajemnie i w pewnym sensie uważają, że ich udział jest kluczowy. Takie wzajemne niezrozumienie prowadzi zazwyczaj do powstania tzw. „obszarów niczyich”. Podmiot biznesowy uważa, że jako inicjator i sprzedawca zleca pracę podmiotowi developerskiemu (dosłownie „zleca”, co jest równoznaczne, że sam w tym zakresie niewiele robi i po prostu chciałby gotowy produkt), a z kolei podmiot developerski uważa, że wie lepiej co można, a czego nie i robi jak uważa, samemu „urealniając” potrzeby podmiotu biznesowego. W efekcie zatraca się sens projektu. Mówiąc dobitnie – sens projektu przestaje odgrywać wiodącą rolę, a zaczyna liczyć się jedynie minimalizowanie tych niedoróbek, do których można „doczepić się” z punktu widzenia zapisów umownych.

Czy dobrym pomysłem jest wypełniać umowę Agile obowiązkami w zakresie organizowania regularnych spotkań. Wydaje się, że nie. Pisanie o tych spotkaniach może często tworzyć złudzenie działania w ramach metodologii Agile, pomimo że wdrożenie faktycznie realizowane jest według tradycyjnych metod.

Na zakończenie w kilku słowach chciałem zwrócić uwagę na błędne posługiwanie się pojęciem odpowiedzialności, co dotyczy w szczególności tradycyjnych kontraktów, w mniejszym stopniu umów Agile. Nie-prawnicy posługują się nim jako synanimem słowa „kompetencja” lub „uprawnienie”. Zapisując w umowie, że ktoś jest odpowiedzialny za coś, znaczy dla nich tyle, że to jest jego działka (tym czymś ten ktoś się właśnie zajmuje). Idąc takim tokiem rozumowania, można dodać, że inne osoby nie powinny w ten obszar wkraczać, skoro ten ktoś jest za niego odpowiedzialny. Tak pojmowane pojęcie odpwiedzialności jest w świetle prawa „puste”, ponieważ nie wiąże się z nim sankcji. Dla prawnika powiedzenie, że ktoś jest odpowiedzialny np. za interfejs (ogólnie mówiąc) znaczy tyle, że jak w tym zakresie coś będzie nie tak, to osoba odowiedzialna ponosi konsekwencje niepowodzenia całego projektu, a nie tylko interfejsu.

Mój autorski pomysł na umowę Agile zakłada odrzucenie dotychczas stosowanych wzorców umownych przy projektach informatycznych. Tylko wtedy możliwe jest osiągnięcie realnych korzyści z filozofii Agile. Bez nowatorskiej umowy Agile stosowanie metodologii Agile może okazać się pozorne, a tym samym nie stwarzać dobrych warunków dla realizacji projektu informatycznego.

Od razu wyjaśnię, że przedstawione poniżej założenia umowy Agile mają modelowy charakter. Nie udało mi się nigdy zrealizować ich w pełni, ale staram się w tym kierunku podążać. Tak czy inaczej, moja propozycja odrzucenia tradycyjnych standardów umownych wynika przede wszystkim z dwóćh przyczyn:

1. chce uczestniczyć, jako prawnik, jedynie w projektach, których skutkiem jest dobry produkt i jako takie są udane (to podejście chyba wiąże się z moim drugim zawodem – jako naukowiec mam satysfakcje z tworzenia czegoś nowego),
2. zamiast uczestniczyć w sporze sądowym o niewykonanie lub nienależyte wykonanie wdrożenia, w tym w zakresie stworzenia innowacyjnego produktu, wolę obsługiwać kolejny projekt (kwestia ograniczeń czasowych – jak się robi jedno, to trzeba zrezygnować z innych rzeczy).

Fundamentalna różnica pomiędzy tradycyjną umową projektową (związaną z Waterfall) a zaprezentowanymi poniżej ramowymi warunkach umowy Agile, tkwi w całkowitej rezygnacji z wiązania skutków prawnych z ostatecznym produktem. Znaczenie mają jedynie czynności (zadania) prowadzące do ostatecznego produktu. W takim stanie rzeczy, można powiedzieć, że umowa Agile obsługuje projekt, a nie spór sądowy po niepowodzeniach projektowych. Jest to umowa na dobre czasy projektu, a nie tylko na zły okres. Taka umowa Agile ma służyć bieżącemu zarządzenia projektem, a tym samym odgrywać wiodącą rolę w jego realizacji. Nie można rzucić jej w kąt w czasie prowadzenia projektu i sięgnąć do niej dopiero jak już wiadomo, że z projektu nic dobrego nie będzie. Umowa Agile powinna być taka, że każdy uczestnik projektu powinien móc jej konkretne postanowienia przepisać wprost do swojego kalendarza. Dlatego umowa Agile nie powinna być przegadana, a w szczególności posługiwać się banalnymi unormowaniami. Z tych też względów postuluję:

• rezygnację z tzw. słowniczka na wstępie umowy,
• jak też likwidację jakichkolwiek załączników do umowy.

Występowanie tych elementów, choć w założeniu ma służyć klarowności, to faktycznie utrudnia posługiwanie się umową na potrzeby realizacji projektu, gdyż ulokowanie jednego zagadnienia w wielu miejscach w umowie skutkuje niezrozumiałością kontraktu. Umowa jest wtedy może jasna dla prawników, ale mniej dla wykonawców. Tymczasem zakładam, że umowa ma przede wszystkim służyć organizacji prac w projekcie.

Zawartość umowy Agile

1) Deklaracja ogólnego celu

Wprawdzie, jak wskazałem powyżej, z ostatecznym produktem nie powinny być wiązane z zasady skutki prawne, to jednak warto opisać we wstępie umowy (preambule) cel projektu, czyli wskazać do jakiego dąży się produktu. Raczej należy się posługiwać w tym zakresie potocznym językiem. Nie chodzi o opis od strony informatycznej, lecz ogólne wskazanie jak finalny produkt ma działać, czy inaczej ujmując, jakie potrzeby użytkowników ma zaspokajać.

2) Opis czynności (zadań)

Umowa Agile w proponowanym kształcie powinna składać się głównie z szczegółowego opisu czynności, które w założeniu stron umowy, potencjalnie mogą doprowadzić do stworzenia dobrego produktu. Posługuję się pojęciem opisu czynności, ale nie jest to precyzyjne określenie. Chodzi mi o swoisty zbiór zadań lub szczegółowych celów, a nie opis sposobów dojścia do tego celu (procedur służących wykonaniu zadania). Wreszcie tak ujmowany opis czynności nie musi być chronologiczny, ponieważ gdyby tak było, to mielibyśmy do czynienia z typową kaskadowością, a tym samym zbliżylibyśmy się do modelu Waterfall. Tak rozumiany opis czynności nie musi również pokrywać się z iteracjami (sprintami). Opis czynności może być od nich szerszy lub węższy. Nie jest jednak wykluczone, przynajmniej częściowe, pokrywanie się tych elementów. Zależy to od konkretnego produktu. Niezmiernie ważną kwestią jest racjonalność opisu i adekwatność konkretnych czynności dla projektu.

W mojej ocenie samo ogólne zapisanie w umowie potrzeby odbywania spotkań lub powołanie komitetów sterujących nie jest wystarczająco konkretne. Należy rozsądnie wpisywać takie rzeczy do umowy Agile, gdyż może to służyć stworzeniu iluzji posługiwania się metodologią Agile. Swoistego zamaskowania rzeczywistego działania w ramach Waterfall.

Trzeba ze spotkaniami wiązać z góry konkretne zadania. Nie chodzi o to, żeby umowa stanowiła opis ogólnej filozofii Agile, lecz ma porządkować prace w ramach danego projektu. Umowa Agile ma służyć obsłudze projektu, a zatem musi konkretyzować metodologię Agile. Kształt umowy sam powinien wymusić spotkania i współprace poszczególnych osób. Istnieje realne niebezpieczeństwo, że ogólne zadeklarowanie w umowie spotkań, doprowadzi, w trakcie projektu, do rozmycia ich znaczenia.

Najistotniejszą kwestią jest jednoznaczne powiązania z daną czynnością podmiotu (osoby) mającego ją zrealizować oraz odpowiedzialności za ewentualny brak realizacji w odpowiednim czasie. Kary w tym zakresie nie powinny być szczególnie dotkliwe, ale powinny być egzekwowane. Na pewno jednak kary muszą być instrumentem o charakterze ostatecznym, gdyż dążyć powinno się do polubownego rozwiązywania problemów, w szczególności poprzez współpracę. Ważne jest jednak, aby było jasne kiedy pojawia się widmo kary, aby stymulowało to do wczesnego podjęcie środków zaradczych. W zakresie odpowiedzialności zawsze problemem pozostanie ustalenie kto jest winny. Rozwiązania umowne w tym zakresie powinny wymuszać, aby osoba, która ma zrealizować zadanie robiła wszystko co możliwe, w celu zapobiegnięcia niepowodzeniom. Nie może zatem mieć łatwego wytłumaczenia w postaci „przerzucenia” winy na innego członka zespołu lub podmiotu.

Ktoś może powiedzieć, że w umowie Agile nie powinno być w ogóle kar, lecz dominować powinno nastawienia na współpracę i rozwiązywanie problem. Niby racja. Jednak, w jakimś miejscu kary powinny być określone. Zwracam uwagę, że w prezentowanym modelu umowy Agile, kary nie są wiązane z ostatecznym produktem. Następuje zatem ich przesunięcie na niższy poziom realizacji projektu.

3) Końcowe przepisy techniczne

Ze struktury tradycyjnej umowy wdrożeniowej warto zaadoptować na potrzeby umowy Agile tzw. przepisy końcowe. Zwłaszcza w kwestii czasu obowiązywania umowy i sposobu dokonywania jej zmian. Chodzi zatem o unormowania, które są typowe dla każdej umowy.

Zalety

Pierwszorzędna zaleta tak skonstruowanej umowy jest możliwie pełne urzeczywistnienie filozofii Agile, a tym samym wszelkie pozytywy tej filozofii można wprost przypisać umowie Agile.

Uważam, że stosowanie metodologii Agile, ale bez umowy Agile, w efekcie spowoduje, wcześniej lub później, konieczność powrotu do tradycyjnych metod pracy, w tym sposobu zarządzania projektem informatycznym. Nie bez przyczyny Waterfall określa się mianem „tradycyjnej” metodologii. Jeśli nie dba się o Agile, następuje ciąg do kierowania się przyzwyczajeniami.

Wydaje się, że proponowany model umowy zapewnia wysoki stopień elastyczności. Daje choćby możliwość łatwej zmiany podmiotu (osoby), który sobie nie radzi. Zastąpić może go ktoś lepszy. Tym samym nie jest zagrożone stworzenie finalnego produktu.

Wady

Przedstawiony kształt umowy ma również pewne wady. Jak też wskazano, samo dokonania opisu czynności jest niezmiernie czasochłonne i trudne. Wymaga od prawnika tworzącego umowę Agile nie tylko znajomości prawa, ale też posiadanie „wyobraźni” co do przebiegu projektów informatycznych. Co oczywiste, prawnik przy sporządzaniu umowy musi współpracować z innymi podmiotami zaangażowanymi w projekt. Poza tym rola prawnika nie ogranicza się wtedy do doradzania jak „gasić pożary” w projekcie, lecz konieczne jest stałe monitorowanie realizacji projektu.

Rola dokumentacji w metodologii Agile

Wprawdzie filozofia Agile zakłada odejście od generowania stosów dokumentów, to dotyczy to w szczególności dokumentacji projektowej, w tym włączanej do kontraktów. Nie oznacza to jednak, że nie ma potrzeby stworzenia kontraktu. Musi być. Ale niekoniecznie należy tworzyć go na kształt dokumentacji projektowej. Wydaje mi się, że obsługa prawna w metodologii Agile nie powinna bazować na dokumentacji projektowej w tak wielkim stopniu jak przy Waterfall. Kluczowe powinny być dokumenty przygotowane przez prawnika, a nie zespół projektowy. Koresponduje to ze wskazanym na wstępie postulatem w zakresie pozbawienia umowy jakichkolwiek załączników, lecz zamieszczanie wszystkiego w treści umowy. Precyzyjny język prawny, który z natury jest syntetyczny, świetnie nadaje do zorganizowania prac w ramach projektu.