Umowa IT – co powinna zawierać i jak ją skonstruować?

Umowa IT skonstruowana w sposób przemyślany i szczegółowy to podstawa bezpieczeństwa i sukcesu w branży nowych technologii. Odpowiednio przygotowany dokument chroni interesy zamawiającego i wykonawcy, minimalizuje ryzyko sporów i zapewnia przewidywalność współpracy. W artykule omawiam, co powinna zawierać umowa IT, jakie zapisy są kluczowe oraz na co zwrócić szczególną uwagę przy jej negocjowaniu.

1. Opis projektu w umowie IT

Większość projektów informatycznych to rozwiązania przygotowywane "na miarę". Dlatego umowa IT powinna jak najdokładniej określać przedmiot zamówienia – najlepiej w formie załącznika z listą funkcjonalności i podstawową specyfikacją systemu.

Jeżeli szczegółowy zakres nie jest znany w chwili podpisywania kontraktu, a projekt ma być realizowany w metodyce Agile, należy wskazać elementy już ustalone: cele projektu, kluczowe funkcje systemu, wymagania techniczne. Umowa powinna również regulować sposób doprecyzowania pozostałych elementów.

W praktyce można zastosować dwa rozwiązania:

Faza wstępna – osobny etap projektu (z osobnym wynagrodzeniem), w ramach którego przygotowywana jest analiza, dokładna specyfikacja, harmonogram i budżet. Jeżeli strony nie dojdą do porozumienia, możliwe jest zakończenie współpracy po tym etapie bez dalszych konsekwencji.
Praca w Scrumie – metodyka, w której zakres, budżet i terminy mają charakter ramowy, a szczegóły są ustalane w kolejnych sprintach. Taki kontrakt wymaga dodatkowych zapisów, np. jak przebiega akceptacja prac, w jaki sposób ustalane są harmonogramy i kosztorysy oraz co w sytuacji, gdy prace przekroczą uzgodnione limity. Brak dokładności w tego typu zapisach może spowodować konwikty między stronami.

2. Odpowiedzialność stron w umowie IT

W kontraktach IT zapisy dotyczące odpowiedzialności są kluczowe dla bezpieczeństwa prawnego i biznesowego. Precyzyjne określenie tych kwestii ogranicza ryzyko sporów i chroni interesy obu stron.

Zapisy o odpowiedzialności w umowie IT mogą obejmować w szczególności:

analizę przedwdrożeniową – poprawne oszacowanie kosztów i przygotowanie specyfikacji,
zgodność z prawem – w tym z RODO (privacy by design) i przepisami branżowymi,
terminowość realizacji – z uwzględnieniem kar umownych za opóźnienia,
utrzymanie i SLA – dotrzymanie ustalonych KPI i poziomów dostępności,
prawa autorskie i licencje – legalność i właściwy dobór komponentów,
kompatybilność systemową – zgodność nowego rozwiązania z istniejącą infrastrukturą oraz systemami zewnętrznymi,
poufność i lojalność – ochrona danych, zakaz konkurencji, niepowielanie kodu lub pewnych pomysłów w innych projektach,
budżet projektu – odpowiedzialność za jego przekroczenie w wyniku błędów dostawcy lub zmian ze strony zamawiającego.

3. Zasady współpracy w umowie IT

Umowy w branży IT należą do jednych z najbardziej złożonych kontraktów gospodarczych. Dlatego tak ważne jest, aby szczegółowo regulowały one sposób współpracy.

3.1 Harmonogram realizacji

ustalanie harmonogramu – w Agile planowanie odbywa się iteracyjnie, jednak dla bezpieczeństwa kontrakt powinien zawierać ogólny zarys czasowy i sugerować limity dla poszczególnych faz,
zmiany harmonogramu – określenie dopuszczalnych przyczyn (np. brak decyzji zamawiającego, zmiana zakresu) i formy ich zatwierdzania (np. aneks, protokół, ticket),
konsekwencje opóźnień po stronie zamawiającego – np. przesunięcie terminów lub pokrycie dodatkowych kosztów

3.2 Procedura odbioru i akceptacji

odbiory częściowe i końcowe,
formy akceptacji (protokoły, raporty z testów, potwierdzenia elektroniczne),
terminy na zgłaszanie uwag i ich skutki (np. domniemana akceptacja),
osoby uprawnione do zatwierdzania etapów.

3.3 Dokumentacja i kod źródłowy

forma przekazania (transfer/repozytorium - pliki, dokumentacja),
moment przekazania (np. po iteracji, po zapłacie wynagrodzenia),
zakres dokumentacji (architektura, instrukcje użytkownika, administracja, testy).

3.4 Prawo do audytu

Zamawiający (zwłaszcza przy dużych projektach) może mieć prawo do audytu, obejmującego:

postęp prac,
zgodność z RODO i standardami bezpieczeństwa informacji,
prawidłowość korzystania z licencji,
finanse (np. przy modelu time & material).

3.5 Współpraca zespołów

spotkania robocze (sprint review, sprint planning),
dostępność kluczowych osób,
skład zespołu i zasady jego zmiany,
podwykonawcy i konieczność zgody zamawiającego.

4. Service Level Agreement (SLA) w umowie IT

SLA to praktyczny załącznik do umowy IT, określający zasady reagowania na awarie i utrzymania jakości usług.

Powinien zawierać m.in.:

zakres usług/elementów objętych SLA,
poziomy dostępności (np. 99,9%),
sposób monitorowania i raportowania (do oceny poziomu dostępności),
klasyfikację usterek (krytyczne, średnie, niskie),
czasy reakcji i usunięcia problemu,
procedury zgłoszeń (helpdesk, e-mail, telefon),
kary i rekompensaty za przekroczenie parametrów,
wyłączenia (np. prace konserwacyjne, błędy użytkownika).

SLA a gwarancja

SLA można traktować jako rozszerzoną, często odpłatną formę gwarancji. W odróżnieniu od klasycznej gwarancji, obejmuje ono także wady i problemy, które mogą powstać po wdrożeniu – np. w wyniku aktualizacji czy zmian w środowisku.

5. Prawa autorskie w umowie IT

Prawa autorskie to jeden z najczęściej negocjowanych elementów kontraktów IT.

Oprogramowanie dedykowane – możliwe pełne przeniesienie praw majątkowych,
Oprogramowanie standardowe wykonawcy – zwykle udzielana jest licencja (czasem z prawem modyfikacji),
Oprogramowanie zewnętrzne i open source – konieczna weryfikacja warunków licencyjnych oraz ustalenie zasad sublicencji.

Brak precyzyjnych zapisów może prowadzić do uzależnienia zamawiającego od jednego dostawcy, co utrudni późniejsze modyfikacje i rozwój systemu.

Podsumowanie – jak zabezpieczyć się w umowie IT?

Dobrze przygotowana umowa IT powinna obejmować przede wszystkim:

szczegółowy opis projektu,
rozbudowane zapisy dotyczące odpowiedzialności,
jasno określone zasady współpracy,
precyzyjne SLA,
przemyślane regulacje dotyczące praw autorskich.