Aspekty prawne umowy na wykonanie projektu w metodyce zwinnej (agile)

Czym wyróżnia się metodyka agile?

Jak wskazuje sama nazwa, programowanie zwinne (ang. agile) zakłada dużą dynamikę poszczególnych etapów developmentu software’u. Oczywiście na samym początku zamawiającemu towarzyszy wizja jak taki gotowy projekt ma wyglądać, a zespołowi deweloperów, w jaki sposób należy go wykonać, ale całość prac jest podzielona na niewielkie etapy, tzw. sprinty, które mogą trwać kilka tygodni, ale też zaledwie kilka dni.

Ideą metodyki agile jest, aby po każdym sprincie (lub zestawie sprintów) przeanalizować efekt prac pod kątem oczekiwań i wymagań zamawiającego po to, aby kolejny etap prac (tzw. iteracje) przyniósł lepiej zoptymalizowane efekty. To dlatego w teorii metodykę agile określa się programowaniem iteracyjno-przyrostowym. W praktyce wyróżnia się szereg praktyk na działające oprogramowanie z prawnego punktu widzenia, typu agile, jak np. scrum, dynamic system development method czy adaptive software development oraz takie w ramach poszczególnych sprintów czy umowa zlecenia lub toku projektu. Choć różnią się one z punktu widzenia metodologii pracy programistów, założenia każdej z nich obejmują następujące etapy w ramach projektu:

planowanie;
projektowanie;
programowanie;
testowanie;
wdrożenie systemu;,
informacja zwrotna.

Trudność w tworzeniu umów uwzględniających pracę w modelu zwinnym polega na tym, że kontrakt powinien umożliwić płynne reagowanie na zmiany zachodzące w środowisku pracy oraz kwestii związanych z przeniesieniem praw autorskich, szczególnie przy projektach agile, czy jeśli chodzi o negocjowanie umów związanych z prawem zamówień publicznych dla realizacji projektów zespołu deweloperskiego od strony klienta, dla metodyk zwinnych czy feature driven development opartych o zwinne podejście. Chodzi nie tylko o zmiany założeń samego projektu, ale także zmiany składu osobowego zespołu deweloperów, poszerzenie wymagań przez zamawiającego czy dopasowanie założeń projektu do ewoluującej technologii. Jak odzwierciedlić tę elastyczność w umowie?

Oznaczenie stron umowy oraz zespołu wykonawcy

Przy oznaczaniu stron umowy należy wskazać osoby, które będą reprezentowały zarówno zamawiającego, jak i wykonawcę. Niezależnie od tego warto zastrzec skład osobowy, jaki deklaruje wykonawca, np. dwóch grafików albo trzech programistów i jeden tester.

Dzięki takiemu postanowieniu ewentualna rotacja personalna nie będzie miała znaczenia dla zakresu praw i obowiązków stron i sprowadzi się do poinformowania zamawiającego o tym, że dana osoba nie pracuje już nad projektem, a jej miejsce zajął inny specjalista.

Aby zapewnić zamawiającemu wpływ na kompetencje osób zatrudnionych przez wykonawcę, warto rozważyć wprowadzenia do umowy postanowienia, które przyznaje zamawiającego prawo do akceptacji wyboru specjalisty dokonanego przez software house z uwzględnieniem jego kwalifikacji zawodowych i doświadczenia.

Jak określić przedmiot umowy?

Umowy IT mogą kojarzyć się z obszerną specyfikacją techniczną aplikacji czy architektury systemu. W przypadku metodyki agile trudno o jednoznaczne wskazanie specyfikacji, ponieważ założenia projektu będą się na bieżąco zmieniały. W rezultacie wiele z takich kontraktów nie stanowi typowej umowy o dzieło, ale jest umową zlecenie (o świadczenie usług) albo konstrukcją hybrydową, która łączy umowę o dzieło z umową zlecenie.

Programowanie zwinne powinno zakładać jedynie ogólny cel pracy wykonawcy, konkretne założenia precyzyjne należy umieszczać w briefach do konkretnych sprintów, które zawierają wyszczególnienie zakresu funkcjonalności aplikacji na danym etapie. W ten sposób wykonawca unika zarzutu, że działa „obok” zaleceń zamawiającego, a nie w zgodzie z nimi.

Pomimo braku klasycznie rozumianego przedmiotu umowy należy dokładnie określić, do jakiego rezultatu dążą strony. Tylko w taki sposób będzie możliwe jednoznaczne określenie, że projekt został zrealizowany. Można tego dokonać np. poprzez określenie docelowych funkcji, jakie ma spełniać aplikacja.

Uproszczenie procesu decyzyjnego

