III. Piękna umowa, tylko nie na temat

Niejednokrotnie w sądzie stajemy wobec głupiej sytuacji – umowa jako taka jest jasna, ale projekt jest prowadzony całkowicie inaczej. Prawnicy sobie, świat sobie. Począwszy od definicji (w tym moje ulubione pomieszanie definicji „itilowskich” ze swobodą twórczą prawników) po opisanie SLA, priorytetów błędów, metodyk etc.

Efekty są zdumiewające – sądy otrzymują umowy i interpretują je tak, jak są napisane. Na co wstają strony i zgodnie zeznają „nie, nie, nie, myśmy to zupełnie inaczej robili”. Wtedy sąd wyjmuje umowę i czyta: „wszelkie zmiany wymagają formy pisemnej pod rygorem nieważności”. Strony milczą. Prawnicy mają dużo pracy. Surrealistycznej.

Przykład prawdziwy i szkoleniowy – kierownicy projektu zmienili harmonogram szczegółowy (będący załącznikiem do analizy, która była załącznikiem do umowy). Pełna zgoda stron. Tylko że sąd – skądinąd słusznie – stwierdził, iż po pierwsze, nie mieli w umowie do tego pełnomocnictw, a po drugie – nie dochowali formy pisemnej. I uznał roszczenie Zamawiającego o zapłatę kar umownych, liczonych według harmonogramu z umowy, a nie realizowanego rzeczywiście. W sumie kilkaset tysięcy odszkodowania, które pojawiło się tylko dlatego, że Wykonawca nie przypilnował zgodności umowy z rzeczywistością.

IV. Prawa autorskie i kod źródłowy

Niezwykle gorący i trudny temat. Począwszy od mitów (prawa majątkowe dają więcej uprawnień niż licencje), poprzez trudną (czasem wręcz niemożliwą) interpretację warunków licencyjnych oferowanych przez producentów, po faktyczne uwarunkowania biznesowe, które z tymi warunkami stoją w jawnej sprzeczności (modele SaaS, cloud, zwłaszcza w grupach kapitałowych).

Lista błędów, które można popełnić podczas negocjowania rozdziału o prawach autorskich jest długa. Duża część zamawiających (zwłaszcza publicznych, pod wpływem dość nieszczęśliwych co do wniosków rekomendacji Prezesa UZP) określa za daleko idące, nierynkowe wymagania (w tym nabycie praw majątkowych do standardowych produktów). Z drugiej strony zamawiający nie zabezpieczają kluczowych interesów – czasu trwania umowy, zasad wypowiadania (także w przypadku naruszenia warunków licencji), prawa do rozwoju, przenoszenia licencji, możliwości outsourcingu, powierzenia administracji na zewnątrz etc. Zazwyczaj dużo czasu poświęca się prawu do modyfikacji kodu (choć często Zamawiający nie ma żadnej faktycznej możliwości i zasobów, by rozwijać taki kod), pomijając np. sposób liczenia opłat serwisowych. W tym zakresie jest stosunkowo mało sporów sądowych, ale to głównie dlatego, że ryzyka sporu po stronie zamawiających są za duże i lepiej podpisać ugodę. Ale jeszcze lepiej jasno wynegocjować swoje oczekiwania.

Depozyt kodów źródłowych jest zwierzęciem mitycznym. W 90% umów, które znam, utożsamia się depozyt ze złożeniem jakiegoś nośnika u notariusza. Z reguły dzieje się to bez sprawdzenia, co na tym nośniku jest, nie mówiąc o próbnej kompilacji. Ani o kopii w innym miejscu. Ani o procedurach dostarczania nowych wersji. Ani o wymaganiach dokumentacji kodu. Idea depozytu jest świetna – rozwiązuje wiele spornych rzeczy, ale tylko wtedy, kiedy jest profesjonalnie obsłużona przez wyspecjalizowane podmioty. Osobiście byłem dwa razy przy podjęciu kodu – raz był to czysty kod, bez linijki komentarza, drugi raz kod był zaszyfrowany. A wykonawca zwyczajnie odmówił podania hasła. Oczywiście lista roszczeń teoretycznie jest długa, tylko że w IT, jak rzadko w której części biznesu, zupełnie nie chodzi o roszczenia.

V. Odpowiedzialność i system kar umownych

Najbardziej prawniczy temat, z niewiadomych przyczyn powierzany prawnikom. Wbrew pozorom nie jest to zdanie nielogiczne. O ile same zapisy muszą być przez prawników tworzone czy weryfikowane, o tyle pomysły na zasady odpowiedzialności to kwestie wybitnie biznesowe. I zarazem jedna z najbardziej twórczych prac podczas negocjacji. Oczywiście może być tak, że wystarczą nam same kary za zwłokę. Ale dobry kontrakt przewiduje prawdziwe zagrożenia i próbuje im przyporządkować zasady odpowiedzialności – np. wprowadzając progresję kar, kary za nieodpowiednią jakość kodu, kary za nieusunięcie zgłoszonych błędów (retestowanie niepoprawionych wersji), rozbudowane systemy SLA z rozbudowanym systemem sankcji. Idea jest prosta – po pierwsze, zabezpieczyć prawdziwie kluczowe interesy stron, po drugie – zrobić to precyzyjnie i skutecznie.

Niezwykle trudno jest pisać o „kluczowych” interesach w sposób abstrakcyjny, bo one bardzo się różnią. Opóźnienia w projekcie to oczywistość, ale np. procedura testowania, kary za przekazanie do testowania niewłaściwej jakości kodu, za niepoprawienie błędu i zmuszanie do retestowania tych samych wersji wymagają bardzo ścisłej współpracy z zespołem IT czy zespołem odpowiedzialnym za biznes. Brak tego współdziałania prowadzi do standardowych kontraktów, które nie uchronią przed problemami innymi niż standardowe.

W sądach często pojawia się spór dotyczący tego, jak rozumieć zapisy – za co jest kara (mityczna „dostępność”), jak należy ją liczyć (procent wynagrodzenia w kontraktach ze zmiennym wynagradzaniem) i czy w ogóle jest skuteczna (kary za zwłokę przy odstąpieniu od umowy). To już warsztat prawny, ale zaniedbania w precyzyjnym opisie są częste i zasłużenie kwalifikują się do „top five”.

Każdy z powyższych punktów wymaga oddzielnego omówienia, a to oczywiście lista niepełna. Przez ostanie dwadzieścia lat kontrakty IT nauczyły mnie jednego – że niepowodzenie projektu IT ma z reguły o wiele większe skutki niż wartość samej umowy. Nie negocjujemy kontraktu o wartości X – negocjujemy niezbędny fragment inwestycji o wartości wiele razy X. Nie jest możliwe napisanie idealnego, precyzyjnego i niepozbawionego pola do interpretacji kontraktu – ale zbyt często, pod wpływem presji czasu lub innych czynników, zgadzamy się na zapisy jawnie prowokujące do sporów. Których – zaręczam – warto w naszym systemie sądownictwa unikać, jak tylko się da. Zajmują za wiele czasu, emocji i kosztują zbyt dużo. O wiele więcej niż uczciwie przeprowadzone negocjacje.

Więcej o umowach wdrożeniowych autor artykułu-Marcin Maruta opowie podczas warsztatów „Najlepsze praktyki umów wdrożeniowych- czyli droga do udanego projektu IT” 28 października 2014 w Warszawie.

Szczegóły na: https://www.computerworld.pl/konferencja/umowyIT3