Spis treści
- adw. TOMASZ SOWA, LL.M.
- +48 22 243 34 75
- kancelaria@sowaip.pl
W skrócie
- „Karuzela poprawek” to następstwo scope creep – stopniowego rozszerzania zakresu projektu po zawarciu umowy, bez zwiększenia wynagrodzenia.
- Orzecznictwo jest jednoznaczne: odbioru nie można uzależniać od spełnienia wymagań, które nie wynikają z umowy.
- Brak formalnego protokołu nie zawsze oznacza brak wykonania – możliwy jest odbiór dorozumiany wynikający z zachowania stron.
- O skuteczności jednostronnego odbioru decyduje jakość dokumentacji: historia wdrożeń, zgłoszeń i wyników testów.
- Klucz to precyzyjny zakres umowy i procedura odbioru odróżniająca wadę od nowej funkcjonalności.
W projektach IT jednym z najczęstszych problemów jest przewlekły i niejednoznaczny proces odbioru. System zostaje wdrożony i udostępniony klientowi, jednak zamiast zakończenia projektu pojawiają się kolejne uwagi, a podpisanie protokołu odbioru jest odkładane w czasie. Każda poprawka rodzi następne oczekiwania, a granica między usuwaniem wad a realizacją nowych funkcjonalności stopniowo się zaciera. W efekcie wykonawca nierzadko realizuje dodatkowe prace bez pewności co do ich odpłatności, a proces odbiorowy przestaje pełnić funkcję potwierdzenia wykonania umowy i staje się narzędziem negocjowania rozszerzenia zakresu projektu.
Karuzela poprawek a pełzanie zakresu (zjawisko scope creep)
Zjawisko to w praktyce projektowej określa się jako „scope creep”, czyli stopniowe rozszerzanie zakresu projektu już po zawarciu umowy, bez odpowiedniego zwiększenia wynagrodzenia. Klient, zamiast ograniczyć się do weryfikacji zgodności systemu z ustaleniami umownymi, zaczyna formułować kolejne oczekiwania dotyczące funkcjonalności, integracji czy sposobu działania systemu. Często zgłaszane uwagi nie odnoszą się do pierwotnie uzgodnionych wymagań, lecz stanowią nowe propozycje rozwiązań, których nie przewidziano w dokumentacji projektowej. Mimo to ich realizacja jest przedstawiana jako warunek konieczny do dokonania odbioru.
Orzecznictwo konsekwentnie podkreśla, że taka praktyka nie znajduje podstaw prawnych. W sprawie rozpoznawanej przez Sąd Okręgowy w Warszawie (wyrok z 25 sierpnia 2021 r., sygn. akt XXII GW 42/20) wskazano, że odbiór nie może być uzależniany od spełnienia wymagań, które nie wynikają z treści umowy. Zamawiający nie może wstrzymywać odbioru ani płatności poprzez formułowanie nowych oczekiwań po wykonaniu dzieła, jeżeli nie zostały one wcześniej uzgodnione przez strony. W takim przypadku należy uznać, że dzieło zostało dostarczone, a umowa spełniona.
Podobne stanowisko odnajdziemy w orzeczeniu Sądu Rejonowego w Lubinie z 3 lutego 2014 r. (sygn. akt I C 2053/13), gdzie podkreślono, że ponowne podnoszenie zastrzeżeń po rozliczeniu prac i zakończeniu etapu nie może prowadzić do podważenia skutecznie wykonanego świadczenia. Kluczowe znaczenie ma zatem precyzyjne określenie zakresu umowy, które pozwala odróżnić rzeczywistą wadę od żądania wykonania nowej funkcjonalności.
Odbiór jednostronny i znaczenie dokumentacji
W obrocie gospodarczym coraz częściej pojawia się pytanie, czy brak podpisanego protokołu odbioru rzeczywiście blokuje zakończenie projektu. Choć w wielu umowach odbiór formalny stanowi istotny element procedury, jego brak nie zawsze oznacza brak wykonania zobowiązania – co ostatecznie podlega ocenie sądu.
W orzecznictwie dopuszcza się tzw. odbiór dorozumiany, który może wynikać z zachowania stron, w szczególności z korzystania z systemu, prowadzenia testów czy potwierdzeń przekazywanych w korespondencji elektronicznej. W wyroku Sądu Rejonowego w Kłodzku z 12 lipca 2013 r. (sygn. akt I C 137/12) uznano, że akceptacja przesłana drogą mailową oraz żądanie uruchomienia strony internetowej mogą stanowić wystarczające potwierdzenie odbioru dzieła, mimo braku formalnego protokołu.
Jednocześnie sądy zwracają uwagę na ryzyko dowodowe związane z brakiem właściwej dokumentacji. Z wyroku Sądu Apelacyjnego we Wrocławiu z 28 sierpnia 2013 r. (sygn. akt I ACa 796/13) wynika, że jeżeli wykonawca nie jest w stanie wykazać momentu zakończenia prac, odróżnić etapu wdrożeniowego od późniejszych poprawek ani powiązać wystawianych faktur z realizacją określonego etapu, ustalenie, czy doszło do wykonania umowy, może okazać się niemożliwe. Skuteczność jednostronnego odbioru zależy więc w dużej mierze od jakości i kompletności dokumentacji projektowej – historii wdrożenia, zgłoszeń oraz wyników testów.
Wynagrodzenie mimo braku podpisu klienta
Brak podpisanego protokołu nie przesądza automatycznie o braku prawa do wynagrodzenia. Decydujące znaczenie ma rzeczywiste wykonanie dzieła zgodnie z umową oraz charakter ewentualnych wad.
Jeżeli system nie spełnia podstawowych funkcji określonych w umowie, klient ma prawo odmówić odbioru i zapłaty. Potwierdza to wyrok Sądu Okręgowego w Rzeszowie (sygn. akt VI GC 102/14), w którym wskazano, że brak zgodności z istotnymi postanowieniami umowy uzasadnia odmowę odbioru, a korzystanie z rozwiązania wyłącznie w celach testowych nie oznacza jego akceptacji.
Z drugiej strony, jeżeli dzieło zostało wykonane zgodnie z ustaleniami i udostępnione klientowi, sama niechęć do podpisania protokołu nie może być utożsamiana z niewykonaniem zobowiązania. Sąd Apelacyjny w Katowicach (wyrok z 5 lipca 2017 r., sygn. akt V ACa 924/16) podkreślił, że jedynie wady istotne mogą uzasadniać odmowę odbioru, natomiast drobne nieprawidłowości nie powinny blokować zakończenia umowy. Jeżeli wykonawca zrealizował zakres umowy, udostępnił system do testów i nie otrzymał w terminie zgłoszeń istotnych wad, brak podpisu nie powinien wyłączać prawa do wynagrodzenia.
Jak zabezpieczyć się przed „karuzelą poprawek”? Praktyczne klauzule
Analiza sporów w projektach IT prowadzi do wniosku, że ich źródłem rzadko są wyłącznie kwestie techniczne. Znacznie częściej problem wynika z nieprecyzyjnego określenia zakresu umowy oraz braku jednoznacznej procedury odbioru, która odróżniałaby wady od zmian funkcjonalnych. Proces odbioru przestaje wtedy pełnić swoją funkcję i staje się narzędziem stopniowego rozszerzania projektu.
Aby ograniczyć to ryzyko, w umowie wdrożeniowej warto zawrzeć co najmniej następujące mechanizmy:
- precyzyjny opis zakresu funkcjonalnego (specyfikacja, kryteria akceptacyjne, definicja „done”) jako załącznik do umowy,
- procedurę testów akceptacyjnych z terminem na zgłoszenie wad i wymaganą formą zgłoszenia,
- klasyfikację błędów (wady krytyczne / istotne / nieistotne) przesądzającą, które z nich blokują odbiór,
- mechanizm milczącego odbioru: brak zgłoszenia wad istotnych w terminie oznacza przyjęcie etapu,
- sformalizowaną procedurę change request – każda nowa funkcjonalność wymaga odrębnej wyceny i aneksu,
- zasady jednostronnego zamknięcia etapu przy bierności zamawiającego.
Dopiero takie podejście zapewnia, że odbiór projektu pozostaje faktycznym potwierdzeniem wykonania uzgodnionych prac, a nie narzędziem do niekontrolowanego rozszerzania zakresu obowiązków wykonawcy.
Najczęściej zadawane pytania (FAQ)
Czym jest scope creep w projekcie IT?
To niekontrolowane, stopniowe rozszerzanie zakresu projektu po zawarciu umowy – klient zgłasza kolejne oczekiwania jako „warunek odbioru”, mimo że nie wynikają one z pierwotnych ustaleń ani dokumentacji projektowej, i bez zwiększenia wynagrodzenia.
Czy klient może uzależnić odbiór od nowych, nieuzgodnionych wymagań?
Nie. Orzecznictwo (m.in. wyrok SO w Warszawie XXII GW 42/20) jednoznacznie wskazuje, że odbioru nie można uzależniać od spełnienia wymagań, które nie wynikają z treści umowy.
Jak odróżnić wadę od nowej funkcjonalności?
Punktem odniesienia jest zakres umowy, specyfikacja i kryteria akceptacyjne. Jeżeli zgłoszenie dotyczy funkcji uzgodnionej w umowie – jest to wada; jeżeli wykracza poza uzgodniony zakres – to nowe wymaganie (change request) podlegające odrębnej wycenie.
Jakie klauzule chronią wykonawcę przed karuzelą poprawek?
Precyzyjna specyfikacja i kryteria akceptacyjne, procedura testów z terminami, klasyfikacja błędów, mechanizm milczącego odbioru oraz sformalizowana procedura change request wymagająca aneksu do umowy.