Ważnym aspektem umowy w omawianym kontekście jest zapewnienie możliwości płynnego i jednocześnie wiążącego wprowadzania zmian w umowie. Dlatego strony powinny unikać tworzenia wielostopniowych procesów akceptacji czy nadmiernie rozbudowanych protokołów odbioru.

Warto pamiętać, aby kompetencje do akceptacji zmian posiadał osoba bezpośrednio odpowiedzialna za komunikację z zespołem programistów (np. kierownik działu). Przerzucenie tego obowiązku na zarząd sprawi, że plastyczność umowy będzie niewielka, ponieważ na każdy akcept trzeba będzie długo czekać. Może się też okazać, że osoby zarządzające spółką nie dysponują wiedzą technologiczną wystarczającą dla nadania projektowi właściwego kierunku i znacznie więcej może w tej materii wnieść pracownik niższego szczebla.

Aby zamawiający miał gwarancję, że zmiany w umowie będzie podejmowała właściwa osoba, warto rozważyć udzielenie stosownych pełnomocnictw o różnym, ale precyzyjnie określonym zakresie.

Innym sposobem na ułatwienie pracy jest wprowadzenie krótkich (nawet kilkudniowych) terminów nie tylko na ukończenie kolejnych sprintów, ale także na ich akceptację lub wprowadzenie zmian.

Skuteczną metodą jest zastąpienie klasycznego postanowienia, które zakłada formę pisemną dla wszelkich zmian w umowie jedną z dwóch możliwości:

wprowadzenie do umowy możliwości skutecznej zmiany umowy za pomocą formy dokumentowej (np. e-maila);
upewnienie się z wyprzedzeniem, że obie strony umowy dysponują kwalifikowanym podpisem elektronicznym, który w rozumieniu art. 781 k.c. zastępuje formę pisemną.

Nie wszystkie zmiany umowy mogą być dokonane z zachowaniem formy dokumentowej. Jako przykład można podać zawarcie umowy o przeniesienie praw autorskich. Zgodnie z art. 53 ustawy o prawie autorskim i prawach pokrewnych dla ważności takiej umowy niezbędne jest zachowanie formy pisemnej.

Kiedy warto zachować formę pisemną zmiany umowy?

O ile w kwestiach dotyczących weryfikacji bieżących rezultatów można zdecydować się na formę dokumentową, warto zastrzec formę pisemną dla kwestii o kluczowym znaczeniu dla całego projektu, np. zwiększenia budżetu, zmiany głównych założeń zamówienia, możliwości wypowiedzenia umowy czy zmiana harmonogramu ukończenia całości prac (nie poszczególnych sprintów).

Dzięki temu umowa będzie elastyczna tam, gdzie jest to wymagane, ale jej główny szkielet będzie chroniony przed pochopnymi decyzjami.

Terminy w metodyce agile

Programowanie wykorzystujące metodykę agile zakłada wiele zmian, ale łatwiej będzie zachować nad nimi kontrolę, jeżeli częścią umowy będzie harmonogram poszczególnych etapów prac. Warto wprowadzić terminy ukończenia poszczególnych sprintów z zastrzeżeniem, że nie mogą być one przesunięte więcej niż raz lub dwa razy i o nie więcej niż określona liczba dni. Dopuszczalne odchylenia od pierwotnych założeń nie powinny też wpływać negatywnie na termin ukończenia całego projektu Dla stworzenia motywacji termin może zostać zabezpieczony karą umowną, która będzie tworzyła instrument chroniący przede wszystkim zamawiającego.

W kontekście terminów warto wspomnieć, że bardzo ważne jest aktualizowanie wszelkiego rodzaju zaleceń, feedbacku czy backlogów w jak najkrótszym czasie. W umowie można wprowadzić nawet określony przedział czasowy, np. nie więcej niż 24 godziny. W praktyce przekazywanie informacji zwrotnej i określanie poszczególnych sprintów odbywa się z wykonywaniem narzędzi typu Discord lub Asana, które zapewniają szybki wgląd w zakres obowiązków wszystkim członkom zespołu. To również miejsce na określenie priorytetów poszczególnych etapów prac i przydzielenie ich poszczególnym osobom (działanie typowe dla modelu kaskadowego programowania, tzw. waterfall).

Sankcjonowanie ewentualnych opóźnień zwykle następuje z wykorzystaniem mechanizmu kary umownej. Strony mogą też zadecydować, że przekroczenie określonego pułapu czasowego (np. 10% w skali całego projektu albo 25% w skali jednego sprintu) uzasadnia odstąpienie od umowy bez zachowania okresu wypowiedzenia.

Kontrola wykonania umowy

