Jak pisać umowy dla projektów IT realizowanych w modelu Agile? Cz. II.

Agile

Jako odpowiedź na problemy związane z realizacją projektów IT w modelu kaskadowym powstała metoda Agile, będąca wspólnym zbiorem zasad dla tzw. zwinnych (z ang. agile) metodyk wytwarzania oprogramowania (np. Scrum, Programowanie Ekstremalne, DSDM, Feature Driven Development, itp.). Podstawowe założenia modelu Agile zostały opracowane w 2001 roku i ogłoszone w tzw. Manifeście Agile.

Twórcy Manifestu Agile 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.
  • 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ściwie filozofia) Agile sprowadza się do dostarczania zamawiającemu działającego oprogramowania, wytwarzanego w krótkich iterakcjach. W związku z tym powyższe założenie 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 pozwalają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 Waterfallu 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 Agile 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 roku. 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.

Rola prawnika

Wracając do roli prawnika i wyboru optymalnego modelu umowy. 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 swojego klienta na wypadek procesu sądowego. Cóż, na pierwszy rzut oka wydaje się, że nie wolno mieć pretensji.

Pytanie tylko czy właśnie o to w umowach wdrożeniowych chodzi? Czy to ma być jej zasadniczy cel?

Cóż, oczywiście 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ń informatycznych 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, żeby wyeliminować wszystkie ryzyka prawne. We wdrożeniach chodzi o to, żeby 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, żeby 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ść, czyt. 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

Tradycyjny model kontraktowy odpowiadający metodyce Waterfall koncentruje swoją 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, niekoniecznie 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ść ich ponownego przywrócenia bez aneksu umowy.

Nowy 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 oraz ewentualną kontynuację projektu z innym dostawcą.

Podsumowanie

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ł …


Zobacz kolejny artykuł z serii