Na co zwrócić uwagę, czytając umowę wdrożeniową IT otrzymaną od Klienta? Poradnik dla software house’ów #2

Na rynku IT objętość umów wdrożeniowych (czyli szczególnego rodzaju umów o dzieło) rośnie wraz z poziomem złożoności samego wdrożenia oraz wysokości wynagrodzenia wykonawcy. Zasada jest bardzo prosta. Im większy projekt wykonujesz dla swojego klienta, tym zajmuje on więcej czasu. W konsekwencji tego znacząco zwiększa się prawdopodobieństwo, że coś we współpracy z zamawiającym się popsuje. Może to być zwykły problem komunikacyjny, ale równie dobrze może to być problem wynikający z braku współpracy klienta z software house’m lub opóźnieniami spowodowanymi błędami Twojego podwykonawcy. Artykuł jest częścią serii dotyczącej umowy wdrożeniowej, poniżej znajdziesz odnośniki do pozostałych wpisów. 

Zamów wzór umowy wdrożeniowej IT!

Klient naciska na swój wzór umowy wdrożeniowej? Przygotuj własny zestaw umów IT!

Każda firma usługowa, także software house, powinna mieć przygotowany zestaw swoich standardowych umów, które następnie będzie mogła przedstawić swoim potencjalnym klientom.

Dzięki temu od razu można przedstawić umowę, która z automatu chroni interesy jej autora. Ciężar analizy umowy zostaje wtedy przerzucony na klienta. Oczywiście istnieją sytuacje, jak np. współpraca z korporacjami, gdy rozpoczęcie współpracy w oparciu o własną umowę będzie niemożliwe.

Jednak w większości przypadków to właśnie własny wzór umowy wdrożeniowej może uratować sytuację podczas kryzysu.

Warto pamiętać, że posiadanie własnych wzorów umów to nie tylko kwestia wygody, ale przede wszystkim zarządzania ryzykiem biznesowym. Dobrze przygotowany zestaw umów powinien zawierać nie tylko standardową umowę wdrożeniową, ale także:

• umowę NDA (Non-Disclosure Agreement) do ochrony informacji poufnych na etapie wstępnych rozmów;
• umowę na analizę przedwdrożeniową lub proof of concept;
• umowę serwisową/SLA na okres powdrożeniowy;
• umowę ramową na świadczenie usług programistycznych z zamówieniami (SoW);
• ogólne warunki współpracy.

Negocjowanie oraz zawieranie umowy IT

Co w sytuacji, gdy nie masz wzorów standardowych umów przygotowanych dla Twojego software house’u i za każdym razem musisz negocjować treść umowy przesłanej przez Klienta?

Poniżej znajdziesz kilka kluczowych elementów, na które warto spojrzeć, aby wręcz w kilkadziesiąt sekund zorientować się co w trawie piszczy. Oczywiście elementem profesjonalnie wykonanej analizy umowy jest jej dokładna lektura.

Jednakże często klienci proszą mnie o szybką ocenę wykonaną ,,na oko”. Na co wtedy zwracam uwagę?

Najważniejsze zagadnienia, na które zwracam uwagę w pierwszej kolejności:

1. komparycja (oznaczenie stron w umowie),
2. odstąpienie od umowy,
3. przeniesienie autorskich praw majątkowych,
4. odpowiedzialność,
5. zasady współpracy stron podczas realizacji przedmiotu umowy.

Do tej listy warto dodać również warunki płatności i model rozliczeń, procedury zarządzania zmianami (change management), mechanizmy rozwiązywania sporów, klauzule dotyczące siły wyższej oraz postanowienia o poufności i ich okres obowiązywania.

Poniżej znajdziesz trochę szersze omówienie powyżej wskazanych zagadnień.

Komparycja w umowie wdrożeniowej

Pierwszym elementem, który rzuca się w oczy jest komparycja umowy, czyli oznaczenie jej stron. Możesz się dziwić dlaczego w ogóle o tym piszę skoro nie ma to wpływu na realizację postanowień umowy regulujących współpracę stron. Z mojego doświadczenia wynika, że jeżeli komparycja została napisana niechlujnie to  tak samo mogły zostać potraktowane inne kluczowe elementy umowy. Zasada ta sprawdza się niemal w 100% przypadków.

