Spis treści
- adw. TOMASZ SOWA, LL.M.
- +48 22 243 34 75
- kancelaria@sowaip.pl
Analiza przedwdrożeniowa w projektach IT pełni funkcję, którą można porównać do funkcji, jaką w tradycyjnych inwestycjach budowlanych spełnia projekt koncepcyjny – pozwala określić, co chcemy osiągnąć, zanim przystąpimy do szczegółowego projektowania. Choć pojęcie to nie zostało zdefiniowane w przepisach prawa, jego opracowanie coraz częściej pojawia się w orzecznictwie sądów powszechnych. Analogia do prawa budowlanego, choć użyteczna jako punkt wyjścia, wymaga jednak ostrożności – specyfika projektów informatycznych, w szczególności ich iteracyjny charakter i trudność w pełnym zdefiniowaniu zakresu ex ante, sprawia, że mechaniczne przenoszenie rozwiązań z jednej dziedziny do drugiej może prowadzić do błędnych wniosków.
Analiza przedwdrożeniowa a specyfikacja techniczna – kluczowe rozróżnienie
Przed omówieniem orzecznictwa konieczne jest dokonanie rozróżnienia, które w praktyce projektów IT ma fundamentalne znaczenie, a które bywa pomijane lub zacierane – zarówno w umowach, jak i w pismach procesowych.
Analiza przedwdrożeniowa odpowiada na pytanie: co chcemy osiągnąć? Jest to dokument strategiczny i biznesowy – rozpoznaje potrzeby zamawiającego, identyfikuje cele systemu, mapuje procesy i określa ogólne wymagania funkcjonalne. Jej efektem jest obraz pożądanego stanu docelowego, niekoniecznie przełożony jeszcze na język techniczny.
Specyfikacja techniczna odpowiada na pytanie: jak dokładnie ma to działać? Jest to dokument inżynierski – precyzuje zachowanie każdego modułu, interfejsy wymiany danych, scenariusze użycia, warunki brzegowe, wymagania wydajnościowe i kryteria akceptacji. To ona wyznacza granice zobowiązania wykonawcy w sposób weryfikowalny.
Analogia budowlana: Analiza przedwdrożeniowa to program funkcjonalno-użytkowy – mówi, że inwestor chce biurowca z 200 stanowiskami pracy i salą konferencyjną. Specyfikacja techniczna to projekt budowlany i wykonawczy – mówi, jak ten budynek ma być zbudowany, z jakich materiałów, z jakimi parametrami. Bez projektu budowlanego inwestor nie wydaje pozwolenia na budowę. W projektach IT bez specyfikacji technicznej nie powinno się zaczynać kodowania.
To rozróżnienie ma bezpośrednie przełożenie na sytuację procesową stron. Jak wynika z wyroku Sądu Apelacyjnego we Wrocławiu z 28 sierpnia 2013 r. (I ACa 796/13), sam fakt dysponowania przez strony analizą przedwdrożeniową nie zastępuje specyfikacji technicznej. W tej sprawie wykonawca sporządził specyfikację funkcjonalną dla całego systemu, ale nie zadbał o odrębną, szczegółową specyfikację dla jednego z kluczowych modułów. Efekt był taki, że w toku sporu sądowego nie dało się ustalić, do wykonania czego dokładnie wykonawca się zobowiązał w zakresie tego modułu – a tym samym nie można było stwierdzić ani że go wykonał, ani że zamawiający niezasadnie zmienił wymagania.
Analiza przedwdrożeniowa – rola w projekcie i w sporze
W praktyce analiza przedwdrożeniowa – niezależnie czy dotyczy stworzenia programu, aplikacji czy strony internetowej – polega na szczegółowym rozpoznaniu potrzeb zamawiającego oraz przełożeniu ich na ogólne wymagania funkcjonalne systemu. Jej efektem jest dokument, który wyznacza cele i ramy przyszłego dzieła. W konsekwencji analiza staje się ważnym narzędziem ograniczającym spory dotyczące sensu i celu projektu, natomiast to specyfikacja techniczna – opracowana na podstawie analizy – wyznacza precyzyjne granice świadczenia wykonawcy i stanowi właściwy punkt odniesienia przy ocenie, czy dzieło zostało wykonane zgodnie z umową.
Nie oznacza to, że analiza przedwdrożeniowa jest pozbawiona znaczenia prawnego. W sytuacji gdy strony nadały jej status integralnej części umowy, może ona pełnić rolę dokumentu uzupełniającego specyfikację lub – w braku szczegółowej specyfikacji – zastępować ją w zakresie, w jakim określa wymagania zamawiającego. Ryzyko takiego rozwiązania ponosi jednak przede wszystkim wykonawca, który jako profesjonalista powinien zadbać o uszczegółowienie zobowiązania.
Współdziałanie stron jako warunek skutecznej analizy i specyfikacji
Zarówno sporządzenie analizy przedwdrożeniowej, jak i opracowanie specyfikacji technicznej wymaga ścisłego współdziałania obu stron stosunku prawnego. Z orzecznictwa wynika jednoznacznie, że inicjatywa i ciężar dowodowy w tym zakresie spoczywają na wykonawcy jako profesjonaliście.
W wyroku Sądu Okręgowego w Szczecinie z 21 maja 2015 r. (sygn. VIII Ga 20/15) sąd rozpoznawał sprawę, w której wykonawca sporządził analizę przedwdrożeniową wyłącznie dla jednego z dwóch systemów objętych umową, pomijając drugi – i przystąpił do jego wdrożenia bez jakiejkolwiek dokumentacji wymagań. W toku postępowania wykonawca twierdził, że brak analizy dla drugiego systemu wynikał z niedostarczenia przez zamawiającego niezbędnych danych. Sąd odrzucił tę argumentację, wskazując, że w aktach sprawy brak jest jakiegokolwiek dowodu, aby wykonawca żądał dalszych danych lub sygnalizował ich niewystarczalność. Sąd przyjął, że skoro wykonawca podjął się realizacji umowy bez wymaganej dokumentacji i bez zgłaszania zastrzeżeń, to on – jako profesjonalny przedsiębiorca – ponosi ryzyko związane z brakiem informacji koniecznych dla prawidłowego wykonania systemu.
Wniosek praktyczny: Wykonawca nie może po zakończeniu projektu zasłaniać się brakiem danych ze strony zamawiającego, jeżeli w toku realizacji nie żądał ich uzupełnienia i nie sygnalizował, że brak określonych informacji uniemożliwia mu sporządzenie analizy lub specyfikacji. Milczące przystąpienie do prac bez wymaganej dokumentacji obciąża wykonawcę.
Jednocześnie wyrok ten potwierdza, że zamawiający, który uchyla się od współdziałania mimo wezwań wykonawcy, naraża się na ograniczenie swoich roszczeń. Relacja ta ma charakter wzajemny – obowiązek lojalnej współpracy ciąży na obu stronach.
Analiza i specyfikacja jako podstawa wyceny oraz harmonogramu
Analiza przedwdrożeniowa pełni istotną rolę w procesie wyceny i planowania projektu – pozwala wykonawcy wstępnie oszacować zakres prac. Jednak to specyfikacja techniczna, jako dokument bardziej precyzyjny, stanowi właściwą podstawę do ostatecznego ustalenia wynagrodzenia i harmonogramu. Wykonawca, który podpisuje umowę dysponując oboma dokumentami i nie zgłasza do nich zastrzeżeń, przyjmuje na siebie ryzyko realizacji tak zdefiniowanego zobowiązania.
W wyroku Sądu Rejonowego w Bytomiu z 11 lipca 2016 r. (sygn. I C 1471/14) sąd rozpatrywał sprawę dotyczącą niewykonania aplikacji internetowej. Specyfikacja techniczna oraz analiza przedwdrożeniowa zostały przekazane wykonawcy przed podpisaniem umowy, a wykonawca nie zgłaszał do nich zastrzeżeń. Mimo to nie wykonał dzieła w kolejno przedłużanych terminach. Sąd uznał, że skoro wykonawca dysponował dokumentacją wymagań przed zawarciem umowy i mógł swobodnie zapoznać się z jej treścią, a mimo to zawarł umowę, to bierze na siebie ryzyko realizacji zobowiązania. Brak trafnego oszacowania własnych możliwości i zasobów obciąża wykonawcę.
Wniosek praktyczny: Podpisanie umowy bez zastrzeżeń do specyfikacji technicznej i analizy przedwdrożeniowej oznacza akceptację ryzyka ich realizacji. Wykonawca, który dopiero w toku projektu odkrywa, że nie jest w stanie wywiązać się z zobowiązania, nie może skutecznie przerzucić tej odpowiedzialności na zamawiającego.
Specyfikacja techniczna jako wzorzec oceny wykonania dzieła
Przy ocenie, czy wykonane dzieło posiada wady, kluczowym punktem odniesienia jest specyfikacja techniczna – nie analiza przedwdrożeniowa. To specyfikacja określa bowiem konkretne, weryfikowalne wymagania, które oprogramowanie musi spełniać. Analiza wyznacza cele; specyfikacja wyznacza kryteria odbioru.
Ilustruje to wyraźnie wyrok Sądu Apelacyjnego we Wrocławiu (I ACa 796/13). Biegły sądowy oceniał tam, czy dostarczony moduł spełnia wymagania – i czynił to właśnie w odniesieniu do specyfikacji funkcjonalnej sporządzonej przez wykonawcę. Stwierdził, że moduł nie spełniał 9 z 17 punktów tej specyfikacji. Co znamienne: była to specyfikacja przygotowana przez samego wykonawcę. Brak odrębnej specyfikacji dla innego kluczowego modułu uniemożliwił zaś jakąkolwiek miarodajną ocenę – i to właśnie ten brak sąd potraktował jako okoliczność obciążającą wykonawcę.
Odmienną perspektywę – dotyczącą gotowego oprogramowania licencyjnego, nie tworzonego na zamówienie – przedstawia wyrok Sądu Rejonowego w Sopocie z 27 stycznia 2021 r. (sygn. I C 422/19). Sąd ustalił, że przed zawarciem umowy odbyły się dwie szczegółowe prezentacje oprogramowania, podczas których zamawiający mógł weryfikować funkcjonalności. Zamawiający nie skorzystał z oferowanej przez wykonawcę odpłatnej analizy przedwdrożeniowej i nie zgłaszał konkretnych wymagań w zakresie planowania budżetowego czy rozszerzonej sprawozdawczości. Sąd uznał, że nie może on skutecznie uchylić się od zapłaty, powołując się na błąd co do funkcjonalności.
Uwaga: Wyrok z Sopotu dotyczy nabycia gotowego oprogramowania licencyjnego, a nie tworzenia dedykowanego systemu na zamówienie. W tym kontekście nie istnieje specyfikacja techniczna tworzona pod projekt – zamawiający ocenia produkt podczas prezentacji. Wnioski z tego wyroku należy stosować ostrożnie w kontekście umów o wykonanie dzieła według indywidualnej specyfikacji.
Wyrok ten potwierdza jednak szerszą zasadę wspólną dla obu reżimów: brak precyzyjnego określenia wymagań przed zawarciem umowy – niezależnie od formy tego określenia – osłabia pozycję zamawiającego w ewentualnym sporze o zakres funkcjonalności.
Analiza i specyfikacja a roszczenia o wynagrodzenie za prace dodatkowe
Precyzja dokumentacji wymagań ma bezpośrednie przełożenie na możliwość dochodzenia wynagrodzenia za prace dodatkowe. Generalną zasadę można sformułować następująco: za prace dodatkowe mogą być uznane tylko te czynności, których nie można było przewidzieć na etapie sporządzenia dokumentacji wymagań. Wszystko, co mieściło się w zakresie analizy lub specyfikacji, stanowi zobowiązanie umowne wykonawcy – niezależnie od tego, czy oszacował je prawidłowo.
Znaczenie specyfikacji jest tu nawet ważniejsze niż analizy: jeżeli określone funkcjonalności wynikają ze specyfikacji, wykonawca nie może skutecznie twierdzić, że stanowią one prace dodatkowe – nawet jeśli ich realizacja okazała się bardziej czasochłonna niż zakładał. Jeżeli natomiast zamawiający żąda funkcjonalności, które nie wynikają ani z analizy, ani ze specyfikacji i których potrzeba ujawniła się dopiero w toku realizacji projektu – mogą one być kwalifikowane jako prace dodatkowe.
W orzecznictwie Sądu Najwyższego ugruntowany jest pogląd, zgodnie z którym w określonych sytuacjach możliwe jest dochodzenie wynagrodzenia za prace dodatkowe na podstawie przepisów o bezpodstawnym wzbogaceniu (por. wyroki SN: z 2 lutego 2011 r., II CSK 414/10; z 1 grudnia 2010 r., I CSK 64/10; z 7 listopada 2007 r., II CSK 344/07). Konstrukcja ta ma jednak charakter wyjątkowy i jest istotnie ograniczona tam, gdzie zakres prac został uprzednio precyzyjnie określony w dokumentacji wymagań.
Funkcja ochronna dokumentacji wymagań
Zarówno analiza przedwdrożeniowa, jak i specyfikacja techniczna pełnią funkcję ochronną wobec obu stron, przy czym każdy z tych dokumentów chroni przed innym rodzajem ryzyka.
Analiza przedwdrożeniowa chroni przede wszystkim przed sporem o cel i sens projektu – ustala wspólne rozumienie tego, po co system jest tworzony i jakie potrzeby biznesowe ma zaspokajać.
Specyfikacja techniczna chroni przed sporem o zakres i jakość wykonania – precyzuje, co dokładnie musi robić system, aby można było uznać umowę za wykonaną. Stanowi też podstawę dla biegłego sądowego, który w razie sporu ocenia, czy dzieło zostało wykonane zgodnie z zobowiązaniem.
W praktyce szczególnie korzystnym rozwiązaniem jest przyjęcie modelu, w którym analiza przedwdrożeniowa stanowi odrębny, odpłatny etap współpracy – a jej wynik stanowi podstawę do opracowania specyfikacji technicznej, która z kolei stanowi załącznik do właściwej umowy wykonawczej. Taki model – potwierdzony zresztą praktyką opisaną w wyroku Sądu Rejonowego w Sopocie, gdzie wykonawca oferował odpłatną analizę przedwdrożeniową jako osobną usługę – motywuje obie strony do rzetelnego przeprowadzenia prac przygotowawczych i znacząco zmniejsza ryzyko sporów na dalszych etapach projektu.
Model rekomendowany: etap 1 – odpłatna analiza przedwdrożeniowa (wynik: raport z analizy); etap 2 – opracowanie specyfikacji technicznej na podstawie analizy (wynik: specyfikacja jako załącznik do umowy); etap 3 – zawarcie umowy wykonawczej ze specyfikacją jako integralnym elementem; etap 4 – realizacja i odbiór według kryteriów ze specyfikacji. Każdy z tych etapów powinien kończyć się dokumentem podpisanym przez obie strony.
Podsumowanie
Analiza przedwdrożeniowa i specyfikacja techniczna to dwa odrębne dokumenty, które pełnią różne funkcje – zarówno w toku realizacji projektu, jak i w ewentualnym sporze sądowym. Ich mylenie lub utożsamianie jest błędem, który w praktyce najczęściej obciąża wykonawcę. Omówione wyroki sądów powszechnych wskazują przy tym na trzy kluczowe zasady.
- Brak specyfikacji technicznej dla istotnych modułów systemu jest okolicznością obciążającą wykonawcę jako profesjonalistę – nie może on skutecznie twierdzić, że odpowiedzialność za niepowodzenie projektu leży wyłącznie po stronie zamawiającego, jeżeli sam nie zadbał o precyzyjne określenie zakresu swojego zobowiązania.
- Specyfikacja, nie analiza, jest właściwym wzorcem oceny wykonania dzieła – to na jej podstawie biegły sądowy ocenia, czy oprogramowanie spełnia wymagania umowne, a sąd ustala, czy doszło do wykonania zobowiązania.
- Zamawiający, który nie określił precyzyjnie swoich wymagań, ponosi ryzyko nabycia produktu niespełniającego jego oczekiwań – dotyczy to zarówno sytuacji, gdy nie skorzystał z analizy przedwdrożeniowej (jak w wyroku z Sopotu), jak i sytuacji, gdy analiza nie została przełożona na szczegółową specyfikację.
W efekcie pełna dokumentacja wymagań – obejmująca zarówno analizę przedwdrożeniową, jak i wynikającą z niej specyfikację techniczną – stanowi narzędzie, które przy prawidłowym wykorzystaniu pozwala znacząco ograniczyć ryzyko sporów i zapewnić sprawną realizację przedsięwzięć informatycznych.
