Różnica między „dogadaniem się” mailowo a spisaną umową
Mail, czat czy ustne ustalenia są dobre na etapie rozpoznania i negocjacji. Nie zastąpią jednak przejrzystej umowy współpracy w projekcie, która krok po kroku opisuje, co kto robi, za ile, w jakim czasie i co dzieje się, gdy coś pójdzie nie tak.
Ustalenia mailowe są rozproszone, często sprzeczne, nikt do nich nie wraca, a po kilku miesiącach nikt nie pamięta, co dokładnie obiecał. Umowa porządkuje to w jednym dokumencie, z jasną chronologią i hierarchią: umowa główna, załączniki, ewentualne aneksy.
W sporze prawnym sędzia w pierwszej kolejności patrzy na umowę, a dopiero potem na maile. Jeżeli umowy brak, każda ze stron „pamięta” coś innego. To klasyczny przepis na długi konflikt, przeciąganie projektu i zniszczone relacje.
Umowa jako narzędzie zarządzania ryzykiem
Dobra umowa współpracy w projekcie nie jest papierem dla prawnika, ale narzędziem zarządzania ryzykiem: opóźnień, niedoprecyzowanego zakresu, nieopłaconych faktur, zmiany zakresu czy zmiany osób w zespole.
Każdy istotny obszar projektu powinien mieć w umowie „bezpiecznik”: co jeśli klient nie dostarczy materiałów, co jeśli wykonawca nie dotrzyma terminu, co jeśli trzeba będzie zwiększyć zakres prac, co jeśli strona chce przerwać współpracę w trakcie.
Spisana umowa zmusza obie strony do odpowiedzi na trudne pytania jeszcze przed startem. To często jedyny moment, kiedy można tanio i spokojnie skorygować oczekiwania, dopracować harmonogram czy doprecyzować odpowiedzialność stron w projekcie.
Co realnie daje dobrze przygotowana umowa
Skuteczna umowa współpracy nie tylko „chroni”, ale przede wszystkim porządkuje codzienną pracę. Daje:
przewidywalność – jasne terminy, etapy, warunki płatności, procedury zmian,
mniejszą liczbę sporów – większość sporów wynika z niedomówień, a nie złej woli,
łatwiejsze zarządzanie projektem – umowa staje się punktem odniesienia dla zespołu,
możliwość egzekwowania zobowiązań – bez umowy trudno dochodzić czegokolwiek na piśmie.
Gdy brak umowy lub „szablon z internetu” psuje projekt
Typowy scenariusz: agencja marketingowa umawia się z klientem „na kampanię i obsługę social mediów”, strony wymieniają kilka maili, zaczynają działać. Po trzech miesiącach klient twierdzi, że miały być również kampanie w nowych kanałach, raporty co tydzień i obsługa kryzysowa 24/7, bo „przecież rozmawialiśmy”. Bez umowy trudno temu zaprzeczyć.
Drugi przykład: NGO bierze szablon umowy z programu grantowego sprzed kilku lat. Dokument opisuje dotacje i sprawozdawczość, ale niemal nic nie mówi o prawach autorskich, danych osobowych czy konkretnych obowiązkach podwykonawców. Projekt kończy się sporem o to, kto ma prawo do materiałów i czy można je wykorzystać w kolejnym projekcie.
Umowa współpracy w projekcie ma być szyta na miarę celu, zakresu i ryzyk konkretnego przedsięwzięcia. Szablony z internetu mogą być punktem wyjścia, ale nie gotowym rozwiązaniem.
Jak dobrze przygotować się do stworzenia umowy
Zbieranie założeń: cele, strony, otoczenie prawne
Umowę pisze się na bazie konkretu. Zanim powstanie pierwszy paragraf, trzeba mieć spisane założenia projektu: cel, główne rezultaty, budżet, przewidywany czas trwania oraz kluczowe ryzyka.
Istotne jest też, w jakim reżimie działają strony: czy to współpraca B2B, umowa z konsumentem, współpraca z NGO, czy porozumienie partnerskie kilku podmiotów. Od tego zależą wymogi ustawowe i ograniczenia, np. w zakresie klauzul niedozwolonych, ochrony konsumenta czy zasad konkurencji.
Jeżeli w projekcie występują podwykonawcy lub partnerzy (np. konsorcjum kilku firm lub NGO z różnymi rolami), już na starcie trzeba ustalić, kto z kim zawiera umowę i jakie istnieją powiązania między tymi relacjami.
Największym błędem jest pisanie umowy „z głowy”, bez oparcia w dokumentach projektowych. Każdy poważniejszy projekt powinien mieć:
krótki brief opisujący cel, grupę docelową, główne wymagania,
specyfikację lub opis zakresu prac (np. funkcjonalności systemu, zakres kampanii),
backlog lub listę zadań/produktów, jeśli pracujecie zwinnie,
wstępny harmonogram z podziałem na etapy i kamienie milowe.
Te materiały nie muszą być perfekcyjne, ale powinny być wystarczająco konkretne, by można było na nich oprzeć przedmiot umowy, zakres obowiązków i harmonogram. Idealnie, jeśli stają się załącznikami do umowy – wtedy łatwiej aktualizować szczegóły bez przepisywania całości.
Lista pytań kontrolnych przed spisaniem umowy
Dobrą praktyką jest przejście z partnerem przez krótką checklistę. To kilka pytań, które ujawniają niedomówienia zanim staną się problemem:
Jakie są trzy najważniejsze rezultaty, które mają być osiągnięte w ramach projektu?
Kto po stronie klienta decyduje o zmianach zakresu, akceptuje etapy i podpisuje protokoły?
Jakie dane, materiały, dostępy musi dostarczyć klient i w jakich terminach?
Jak wygląda współpraca na co dzień: narzędzia, częstotliwość kontaktu, sposób raportowania?
Jakie są kluczowe terminy nie do ruszenia (np. event, start kampanii, zobowiązania grantowe)?
Jakie wydatki dodatkowe poza wynagrodzeniem mogą się pojawić (np. licencje, podróże)?
Co jest absolutnie niedopuszczalne dla każdej ze stron (np. podzlecanie bez zgody, brak kontaktu)?
Odpowiedzi na te pytania często zmieniają sposób myślenia o umowie. Nagle okazuje się, że trzeba mocniej opisać komunikację, dodać zapis o akceptacji podwykonawców czy doprecyzować, co dzieje się z materiałami po zakończeniu projektu.
Kiedy wystarczy prosty kontrakt, a kiedy potrzebny jest prawnik
Proste projekty (np. jednorazowe warsztaty, mały landing page, krótka kampania) często wystarczy zabezpieczyć krótką, 2–4-stronicową umową z jasnym zakresem, terminem, wynagrodzeniem i podstawowymi klauzulami o prawach autorskich i poufności.
Prawnika lub doświadczonego specjalistę od umów warto włączyć, gdy:
wartość projektu jest wysoka lub umowa obejmuje długi okres (np. 12–24 miesiące),
projekt wiąże się z wysokim ryzykiem prawnym (dane osobowe, własność intelektualna, duże budżety mediowe),
mamy do czynienia z konsorcjum lub kilkoma podmiotami, między którymi trzeba uregulować podział odpowiedzialności,
druga strona przedstawia skomplikowaną umowę „od siebie” i oczekuje szybkiego podpisu.
Dobry prawnik nie pisze „prawniczego bełkotu”, tylko przekłada ryzyka na konkretne zapisy. W złożonych projektach taka inwestycja często zwraca się przy pierwszym poważniejszym kryzysie.
Strony umowy i podstawowe definicje
Dokładna identyfikacja stron umowy
Na początku każdej umowy trzeba precyzyjnie zidentyfikować strony. Brzmi banalnie, ale to tam rodzi się wiele problemów. Inaczej opisuje się osobę fizyczną prowadzącą działalność, inaczej spółkę z o.o., inaczej fundację czy stowarzyszenie.
Minimalny zestaw danych dla podmiotu gospodarczego to: pełna nazwa, forma prawna, adres, KRS lub CEIDG, NIP, REGON (jeśli ma), a także reprezentacja (np. zarząd jednoosobowy). Dla freelancera wystarczą dane z CEIDG i NIP.
Jeśli po drugiej stronie jest konsorcjum lub partnerstwo kilku podmiotów, trzeba jasno wskazać, kto jest liderem umowy i które postanowienia stosują się do wszystkich członków, a które tylko do jednej strony.
Reprezentacja i osoby kontaktowe
Poza formalną reprezentacją (kto w imieniu strony może podpisywać umowę i aneksy) opłaca się wpisać do umowy osoby kontaktowe odpowiedzialne za bieżącą współpracę. Dzięki temu obie strony wiedzą, kto ma realną decyzyjność operacyjną.
Warto dodać prosty zapis, że zmiana osoby kontaktowej wymaga wyłącznie powiadomienia mailowego, a nie aneksu. Dzięki temu rotacje w zespole nie paraliżują formalności.
W projektach dużych lub wrażliwych dobrze działa też rozdzielenie ról: jedna osoba kontaktowa ds. merytorycznych, druga ds. finansowych (faktury, płatności), czasem trzecia ds. prawnych lub ochrony danych.
Definicje kluczowych pojęć w umowie
Źródłem wielu konfliktów są pojęcia „oczywiste”, które każdy rozumie inaczej. Dlatego w skutecznej umowie współpracy w projekcie powinien pojawić się krótki słownik definicji. Nie chodzi o kilkanaście stron definicji, lecz o kilka najważniejszych terminów.
Często potrzebne są definicje takich pojęć jak:
Projekt – konkretny zakres prac objęty umową, wraz z terminem trwania,
Etap – część projektu kończąca się określonym rezultatem i odbiorem,
Materiały – treści, dane, pliki przekazywane przez którąkolwiek ze stron,
Wyniki prac – to, co ma powstać w wyniku wykonania umowy,
Informacje poufne – co dokładnie jest poufne w kontekście klauzul NDA.
Definicje powinny być proste, krótkie i jednoznaczne. Późniejsze zapisy umowy odwołują się do nich, co ogranicza liczbę nieporozumień.
Jak uniknąć „pływających” pojęć
Należy unikać w umowie pojęć tak ogólnych, że nie wiadomo, o co chodzi. Sformułowania typu „rozsądny termin”, „uzasadnione starania”, „standard rynkowy” mogą być przydatne, ale trzeba je opisać kontekstowo lub uzupełnić przykładami w załącznikach.
Jeżeli strona liczy na „pełne wsparcie”, warto w załączniku opisać, co to znaczy: kanały komunikacji, czas reakcji, zakres godzin, dostępność w weekendy. Analogicznie z „obsługą powdrożeniową”, „supportem” czy „utrzymaniem systemu”.
Im więcej nieprecyzyjnych pojęć, tym więcej pola do interpretacji. Lepiej doprecyzować kluczowe z nich niż później tłumaczyć, że „nam chodziło o coś innego”.
Przedmiot umowy i zakres współpracy
Precyzyjny opis przedmiotu umowy
Przedmiot umowy to jej serce. Powinien jasno odpowiadać na pytanie: co dokładnie ma zostać wykonane, dostarczone lub osiągnięte w ramach projektu. Zbyt ogólny opis („świadczenie usług marketingowych”) jest proszeniem się o kłopoty.
Dobry opis przedmiotu umowy zawiera co najmniej:
rodzaj działań (np. przygotowanie strategii, wdrożenie systemu, kampania reklamowa),
zakres rzeczowy (co konkretnie wchodzi w skład usługi/produktu),
formę rezultatów (raport, aplikacja, szkolenie, scenariusz, materiały wideo),
ograniczenia (czego umowa nie obejmuje, np. utrzymania, hostingu, kosztów mediowych).
Warto rozdzielić to, co obowiązkowe (objęte wynagrodzeniem podstawowym) od tego, co może być realizowane za dodatkową opłatą na podstawie odrębnego zlecenia.
Załączniki: specyfikacja, backlog, makiety, lista usług
Im bardziej złożony projekt, tym bardziej opłaca się przenieść dużą część szczegółów do załączników. Dzięki temu sama umowa pozostaje dość uniwersalna, a konkretne wymagania można doprecyzowywać i aktualizować aneksami.
Typowe załączniki w umowie współpracy w projekcie to:
opis zakresu prac (specyfikacja techniczna, zakres merytoryczny),
harmonogram z podziałem na etapy i kamienie milowe,
cennik lub tabela stawek godzinowych,
makiety, projekty graficzne, struktury informacji,
backlog funkcjonalności (w projektach IT lub produktowych).
W umowie należy jasno wskazać, które dokumenty są załącznikami i jaką mają moc (np. „Załącznik nr 1 stanowi integralną część umowy”). Dzięki temu, jeśli część zakresu zmienia się, nie trzeba przepisywać całej umowy – wystarczy aneks do konkretnego załącznika.
Dobrze działa też rozbicie zakresu na poziomy szczegółowości: w umowie – opis ogólny i zasady współpracy, w załącznikach – konkretne listy zadań, user stories, moduły, kampanie. Przy zmianach wystarczy doprecyzować backlog lub zakres sprintu, zamiast negocjować cały kontrakt od zera.
Przy projektach rozwijanych iteracyjnie (np. software, długie działania marketingowe) sensowne bywa dodanie mechanizmu cyklicznej aktualizacji załączników, np. raz w miesiącu lub na początku każdego etapu. Ogranicza to dyskusje „czy to już zmiana umowy, czy tylko doprecyzowanie” i porządkuje codzienną pracę.
Jeżeli część materiałów lub wymagań dopiero powstaje (np. szczegółowe scenariusze szkoleń, struktura serwisu), można je oznaczyć jako „do doprecyzowania w Załączniku nr X do dnia Y”. Takie „puste sloty” mobilizują strony do szybkiego dopięcia szczegółów i zmniejszają ryzyko, że ktoś później powie: „my myśleliśmy, że będzie więcej”.
Dobrze opisana umowa współpracy nie rozwiąże wszystkich problemów projektowych, ale usuwa wiele potencjalnych min, zanim wybuchną. Im bardziej konkretne są definicje, zakres, harmonogram i zasady zmian, tym łatwiej skupić się na realnej pracy, a nie na przepychankach o interpretację zapisów.
Zakres obowiązków i odpowiedzialności stron
Wyraźny podział obowiązków operacyjnych
Po ustaleniu przedmiotu umowy trzeba rozpisać, co dokładnie robi każda ze stron. Bez tego szybko pojawia się gra w zrzucanie winy: „to nie my mieliśmy to przygotować”.
Podział obowiązków dobrze jest powiązać z etapami i rezultatami. Przykład: wykonawca przygotowuje koncepcję i projekt, klient dostarcza treści i decyduje o akceptacji, wspólnie testują rozwiązanie.
Drobne rzeczy też wymagają przypisania: kto organizuje salę szkoleniową, kto odpowiada za licencje narzędzi, kto zamawia tłumaczenia. To one później blokują pracę.
Odpowiedzialność za decyzje, opóźnienia i błędne dane
Umowa powinna rozdzielić odpowiedzialność za decyzje merytoryczne i za jakość danych wejściowych. Jeśli klient dostarcza błędne dane, wykonawca nie powinien brać za nie pełnej odpowiedzialności.
Dobrym zapisem jest wskazanie, że terminy przesuwają się o czas opóźnień po stronie klienta (np. brak akceptacji, brak materiałów), a wykonawca nie ponosi sankcji za skutki tych opóźnień.
Przy projektach analitycznych lub strategicznych można dodać, że rekomendacje są oparte na danych przekazanych przez klienta, a wykonawca nie odpowiada za szkody wynikające z ich nieprawdziwości.
Odpowiedzialność za podwykonawców
Jeśli wykonawca korzysta z podwykonawców, umowa powinna jasno mówić, kto za nich odpowiada wobec klienta. Co do zasady pełną odpowiedzialność ponosi wykonawca.
Można wymagać od wykonawcy, by zapewnił, że podwykonawcy mają podpisane umowy o poufności i przeniesienie praw autorskich. Warto dodać prosty obowiązek: na żądanie klienta przedstawić dowód tych zabezpieczeń.
Wrażliwe obszary (np. przetwarzanie danych osobowych, audyty bezpieczeństwa) dobrze jest wyłączyć z dalszego podzlecania bez pisemnej zgody klienta.
Limity odpowiedzialności i wyłączenia
W większości projektów strony chcą ograniczyć wzajemną odpowiedzialność finansową. Standardem jest limit do wysokości wynagrodzenia z umowy lub jego wielokrotności.
Jednocześnie niektóre ryzyka zwykle są wyłączane z limitów, np. rażące niedbalstwo, szkody na osobach, naruszenia praw autorskich, poufności lub RODO.
Umowa powinna też jasno wykluczać odpowiedzialność za utracone korzyści, chyba że strony wyraźnie ustalą inaczej. Dzięki temu nie pojawiają się roszczenia za hipotetyczne „utracone miliony ze sprzedaży”.
Harmonogram, etapy, kamienie milowe
Struktura harmonogramu dopasowana do projektu
Harmonogram nie musi być rozbudowaną tabelą Gantta, ale powinien odzwierciedlać kluczowe etapy i zależności. Prosty projekt może mieć 2–3 etapy, złożony – kilkanaście.
Najczęściej stosuje się podział na: analizę, projekt/koncepcję, produkcję/implementację, testy, wdrożenie, stabilizację lub support.
Każdy etap powinien mieć datę startu, datę końca lub warunki jego rozpoczęcia (np. akceptacja poprzedniego etapu, dostarczenie materiałów).
Definicja i rola kamieni milowych
Kamień milowy to konkretny moment w projekcie, kiedy coś musi być zakończone lub zatwierdzone. Łatwo go powiązać z płatnościami lub decyzjami co do dalszego zakresu.
W umowie dobrze zdefiniować, czym jest „ukończenie kamienia milowego”: np. dostarczenie określonych plików, podpisanie protokołu odbioru, publikacja strony testowej.
Bez takiej definicji przychodzi moment faktury, a klient twierdzi, że etap nie jest zakończony, bo „wyobrażał to sobie inaczej”.
Elastyczne terminy a odpowiedzialność za opóźnienia
Nie każdy projekt pozwala na sztywne daty. Czasem lepiej użyć formuły „X dni roboczych od dostarczenia materiałów” lub „do końca miesiąca następującego po akceptacji etapu”.
Warto jednak z góry określić, kiedy strona wchodzi w opóźnienie i jakie są tego konsekwencje: odsetki, kary umowne, przesunięcie kolejnych terminów, możliwość rozwiązania umowy.
Przy dłuższych projektach przydaje się mechanizm przeglądu harmonogramu co określony czas (np. raz na kwartał) i formalne aktualizowanie go w załączniku.
Kary umowne za opóźnienie – kiedy mają sens
Kary umowne za opóźnienie działają dyscyplinująco, ale łatwo przesadzić. Zbyt wysokie stawki powodują, że wykonawca woli w ogóle nie wchodzić w projekt albo wlicza wysokie ryzyko w cenę.
Rozsądnym rozwiązaniem jest ustalenie dziennych kar za opóźnienie w kluczowych etapach (np. uruchomienie systemu, start kampanii), z łącznym limitem procentowym wynagrodzenia.
Trzeba też jasno powiązać kary wyłącznie z opóźnieniami zawinionymi przez daną stronę, a nie tymi wynikającymi z braku współpracy lub decyzji po drugiej stronie.
Wynagrodzenie, rozliczenia i zmiany zakresu
Modele rozliczeń: ryczałt, time & material, abonament
Podstawowa decyzja to wybór modelu wynagrodzenia. Najczęściej stosuje się trzy podejścia lub ich mieszanki.
Ryczałt oznacza stałą kwotę za uzgodniony zakres. Daje przewidywalność kosztów, ale wymaga dobrze opisanych wymagań i dopracowanej procedury zmian.
Time & material (stawka godzinowa/dzienna) daje elastyczność, lecz wymaga zaufania i kontroli czasu pracy. Tu kluczowe są czytelne raporty godzinowe i limit budżetowy.
Abonament to stała opłata okresowa za z góry określony pakiet usług (np. określona liczba godzin wsparcia miesięcznie). Nadaje się do utrzymania, supportu, długotrwałej współpracy.
Struktura płatności i powiązanie z etapami
W projektach jednorazowych najczęściej stosuje się zaliczkę, płatność po kluczowych etapach i resztę po zakończeniu zadania. W projektach długoterminowych – miesięczne faktury okresowe.
Warto powiązać płatności z obiektywnymi zdarzeniami: odbiór etapu, dostarczenie określonego rezultatu, upływ danego okresu rozliczeniowego.
Nie ma obowiązku, by ostatnia płatność była największa. Często lepiej rozłożyć wynagrodzenie równomiernie, by żadna ze stron nie czuła nadmiernego ryzyka.
Terminy płatności i zabezpieczenia
Standardowy termin płatności to 14–30 dni, ale przy mniejszych projektach można stosować krótsze okresy. Jeżeli klient ma długie procedury, niech nazwie to wprost w umowie.
Dla wykonawcy ważne jest wskazanie, że opóźnienie płatności może powodować wstrzymanie prac po uprzednim wezwaniu. Dla klienta – że takie wstrzymanie nie oznacza automatycznego przedłużenia całego projektu w nieskończoność.
Przy dużych kwotach można użyć zaliczek, gwarancji bankowych lub płatności escrow, ale w większości standardowych projektów wystarczy przejrzysty harmonogram faktur i zdrowa dyscyplina.
Scope creep: jak go opisać i kontrolować
Scope creep, czyli niekontrolane rozrastanie się zakresu, to jeden z głównych zabójców projektów. Umowa powinna przewidywać, że wszelkie nowe wymagania ponad ustalony zakres są osobno wyceniane.
Dobre rozwiązanie to prosty workflow: zgłoszenie zmiany, jej oszacowanie (koszt i wpływ na terminy), akceptacja lub odrzucenie na piśmie (najczęściej mailowo) i dopiero wtedy realizacja.
Przy stałej współpracy sprawdzają się pakiety godzin dodatkowych, z góry wycenione bloki (np. „do 10 godzin zmian graficznych miesięcznie w cenie, potem według stawki godzinowej”).
Indeksacja i zmiana wynagrodzenia w czasie
Przy umowach trwających rok i dłużej dobrze jest przewidzieć mechanizm zmiany stawek, np. raz w roku o określony wskaźnik lub w określonym przedziale procentowym.
Bez takiej klauzuli wykonawca może po kilku latach pracować po stawkach, które dawno nie odzwierciedlają realnych kosztów. Z drugiej strony klient nie chce niespodzianek w postaci nagłego podwojenia wynagrodzenia.
Najbezpieczniej powiązać indeksację ze znanym wskaźnikiem (np. inflacji) i określić maksymalny roczny wzrost stawek.
Źródło: Pexels | Autor: www.kaboompics.com
Jakość, odbiór prac i reklamacje
Standardy jakości i kryteria akceptacji
Bez opisania standardów jakości przy odbiorze zaczyna rządzić subiektywne „podoba się / nie podoba się”. Lepiej ustalić z góry mierzalne kryteria.
Przykłady: zgodność z makietami i zakresem funkcjonalnym, poprawność techniczna (brak błędów krytycznych), zgodność z brandbookiem, wyniki testów (np. szybkość ładowania strony).
Nie da się opisać wszystkiego, ale kilka kluczowych wymagań potrafi uciąć większość sporów.
Procedura odbioru: kto, kiedy, jak
Ogólny schemat odbioru zwykle wygląda tak: wykonawca dostarcza rezultat, klient ma określony czas na testy i zgłoszenie uwag, brak uwag w terminie oznacza odbiór milczący.
Umowa powinna zawierać konkretne terminy (np. 5–10 dni roboczych na zgłoszenie zastrzeżeń) i wymagany kanał komunikacji (e-mail, system ticketowy, dedykowane narzędzie).
Jeśli klient zgłasza uwagi, powinny być one możliwie precyzyjne i odnosić się do zakresu ustalonego w umowie. Zapis o obowiązku „szczegółowego opisania zastrzeżeń” oszczędza obu stronom długich dyskusji.
Poprawki, iteracje i granice zmian
Najczęstszy problem to liczba poprawek. Klient oczekuje „nieograniczonej liczby iteracji”, wykonawca zakłada jedną lub dwie tury zmian.
Dla liderów i koordynatorów projektów, także tych w NGO (o czym więcej znajdziesz jako więcej o NGO), jasne zapisy umowne są równie ważne jak harmonogram czy budżet.
Rozsądne rozwiązanie to określenie liczby rund poprawek w ramach wynagrodzenia podstawowego oraz sposobu rozliczania dodatkowych iteracji (np. według stawek godzinowych).
Można też odróżnić poprawki od zmian: poprawka usuwa błąd lub dopasowuje efekt do ustalonej specyfikacji; zmiana wykracza poza pierwotne ustalenia i podlega odrębnej wycenie.
Okres rękojmi / gwarancji jakości
W umowach projektowych pojawia się często rękojmia lub gwarancja jakości na określony czas po odbiorze. W tym okresie wykonawca usuwa ujawnione wady bez dodatkowego wynagrodzenia.
Przy systemach IT standardem są 3–12 miesięcy na błędy krytyczne lub uniemożliwiające korzystanie z systemu. Dla materiałów kreatywnych termin bywa krótszy, ale też warto go nazwać.
Jednocześnie dobrze jest wyłączyć z rękojmi błędy powstałe w wyniku ingerencji osób trzecich, nieautoryzowanych zmian lub nieprawidłowego używania rozwiązania.
Reklamacje i dochodzenie roszczeń
Umowa może przewidywać prostą procedurę reklamacyjną: termin na zgłoszenie wady od jej zauważenia, obowiązek opisania problemu i dostarczenia materiałów umożliwiających diagnozę.
Przy usługach ciągłych (np. obsługa kampanii, utrzymanie systemu) przydaje się rozróżnienie wad według istotności, z różnymi czasami reakcji i usunięcia problemu.
Jeśli strony przewidują kary umowne za nienależyte wykonanie usług, powinny wskazać, że ich zapłata nie wyklucza dochodzenia dalszych roszczeń odszkodowawczych, chyba że chcą to świadomie ograniczyć.
Prawa autorskie, licencje i korzystanie z rezultatów
Utwory chronione a proste rezultaty prac
Nie każdy rezultat projektu podlega ochronie prawnoautorskiej. Raport z liczbami, surowe dane czy prosta tabela często nie są „utworem” w rozumieniu prawa autorskiego.
W umowie dobrze jednak założyć, że wszystko, co może być utworem (grafika, tekst, kod, projekt UX, scenariusz), jest nim i opisać zasady korzystania z tego przez klienta.
Przeniesienie autorskich praw majątkowych
Jeśli celem jest pełne „posiadanie” rezultatów przez klienta, stosuje się przeniesienie autorskich praw majątkowych na polach eksploatacji istotnych dla projektu.
Należy wskazać te pola konkretnie, np. utrwalanie i zwielokrotnianie dowolną techniką, wprowadzanie do obrotu, publiczne udostępnianie w internecie, modyfikacje i opracowania.
Brak wyliczenia pól eksploatacji skutkuje tym, że przeniesienie jest niepełne, a spory pojawiają się przy pierwszej większej zmianie lub re-use materiałów.
Licencja zamiast przeniesienia praw
Przy stałej współpracy lub usługach specjalistycznych częściej stosuje się licencję, zwykle niewyłączną. Pozwala to wykonawcy korzystać z części rozwiązań u innych klientów.
Trzeba określić, czy licencja jest terytorialnie nieograniczona, na jaki czas jest udzielana oraz czy klient może udzielać sublicencji (np. swoim podwykonawcom, partnerom).
Jeżeli klient wymaga licencji wyłącznej, wykonawca powinien skalkulować to w cenie – ogranicza to bowiem możliwość ponownego użycia wypracowanych rozwiązań.
Moment przejścia praw i warunek zapłaty
Bez wskazania momentu przejścia praw powstaje luka: klient korzysta z materiałów w trakcie projektu, ale formalnie nie ma do tego tytułu.
Częsty model: prawa przechodzą z chwilą zapłaty pełnego wynagrodzenia za dany etap lub całość prac. Zabezpiecza to wykonawcę przed zaległymi płatnościami.
Przy projektach krytycznych dla klienta lepszy bywa kompromis: przejście praw po odbiorze, z prawem wstrzymania licencji przy braku zapłaty w terminie.
Materiały dostarczone przez klienta
Jeśli klient dostarcza logotypy, zdjęcia, teksty czy bazy danych, w umowie powinien oświadczyć, że ma prawa do ich wykorzystania w projekcie.
Chroni to wykonawcę przed roszczeniami osób trzecich (np. fotografa, który nigdy nie udzielił licencji na publikację zdjęć w internecie).
Można dodać zapis, że klient zwalnia wykonawcę z odpowiedzialności za naruszenia praw osób trzecich wynikające z użycia przekazanych materiałów.
Gotowe komponenty, biblioteki i stocki
W wielu projektach wykorzystuje się biblioteki open source, fonty, zdjęcia stockowe czy szablony. Umowa powinna to dopuszczać i porządkować.
Wykonawca może zobowiązać się do używania wyłącznie komponentów z legalnych źródeł oraz wskazania ich listy (np. w załączniku technicznym).
Dobrą praktyką jest rozdzielenie: wykonawca zapewnia licencje na część elementów (np. płatne wtyczki), a za inne płaci klient na własnym koncie, by mieć do nich bezpośredni dostęp.
Prawo do portfolio i case studies
Agencje i freelancerzy zwykle chcą pokazywać wykonane projekty w portfolio. Klienci czasem chcą ciszy aż do premiery albo w ogóle zakazu publicznego chwalenia się współpracą.
Można to prosto uregulować: zgoda na użycie logotypu klienta, nazwy i skróconego opisu projektu w portfolio wykonawcy, z zastrzeżeniem, że poufne dane i liczby nie będą ujawniane.
Przy projektach wrażliwych dopuszczalne jest uzależnienie publikacji case study od wcześniejszej akceptacji jego treści przez klienta.
Poufność, dane osobowe i bezpieczeństwo informacji
Zakres informacji poufnych
Standardowa klauzula poufności, że „wszystko jest tajemnicą”, w praktyce bywa martwa. Lepiej określić przynajmniej przykładowe kategorie informacji.
Przykłady: dane klientów, wyniki badań, know-how techniczne, strategie marketingowe, informacje o cenach i marżach, niewprowadzone jeszcze produkty.
Klauzula powinna przewidywać wyjątki: informacje powszechnie znane, uzyskane legalnie od osób trzecich lub wymagane do ujawnienia przez prawo lub organ.
Czas trwania obowiązku zachowania tajemnicy
Obowiązek poufności często obowiązuje w trakcie umowy i przez określony czas po jej zakończeniu (np. 3–5 lat). W niektórych branżach uzasadniony jest dłuższy okres.
Nie ma sensu wpisywać „wieczystej” poufności dla każdej informacji – lepiej zdefiniować rozsądny horyzont, zostawiając możliwość przedłużenia dla wybranych danych.
Dane osobowe i RODO
Jeżeli w ramach projektu dochodzi do przetwarzania danych osobowych, potrzebna jest odrębna umowa powierzenia przetwarzania albo odpowiednie postanowienia w głównej umowie.
Należy ustalić role stron: administrator, podmiot przetwarzający, ewentualnie współadministratorzy. Bez tego trudno później rozliczać obowiązki informacyjne i bezpieczeństwo.
W umowie powierzenia powinny znaleźć się m.in. kategorie danych, cele i czas przetwarzania, środki bezpieczeństwa oraz zasady korzystania z podwykonawców (podprocesorów).
Standardy bezpieczeństwa i dostęp do systemów
Przy projektach IT, marketing automation czy integracjach systemów kluczowe są zasady dostępu do środowisk klienta.
Umowa może wymagać stosowania określonych standardów bezpieczeństwa (np. hasła o określonej złożoności, szyfrowanie dysków, VPN, dwuskładnikowe uwierzytelnianie).
Przydatne są też jasne reguły: kto zakłada konta, kto je usuwa po zakończeniu współpracy, jak dokumentuje się przekazanie danych dostępowych i kto odpowiada za ich ochronę.
Konsekwencje naruszenia poufności
Same ogólne zakazy bez sankcji motywują słabo. Można przewidzieć kary umowne za istotne naruszenia poufności, zwłaszcza takie, które powodują szkody wizerunkowe lub regulatorowe.
Rozsądne jest zastrzeżenie, że zapłata kary nie wyłącza możliwości dochodzenia odszkodowania przewyższającego jej wysokość, jeśli szkoda okaże się większa.
Podwykonawcy, zespół projektowy i komunikacja
Kto faktycznie realizuje projekt
Przy większych projektach klient często oczekuje konkretnych osób po stronie wykonawcy (np. senior developera, stratega, lead designera).
Da się to wpisać w umowę jako skład zespołu, z możliwością jego zmiany tylko za zgodą klienta lub przy zapewnieniu porównywalnych kwalifikacji.
Podwykonawcy i odpowiedzialność za nich
Większość realizacji wymaga podwykonawców: copywriterów, grafików, programistów, firm hostingowych. Umowa może generalnie na to zezwalać, ale zastrzegać pełną odpowiedzialność wykonawcy za ich działania.
Przy krytycznych elementach (np. hosting danych medycznych) klient może wymagać zatwierdzenia konkretnego podwykonawcy lub określonego poziomu certyfikacji.
Osoby kontaktowe i ścieżki decyzyjne
Brak jasno wyznaczonych osób kontaktowych generuje chaos: sprzeczne wytyczne, dublujące się zadania, decyzje cofane przez „kogoś wyżej”.
W umowie dobrze wskazać koordynatora po każdej stronie oraz zastrzec, że tylko jego decyzje i akceptacje są wiążące dla projektu, chyba że wskazano inaczej na piśmie.
Można też doprecyzować, które decyzje wymagają formy pisemnej (np. zakres, budżet), a które mogą się odbywać operacyjnie (np. wybór zdjęcia do posta).
Narzędzia i kanały komunikacji
Im więcej kanałów, tym większe ryzyko, że coś umknie. Warto wskazać w umowie podstawowe narzędzia: e-mail, komunikator, system do zadań.
Najbezpieczniej powiązać skutki prawne (akceptacje, zmiany, zgłoszenia wad) z jednym, głównym kanałem, najczęściej e-mailem lub systemem ticketowym.
Ustne ustalenia na spotkaniach można zobowiązać do potwierdzania „dla porządku” mailowo – to prosty sposób na unikanie nieporozumień.
Zmiana, zawieszenie i rozwiązanie umowy
Zmiany umowy i aneksy
W każdym dłuższym projekcie umowa wymaga korekt: zmienia się zakres, terminy, czasem model współpracy. Dobrze zawczasu określić tryb takich zmian.
Klauzula typu „wszelkie zmiany wymagają formy pisemnej pod rygorem nieważności” daje bezpieczeństwo, ale bywa zbyt sztywna przy dynamicznych projektach.
Alternatywa: dopuszczenie formy dokumentowej (np. wymiana e-maili) dla zmian mniejszej wagi, przy zastrzeżeniu pisemnego aneksu dla kluczowych parametrów (budżet, harmonogram główny).
Zawieszenie projektu
Projekty potrafią stanąć z powodów niezależnych: zmiana zarządu, brak budżetu, opóźnione decyzje regulatora. W umowie można przewidzieć prawo do czasowego zawieszenia.
Wykonawca może zastrzec minimalny okres zawieszenia, zasady przechowywania materiałów oraz rozliczenia prac wykonanych do dnia zawieszenia.
Strony mogą też ustalić maksymalny łączny czas zawieszeń, po którym każda z nich zyska prawo do zakończenia umowy z określonym skutkiem finansowym.
Rozwiązanie umowy z ważnych przyczyn
Poza standardowym wypowiedzeniem „bez podania przyczyny” (z określonym okresem) przydaje się katalog ważnych przyczyn natychmiastowego zakończenia współpracy.
Przykłady: rażące naruszenie poufności, istotne i nieusunięte naruszenia jakości, uporczywe opóźnienia w płatnościach, łamanie prawa w związku z projektem.
Dobrą praktyką jest obowiązek uprzedniego wezwania do naprawy naruszeń w wyznaczonym terminie, chyba że sytuacja jest na tyle poważna, że dalsza współpraca jest obiektywnie niemożliwa.
Rozliczenie po zakończeniu współpracy
Umowa powinna opisywać, co się dzieje po jej rozwiązaniu: które wynagrodzenie jest należne, jakie prawa przechodzą, co z rozpoczętymi, ale niedokończonymi etapami.
Możliwy model: wykonawca otrzymuje wynagrodzenie proporcjonalne do wykonanych i przekazanych prac, a klient uzyskuje prawa tylko do tej części rezultatów.
Trzeba też uregulować zwrot lub usunięcie danych, przekazanie haseł, repozytoriów kodu, plików źródłowych oraz forma potwierdzenia, że to nastąpiło.
Odpowiedzialność, ograniczenia i siła wyższa
Zakres odpowiedzialności odszkodowawczej
Bez ograniczeń wykonawca teoretycznie odpowiada za każdą szkodę pozostającą w adekwatnym związku z naruszeniem umowy. To zbyt szerokie ryzyko przy wielu projektach.
Standardem jest limit odpowiedzialności, np. do wysokości wynagrodzenia z ostatnich kilku miesięcy lub z całej umowy, z wyłączeniem szkód wyrządzonych umyślnie.
Ważne jest wyraźne wyłączenie odpowiedzialności za utracone korzyści, chyba że projekt dotyczy wprost generowania przychodu i strony chcą je świadomie objąć ryzykiem.
Wyłączenia odpowiedzialności za naruszenia prawa
Jeżeli klient wymusza działania na granicy prawa (np. w mailingu, zbieraniu zgód marketingowych), wykonawca powinien mieć prawo odmowy oraz zapis, że nie odpowiada za konsekwencje zaleceń klienta sprzecznych z prawem.
Można ująć to wprost: klient ponosi odpowiedzialność za zgodność z prawem treści, które zatwierdza, oraz za model pozyskiwania danych, na bazie których prowadzone są działania.
Siła wyższa i zdarzenia nadzwyczajne
Klauzula siły wyższej chroni obie strony, gdy dochodzi do zdarzeń całkowicie od nich niezależnych: wojny, katastrof naturalnych, poważnych awarii infrastruktury krytycznej.
Umowa zwykle przewiduje, że w okresie trwania siły wyższej obowiązki stron ulegają zawieszeniu, a terminy się przesuwają, o ile strona dotknięta zdarzeniem niezwłocznie o nim poinformuje.
Jeśli stan ten utrzymuje się dłużej (np. kilka miesięcy), każda ze stron może mieć prawo zakończenia umowy bez odpowiedzialności odszkodowawczej, z rozliczeniem dotychczas wykonanych prac.
Jurysdykcja, prawo właściwe i sposób rozwiązywania sporów
Wybór prawa i sądu
Przy współpracy międzynarodowej trzeba wskazać, jakie prawo stosuje się do umowy i który sąd będzie rozstrzygał spory.
Najprościej: prawo państwa, w którym siedzibę ma jedna ze stron, oraz sąd właściwy dla jej siedziby. Przy silniejszym partnerze często nie ma tu pola do negocjacji.
Dla relacji B2B istotne jest, by uniknąć niejasności – brak zapisu oznacza później konieczność badania przepisów kolizyjnych, co wydłuża każdy spór.
Mediacja, negocjacje i klauzule polubowne
Spory rzadko opłaca się zaczynać od sądu. Często wystarcza rozmowa na poziomie zarządów lub z udziałem zewnętrznego mediatora.
Umowa może wprowadzać obowiązkowy etap negocjacji lub mediacji przed pozwem, z określeniem terminu na jego przeprowadzenie i sposobu wyboru mediatora.
Przy prostszych projektach wystarczy obowiązek „podjęcia próby ugodowego rozwiązania sporu w terminie 30 dni od zgłoszenia zastrzeżeń”. Przy większych budżetach można dodać bardziej szczegółową procedurę: wymiana stanowisk na piśmie, jedno spotkanie decyzyjne, potem dopiero droga sądowa lub arbitraż.
Klauzula polubownego rozwiązywania sporów nie powinna blokować dochodzenia roszczeń zabezpieczających (np. zakaz używania materiałów naruszających prawa). Można to wprost wyłączyć, wskazując, że żądanie zabezpieczenia nie narusza obowiązku mediacji.
Przy projektach o dużym znaczeniu biznesowym strony czasem wybierają stały sąd arbitrażowy zamiast sądu powszechnego. Postępowanie bywa szybsze i bardziej poufne, ale też droższe, więc bez realnej potrzeby lepiej nie narzucać arbitrażu w typowych umowach usługowych.
Finalny kształt umowy współpracy w projekcie zawsze jest wynikiem kompromisu między elastycznością a bezpieczeństwem. Im precyzyjniej opisane role, zakres, komunikacja, odpowiedzialność i scenariusze „na trudne czasy”, tym mniej zaskoczeń w trakcie realizacji i większa szansa, że obie strony zakończą projekt z poczuciem dobrze wykonanej roboty.
Źródło: Pexels | Autor: RDNE Stock project
Bezpieczeństwo informacji i dane w projekcie
Poufność i zakres informacji chronionych
Praktycznie każda współpraca wymaga wymiany informacji, których nie chce się widzieć u konkurencji ani w mediach.
Klauzula poufności powinna wskazywać, co dokładnie jest poufne: dokumenty projektowe, dane klientów, know-how, warunki handlowe, kod źródłowy, dostępy do narzędzi.
Można wprowadzić prostą zasadę: wszystko, co nie jest publicznie dostępne i zostało ujawnione w związku z projektem, traktuje się jako poufne, nawet bez oznaczenia „confidential”.
Obowiązki stron w zakresie poufności
Umowa może wymagać stosowania co najmniej „rozsądnych środków” ochrony, zgodnych ze standardem branży, albo wymieniać konkretne wymogi (szyfrowanie dysków, brak zapisywania haseł w przeglądarce itp.).
Przydatny jest zapis, że dostęp do informacji poufnych uzyskują tylko osoby faktycznie potrzebne do projektu, a strony zapewniają im stosowne zobowiązania do poufności.
Dobrze też ograniczyć wykorzystanie informacji poufnych wyłącznie do realizacji umowy, bez prawa użycia w innym celu (np. w innym projekcie lub w działaniach marketingowych).
Czas trwania obowiązku poufności
Obowiązek poufności zwykle wykracza poza czas trwania projektu.
Typowy okres to 3–5 lat od zakończenia umowy, ale przy szczególnie wrażliwych danych (np. wynalazki, algorytmy) okres może być dłuższy lub bezterminowy.
Wyjątek można przewidzieć dla informacji, które staną się publiczne z przyczyn niezależnych od strony zobowiązanej, lub zostały już wcześniej legalnie znane stronie.
Bezpieczeństwo danych i dostępy
Jeżeli współpraca wymaga dostępu do systemów klienta, umowa powinna opisywać zasady ich nadawania, korzystania i odwoływania.
Przydatna jest checklista: jakie konta trzeba założyć, kto je zakłada, jak szybko po zakończeniu współpracy dostępy są blokowane, kto archiwizuje logi.
Przy danych szczególnie wrażliwych (np. dane zdrowotne, dane finansowe) strony mogą wymagać dodatkowych zabezpieczeń: VPN, klucze sprzętowe, praca wyłącznie z biura.
Dane osobowe i RODO w umowach projektowych
Rola stron: administrator i podmiot przetwarzający
Przy projektach, które dotykają danych osobowych (np. mailing, CRM, aplikacja dla klientów), trzeba określić role z punktu widzenia RODO.
Najczęściej klient jest administratorem danych, a wykonawca – procesorem (podmiotem przetwarzającym) działającym na jego polecenie.
Jeżeli każda ze stron ma własne zbiory danych, którymi się wymienia (np. lista partnerów), może wystąpić dwóch niezależnych administratorów – warto nazwać to wprost.
Umowa powierzenia przetwarzania danych
RODO wymaga odrębnej umowy lub załącznika określającego warunki powierzenia danych.
Powinno się tam wskazać cel, zakres i czas przetwarzania, kategorie danych i osób, a także instrukcje klienta dotyczące przetwarzania.
Bez tych elementów współpraca przy danych osobowych jest po prostu niezgodna z prawem i grozi sankcjami obu stronom.
Środki techniczne i organizacyjne
Standardowy zapis „zastosuje odpowiednie środki techniczne i organizacyjne” jest zbyt ogólny przy projektach wysokiego ryzyka.
Przy większych kontraktach dodaje się też obowiązek okresowych audytów bezpieczeństwa albo udostępniania raportów z zewnętrznych testów (np. testy penetracyjne).
Incydenty bezpieczeństwa i zgłoszenia naruszeń
Umowa powinna określać, co się dzieje, gdy dojdzie do wycieku danych lub innego incydentu bezpieczeństwa.
Kluczowy jest czas reakcji – np. obowiązek poinformowania administratora „bez zbędnej zwłoki, nie później niż w ciągu 24 godzin od wykrycia naruszenia”.
Następnie ustala się podział zadań: kto analizuje przyczynę, kto przygotowuje zgłoszenia do organu nadzorczego i komunikację do osób, których dane dotyczą.
Zmiany w projekcie i zarządzanie zakresem
Procedura zgłaszania zmian (change request)
Przy bardziej złożonych projektach zmian nie da się uniknąć, ale można je kontrolować.
Przydatna jest formalna procedura change request: opis zmiany, wpływ na czas i budżet, termin na akceptację przez klienta, osoba zatwierdzająca.
Bez tego niewinne „a może jeszcze tylko…” kończy się konfliktem o nieopłacone godziny i spóźnione wdrożenie.
Drobne modyfikacje a istotna zmiana zakresu
Umowa może przewidywać pakiet drobnych zmian mieszczących się w ustalonej liczbie godzin lub procentowym limicie budżetu.
Powyżej tego progu każda zmiana jest traktowana jako istotna i wymaga osobnego zamówienia, aneksu lub dodatkowego budżetu.
Przykład: do 10% wartości kontraktu zmiany mogą być zatwierdzane mailowo przez kierownika projektu, powyżej – wymagają aneksu podpisanego przez zarząd.
Rejestr decyzji i historii zmian
Przy dłuższych projektach przydaje się jeden rejestr zmian, choćby w arkuszu online lub w systemie do zarządzania zadaniami.
Każda istotna decyzja: kto zainicjował, na czym polega zmiana, data, szacowany wpływ na inne elementy, sposób akceptacji.
Taki rejestr często ratuje przy sporach o interpretację zakresu i pozwala szybko odtworzyć historię projektu, mimo rotacji osób po obu stronach.
Zarządzanie wiedzą i przekazanie rezultatów
Dokumentacja projektowa i jej zakres
Bez dokumentacji projekt po kilku miesiącach staje się „czarną skrzynką”, której nikt nie chce dotykać.
Umowa może wymagać konkretnych artefaktów: specyfikacji, instrukcji użytkownika, instrukcji administracyjnej, diagramów architektury, listy zależności zewnętrznych.
Dobrze wyraźnie zaznaczyć, czy dokumentacja jest elementem wynagrodzenia, czy dodatkową usługą, i jakie są minimalne standardy (format, język, poziom szczegółowości).
Przekazanie materiałów i środowisk
Na etapie zakończenia projektu często pojawia się chaos: część plików na prywatnych dyskach, część w narzędziach, do których klient nie ma dostępu.
Umowa może przewidywać uporządkowany proces: lista folderów, przekazanie repozytoriów, kont na platformach, kluczy API, licencji użytych w projekcie.
Dobrym rozwiązaniem jest „protokół przekazania”, w którym strony potwierdzają, co zostało przekazane i w jakiej wersji.
Wsparcie powdrożeniowe i utrzymanie
Po zakończeniu głównej fazy projektu zwykle potrzebne jest wsparcie: naprawa błędów, aktualizacje, drobne zmiany.
Można to rozwiązać przez okres gwarancji (naprawa błędów w cenie) oraz odrębny pakiet utrzymaniowy, rozliczany abonamentowo lub godzinowo.
Umowa powinna precyzować, co jest „błędem” podlegającym usunięciu w ramach gwarancji, a co jest zmianą funkcjonalności wymagającą dodatkowego wynagrodzenia.
Etyka biznesowa i konflikty interesów
Zakaz pozyskiwania pracowników i podwykonawców
W trakcie dłuższego projektu strony często się poznają na tyle dobrze, że pojawia się pokusa „podebrania” kluczowych ludzi.
Chroni przed tym klauzula zakazu rekrutacji (non-solicitation), np. przez 6–12 miesięcy po zakończeniu współpracy.
Można przewidzieć wyjątek: możliwość przejęcia pracownika za ustaloną z góry opłatą rekrutacyjną.
Konflikty interesów i praca dla konkurencji
W niektórych branżach (np. farmacja, bankowość) klient wymaga, by wykonawca nie pracował równolegle dla bezpośredniej konkurencji przy podobnych projektach.
Zakazy tego typu trzeba zawężać: czasowo, geograficznie i przedmiotowo, żeby nie blokowały całej działalności wykonawcy.
W umowie można dodać obowiązek ujawniania potencjalnych konfliktów interesów i procedurę ich rozwiązywania (np. wyłączenie danego zespołu z projektu po jednej ze stron).
Standardy etyczne i zgodność z regulacjami
Przy projektach z sektora regulowanego (publiczny, medyczny, finansowy) klient często wymaga stosowania własnych kodeksów etyki, polityk antykorupcyjnych czy compliance.
Umowa może zobowiązywać wykonawcę do zapoznania zespołu z tymi dokumentami oraz do ich przestrzegania, pod rygorem kar umownych lub rozwiązania kontraktu.
Wykonawca z kolei może zastrzec, że nie będzie realizować działań sprzecznych z prawem lub dobrymi obyczajami, nawet jeśli klient będzie tego oczekiwał.
Przykładowe załączniki do umowy projektowej
Zakres prac (Statement of Work, SOW)
Zamiast przeładowywać główny tekst umowy, szczegółowy opis zakresu często umieszcza się w załączniku SOW.
Można w nim rozbić projekt na moduły, podać kryteria akceptacji, listę dostarczanych elementów i szczegółowy harmonogram.
Zaletą jest możliwość aktualizacji SOW w drodze aneksu bez naruszania całej umowy ramowej.
Budżet, stawki i model rozliczeń
Oddzielny załącznik finansowy porządkuje stawki, limity godzin, zasady rozliczania kosztów zewnętrznych (np. licencje, kampanie reklamowe, podróże).
Można tam umieścić tabele z progami rabatowymi, dopłatami za tryb „express” lub pracę poza standardowymi godzinami.
Przy projektach długoterminowych przydatny jest też wzór raportu godzinowego lub rozliczenia etapów.
Standardy jakości i SLA
Przy usługach ciągłych (np. utrzymanie systemu, obsługa kampanii) typowym załącznikiem jest dokument SLA opisujący parametry jakościowe.
Mogą to być czasy reakcji na zgłoszenia, dostępność systemu, dopuszczalna liczba błędów na miesiąc i sankcje za ich przekroczenie.
Wyraźne połączenie SLA z rozliczeniami (np. rabat za niedotrzymanie parametrów) często działa lepiej niż ogólne groźby kar umownych.
Wzory dokumentów i formularzy
Drobny, ale praktyczny element to wzory podstawowych dokumentów projektowych: protokołów odbioru, zgłoszeń błędów, raportów miesięcznych.
Dzięki temu od początku wiadomo, jakie informacje będą zbierane i w jakiej formie, co ułatwia obieg dokumentów po obu stronach.
Zmiany wzorów można uzgodnić później roboczo, ale bazowy zestaw na starcie ogranicza liczbę nieporozumień organizacyjnych.
Rozwiązanie umowy i zakończenie współpracy
Przesłanki wypowiedzenia i odstąpienia
W projektach ryzyko rozstania „w trakcie” jest wyższe niż przy prostych zleceniach.
Umowa powinna precyzyjnie opisywać, kiedy strona może odstąpić (skutek wsteczny) albo wypowiedzieć umowę (skutek na przyszłość).
Standardowo pojawiają się przesłanki: istotne naruszenie umowy, zwłoka w płatnościach, rażące naruszenie zasad bezpieczeństwa czy poufności.
Okres wypowiedzenia i naprawa naruszeń
Zamiast „natychmiastowego” rozwiązania w wielu sytuacjach stosuje się mechanizm uprzedniego wezwania do usunięcia naruszeń.
Przykład: najpierw pisemne wezwanie z 14-dniowym terminem na poprawę, a dopiero potem prawo do wypowiedzenia ze skutkiem natychmiastowym.
Przy wypowiedzeniu z zachowaniem okresu (np. 1 miesiąc) warto doprecyzować, czy w tym czasie realizowane są tylko rozpoczęte zadania, czy można zlecać nowe.
Rozliczenie prac na dzień zakończenia
Umowa powinna wskazywać, jak rozliczyć się w momencie zakończenia współpracy, zwłaszcza przy modelu time & material.
Typowo rozlicza się wykonane i odebrane etapy, a prace w toku według ustalonej metody (np. procent zaawansowania albo stawki godzinowe).
Bez tego po rozwiązaniu kontraktu powstaje spór o to, co „już się należy”, a co jest „niedokończone i bezużyteczne”.
Kontynuacja krytycznych usług
Przy projektach zależnych od ciągłego działania systemów dobrze przewidzieć obowiązek tymczasowego utrzymania kluczowych usług po wypowiedzeniu.
Może to być np. 30–60 dni „okresu przejściowego”, w którym wykonawca zapewnia minimalne SLA do czasu przejęcia systemów przez nowy zespół.
Bez takiego bufora klient zostaje z ryzykiem nagłej przerwy w działaniu biznesu.
Źródło: Pexels | Autor: RDNE Stock project
Odpowiedzialność, szkody i kary umowne
Ograniczenie odpowiedzialności
Standardem przy projektach jest ograniczenie odpowiedzialności wykonawcy do określonej kwoty, najczęściej do sumy wynagrodzenia z ostatniego okresu.
Wyłącza się też zwykle utracone korzyści, chyba że strony uzgodnią inaczej w związku z krytyczną infrastrukturą.
Przy projektach wysokiego ryzyka sensowne jest powiązanie limitu z polisą OC (np. odpowiedzialność do wysokości sumy ubezpieczenia).
Kary umowne – kiedy i jak je konstruować
Kary umowne działają głównie motywująco, ale źle napisane stają się polem do długich sporów.
Najpraktyczniej wiązać je z mierzalnymi zdarzeniami: opóźnienia, brak dostępności systemu, naruszenie poufności, brak usunięcia wady w terminie.
Powinien pojawić się górny limit kar za cały okres umowy oraz jasna informacja, czy klient może dochodzić odszkodowania ponad karę.
Odpowiedzialność za podwykonawców
Jeżeli w projekt zaangażowani są podwykonawcy, zwykle przyjmuje się odpowiedzialność wykonawcy „jak za własne działania”.
Można jednak wprowadzić dodatkowe wymagania, np. obowiązek uzgadniania kluczowych podwykonawców z klientem albo wymóg określonych certyfikatów.
Przy bardziej złożonych łańcuchach dostaw przydatne jest wskazanie, kto odpowiada za zarządzanie konfliktami między podwykonawcami.
Spory, eskalacja i właściwość sądu
Wejście na ścieżkę sporu – najpierw rozmowa, potem prawnik
W wielu projektach udaje się uniknąć procesu sądowego dzięki formalnej procedurze eskalacji.
Najpierw spotkanie robocze zespołów, potem eskalacja na poziom zarządów, a dopiero w razie braku porozumienia – droga sądowa lub arbitraż.
W umowie warto wskazać terminy na odpowiedź i uzgodnienie stanowisk, żeby spór nie „kisił się” miesiącami bez decyzji.
Mediacja i arbitraż
Przy większych kontraktach pojawiają się zapisy o obowiązkowej mediacji przed wniesieniem pozwu.
Można wskazać konkretną instytucję mediacyjną lub arbitrażową i skrócony tryb postępowania.
Takie rozwiązanie bywa szybsze i tańsze niż kilkuletni spór w sądzie powszechnym.
Prawo właściwe i sąd
Przy współpracy międzynarodowej elementem krytycznym jest wybór prawa właściwego i sądu.
Brak jednoznacznego zapisu oznacza duże ryzyko – każda ze stron może próbować forsować „swój” porządek prawny.
Najczęściej wybiera się prawo siedziby klienta lub wykonawcy, a przy projektach unijnych – prawo państwa, gdzie koncentrują się główne świadczenia.
Ubezpieczenia w projektach
Polisa OC wykonawcy
Przy bardziej wrażliwych projektach klient często wymaga od wykonawcy posiadania aktualnej polisy OC.
W umowie podaje się minimalną sumę ubezpieczenia, zakres (np. szkody w danych, szkody rzeczowe) oraz obowiązek dostarczenia potwierdzenia polisy.
Brak ważnego ubezpieczenia można powiązać z prawem do wstrzymania płatności albo nawet rozwiązania kontraktu.
Dodatkowe ubezpieczenia specyficzne dla projektu
Niektóre projekty wymagają dodatkowych polis, np. cyber, zawodowej (professional indemnity) czy ubezpieczenia sprzętu.
Umowa może wskazywać, która strona je zapewnia i jak koszty są refakturowane lub wliczane w wynagrodzenie.
Jeżeli odpowiedzialność wykonawcy jest powiązana z polisą, zapis o limitach odpowiedzialności powinien to jasno odzwierciedlać.
Specyfika projektów IT i digital
Repozytoria kodu i dostęp do narzędzi
Przy projektach IT kluczowe jest uregulowanie dostępu do repozytoriów kodu i systemów CI/CD.
Najbezpieczniejszy model to repozytorium należące do klienta, z dostępem dla wykonawcy i precyzyjnymi uprawnieniami.
W umowie można wskazać, kto zarządza uprawnieniami, jak długo przechowywane są gałęzie i jak wygląda procedura zamknięcia dostępu.
Open source i licencje zewnętrzne
Kod otwarty ułatwia pracę, ale może generować ryzyka licencyjne.
Umowa może wymagać prowadzenia listy użytych bibliotek wraz z ich licencjami oraz zakazywać stosowania licencji „zaraźliwych” (np. GPL) bez zgody klienta.
Przy płatnych komponentach (np. komponenty UI, biblioteki komercyjne) trzeba ustalić, kto kupuje licencje i kto będzie ich właścicielem po projekcie.
Środowiska: deweloperskie, testowe, produkcyjne
Warto rozróżnić środowiska i przypisać odpowiedzialność za każde z nich.
Klient może utrzymywać produkcję, a wykonawca – środowiska testowe; albo odwrotnie, zależnie od modelu współpracy.
Należy też określić, czy na środowiskach testowych mogą znajdować się dane produkcyjne, a jeśli tak – na jakich warunkach i z jakimi zabezpieczeniami.
Projekty kreatywne i marketingowe
Akceptacja koncepcji i kreacji
Przy projektach kreatywnych największe konflikty dotyczą gustu i oczekiwań względem efektu.
Umowa może przewidywać kilka iteracji koncepcji, z limitem poprawek na każdym etapie i jasnym kryterium „akceptacji milczącej” po braku uwag w terminie.
Dzięki temu projekt nie utknie w niekończącej się serii drobnych kosmetycznych zmian.
Prawa do wykorzystania wizerunku i treści
Jeśli projekt obejmuje tworzenie treści z udziałem osób trzecich (modele, influencerzy, eksperci), konieczne są odpowiednie zgody i umowy wizerunkowe.
Warto wskazać, kto je pozyskuje i na jaki czas oraz obszar są udzielane prawa do wykorzystania wizerunku.
W przeciwnym razie ryzyko roszczeń z tytułu naruszenia dóbr osobistych spada na stronę, która korzysta z materiałów.
Emisja, media i odpowiedzialność za publikację
W kampaniach istotne jest rozdzielenie odpowiedzialności za przygotowanie kreacji i jej emisję.
Jeśli emisją zajmuje się klient lub osobny dom mediowy, umowa powinna jasno stwierdzać, że wykonawca nie odpowiada za błędy w publikacji poza jego kontrolą.
Z kolei wykonawca powinien zagwarantować, że przygotowane materiały nie naruszają praw osób trzecich (prawa autorskie, znaki towarowe).
Projekty z sektorem publicznym
Szczególne wymogi formalne
Współpraca z administracją wiąże się z dodatkowymi wymogami wynikającymi z prawa zamówień publicznych lub wewnętrznych regulaminów.
Umowa często musi odwzorowywać postanowienia SIWZ/OPZ, a odstępstwa są praktycznie niemożliwe.
W praktyce większe pole negocjacji pojawia się dopiero w zakresie załączników technicznych i organizacyjnych.
Jawność i kontrola
Podmiot publiczny bywa zobowiązany do udostępniania części informacji, także umów.
Wykonawca może jednak zastrzec informacje stanowiące tajemnicę przedsiębiorstwa, pod warunkiem właściwego oznaczenia ich w dokumentach.
W umowie można wskazać zasady współpracy przy kontrolach (np. NIK, instytucje audytujące fundusze unijne).
Finansowanie ze środków UE
Przy projektach unijnych umowa musi być spójna z wytycznymi instytucji finansującej.
Może to oznaczać obowiązek prowadzenia szczegółowej dokumentacji, raportowania czy przechowywania dokumentów przez określony czas.
Niedostosowanie zapisów umowy do wymogów programu grozi korektami finansowymi po stronie klienta, a potem regresami wobec wykonawcy.
Operacjonalizacja umowy – jak nią zarządzać w praktyce
Mapowanie zapisów umowy na procesy
Nawet najlepsza umowa nie zadziała, jeśli jej postanowienia nie zostaną przełożone na proste procedury.
Praktycznym krokiem jest stworzenie krótkiej „mapy umowy”: kto odpowiada za akceptacje, kto zatwierdza zmiany, kto pilnuje SLA i raportów.
Takie zestawienie można trzymać w narzędziu projektowym i regularnie aktualizować.
Szkolenie zespołów z kluczowych zapisów
Większość sporów wynika z tego, że osoby operacyjne nigdy nie widziały treści umowy.
Warto zorganizować krótkie omówienie kluczowych zapisów dla PM-ów, liderów technicznych i osób kontaktowych po obu stronach.
Nawet godzinne spotkanie z omówieniem zasad change requestów, akceptacji i SLA znacząco ogranicza liczbę niedomówień.
Monitorowanie wskaźników umownych
Jeśli w umowie zdefiniowano mierzalne parametry (SLA, KPI), powinny być one monitorowane w stałym rytmie.
Minimum to okresowe raporty (np. miesięczne) z jasno przedstawionymi odchyleniami od ustalonych poziomów.
Przekroczenia progów mogą automatycznie uruchamiać działania naprawcze albo dodatkowe spotkania zarządcze, zamiast czekać do końca projektu.
Najczęściej zadawane pytania (FAQ)
1. Czy umowa współpracy w projekcie jest konieczna, jeśli „dogadamy się” mailowo?
Ustalenia mailowe pomagają na etapie rozmów, ale nie zastąpią spójnej umowy. Maile są rozproszone, często niespójne i po kilku miesiącach trudno odtworzyć, co faktycznie ustalono.
W razie sporu sąd w pierwszej kolejności bada umowę, a dopiero potem korespondencję. Brak umowy to większe ryzyko konfliktu, przeciągających się projektów i sytuacji, w której każda strona „pamięta” coś innego.
2. Co powinna zawierać dobra umowa współpracy przy projekcie?
Podstawą jest jasny opis przedmiotu umowy, zakresu prac, harmonogramu oraz wynagrodzenia z zasadami rozliczeń. Bez tego trudno zarządzać projektem i jego zmianami.
W praktyce przydaje się też kilka bloków: prawa autorskie, zasady komunikacji i akceptacji etapów, reguły wprowadzania zmian w zakresie, odpowiedzialność stron, procedura rozwiązania umowy i kwestie poufności. Detale często doprecyzowuje się w załącznikach (brief, specyfikacja, backlog, harmonogram).
3. Kiedy wystarczy prosty kontrakt, a kiedy potrzebny jest prawnik?
Przy prostych, krótkich zleceniach (np. jednorazowe szkolenie, mały landing page, krótka kampania) zwykle wystarcza zwięzła umowa na 2–4 strony z jasno opisanym zakresem, terminem, wynagrodzeniem, prawami autorskimi i poufnością.
Prawnika warto włączyć, gdy projekt ma dużą wartość, trwa długo, dotyczy danych osobowych, własności intelektualnej, dużych budżetów mediowych albo obejmuje kilka podmiotów (konsorcjum, partnerstwo). Pomoc przy analizie skomplikowanej umowy podsuwanej przez drugą stronę często oszczędza nerwów i pieniędzy przy pierwszym kryzysie.
4. Czy mogę użyć szablonu umowy z internetu do współpracy przy projekcie?
Szablon może być dobrym punktem startowym, ale rzadko nadaje się do podpisania „jak leci”. Gotowce zwykle nie uwzględniają specyfiki projektu, realnego zakresu, ryzyk ani roli podwykonawców i partnerów.
Częsty problem: szablon w ogóle nie reguluje praw autorskich, danych osobowych czy podziału odpowiedzialności między kilka organizacji. Efekt to późniejsze spory o materiały, dostęp do danych lub to, kto odpowiada za opóźnienia. Szablon trzeba zawsze przepracować pod konkretny projekt.
5. Jakie dokumenty pomocnicze warto mieć przed spisaniem umowy współpracy?
Najlepiej, gdy umowa nie powstaje „z głowy”, tylko opiera się na istniejących materiałach. W praktyce przydają się:
brief z celem, grupą docelową i głównymi wymaganiami,
specyfikacja lub opis zakresu prac (funkcjonalności, kanały, działania),
backlog lub lista zadań/produktów przy pracy zwinnej,
wstępny harmonogram z etapami i kamieniami milowymi.
Takie dokumenty dobrze dołączyć jako załączniki do umowy. Ułatwia to późniejsze doprecyzowanie szczegółów bez przepisywania całego kontraktu.
6. Jakie pytania zadać przed przygotowaniem umowy, żeby uniknąć niedomówień?
Krótka checklista na wspólne spotkanie często wyłapuje ryzyka zawczasu. Kluczowe pytania to m.in.: jakie trzy główne rezultaty ma dać projekt, kto po stronie klienta decyduje o zmianach i akceptuje etapy, jakie dane i materiały oraz w jakich terminach ma dostarczyć klient.
Warto też doprecyzować sposób współpracy na co dzień (narzędzia, raportowanie), terminy „nie do ruszenia” (np. start kampanii), możliwe koszty dodatkowe oraz rzeczy absolutnie niedopuszczalne (np. podzlecanie bez zgody). Odpowiedzi zwykle pokazują, co trzeba mocniej opisać w samej umowie.
7. Jak poprawnie opisać strony umowy i osoby odpowiedzialne za projekt?
Strony trzeba zidentyfikować precyzyjnie: pełna nazwa, forma prawna, adres, numery rejestrowe (KRS/CEIDG, NIP, REGON, jeśli jest) oraz sposób reprezentacji. Przy freelancerze wystarczą dane z CEIDG i NIP, przy fundacji czy spółce – dane z odpowiedniego rejestru.
Oprócz tego w umowie dobrze wskazać osoby kontaktowe odpowiedzialne za bieżącą współpracę, inną niż osoby uprawnione do podpisywania dokumentów. Ułatwia to egzekwowanie decyzji i przyspiesza reakcję na problemy w projekcie.
Bibliografia i źródła
Kodeks cywilny. Komentarz. C.H.Beck (2022) – Komentarz do przepisów o zobowiązaniach i umowach w prawie polskim
Kodeks cywilny. Sejm Rzeczypospolitej Polskiej (1964) – Podstawowe regulacje dotyczące umów, odpowiedzialności i dowodów
Prawo umów. Zarys wykładu. Wolters Kluwer Polska (2020) – Ogólne zasady konstruowania i wykonywania umów cywilnoprawnych
Umowy w działalności gospodarczej. Polskie Wydawnictwo Ekonomiczne (2018) – Praktyczne omówienie umów B2B, ryzyk i zabezpieczeń kontraktowych
Umowy w projektach IT. Przewodnik praktyczny. ODDK (2019) – Zakres prac, harmonogram, zmiany zakresu, prawa autorskie w projektach IT
Ochrona danych osobowych. RODO w praktyce. Difin (2019) – Obowiązki stron umowy przy przetwarzaniu danych osobowych w projektach
Project Management Body of Knowledge (PMBOK Guide). Project Management Institute (2021) – Standardy zarządzania zakresem, harmonogramem i ryzykiem w projektach