Sprawdź również:  Jak poprawnie oznaczyć strony umowy wdrożeniowej?

Odstąpienie i wypowiedzenie w umowie wdrożeniowej

Odnoszę wrażenie, że właśnie ten termin sprawia najwięcej problemu. Odstąpienie najczęściej bywa mylone w wypowiedzeniem umowy.

Warto zaznaczyć, że w polskim prawie nie istnieje możliwość wypowiedzenia umowy o dzieło, jaką jest umowa wdrożeniowa. Zamiast tego istnieje możliwość odstąpienia od umowy. Oba te terminy w języku prawnym oznaczają jednak co innego i mają różne konsekwencje.

Wypowiedzenie jest typowym sposobem zakończenia współpracy opartej na umowie zlecenia, czyli umowie, w której najważniejsze jest staranne działanie, a nie rezultat. Zazwyczaj takie umowy są terminowe.

W odróżnieniu od wypowiedzenia, odstąpienie dotyczy współpracy opartej na umowie o dzieło, czyli umowie, w której najważniejszy jest rezultat np. wykonanie aplikacji. Umowy o dzieło, mimo że najczęściej zawierają termin wykonania dzieła, nie są umowami terminowymi.

Jakie są konsekwencje? Wypowiadając umowę, strony kończą współpracę z ustalonym dniem. Wykonujący usługę zachowuje wynagrodzenie, zaś podmiot, dla którego ta usługa została wykonana zachowuje wszelkie prawa do jej efektów.

W przypadku odstąpienia sytuacja ma się inaczej. Gdy jedna ze stron korzysta z prawa odstąpienia, skutkiem jest konieczność wzajemnego zwrotu tego, co strony sobie do tej pory świadczyły. 

Zgodnie z kodeksowym rozwiązaniem wykonawca zwraca wynagrodzenie lub otrzymaną do momentu odstąpienia jego część, zaś zamawiający powinien zwrócić zrealizowaną przez wykonawcę część dzieła – a co za tym idzie nie ma prawa do korzystania z niego w przyszłości.

W pierwszej kolejności analizując umowę zwróć więc uwagę na to czy umowa wdrożeniowa zaproponowana przez klienta przewiduje możliwość jej wypowiedzenia.

Jeśli tak to z pewnością należy tę kwestię poruszyć podczas negocjacji warunków umowy, aby postanowienia umowne nie były sprzeczne z obowiązującym prawem i w konsekwencji nie doprowadziły do sporów w jej interpretacji.

W drugiej kolejności upewnij się, czy kwestia odstąpienia jest w ogóle poruszana w umowie. Oczywiście, jeśli nie jest ona poruszana, nie znaczy to, że odstąpienie nie będzie Ciebie i Twojego klienta obowiązywało.

Nic bardziej mylnego – będzie obowiązywało, ale jego realizacja będzie musiała odbyć się w myśl przepisów zawartych w kodeksie cywilnym. Jest to szczególnie groźna sytuacja dla Ciebie jako wykonawcy. Warto zatem taki stan rzeczy odpowiednio zmodyfikować w umowie.

Możesz spotkać się z sytuacją, że druga strona lub jej prawnik powie Ci, że nie można modyfikować kodeksowego modelu odstąpienia od umowy. Sam się z tym spotkałem. Nie jest to prawda.

Kluczowe aspekty odstąpienia, które warto uregulować w umowie, obejmują przede wszystkim precyzyjne określenie przyczyn odstąpienia. Należy dokładnie wskazać, jakie okoliczności uprawniają każdą ze stron do odstąpienia, takie jak istotne naruszenie umowy czy opóźnienie przekraczające określoną liczbę dni.

Równie ważne jest ustalenie konkretnego terminu, w którym strona może skorzystać z prawa odstąpienia, na przykład 30 dni od wystąpienia przyczyny. Forma odstąpienia również wymaga doprecyzowania – warto określić, że odstąpienie wymaga formy pisemnej pod rygorem nieważności.

Szczegółowe zasady rozliczeń po odstąpieniu stanowią kolejny istotny element, w tym możliwość zachowania wynagrodzenia za ukończone etapy. Nie można też zapomnieć o uregulowaniu kwestii praw do już wykonanych części systemu.

