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:
- 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),
- 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.
