Truizmem jest, że dobra umowa to zabezpieczenie każdego przedsięwzięcia. Wysoki stopień skomplikowania wdrożeń informatycznych, szybki rozwój nowych technologii, a także kosztowność tych przedsięwzięć (jak wynika z raportu The Standish Group¹ – szacuje się, że w samych Stanach Zjednoczonych co roku wydaje się 250 bilionów $ na rozwój oprogramowania, przy czym przeciętny koszt jednego projektu dla dużej firmy to 2.322.000$) sprawiają, że jest to inwestycja niezwykle ryzykowna i rzadko kiedy kończy się pełnym sukcesem. Znaczna większość projektów IT przekracza początkowy budżet, harmonogram czy też zwyczajnie nie spełnia wszystkich początkowych założeń.
Środki ochrony prawnej maksymalizujące szansę powodzenia projektu IT zależą od modelu realizacji konkretnego przedsięwzięcia. Myślę, że różnice pomiędzy waterfall i Agile wszystkim tutaj obecnym są doskonale znane, jednak chciałabym w niniejszym artykule spojrzeć na nie z punktu widzenia prawniczego i przedstawić aspekty, jakimi jako prawnicy kierujemy się, tworząc umowy wdrożeniowe.
Spoglądając na powyższą tabelkę, większość prawników nie mających do czynienia z branżą IT jako model kontraktowy wybrałoby model waterfallowy. Wspomniany model zawiera wszystkie cechy umowy maksymalizującej szanse wygranej na wypadek drogi sądowej. W przypadku branży IT umowy wdrożeniowe nie są pisane jednak na tzw. złe czasy, umowy wdrożeniowe w IT należy pisać w taki sposób, aby zmaksymalizować szansę zakończenia projektu sukcesem.
Umowy wdrożeniowe w modelu waterfall
Precyzyjnie opisany przedmiot umowy to nic innego jak dzieło, które dostawca zobowiązuje się wykonać na rzecz zleceniodawcy. Dostawca będzie zatem rozliczany z tego czy przedmiotowe dzieło dostarczył zgodnie z zamrożonymi w umowie wymaganiami. Wynagrodzenie będzie zawsze należne, jeśli dzieło będzie zgodne ze wspomnianymi wymaganiami i na czas. Jeśli dzieło nie spełni odpowiednich kryteriów, a dostawca nie odda dzieła na czas, mogą mu zostać naliczone kary umowne.
Zmiana potrzeb biznesowych klienta w przypadku realizacji projektu w oparciu o model waterfall będzie wymagała uruchomienia procesu zarządzania zmianą, mimo to zleceniodawca ryzykuje tym, iż otrzymane dzieło niekoniecznie będzie spełniać jego aktualne oczekiwania. W przypadku wyboru modelu waterfall zgrzyty między dostawcą a zleceniodawcą rozpoczną się już na etapie negocjacji umowy, a konkretnie analizy przedwdrożeniowej, co często prowadzić będzie do niepotrzebnego “nadmuchania” analizy, a tym samym przełoży się na harmonogram i koszty realizacji. Podkreślenia wymaga fakt, iż w tym modelu kontraktowym każda, nawet najdrobniejsza zmiana, będzie wymagała aneksu do umowy.
Warto w tym miejscu również zwrócić uwagę na badanie przeprowadzone przez naukowców z Uniwersytetu Missouri² na temat dezaktualizacji analizy przedwdrożeniowej w trakcie życia projektu. W latach 90-tych średni czas życia (aktualności i niezmienności) wymagań biznesowych wynosił 10-12 lat, w roku 2000 2-3 lat, a obecnie 6 miesięcy. Odpowiedź na pytanie ile z wymagań zawartych w analizie przedwdrożeniowej będzie w obecnych czasach aktualna po 2 latach od rozpoczęcia realizacji projektu wydaje się być oczywista.
Umowy wdrożeniowe w modelu Agile
Skonstruowanie dobrej umowy w modelu Agile dla prawnika na pierwszy rzut oka wydaje się niemal niemożliwe. Agile kłóci się bowiem z podstawowymi założeniami dobrych umów – brak precyzyjnie opisanego przedmiotu, brak harmonogramu prac oraz brak precyzyjnie określonych kosztów. Agile nie skupia się na dziele jako takim, ale dziele spełniającym potrzeby biznesowe zleceniodawcy w momencie zakończenia projektu. Agile to sposób dostarczenia przedmiotu umowy w oparciu o ścisłą współpracę zamawiającego z dostawcą. W umowach tego typu nacisk wyraźnie kładziony jest na procedury realizacji, a nie odbiór prac, a osobiste cechy wykonującego zlecenie mają niemałe znaczenie, dlatego też mają one wiele punktów wspólnych z kodeksową umową zlecenia.
Zasada Manifestu Agile mówiąca o współpracy osób reprezentujących biznes z zespołem produkcyjnym powinna znaleźć swoje odzwierciedlenie w klauzulach opisujących precyzyjnie zakres praw, obowiązków i odpowiedzialności za wybrane obszary projektów poszczególnych ról projektowych w Zespole Scrumowym (Product Owner, Scrum Master, Zespół Developerski). Precyzyjny opis odpowiedzialności i decyzyjności poszczególnych ról projektowych pozwoli uniknąć w przyszłości sporów na tle kompetencyjnym. Przy czym bardzo istotnym jest aby postanowienia odnoszące się do wspomnianych obszarów działania Zespołu Scrumowego nie zawierały tzw. pojęć nieostrych i zbyt ogólnych.
Zasada mówiąca o tym, iż najbardziej efektywnym i wydajnym sposobem przekazywania informacji zespołowi deweloperskiemu i wewnątrz niego jest rozmowa powinna znaleźć swoje odzwierciedlenie w zapisach wskazujących na dostępność responsywność i decyzyjność osób reprezentujących biznes oraz zespołu deweloperskiego. Dla efektywności projektu powinna to być dostępność codzienna, jeśli nie zawsze fizyczna, to chociażby za pośrednictwem środków zdalnego komunikowania się. Klauzule umowy powinny nakładać na poszczególne role projektowe bezwzględny obowiązek stawiennictwa na określonych spotkaniach.
Chociaż na pierwszy rzut oka podejście Agile w umowach wydaje się być kompletnie chaotyczne i mało precyzyjne, wczytując się w dobrze skonstruowane umowy wdrożeniowe tego typu szybko się przekonamy o ich kompleksowej i szczegółowej regulacji zakresu działań i odpowiedzialności poszczególnych członków zespołu projektowego oraz dokładnych ramach czasowych przewidzianych dla poszczególnych zdarzeń (Sprinty, Retrospekcje, Planowania czy Dzienny Scrum), od których nie przewiduje się wyjątków.
Podsumowanie
To, która z przedstawionych powyżej umów będzie bardziej odpowiednia zależy od samego projektu i oczekiwań stron. Pomimo, iż procesy wytwarzania oprogramowania Agile zostały stworzone, aby sprostać wyzwaniu jakim jest dynamiczny rozwój nowych technologii, wcale nie oznacza, iż będą one najlepszym rozwiązaniem dla każdego projektu.
¹ Project Smart 2014, The Standish Group Report CHAOS, http://www.standishgroup.com/.
² S. Atkinson, G. Benefield, Software Development: Why the Traditional Contract Model Is Not Fit for Purpose, „HICSS” 2013.
***Artykuły zamieszczane w ramach niniejszego bloga mają charakter wyłącznie informacyjny i nie stanowią porady prawnej lub opinii prawnej, ani nie mogą być traktowane jako świadczenie pomocy prawnej w jakiejkolwiek formie.
Zdjęcie: http://www.freepik.com, Designed by katemangostar / Freepik
Hej, dobry wpis. Czekam na obiecaną część dotyczącą klauzul :) Co do tabeli i sztywności dat to w Agile jak najbardziej jest miejsce na projekty typu fixed date – wówczas nieco inaczej zarządza się zmianą w projekcie, ale da się to ogarnąć. Ciekawy wątek i czekam na więcej!
Cześć Tomek! Dziękuje za miłe słowa :). W umowach tak na prawdę możemy zawrzeć wszystko o ile mieści się to w granicach prawa. W artykule bardziej chodziło o to, żeby pokazać wyraźne różnice pomiędzy Waterfall i Agile. Nowy wpis już wkrótce. Pozdrawiam!