Szczególnie istotne jest wprowadzenie klauzuli „częściowego odstąpienia”, która pozwala zachować wynagrodzenie i prawa do zakończonych etapów projektu. Bez takiej klauzuli software house może stracić całe wynagrodzenie mimo wykonania znacznej części prac.

Sprawdź również: Prawo odstąpienia od umowy wdrożeniowej

Autorskie prawa majątkowe w umowie wdrożeniowej

Kolejnym elementem umowy wdrożeniowej, na który warto zwrócić uwagę jest klauzula przeniesienia autorskich praw majątkowych (oczywiście jeśli strony wybrały taki model zarządzania własnością intelektualną).

Przed analizą klauzuli przeniesienia praw, warto rozważyć alternatywne modele zarządzania własnością intelektualną. Model licencyjny zakłada, że software house zachowuje prawa autorskie, a klient otrzymuje licencję wieczystą lub czasową. Model mieszany przewiduje przeniesienie praw do dedykowanych rozwiązań przy jednoczesnym udzieleniu licencji na komponenty standardowe. Z kolei model SaaS oznacza brak przeniesienia praw, gdzie klient korzysta z oprogramowania jako usługi.

Długość postanowienia dotyczącego praw autorskich

Pierwszym znakiem ostrzegawczym powinna być długość postanowienia dotyczącego praw autorskich. Jeśli takie postanowienie jest krótkie lub wręcz jednozdaniowe (bo z takimi także się niestety spotkałem), rośnie ryzyko wzajemnego niezrozumienia stron.

Zamawiający, proponując tak krótką klauzulę przeniesienia autorskich praw majątkowych, może zakładać, że wykonawca przenosi na niego wszystko, co tylko możliwe w nieograniczonym zakresie. Wykonawca w tym samym czasie może dojść do wniosku, że krótkie postanowienie jest mu na rękę, gdyż zamawiający nie zawarł w niej wielu ważnych dla siebie kwestii.

Z drugiej strony zbyt długa klauzula może oznaczać, że zamawiający bardzo szeroko opisuje obowiązki wykonawcy np. w zakresie zaniechania wykonywania autorskich praw osobistych, w zakresie przeniesienia praw zależnych, czy też w zakresie przeniesienia praw do oprogramowania standardowego wykonawcy.

Profesjonalna klauzula dotycząca praw autorskich powinna regulować co najmniej zakres terytorialny przeniesienia praw, określając czy dotyczy on Polski, Europy czy całego świata. Istotne jest również uregulowanie praw zależnych i prawa zezwalania na wykonywanie praw zależnych. Należy też jasno określić, czy wynagrodzenie za przeniesienie praw jest wliczone w cenę umowy. Wykonawca powinien udzielić gwarancji dotyczących nienaruszania praw osób trzecich oraz określić procedurę zgłaszania i usuwania wad prawnych.

Moment przeniesienia praw autorskich

W dalszej kolejności, czytając umowę wdrożeniową przesłaną przez klienta, zwróć uwagę na moment przeniesienia autorskich praw majątkowych. W Twoim interesie jest by oznaczyć go w taki sposób, aby zabezpieczał zapłatę należnego Ci wynagrodzenia.

Najczęściej spotykane momenty przeniesienia praw to przeniesienie z chwilą utworzenia, które jest najmniej korzystne dla wykonawcy. Model kompromisowy zakłada przeniesienie z chwilą odbioru poszczególnych etapów.

Najbezpieczniejsze dla wykonawcy jest przeniesienie z chwilą zapłaty całości wynagrodzenia, natomiast standardem rynkowym jest przeniesienie z chwilą podpisania protokołu odbioru końcowego.

Rekomenduje się powiązanie momentu przeniesienia praw z zapłatą wynagrodzenia poprzez zastrzeżenie warunku rozwiązującego. W tym modelu prawa przechodzą z chwilą odbioru, ale pod warunkiem zapłaty. Brak zapłaty w terminie powoduje automatyczny powrót praw do wykonawcy.

Prowadząc software house z pewnością udało Ci się wypracować standardowe rozwiązania, które stosujesz podczas realizacji projektów dla różnych klientów. Zwróć więc uwagę na to, aby wyłączyć takie oprogramowanie z zakresu, który obejmuje przeniesienie autorskich praw majątkowych.

