Na co zwrócić uwagę, czytając umowę wdrożeniową 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. Jeśli, któryś z artykułów nie jest jeszcze podlinkowany, oznacza to, że wpis dotyczący tego zagadnienia pojawi się na blogu w najbliższej przyszłości.

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.

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.

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.

Więcej informacji o sposobie oznaczania stron w umowach przeczytasz artykule ,,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.

Temat odstąpienia będzie jeszcze szerzej poruszany na moim blogu.

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.

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.

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.

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.

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.

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

Tak! Czytaj dokładnie każdą umowę, pobierz moją checklistę najważniejszych postanowień umowy wdrożeniowej i analizuj każdą umowę według jednego ustandaryzowanego schematu.

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.

Jeśli podobał Ci się ten artykuł, będzie mi bardzo miło jeśli go skomentujesz i podzielisz się swoimi doświadczeniami.

Chcesz otrzymać darmową checklistę z kluczowymi elementami umowy wdrożeniowej? Zapisz się do mojego newslettera! Dzięki temu w pierwszej kolejności otrzymasz informacje o moich najnowszych wpisach, e-bookach i infografikach.