Zastrzeżenie: ten artykuł ma charakter biznesowy i edukacyjny, nie jest poradą prawną ani wzorem umowy. Każdy kontrakt powinien zostać sprawdzony przez prawnika znającego projekty IT i realny model współpracy stron.
Umowa wdrożeniowa nie musi mieć stu stron, żeby dobrze chronić obie strony. Musi za to odpowiadać temu, jak zespół naprawdę pracuje. Jeśli projekt jest iteracyjny, kontrakt powinien uwzględniać zmiany i decyzje. Jeśli zakres jest zamknięty, potrzebuje konkretnych kryteriów odbioru.
Dobra umowa nie zastąpi kompetentnego zespołu i regularnej komunikacji. Ustala jednak zasady na moment, gdy pojawi się presja: budżet zacznie się kończyć, integracja nie zadziała albo termin kampanii stanie się ważniejszy niż pierwotny plan.
Najpierw dopasuj umowę do modelu współpracy
Fixed price ma sens, gdy rezultat da się dobrze opisać, a założenia są stabilne. Time & Materials daje większą elastyczność, ale wymaga przejrzystego backlogu, raportowania i kontroli priorytetów. Model hybrydowy może połączyć płatne discovery z wyceną konkretnych etapów.
Żaden model nie usuwa ryzyka. Fixed price nie sprawi, że niejasne wymaganie stanie się jasne, a T&M nie oznacza zgody na pracę bez limitu. W umowie trzeba opisać mechanizm podejmowania decyzji, a nie tylko nazwę sposobu rozliczenia.
1. Limit budżetu i czasu w modelu Time & Materials
W T&M płacisz za faktycznie przepracowany czas. To elastyczne, ale wymaga mechanizmu kontroli. Umowa lub zamówienie może określać budżet okresu, zasady raportowania, osoby uprawnione do akceptacji oraz próg, po którego osiągnięciu prace wymagają nowej zgody.
Doprecyzuj także, czy niewykorzystany limit przechodzi na kolejny okres, jak rozliczane są spotkania i analiza oraz co dzieje się po zgłoszeniu zmiany zakresu. Sam „cap” bez procesu decyzyjnego niewiele daje.
W praktyce dobrze działa krótki rytm: plan na okres, widoczny koszt wykorzystany do tej pory i prognoza do końca. Jeśli prognoza się zmienia, klient dowiaduje się przed przekroczeniem limitu, a nie przy fakturze. Umowa powinna wspierać taką rozmowę.
2. Prawa autorskie, repozytorium i licencje
Umowa powinna rozdzielać kod tworzony dla projektu, wcześniejsze komponenty wykonawcy oraz oprogramowanie osób trzecich. Warto wskazać pola eksploatacji, moment przejścia praw lub udzielenia licencji, dostęp do repozytorium i obowiązek przekazania dokumentacji.
Zgodnie z art. 53 polskiej ustawy o prawie autorskim umowa przenosząca autorskie prawa majątkowe wymaga formy pisemnej pod rygorem nieważności. Aktualny tekst ustawy sprawdź w Internetowym Systemie Aktów Prawnych, a zapis skonsultuj z prawnikiem.
Osobna lista powinna obejmować Magento, Hyvä, płatne moduły, fonty, zdjęcia, biblioteki open source i usługi SaaS. Nie wszystko może być przeniesione na klienta — część elementów działa na warunkach licencji producenta.
Warto też ustalić zasady dostępu do repozytorium już w trakcie projektu. Klient nie powinien odkrywać przy zakończeniu współpracy, że kod, historia zmian albo konfiguracja automatycznych wdrożeń są dostępne tylko na prywatnym koncie wykonawcy.
3. Definicja błędu krytycznego i czas reakcji
Określenie „błąd rażący” jest zbyt nieprecyzyjne. Zdefiniuj poziomy incydentów przez wpływ biznesowy. Krytyczny może oznaczać niedostępność sklepu, brak możliwości złożenia zamówienia, błędne naliczanie płatności lub naruszenie bezpieczeństwa bez dostępnego obejścia.
Poza czasem reakcji ustal godziny wsparcia, kanał zgłoszenia, częstotliwość aktualizacji, oczekiwany czas obejścia oraz analizę przyczyny po incydencie. Czas naprawy nie zawsze można zagwarantować, szczególnie gdy awaria leży po stronie zewnętrznego operatora, ale proces komunikacji powinien być jednoznaczny.
Rozdziel też czas reakcji od czasu usunięcia. Reakcję zespół może kontrolować. Naprawa zależy od przyczyny, dostępności danych i dostawców zewnętrznych. Przy krytycznym incydencie często ważniejsze jest szybkie obejście — na przykład wyłączenie wadliwej metody płatności — niż obietnica pełnego rozwiązania w arbitralne dwie godziny.
4. Oddzielenie analizy od implementacji
Przy złożonym projekcie osobny etap discovery chroni obie strony. Najpierw powstaje opis procesów, integracji, architektury, ryzyk i backlogu, a dopiero potem decyzja o zakresie oraz modelu rozliczenia developmentu.
Umowa analityczna powinna określać konkretne rezultaty: mapę systemów, listę wymagań, kryteria akceptacji, makiety kluczowych ścieżek, estymację i plan etapów. Klient powinien móc użyć tych materiałów niezależnie od tego, kto zrealizuje wdrożenie — na zasadach uzgodnionych w kontrakcie.
To ważne szczególnie wtedy, gdy po analizie okaże się, że pierwotny pomysł jest zbyt drogi albo ryzykowny. Discovery ma dawać możliwość świadomej zmiany kierunku, a nie służyć jako elegancki wstęp do z góry przesądzonego wdrożenia.
Przekazanie projektu i zakończenie współpracy
Dobra umowa opisuje również spokojne rozstanie. Lista przekazywanych elementów może obejmować repozytoria, dostęp do infrastruktury, dokumentację, kopie konfiguracji, konta usług zewnętrznych, listę otwartych błędów i wiedzę potrzebną nowemu zespołowi.
Ustal, ile czasu wykonawca ma na handover i na jakich zasadach jest on rozliczany. Warto też zadbać, aby kluczowe konta — domena, hosting, analityka, płatności i repozytorium — od początku należały do klienta albo organizacji klienta. To prostsze i bezpieczniejsze niż późniejsze odzyskiwanie dostępu.
Co jeszcze doprecyzować?
- zakres i procedurę change request,
- odpowiedzialność za dane, integracje i dostawców zewnętrznych,
- kryteria odbioru oraz terminy na uwagi,
- zasady bezpieczeństwa, backupu i dostępu do środowisk,
- gwarancję, utrzymanie i rozwój po starcie,
- warunki zakończenia współpracy i przekazania projektu.
Najlepszy kontrakt jest zgodny z rzeczywistym procesem i napisany na tyle jasno, żeby rozumiał go nie tylko prawnik. Przed podpisaniem warto połączyć ocenę prawną z technicznym przeglądem dokumentu. Prawnik oceni skuteczność zapisów, a osoba techniczna wyłapie obietnice, których nie da się sensownie zmierzyć lub wykonać.