Komponenty, które należy wyłączyć z przeniesienia praw, obejmują przede wszystkim biblioteki i frameworki własne software house’u, narzędzia deweloperskie i skrypty pomocnicze, know-how i metodologię pracy, komponenty open source, gdzie należy jedynie zapewnić zgodność licencyjną, oraz wiedzę i doświadczenie zdobyte podczas projektu.

Istotną kwestią jest również moment przeniesienia autorskich praw majątkowych. Dokładnie przeanalizuj, co dokładnie mówi na ten temat umowa. Tu również możesz spotkać się z różnymi propozycjami. Z punktu widzenia Twojej firmy, a w szczególności zabezpieczenia płatności wynagrodzenia przez klienta, najistotniejsze będzie aby moment przeniesienia następował możliwie jak najpóźniej.

Pola eksploatacji utworu

Nie bez znaczenia są również pola eksploatacji. Postanowienie dotyczące przeniesienia autorskich praw majątkowych powinno dokładnie takie pola określać.

Z punktu widzenia prawnego klauzule stanowiące o przeniesieniu praw na “wszelkich możliwych polach eksploatacji” będą wadliwe. Konieczne jest wówczas wskazanie konkretnych pól eksploatacji, tj. sposobów korzystania z utworu (w Twoim przypadku programu) przez zamawiającego.

Miej świadomość, że profesjonalnie przygotowana klauzula przeniesienia autorskich praw majątkowych powinna opisywać szereg dodatkowych kwestii. Powyżej wskazałem jedynie te podstawowe.

Odpowiedzialność w umowie wdrożeniowej

Zrozumiałą kwestią jest to, że każda ze stron umowy chce w jak najszerszym stopniu zabezpieczyć swój interes. Dla wykonawcy najważniejsze jest to, aby dostać umówione wynagrodzenie oraz by współpraca z klientem przebiegała bezproblemowo. Dla zamawiającego natomiast ważne jest, aby na czas wdrożyć zamówiony system.

Z racji tego, że realizacja projektów IT zazwyczaj obarczona jest dużym ryzykiem niepowodzenia albo przynajmniej wystąpienia dużych problemów lub opóźnień, zamawiający starają się forsować w umowach IT rygorystyczne postanowienia dotyczące odpowiedzialności wykonawcy.

Spójrz więc czy w przedstawionej Ci umowie wdrożeniowej znajdują się postanowienia dotyczące:

1. kar umownych za opóźnienie,
2. odpowiedzialności za szkody zamawiającego,
3. odpowiedzialności z tytułu rękojmi,
4. kar umownych za naruszenie poufności.

Im bardziej świadomy klient (zamawiający), tym podobnych zabezpieczeń może być więcej.

Zasady współpracy w umowie wdrożeniowej

Każdy software house ma wypracowane swoje własne metody realizacji projektów IT. Na pewno często spotykasz się z firmami, które mówią, że działają w tej czy innej metodyce. Najmodniejszym obecnie terminem jest programowanie zwinne (agile software development).

Niemal obecnie wytwarza oprogramowanie właśnie w ,,agile’u”, ale uwierz, że jako prawnik pomagający software house’om widzę, jak bardzo różnie pojęcie to postrzegane jest przez  programistów. Każdy oczywiście zna stosowne definicje, ale już podczas faktycznej realizacji projektu okazuje się, że sprawa się komplikuje.

Z doświadczenia wiem, że nie można polegać na ogólnym pojmowaniu znanych wszystkim haseł. W szczególności jeśli chodzi o projekty IT. Może się bowiem w pewnym momencie okazać, że w przypadku braku opisania metodyki realizacji danego projektu (np. analiza – projektowanie – kodowanie – test – informacja zwrotna) wraz ze szczegółowymi wytycznymi dotyczącymi każdego z etapów, Ty i klient różnie pojmujecie realizację projektu w metodyce agile. Taka sytuacja bardzo łatwo może doprowadzić do impasu, z którego już nie będzie wyjścia.

