Zmiany na rynku IT mają bezpośredni wpływ na stosowane modele kontraktowe. Coraz częściej wykorzystywaną alternatywą dla metodyki Waterfall jest zarządzanie projektem w oparciu o programowanie iteracyjno-przyrostowe, tj. Agile. Ma to bezpośrednie przełożenie na kształt umów dot. procesu tworzenia danego rozwiązania IT.
W ramach współpracy przy projekcie IT warto zawrzeć umowę wdrożeniową. Określając w jej treści, m.in.: zasady komunikacji, etapy pracy czy kwestie IP – maksymalizujemy szansę powodzenia projektu. Jakie są najpopularniejsze modele kontraktowe w branży IT? Czym się one wyróżniają i jakie są skutki stosowania każdego z nich?
Metodyka a wybór rodzaju umowy IT
Często kontrakt na wdrożenie jest kwalifikowany jako umowa o dzieło. Jednak możliwe jest również, że będzie miał charakter umowy o świadczenie usług.
Głównym czynnikiem różnicującym tę kwestię jest przedmiot umowy, czyli konkretne określenie czego ma ona dotyczyć. Umowa o dzieło jest umową rezultatu, czyli zakłada wykonanie określonego dzieła. Z kolei w umowie o świadczenie usług istotne jest staranne działanie Wykonawcy.
Nie bez znaczenia pozostaje kwestia wybranej metodyki pracy.
- Jeśli przedsięwzięcie realizowane jest przy wykorzystaniu metodyki Waterfall – kontrakt najczęściej przyjmie formę umowy o dzieło.
W tym modelu strony z góry umawiają się na stworzenie konkretnego rozwiązania IT. Wykonawca jest rozliczany z efektu swojej pracy, tj. stworzenia oprogramowania/systemu zgodnie ze specyfikacją Zamawiającego. - W przypadku metodyki Agile będziemy mieli najczęściej do czynienia z umową o świadczenie usług (zlecenie).
Strony wówczas nie umawiają się na stworzenie konkretnego rozwiązania IT. Wykonawca rozliczany jest ze starannego prowadzenia czynności na rzecz Zamawiającego. Metodyka ta zakłada też ścisłą współpracę stron.
Jeśli strony umawiają się np. na stworzenie oraz późniejsze serwisowanie oprogramowania – umowa wdrożeniowa może zawierać elementy zarówno umowy o dzieło, jak i świadczenia usług.
Model umowy o dzieło a umowa zlecenie – porównanie
Poniższa tabela określa różnice pomiędzy umową o dzieło a zleceniem.
Cechy | Umowa o dzieło | Umowa zlecenie (o świadczenie usług) |
---|---|---|
Na co umawiają się strony? [przedmiot umowy] | Wykonawca stworzy określone dzieło np. program komputerowy. Zamawiający zapłaci wynagrodzenie za przygotowany program. | Wykonawca będzie w sposób ciągły świadczył usługi na rzecz drugiej strony. Zamawiający będzie rozliczał Wykonawcę za staranne działanie i profesjonalizm. |
Czy dojdzie do oficjalnego przekazania i akceptacji efektów pracy Wykonawcy? [odbiór] | Tak. Wykonawca przekazuje rezultat swoich prac Zamawiającemu, który po akceptacji jest zobowiązany do jego odbioru. | Nie. Mamy do czynienia z obowiązkiem świadczenia usług stale w czasie. |
Jak wygląda współdziałanie stron? | Współdziałanie stron jest charakterystyczną cechą umowy o dzieło (art. 640 k.c.). Zamawiający powinien zaangażować się w proces tworzenia dzieła. Umowa może dokładnie określać, czym jest współdziałanie. | Brak. Nie jest to charakterystyczna cecha tego modelu kontraktowego. |
Czy Wykonawca odpowiada za wady efektów swojej pracy? [rękojmia] | Tak. Wykonawca odpowiada za wady fizyczne dzieła* *standardem jest wyłączenie tego rodzaju odpowiedzialności w umowach IT. | Nie. Chodzi o staranne działanie, a nie rezultat. |
Jak można rozwiązać umowę? | Jest to umowa nieterminowa. Strony mogą tylko od niej odstąpić. Skutek: wstecz – umowa będzie traktowana tak jakby nigdy nie była zawarta. Dlatego strony będą musiały zwrócić to, co sobie świadczyły, tj. zapłacone wynagrodzenie (Wykonawca) i rezultat prac (Zamawiający). | Może być umową terminową lub zawartą na czas nieoznaczony. Strony mogą ją wypowiedzieć. Skutek: na przyszłość – strony mogą zachować to, co sobie świadczyły. |
Modele mieszane
Umowa wdrożeniowa w branży IT może mieć charakter mieszany i zawierać elementy umowy o dzieło, zlecenia, dostawy, a nawet najmu. Dzieje się tak w sytuacji, gdy projekt obejmuje oprócz dostarczenia danego rozwiązania m.in. dalsze utrzymywanie go czy rozwijanie. Warto w tym miejscu również zaznaczyć, że do poszczególnych części umowy w modelu mieszanym będą miały zastosowanie inne przepisy. Przykładowo umowę można będzie wypowiedzieć tylko w części dot. świadczonych usług, ale nie w zakresie wykonania oprogramowania.
W praktyce możemy spotkać różne typy mieszanych modeli kontraktowych. Szczególnym rodzajem jest umowa o świadczenie usług programistycznych tzw. body leasing, w ramach którego dochodzi do wynajmu pracowników.
Wpływ metodyki Waterfall na model kontraktowy
Waterfall zakłada podział realizacji projektu na sztywne, długotrwałe etapy (analiza, projektowanie, implementacja, testowanie, utrzymanie). Przejście z jednego do drugiego jest możliwe tylko po akceptacji poprzedniego kroku przez Zamawiającego. Współpraca jest sformalizowana. Strony z góry umawiają się na osiągnięcie konkretnego rezultatu w postaci wykonania np. systemu informatycznego.
Projekt w tej metodyce zostaje zakończony sukcesem w momencie, gdy:
- efekt pracy Wykonawcy spełni wymagania Zamawiającego,
- nie będzie opóźnień w realizacji projektu,
- program lub system przejdzie testy pozytywnie.
W praktyce wybór metodyki Waterfall najczęściej będzie skutkował zawarciem kontraktu na wdrożenie w formie umowy o dzieło – umowy rezultatu. Może to skutkować różnymi trudnościami na kolejnych etapach projektu.
#PRZYKŁAD 1
W takim modelu już na etapie konstruowania umowy będzie niezbędna precyzyjna specyfikacja rozwiązania-dzieła. Dlatego Zamawiający musi dokładnie wiedzieć, czego chce i najlepiej, gdy Wykonawca wie, że właśnie takie rozwiązanie jest w stanie dostarczyć.
Jest to istotna kwestia, ponieważ w trakcie prac, np. na etapie testów, niekiedy okazuje się, że jednak czegoś nie można zrobić zgodnie z wymaganiami Zamawiającego. Często jedyne co pozostaje w takiej sytuacji to powtórzyć cały cykl od nowa. Jest to wynik konieczności akceptacji przez Zamawiającego każdego z etapów przed przejściem do kolejnego. Sytuacja tego rodzaju generuje dodatkowe koszty, opóźnienia, problemy z jakością i szkody w relacji biznesowej.
Co może pomóc?
Poświęcenie większej ilości czasu przez obie strony na przeprowadzenie analizy przedwdrożeniowej.
Niekiedy warto pokusić się o PoC (Proof of Concept) lub nawet o stworzenie MVP (Minimum Viable Product). Dzięki temu możemy uniknąć fiaska projektu i dodatkowych strat finansowych w przyszłości. Nie bez znaczenia dla dalszej realizacji przedsięwzięcia pozostaje również sprawdzenie, jak wygląda komunikacja pomiędzy stronami na tak wczesnym etapie.
#PRZYKŁAD 2
Realizacja projektu w metodyce Waterfall zakłada sformalizowaną i mniej elastyczną współpracę. Dodatkowo skutkuje wolniejszym tempem prac. Z tego powodu, jeżeli nie określimy zasad współpracy inaczej, Zamawiający po przekazaniu specyfikacji dzieła może ograniczyć swój udział w projekcie do minimum. W skrajnych sytuacjach oznacza to brak możliwości uzyskania koniecznego feedbacku i problemy przy odbiorze.
Co warto zawrzeć w umowie?
Zasady współpracy stron, które zobligują Zamawiającego do większego zaangażowania się w projekt np.:
- określenie rodzaju informacji oraz terminu na ich przekazanie,
- szczegółowe uregulowanie zasad zgłaszania poprawek (terminy, ilość) i odbioru końcowego.
Wpływ metodyki Agile na kształt umowy wdrożeniowej
W przypadku metod zwinnych (np. scrum, kanban) strony dążą do stworzenia rozwiązania IT w oparciu o bieżącą weryfikację założeń Zamawiającego. Skutkiem tego proces tworzenia oprogramowania opiera się na krótkich etapach – serii powtarzalnych sprintów. Każdy sprint zakłada: projektowanie, kodowanie i testowanie.
Ważniejsze dla stron jest bieżące reagowanie na zmiany, jakościowa realizacja projektu oraz ścisła współpraca niż procedury i zbieranie dokumentacji. Agile znajduje zastosowanie np. w procesie tworzenia innowacyjnych rozwiązań IT, których założenia nie mogą zostać konkretnie określone już na początku współpracy.
Zatem jeżeli Wykonawca zobowiązuje się do podejmowania określonych czynności w zakresie wdrażania na rzecz Zamawiającego – będziemy mieli do czynienia z umową o świadczenie usług.
Mimo wielu zalet wypływających z zastosowania tej metodyki (np. szybsze wykrywanie i usuwanie błędów) – brak uregulowania pewnych kwestii w umowie może mieć negatywne skutki dla powodzenia projektu IT.
#PRZYKŁAD 1
Realizując projekt w metodyce Agile, strony nie umawiają się z góry na wykonanie określonego dzieła. Wykonawca świadczy swoje usługi na rzecz Zamawiającego w zakresie wdrażania. Na bieżąco weryfikuje jego założenia dot. projektu. Taka sytuacja może rodzić ryzyko wprowadzania ciągłych zmian wskutek działania klienta biznesowego, a co za tym opóźnień w realizacji projektu.
Co warto określić w umowie?
Zasady ustalenia ostatecznych wymagań Zamawiającego w zakresie planowanego rozwiązania np.:
- opracowanie załącznika do umowy określającego funkcjonalności, które musi spełniać dane rozwiązanie IT tak, aby jego działanie było możliwe w infrastrukturze Zamawiającego,
- ustalenie, które z iteracji są niezbędne dla przejścia do kolejnych etapów.
#PRZYKŁAD 2
W ramach projektu IT prowadzonego w metodykach zwinnych pojawia się sporo zmian, które każdorazowo podlegają weryfikacji i akceptacji Zamawiającego. W związku z tym mogą wystąpić problemy z opóźnieniem w przekazaniu feedbacku. Dodatkowo wyzwaniem często okazuje się kwestia rozmytej odpowiedzialności członków zespołu lub brak dobrej samoorganizacji.
Co warto ustalić?
Zasady komunikacji i odpowiedzialności stron np.:
- wskazanie osoby decyzyjnej z ramienia Zamawiającego w sprawach dot. projektu, z którą zespół będzie mógł się kontaktować – Product Ownera,
- określenie zespołów, które będą samodzielnie organizować swoją pracę i w pełni odpowiadać za efekty swoich działań lub ich braku.
Podsumowanie
O charakterze umowy przesądza jej treść, nie tytuł. Określenie podstawowych założeń kontraktu ma wpływ na jego przyporządkowanie do danego modelu. To z kolei skutkuje konkretnym określeniem praw i obowiązków stron. W sytuacji ewentualnego sporu – o tym, jakiego rodzaju umowa została zawarta, będzie decydował sąd. Wówczas brak właściwego określenia kluczowych kwestii w umowie, może negatywnie odbić się na sytuacji stron w zakresie ich odpowiedzialności.
Aby uniknąć zatem niepotrzebnych komplikacji, warto świadomie podejmować decyzje dot. kształtu umowy wdrożeniowej. Stanowi to duże wyzwanie zarówno dla początkujących programistów, jak i firm funkcjonujących w branży IT od lat. Dlatego jeśli zależy Ci na zawarciu jasno sformułowanej umowy odpowiadającej Twoim potrzebom – skorzystaj z pomocy specjalizującego się w tym zakresie prawnika. Zapraszam!
Źródło zdjęcia: Lukas
Teksty umieszczone na Linkedin lub mojej stronie internetowej mają charakter wyłącznie edukacyjny. Proszę nie traktuj ich jako porady prawnej w konkretnej sprawie. Sposób stosowania przepisów może się znacznie różnić w zależności od danej sytuacji. Informacje zawarte w artykułach nie dotyczą konkretnej sprawy a każdy stan faktyczny wymaga odrębnej analizy prawnej.