Specyfika zwinnego programowania zakłada podział prac na wiele małych etapów w celu jak najszybszego nadania im właściwego kierunku. Dlatego tak ważne jest, aby zamawiający przeprowadzał kontrolę umowy regularnie (np. co każdy sprint albo milestone), a nie wyłącznie po oddaniu prac.

Kontrola powinna odbywać się w sposób pozwalający na szybką reakcję ze strony dewelopera i w możliwie krótkim czasie. Z punktu widzenia wykonawcy zasadne może okazać się umieszczenie w umowie postanowienia, które zakłada, że zastrzeżenia zgłoszone po upływie 72 godzin od oddania fragmentu prac nie zostaną uwzględnione. W ten sposób strony zachowują dynamikę współpracy. W umowie warto zdefiniować obowiązki developera w razie zgłoszenia poprawek i dodatkowe wynagrodzenie w tym zakresie. Aby niepotrzebnie nie przeciągać prac, sprint, względem którego nie zgłoszono zastrzeżeń, uważa się za zakończony i oddany bez uwag.

Jak określić wynagrodzenie w modelu programowania agile?

W przypadku programowania zwinnego wynagrodzenie rzadko określane jest w sposób ryczałtowy, ponieważ osiągnięcie celu wymaga zwykle wielu iteracji i powtarzania tych samych czynności. W praktyce dobrym rozwiązaniem może być np. określenie liczby godzin dla danego sprintu, za jakie wykonawca otrzyma wynagrodzenie (z uwzględnieniem złożoności czynności na konkretnym etapie) przy założeniu utrzymania odpowiedniego poziomu funkcjonalności. Alternatywnym modelem wynagradzania jest odwołanie się do stawki godzinowej lub dziennej każdego z członków zespołu.

Rozliczenie może następować na koniec prac albo po finalizacji określonych kamieni milowych. Zamawiający powinien zadbać o określenie górnej wysokości wynagrodzenia dla całego projektu.

Co z prawami autorskimi do aplikacji?

Decydując się na pracę w metodyce zwinnej, strony powinny ustalić, na jakim etapie i w jakim zakresie prawa autorskie są przenoszone na zamawiającego. Ma to kluczowe znaczenie, ponieważ zaniedbanie na tym polu doprowadzi do sytuacji, w której zamawiający zapłaci za wykonanie prac, z których efektów nie będzie mógł później skorzystać. Przeniesienie praw autorskich majątkowych może nastąpić:

na koniec projektu – rozwiązanie opłacalne dla wykonawcy, ale nie dla zamawiającego;
po każdym sprincie – rozwiązanie opłacalne dla zamawiającego, w mniejszym stopniu dla wykonawcy;
po każdym milestonie – rozwiązanie kompromisowe.

Jak rozwiązać umowę o programowanie w modelu agile?

Każda umowa IT powinna przewidywać tzw. exit plan, czyli rozwiązania na wypadek zakończenia współpracy. Strony mogą uwzględnić zarówno opcję wypowiedzenia terminowego, jak i ze skutkiem natychmiastowym, ale w każdym z tych przypadków trzeba pamiętać m.in]. o:

wydaniu dokumentacji;
przekazaniu know-how;
udostępnieniu kodu źródłowego i jego ewentualnym depozycie;
oferowaniu wsparcia utrzymaniowego przez określony czas.

Skonstruowanie dobrej umowy w IT wymaga nie tylko znajomości przepisów prawa, ale także specyfiki branży. Dlatego konstruując kontrakt, warto rozważyć skorzystanie z pomocy kancelarii prawnej z doświadczeniem w obszarze nowych technologii i obsłudze software house’ów.

Pytania i odpowiedzi

Klient zażądał, aby software house ustalił wynagrodzenie za każdy sprint w sposób ryczałtowy. Czy to dobre rozwiązanie?

Z punktu widzenia zamawiającego wynagrodzenie ryczałtowe pozwala na jednoznaczne określenie całkowitej ceny projektu. Z perspektywy wykonawcy jest to rozwiązanie ryzykowne, ponieważ łatwo o niedoszacowanie liczby godzin niezbędnych do wykonania zadania. Za ewentualne nadgodziny software house nie otrzyma wynagrodzenia.

W jaki sposób zamawiający może zabezpieczyć swoje interesy biznesowe?

Umowie o współpracę powinny towarzyszyć również dodatkowe zabezpieczenia w postaci NDA oraz umowy o zakazie konkurencji. W obu przypadkach ochronę interesów zamawiającego chroni odpowiednio wysoka kara umowna.

MAM PYTANIA | JESTEM ZAINTERESOWANY / A OFERTĄ

Zaufali nam: