Jak napisać dobrą umowę?

Jak powszechnie wiadomo, biznes IT namieszał w systemie prawa. Sam Internet jest przekleństwem, digitalizacja utworów nie mniejszym, ale nawet stare, dobre regulacje dotyczące umów nie mają łatwego życia z wdrożeniami, licencjami czy outsourcingiem. Prawnicy zajmujący się nową technologią chodzą po polu minowym – próbują dostosować przepisy z lat sześćdziesiątych do świata bitów i wyrafinowanych konstrukcji biznesowych. Czasami to się udaje, czasami nie. Chciałbym napisać kilka słów o tym, na co uważać zawierając umowę – artykuł jest oparty na wizji umowy wdrożeniowej i outsourcingowej, ale większość tez ma charakter generalny. Zdaję sobie sprawę, że część uwag może wydać się banalnych i oczywistych – ale proszę wierzyć, nie są to problemy odosobnione.

I. Po co pisać umowy?

Pytanie nie pozbawione sensu. Mamy przecież kodeks cywilny, który większość spraw reguluje. Teoretycznie więc wystarczy opisać kto, komu, co i za ile. W praktyce jest to dość samobójcza strategia. Po pierwsze umowy powinny określać jasne i szczegółowe „techniczne” reguły współpracy – kodeks cywilny posługuje się wieloma określeniami generalnymi typu „bez zbędnej zwłoki”, co przy wymogach stawianych SLA nie wystarcza. Musimy też pamiętać, że biznes IT ma stosunkowo mało wypracowanych standardów, popartych orzecznictwem. W razie sporu pozostają nam tylko zapisy umowy – im bardziej techniczne i konkretne, tym lepiej. Po drugie umowa ma odpowiadać specyfice konkretnego przedsięwzięcia – wiele przepisów, nawet precyzyjnych, próbuje wyważyć interesy stron. W umowach niekoniecznie będziemy chcieli taką równowagę zachować – np. niezwykle restrykcyjnie traktujemy kwestie bezpieczeństwa i zwykła staranność nam nie wystarcza. Tak samo okaże się, że wiele przepisów nie przystaje do specyfiki IT – np. ogólne regulacje dotyczące rozwiązywania umów wdrożeniowych są dla wykonawców zupełnie nie do przyjęcia (co gorsza, nie zawsze możemy je zmienić, ale zawsze możemy uprzedzić o ryzyku). Po trzecie, opracowanie dobrej umowy wymaga analizy wielu wątków i scenariuszy. To z kolei prowadzi do weryfikacji założeń i oczekiwań - już na etapie opracowania umowy możemy opisać i ustawić modele biznesowe, zrezygnować z części oczekiwań, znaleźć nowe zagrożenia. W konsekwencji  otrzymujemy dokument, który odpowiada rzeczywistości, a nie jest zbiorem pobożnych życzeń negocjatorów czy prawników.

II. Co umowa musi zawierać?

Z czysto prawnego punktu widzenia, tylko te elementy, które są wymagane dla danego typu umów. Przy sprzedaży jest to określenie stron, przedmiotu sprzedaży i ceny. Przy zleceniu teoretycznie nawet wynagrodzenia nie musimy określać, będzie się należało „zwyczajowo przyjęte”. Przy umowie przenoszącej prawa autorskie czy licencji będą to m.in. pola eksploatacji. Zakres takiego „minimum obiektywnego” powinni znać prawnicy -jeśli popełnimy błąd, umowa jest nieważna (stosunkowo częsty przypadek w zakresie sprzedaży praw autorskich i wspomnianych pól eksploatacji). Z punktu widzenia realiów biznesowych, każda umowa ma „minimum subiektywne” – regulacje, bez których umowy byśmy nie zawarli, choć prawnie nie są one konieczne. Może to być termin dostawy, mogą to być regulacje dotyczące własności intelektualnej czy gwarancje. Takie elementy muszą być zdiagnozowane przed rozpoczęciem negocjacji i starannie opisane (zadziwiające, jak często nie są). 

Poza uzgodnieniem „minimum” warto zwrócić uwagę na przepisy bezwzględnie i względnie obowiązujące. Te pierwsze to takie „uprawnienia administratora” – co byśmy nie wymyśli, i tak będą obowiązywać. Częsty błąd przy negocjacjach, czyli uporczywe negocjowania i wprowadzanie zapisów, które i tak nie mają zastosowania. Np. zakaz wypowiadania umowy wdrożeniowej w przypadku zwłoki wykonawcy, czy próba obejścia regulacji outsourcingu bankowego. Zdarza się, że wymogi takie są „nieinstynktowne” (termin przy umownym prawie odstąpienia) i łatwo tutaj o błąd. Druga grupa to przepisy, które wchodzą w życie, jak nie uregulowaliśmy danej sytuacji w umowie – nie napisaliśmy nic o odsetkach? No to mamy odsetki ustawowe. Nie napisaliśmy nic o limicie odpowiedzialności – no to mamy odpowiedzialność nielimitowaną, zarówno w zakresie strat i utraconych zysków. Cała sztuka napisania umowy leży w tym, aby nie ruszać przepisów bezwzględnie obowiązujących, tylko znaleźć  biznesowy sposób na ich obejście (prawo zakazuje wyłączenia odpowiedzialności za szkody poniesione przez klientów banku? To ustawmy tak SLA, aby nie zaszedł przypadek nienależytego wykonania umowy) oraz na zmodyfikowaniu przepisów względnie obowiązujących, aby odpowiadały naszym celom. I uwaga, części przepisów lepiej nie ruszać, bo kodeksowe domniemania są dla nas bardzo korzystne – niech o ich zmianę martwi się druga strona (najbardziej jaskrawy przypadek to regulacje przy odstąpieniu od dzieła, w praktyce faworyzujące zamawiającego).

III. Kto i jak może zawrzeć umowę?

W wielkim skrócie osoby fizyczne po ukończeniu 18 lat i osoby prawne, należycie reprezentowane. Z tą reprezentacją bywają problemy, zwłaszcza w ciągu pełnomocnictw. Trzeba sprawdzać, od jakiegoś czasu możliwy jest internetowy dostęp do rejestru spółek (http://pdi.cors.gov.pl/KRSSED/). Sprawa o tyle ważna, że popełnionego błędu nie sposób w wielu sytuacjach naprawić. Praktycznie bez wyjątku umowy zawierane są w formie pisemnej. Nie jest to wymóg prawa (taka forma z rygorem nieważności jest stosunkowo rzadka), ale zdrowy rozsądek. W większości umów wpisuje się magiczną formułkę „że wszystkie zmiany wymagają formy pisemnej pod rygorem nieważności”. A wiec sami sobie taki rygor nakładamy (skutecznie). Musimy pamiętać, że forma pisemna to podpisy własnoręczne (i bezpieczne podpisy elektroniczne) osób reprezentujących spółkę. Jeżeli umowa określa szczegółowo wiele parametrów (a z reguły określa), zmiana np. SLA czy terminu oddania faz wymaga interwencji zarządu lub odpowiednich pełnomocnictw. Zbyt często, w dobrej wierze, zmiany takie są dokonywane  przez kierowników projektów, z reguły mailowo. Umowa sobie, proces wdrożeniowy sobie – żadna z tych zmian nie jest skuteczna (niewłaściwe osoby, niewłaściwa forma), horror w razie sporu. Warto więc upoważnić w odpowiednim zakresie zarząd projektu lub dopuścić chociaż częściowo formę elektroniczną.

IV. Podsumowanie

Jeśli chcemy mieć świetną umowę, musimy mieć jasną i precyzyjną wizję czego oczekujemy, na jakie kompromisy jesteśmy gotowi i jakie środki możemy przeznaczyć. Pozwoli to na określenie „minimum subiektywnego” oraz opracowanie takich rozwiązań prawnych, aby cele zrealizować. Opracowując umowę musimy zanalizować przepisy względnie obowiązujące, które będą miały zastosowanie, i zdecydować które z nich i jak zmieniamy. Musimy wprowadzić regulacje, które w ogóle przepisami nie są regulowane. I uważać, żeby nie popełnić błędu jak sprzeczność z bezwzględnie obowiązującymi przepisami. Nie mówiąc np. o doskonałej konstrukcji cywilistycznej, tyle że podatkowo niekorzystnej. Pracujmy z zespołami merytorycznymi. Nie wymyślajmy metodyk wdrożeniowych czy twórczych procedur testowania softwaru. Umowa nie ma na celu zaspokojenie ego negocjatorów, tylko ułatwienie pracy zespołom merytorycznym. I zminimalizowanie sytuacji konfliktowych, poprzez jasne określenie reguł. Głęboko wierzę, że czas poświęcony na napisanie umowy (zawsze, jak tylko możemy, pracujmy na naszym projekcie) jest dobrą inwestycją. Zarówno w sytuacji, gdy umowa realizowana jest poprawnie (często tak się dzieje tylko dlatego, że potencjalne problemy zostały omówione i opisane), jak i gdy dochodzi do sporu. A spory są coraz częstsze – z punktu widzenia zamawiającego umowa chroni go od przewagi „technicznej” wykonawcy, który z reguły ma więcej wiedzy o samym projekcie wdrożeniowym i lepiej udokumentowane działania – w przypadku braku jasnych reguł co było celem umowy, taki materiał skutecznie chroni go przed roszczeniami. Z punktu widzenia wykonawcy umowa musi złagodzić niekorzystne dla niego standardowe rozwiązania kodeksowe i rozsądnie ograniczyć odpowiedzialności. Sporów nie unikniemy, ale powinniśmy dołożyć najwyższej profesjonalnej staranności aby ułatwić powodzenia projektu IT. Nie znam lepszego sposobu niż dobry kontrakt.

2 myśli nt. „Jak napisać dobrą umowę?

  1. Pingback: [MIMUW] Plan zajęć na 16.10 | mirepoix

  2. Pingback: Post-factum: 23-10-2008 | mirepoix

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany.

Możesz użyć następujących tagów oraz atrybutów HTML-a: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>