Zwróć więc uwagę, aby umowa jasno określała, w jaki sposób będziesz realizować projekt dla klienta, tj. co, w jakim czasie i w jakich cyklach będzie się odbywało. Wiem, że dobre i skuteczne opisanie sposobu współpracy stron często okazuje się bardzo trudne. Na ten element umowy warto jednak poświęcić nieco więcej czasu. Upewnij się, że klient dobrze rozumie to, w jaki sposób będziesz realizować zamówiony przez niego system.

Kluczowe elementy współpracy w metodykach zwinnych, które należy uregulować, obejmują przede wszystkim role i odpowiedzialności. Product Owner po stronie klienta musi mieć jasno określoną dostępność i uprawnienia decyzyjne. Scrum Master i zespół deweloperski po stronie wykonawcy powinni mieć zdefiniowane obowiązki. Należy ustalić zasady komunikacji i eskalacji oraz wskazać osoby uprawnione do akceptacji rezultatów.

Organizacja pracy również wymaga precyzyjnego określenia. Długość i organizacja sprintów, zwykle trwających 2-4 tygodnie, muszą być ustalone. Ceremonie Scrum, takie jak planning, daily, review i retrospective, wymagają określenia formy i obowiązku uczestnictwa. Kluczowa jest też Definicja „Done” (Definition of Done), określająca kiedy zadanie uznaje się za ukończone, oraz zasady zarządzania backlogiem produktu.

Zarządzanie zmianami stanowi kolejny istotny element. Należy określić procedurę wprowadzania zmian do backlogu, wpływ zmian na harmonogram i budżet, mechanizm swap’owania funkcjonalności o podobnej pracochłonności oraz sposób dokumentowania zmian i ich akceptacji.

Dla projektów Agile szczególnie ważne jest wprowadzenie budżetu godzinowego lub story pointów na sprint, mechanizmu „trade-off” umożliwiającego wymianę funkcjonalności bez zmiany budżetu, jasnych kryteriów akceptacji dla każdej user story oraz procedury pilnych zmian (hot-fix).

Dodatkowo pamiętaj, że kwestie modelu realizacji projektu ściśle wiążą się potem z Twoją odpowiedzialnością jako wykonawcy, np. w zakresie opóźnień w wykonaniu danego etapu systemu. Tym ważniejsze jest więc, aby dokładnie opisać jakie obowiązki spoczywają na każdej ze stron umowy w konkretnym momencie współpracy.

Warunki płatności i modele rozliczeń

Analiza modelu płatności jest kluczowa dla oceny ryzyka finansowego projektu. Modele cenowe obejmują Fixed Price, czyli stałą cenę za całość lub etapy, co oznacza największe ryzyko po stronie wykonawcy.

Time & Materials to rozliczenie za faktycznie przepracowane godziny. Capped T&M łączy elastyczność T&M z górnym limitem kosztów. Target Price oznacza cenę docelową z podziałem oszczędności lub przekroczeń między strony. Model Subscription lub Abonament stosuje się dla usług ciągłych.

Harmonogram płatności powinien uwzględniać zaliczkę w wysokości np. 10-30%, która zabezpiecza początkowe koszty projektu. Płatności za kamienie milowe powinny być powiązane z odbiorem etapów. Płatność końcowa nie powinna przekraczać 10-20% wartości projektu. Standardowe terminy płatności to 14-30 dni od wystawienia faktury.

Zabezpieczenia płatności obejmują odsetki za opóźnienia w płatnościach, prawo wstrzymania prac przy braku płatności, zadatek lub gwarancję bankową przy dużych projektach oraz zastrzeżenie własności kodu do momentu pełnej zapłaty.

Sprawdź również: Fixed Price czy Time & Material?

Procedury zarządzania zmianami (Change Management)

Brak formalnej procedury zarządzania zmianami to jedna z głównych przyczyn konfliktów w projektach IT. Proces wprowadzania zmian powinien określać formę zgłoszenia zmiany, czy to pisemną czy przez system ticketowy.

Konieczna jest analiza wpływu (impact assessment) uwzględniająca czas i koszt. Należy określić procedurę akceptacji lub odrzucenia propozycji zmiany oraz sposób dokumentowania zaakceptowanych zmian w formie Change Order.

Kategorie zmian obejmują zmiany w zakresie funkcjonalnym, zmiany techniczne lub architektoniczne, zmiany harmonogramu oraz zmiany priorytetów. Skutki zmian muszą być jasno określone, w tym wpływ na harmonogram poprzez automatyczne przesunięcie terminów, wpływ na budżet w postaci dodatkowego wynagrodzenia, wpływ na inne funkcjonalności poprzez analizę zależności oraz konieczność aktualizacji dokumentacji projektowej.

Mechanizmy rozwiązywania sporów

Przemyślany mechanizm rozwiązywania sporów może zaoszczędzić obu stronom znaczne koszty i czas. Procedura eskalacyjna powinna obejmować kilka poziomów. Na pierwszym poziomie kierownicy projektów powinni rozwiązać problem w ciągu 5 dni. Jeśli to nie przyniesie efektu, na drugim poziomie zarządy firm mają 10 dni na znalezienie rozwiązania. Trzeci poziom to mediacja przed sądem polubownym lub mediatorem. Ostatnim poziomem jest arbitraż lub sąd powszechny.

Wybór forum ma istotne znaczenie. Sąd powszechny oznacza długotrwałe i kosztowne postępowanie. Arbitraż jest szybszy, ale droższy, za to zapewnia poufność. Mediacja jest najtańsza, ale wymaga dobrej woli stron. Należy też określić prawo właściwe i jurysdykcję, dokonując wyboru między prawem polskim a obcym, wskazując sąd właściwy, najlepiej neutralny dla obu stron, oraz określając język postępowania.

Klauzule dotyczące siły wyższej

Wydarzenia ostatnich lat, takie jak pandemia czy wojna, pokazały jak ważne są dobrze skonstruowane klauzule siły wyższej. Definicja siły wyższej powinna obejmować klęski żywiołowe i katastrofy, wojny, zamieszki i akty terroryzmu, epidemie i pandemie, decyzje władz uniemożliwiające wykonanie umowy oraz poważne awarie infrastruktury, na przykład długotrwały blackout.

Procedura postępowania w przypadku siły wyższej musi określać obowiązek niezwłocznego powiadomienia drugiej strony, sposób dokumentowania okoliczności siły wyższej, obowiązek minimalizowania skutków oraz zasady wznowienia prac po ustaniu przeszkody.

Skutki wystąpienia siły wyższej obejmują zawieszenie wykonania umowy, automatyczne przedłużenie terminów, brak kar umownych za okres działania siły wyższej oraz prawo odstąpienia przy długotrwałej sile wyższej, na przykład trwającej powyżej 60 dni.

Sprawdź również: Przykłady siły wyższej w umowach IT

Czy warto czytać umowę wdrożeniową, którą otrzymałeś od Klienta?

Tak! Czytaj dokładnie każdą umowę! W pierwszych krokach analizy umowy wdrożeniowej skup się na podstawach, czyli na:

1. komparycji (oznaczeniu stron w umowie),
2. odstąpieniu od umowy,
3. przeniesieniu autorskich praw majątkowych,
4. odpowiedzialności,
5. zasadach współpracy stron podczas realizacji przedmiotu umowy.

Pamiętaj również o dodatkowych kluczowych elementach, które mogą zdecydować o sukcesie lub porażce projektu. Należą do nich warunki płatności i model rozliczeń, które bezpośrednio wpływają na płynność finansową Twojego software house’u.

Procedury zarządzania zmianami są niezbędne w dynamicznym środowisku IT, gdzie wymagania często ewoluują w trakcie projektu. Mechanizmy rozwiązywania sporów mogą zaoszczędzić czas i pieniądze, gdy współpraca napotka trudności. Klauzule siły wyższej, których znaczenie pokazały ostatnie lata, chronią przed nieprzewidywalnymi zdarzeniami. Wreszcie, postanowienia o poufności zabezpieczają know-how i wrażliwe informacje biznesowe obu stron.

Profesjonalna analiza umowy to inwestycja w bezpieczeństwo Twojego biznesu. Każda przeoczona klauzula może w przyszłości obrócić się przeciwko Tobie, dlatego warto poświęcić czas na dokładne zrozumienie wszystkich postanowień. Jeśli masz wątpliwości, skonsultuj się z prawnikiem specjalizującym się w prawie IT – koszt takiej konsultacji jest nieporównywalnie niższy niż potencjalne straty wynikające z niekorzystnej umowy.