Software house nie dowiózł projektu — jakie roszczenia ma klient?

Zamówienie dedykowanego oprogramowania wiąże się zazwyczaj z istotnym wydatkiem, zaangażowaniem pracowników klienta oraz podporządkowaniem projektu określonemu celowi biznesowemu. Aplikacja ma rozpocząć sprzedaż w ustalonym terminie, zautomatyzować proces, zastąpić dotychczasowy system, umożliwić realizację kontraktu albo zapewnić zgodność z nowymi przepisami. Jeżeli software house nie kończy prac, przekazuje produkt obciążony poważnymi wadami lub po miesiącach współpracy oddaje jedynie fragment kodu, klient może ponieść szkody znacznie przekraczające zapłacone wynagrodzenie.

W praktyce spory dotyczące projektów IT rzadko sprowadzają się do prostego pytania, czy aplikacja została wykonana. Zazwyczaj strony różnie rozumieją zakres projektu, gotowość rozwiązania do odbioru, znaczenie zgłaszanych błędów oraz odpowiedzialność za opóźnienie. Software house może twierdzić, że klient wielokrotnie zmieniał wymagania, nie dostarczył materiałów, opóźniał akceptację makiet albo nie brał udziału w testach. Klient z kolei może wskazywać, że wykonawca źle oszacował projekt, zmieniał skład zespołu, nie posiadał wystarczających kompetencji lub przedstawiał jako ukończone funkcje, które w praktyce nie działały.

Odpowiedź na pytanie, jakie roszczenia przysługują klientowi, zależy przede wszystkim od treści zawartej umowy, charakteru zobowiązania, stopnia wykonania projektu, rodzaju wad, przyczyn opóźnienia oraz tego, czy klient chce jeszcze doprowadzić do ukończenia systemu, czy raczej zakończyć współpracę i odzyskać pieniądze.

Klient może w odpowiednich okolicznościach żądać dokończenia projektu, usunięcia wad, zapłaty kar umownych, naprawienia szkody, obniżenia wynagrodzenia, zwrotu części albo całości wpłaconych środków, wydania kodu i dokumentacji, a także odstąpić od umowy. Nie każde z tych roszczeń powstaje jednak automatycznie. W sporze IT szczególnego znaczenia nabiera sposób, w jaki zamawiający dokumentował przebieg współpracy i reagował na kolejne nieprawidłowości.

Co oznacza, że software house „nie dowiózł” projektu?

Pojęcie niedowiezienia projektu nie jest terminem prawnym. W praktyce może obejmować bardzo różne sytuacje.

Najbardziej oczywistym przypadkiem jest niedotrzymanie końcowego terminu. Umowa przewidywała uruchomienie aplikacji w określonym dniu, ale termin minął, a system nadal nie jest gotowy. Czasami opóźnienie dotyczy jednego etapu, który blokuje dalsze prace lub uniemożliwia rozpoczęcie testów.

Innym przypadkiem jest pozorne zakończenie projektu. Software house przekazuje rozwiązanie i wystawia fakturę, lecz system nie realizuje uzgodnionych funkcji. Niektóre moduły nie istnieją, integracje nie działają, aplikacja traci dane, nie obsługuje wymaganej liczby użytkowników albo posiada błędy uniemożliwiające jej wykorzystanie.

Możliwe jest również wykonanie projektu niezgodnie ze specyfikacją. Aplikacja działa, ale w inny sposób niż określony w umowie, backlogu, dokumentacji analitycznej albo zaakceptowanych makietach. Wykonawca może uważać takie różnice za drobne odstępstwa, podczas gdy dla klienta eliminują one biznesowy sens rozwiązania.

Niedowiezieniem może być także porzucenie projektu. Zespół przestaje odpowiadać, nie publikuje kolejnych wersji, odmawia wydania repozytorium lub uzależnia kontynuację prac od zapłaty kwot, których wcześniej nie uzgodniono.

Jeszcze inny problem występuje, gdy aplikacja została wdrożona, lecz wykonawca nie dostarczył kodu źródłowego, dokumentacji, haseł, kluczy, plików konfiguracyjnych, dostępu do infrastruktury lub innych elementów potrzebnych do samodzielnego utrzymania produktu. Klient może mieć działający system, ale pozostawać całkowicie uzależniony od dotychczasowego wykonawcy.

Każdy z tych przypadków wymaga odmiennej oceny. Opóźnienie nie jest tym samym co wada, brak dokumentacji nie jest tym samym co brak funkcjonalności, a żądanie wykonania umowy prowadzi do innych konsekwencji niż odstąpienie od niej.

Od czego zależy zakres roszczeń klienta?

Pierwszym dokumentem wymagającym analizy jest umowa. Należy ustalić, co dokładnie było przedmiotem zobowiązania software house’u, jakie terminy ustalono, w jaki sposób miały być odbierane poszczególne etapy, kto odpowiadał za przygotowanie wymagań, jak regulowano zmiany zakresu oraz jakie konsekwencje przewidziano na wypadek opóźnienia albo wad.

Nie każda umowa IT ma taką samą konstrukcję. Projekt może być rozliczany ryczałtowo, według czasu pracy, etapami, w modelu time and material albo jako stała usługa zespołu programistycznego. Umowa może przewidywać osiągnięcie konkretnego rezultatu albo jedynie wykonywanie prac z należytą starannością.

To rozróżnienie ma podstawowe znaczenie. Przy umowie nastawionej na rezultat klient oczekuje ukończonego, zgodnego ze specyfikacją rozwiązania. Sam fakt, że programiści przepracowali określoną liczbę godzin, nie musi oznaczać prawidłowego wykonania zobowiązania. Przy czystym modelu usługowym software house może natomiast bronić się, że zobowiązał się do zapewnienia zespołu i wykonywania uzgodnionych zadań, a nie do ukończenia całego produktu za z góry określoną cenę.

Znaczenie ma również praktyka stron. Nawet niedoskonała umowa może zostać uzupełniona przez późniejsze uzgodnienia, korespondencję, zaakceptowane makiety, dokumentację w systemie zarządzania zadaniami, protokoły spotkań i sposób rozliczania kolejnych etapów.

Kodeks cywilny wymaga, aby przy interpretacji umowy badać zgodny zamiar stron i cel kontraktu, a nie ograniczać się wyłącznie do dosłownego brzmienia poszczególnych postanowień. Jednocześnie dłużnik powinien wykonać zobowiązanie zgodnie z jego treścią, celem społeczno-gospodarczym, zasadami współżycia społecznego oraz ustalonymi zwyczajami. (ELI)

Umowa o dzieło, umowa o świadczenie usług czy umowa mieszana?

Umowy wdrożeniowe i umowy na stworzenie oprogramowania nie zostały uregulowane w Kodeksie cywilnym jako odrębny typ kontraktu. W zależności od treści mogą zostać zakwalifikowane jako umowa o dzieło, umowa o świadczenie usług albo umowa mieszana zawierająca elementy kilku typów umów.

Jeżeli wykonawca zobowiązuje się stworzyć konkretną aplikację posiadającą ustalone cechy, funkcje i parametry, silne są argumenty za zakwalifikowaniem zobowiązania jako umowy rezultatu. Przedmiotem umowy ma być oznaczone dzieło, które można poddać odbiorowi i ocenić pod kątem zgodności z uzgodnionymi wymaganiami.

Jeżeli natomiast klient płaci za pracę specjalistów, samodzielnie zarządza backlogiem, na bieżąco ustala priorytety i nie określa zamkniętego rezultatu, relacja może być zbliżona do umowy o świadczenie usług. W takim przypadku podstawowe pytanie będzie dotyczyło tego, czy software house wykonywał prace z należytą starannością.

Wiele projektów łączy oba modele. Poszczególne etapy mogą być rozliczane jako oznaczone rezultaty, podczas gdy utrzymanie, rozwój albo wsparcie odbywają się w modelu usługowym. Zdarza się także, że kontrakt nazwany umową o świadczenie usług w rzeczywistości przewiduje obowiązek dostarczenia dokładnie opisanego produktu.

Kwalifikacja ma wpływ między innymi na możliwość korzystania z przepisów o umowie o dzieło, w tym dotyczących wadliwego wykonywania, odstąpienia przed ukończeniem dzieła i odpowiedzialności za wady. Nie można jej jednak dokonywać wyłącznie na podstawie tytułu dokumentu.

Czy klient może żądać dokończenia projektu?

Podstawowym roszczeniem wierzyciela jest żądanie wykonania zobowiązania zgodnie z umową. Jeżeli współpraca nadal ma sens, klient może wezwać software house do dokończenia określonych funkcji, usunięcia blokujących błędów, przekazania brakujących materiałów i przeprowadzenia wdrożenia.

Wezwanie powinno być precyzyjne. Nie wystarczy ogólne stwierdzenie, że projekt nie działa. Należy wskazać, które funkcje nie zostały wykonane, jakie błędy występują, jakie elementy nie odpowiadają dokumentacji oraz w jakim terminie klient oczekuje ich realizacji.

Warto rozróżnić wady krytyczne, poważne i drobne. Błąd uniemożliwiający zalogowanie użytkowników albo powodujący utratę danych ma inne znaczenie niż nieprawidłowy odstęp pomiędzy elementami interfejsu.

Jeżeli projekt kwalifikuje się jako dzieło, a w trakcie wykonywania okaże się, że wykonawca realizuje je wadliwie lub sprzecznie z umową, zamawiający może wezwać go do zmiany sposobu wykonania i wyznaczyć odpowiedni termin. Po jego bezskutecznym upływie zamawiający może odstąpić od umowy albo powierzyć poprawienie lub dalsze wykonanie innej osobie na koszt i niebezpieczeństwo pierwotnego wykonawcy. Uprawnienie to wynika z art. 636 Kodeksu cywilnego. (ELI)

Przepis może mieć istotne znaczenie, gdy projekt nadal trwa, ale sposób jego realizacji wyraźnie prowadzi do wadliwego rezultatu. Klient nie musi zawsze czekać do formalnego końca prac, jeżeli posiada podstawy do wykazania, że wykonawca realizuje je niezgodnie z umową.

Wykonanie zastępcze przez inny software house

Klient, który utracił zaufanie do wykonawcy, często chce przekazać projekt nowej firmie. Należy jednak zachować ostrożność, ponieważ zbyt szybkie odsunięcie pierwotnego software house’u może utrudnić późniejsze dochodzenie kosztów.

W przypadku wadliwego albo sprzecznego z umową wykonywania dzieła art. 636 Kodeksu cywilnego przewiduje możliwość powierzenia poprawienia lub dalszego wykonania innej osobie na koszt i niebezpieczeństwo przyjmującego zamówienie, ale wcześniej wymaga co do zasady wezwania do zmiany sposobu wykonywania i wyznaczenia odpowiedniego terminu.

W innych sytuacjach wykonanie zastępcze może wymagać uzyskania upoważnienia sądu na podstawie ogólnych przepisów o wykonaniu zobowiązania, chyba że występuje nagły przypadek. W realiach projektu IT zwłoka może jednak prowadzić do narastania szkody, utraty kontraktu albo poważnego zagrożenia bezpieczeństwa. Każdy przypadek wymaga więc odrębnej analizy.

Przed przekazaniem projektu nowemu wykonawcy warto zabezpieczyć dowody stanu, w jakim pozostawił go dotychczasowy software house. Należy wykonać kopię repozytorium, zachować wersje środowisk, wyeksportować zadania i zgłoszenia, utrwalić błędy oraz sporządzić niezależny audyt techniczny.

Jeżeli nowy wykonawca natychmiast przebuduje aplikację, późniejsze wykazanie pierwotnych wad może stać się znacznie trudniejsze. Software house może twierdzić, że nie da się już ustalić, które błędy pochodziły z jego prac, a które powstały podczas ingerencji nowego zespołu.

Odstąpienie od umowy z powodu opóźnienia

Jednym z najdalej idących uprawnień klienta jest odstąpienie od umowy. Prawidłowo złożone odstąpienie może prowadzić do obowiązku zwrotu świadczeń i otworzyć drogę do żądania naprawienia szkody.

Nie każda zwłoka pozwala jednak na natychmiastowe odstąpienie. Zgodnie z ogólną zasadą, jeżeli jedna ze stron umowy wzajemnej pozostaje w zwłoce, druga może wyznaczyć jej odpowiedni dodatkowy termin do wykonania z zagrożeniem, że po jego bezskutecznym upływie odstąpi od umowy. Dopiero niewykonanie zobowiązania w tym terminie pozwala skorzystać z uprawnienia. (ELI)

Dodatkowy termin nie zawsze jest konieczny. Jeżeli strony zastrzegły prawo odstąpienia na wypadek niewykonania w ściśle określonym terminie albo wykonanie po terminie nie miałoby dla klienta znaczenia ze względu na właściwość zobowiązania lub zamierzony cel umowy znany wykonawcy, odstąpienie może być możliwe bez wyznaczania terminu dodatkowego.

Przykładem może być aplikacja przygotowywana na wydarzenie, kampanię sezonową albo datę wejścia w życie określonego obowiązku prawnego. Jeżeli software house wiedział, że po danej dacie system utraci biznesowe znaczenie, argumentacja dotycząca istotnego charakteru terminu będzie silniejsza.

W umowach IT często znajdują się własne klauzule odstąpienia. Mogą one przewidywać prawo zakończenia kontraktu po przekroczeniu określonego opóźnienia, niewykonaniu kamienia milowego, powtarzającym się naruszaniu SLA albo nieusunięciu wad. Przed złożeniem oświadczenia należy dokładnie sprawdzić przesłanki i procedurę, ponieważ błędne odstąpienie może zostać uznane za bezskuteczne.

Odstąpienie jeszcze przed terminem końcowym

Klient nie zawsze musi czekać do nadejścia końcowego terminu realizacji. Jeżeli z zachowania wykonawcy wynika, że nie zdoła ukończyć dzieła w czasie umówionym, Kodeks cywilny przewiduje możliwość odstąpienia jeszcze przed upływem terminu.

Zgodnie z art. 635 Kodeksu cywilnego, jeżeli przyjmujący zamówienie opóźnia się z rozpoczęciem lub wykończeniem dzieła tak dalece, że nie jest prawdopodobne, aby zdołał ukończyć je w czasie umówionym, zamawiający może bez wyznaczenia terminu dodatkowego odstąpić od umowy jeszcze przed upływem terminu wykonania. (ELI)

W projekcie IT może to mieć znaczenie, gdy do terminu pozostało kilka tygodni, a wykonawca nie rozpoczął kluczowych modułów, nie posiada kompletnego zespołu albo nie przedstawił wersji nadającej się do testów.

Klient powinien jednak posiadać dowody pozwalające obiektywnie wykazać, że termin stał się nierealny. Sama utrata zaufania lub ogólne przekonanie o zbyt wolnym tempie prac może nie wystarczyć.

Pomocne mogą być harmonogram, raporty sprintów, stan backlogu, dane z repozytorium, brak wykonania kolejnych kamieni milowych, korespondencja wykonawcy i opinia techniczna wskazująca, jaki zakres prac pozostał.

Odstąpienie od umowy przed ukończeniem dzieła z woli klienta

Kodeks cywilny przewiduje również szczególne uprawnienie zamawiającego do odstąpienia od umowy o dzieło w każdym czasie, dopóki dzieło nie zostało ukończone. Nie jest to jednak odstąpienie bez konsekwencji finansowych. Na podstawie art. 644 Kodeksu cywilnego zamawiający może odstąpić przed ukończeniem dzieła, ale powinien zapłacić umówione wynagrodzenie, odliczając to, co wykonawca oszczędził z powodu niewykonania dzieła. (ELI) Uprawnienie to może być przydatne, gdy klient chce zakończyć projekt z przyczyn biznesowych, mimo że software house nie narusza umowy. Nie należy go mylić z odstąpieniem z powodu zwłoki albo wadliwego wykonywania. Jeżeli klient korzysta z art. 644, punktem wyjścia jest obowiązek zapłaty wynagrodzenia, a nie jego zwrot. W sporze dotyczącym niewykonania projektu korzystniejsze mogą być inne podstawy odstąpienia, o ile ich przesłanki rzeczywiście zostały spełnione.

Jakie skutki wywołuje odstąpienie?

Skutki odstąpienia zależą od podstawy prawnej, treści umowy i charakteru świadczeń. W przypadku umowy wzajemnej odstąpienie może prowadzić do obowiązku zwrotu tego, co strony już otrzymały, oraz do odpowiedzialności odszkodowawczej za niewykonanie zobowiązania.

W projektach IT problemem jest to, że świadczenia nie zawsze można łatwo zwrócić. Software house wykonał część analiz, makiet, kodu i konfiguracji. Klient mógł korzystać z fragmentu aplikacji albo wyników prac. Konieczne jest więc ustalenie, czy odstąpienie dotyczy całej umowy, jedynie niewykonanej części, czy tylko określonego etapu.

Znaczenie ma podzielność świadczenia. Jeżeli poszczególne etapy mają samodzielną wartość i zostały prawidłowo odebrane, odstąpienie od całej umowy może być trudniejsze. Jeżeli jednak system ma znaczenie wyłącznie jako kompletna całość, częściowe elementy mogą być dla klienta bezużyteczne.

W sprawie dotyczącej wdrożenia systemu informatycznego Sąd Najwyższy zwrócił uwagę, że podział projektu na zadania nie musi oznaczać, iż każde z nich stanowi odrębną, samodzielną część zobowiązania. Istotne mogą być między innymi gospodarczy cel całości, sposób odbioru i konstrukcja wynagrodzenia. (Sąd Najwyższy)

Klient powinien zatem bardzo ostrożnie formułować zakres odstąpienia. Oświadczenie dotyczące „całej współpracy” może prowadzić do nieprzewidzianych skutków, jeśli umowa obejmuje także usługi utrzymania, licencje lub prawidłowo wykonane etapy.

Żądanie zwrotu zapłaconego wynagrodzenia

Klient, który skutecznie odstąpił od umowy z powodu niewykonania lub nienależytego wykonania, może co do zasady żądać zwrotu odpowiedniej części zapłaconego wynagrodzenia.

Nie zawsze będzie to jednak cała kwota. Jeżeli klient otrzymał część prac posiadających samodzielną wartość, software house może żądać ich rozliczenia. Jeżeli natomiast dostarczony kod jest bezużyteczny bez niewykonanych modułów, argument za zwrotem całości będzie silniejszy. W praktyce należy ocenić, czy klient może wykorzystać przekazane elementy, czy posiada do nich prawa, czy są wystarczająco udokumentowane oraz ile kosztowałoby ich dokończenie przez inną firmę. Warto pamiętać, że wpłacone transze nie muszą odpowiadać wartości rzeczywiście wykonanych prac. Harmonogram płatności bywa oparty na datach albo deklarowanym postępie. Sam fakt wystawienia i zapłaty faktury nie przesądza, że dany etap został prawidłowo wykonany i odebrany.

Jeżeli klient podpisał protokół odbioru bez zastrzeżeń, odzyskanie wynagrodzenia może być trudniejsze, ale nadal nie musi być niemożliwe. Znaczenie ma to, czy wady były możliwe do wykrycia podczas odbioru, czy ujawniły się dopiero w eksploatacji oraz czy wykonawca zapewnił klientowi realną możliwość przeprowadzenia testów.

Roszczenia z tytułu wad oprogramowania

Jeżeli projekt został ukończony, ale posiada wady, klient może skorzystać z uprawnień związanych z odpowiedzialnością za wadliwe wykonanie.

Do odpowiedzialności za wady dzieła stosuje się odpowiednio przepisy o rękojmi przy sprzedaży, z zastrzeżeniami wynikającymi z regulacji umowy o dzieło. Pozwala to w odpowiednich okolicznościach żądać usunięcia wad, obniżenia wynagrodzenia, a w przypadku wad istotnych także odstąpić od umowy. (ELI)

Wada systemu może polegać zarówno na braku uzgodnionej funkcjonalności, jak i na nieprawidłowym działaniu funkcji formalnie istniejącej. System może być również wadliwy z powodu niedostatecznego bezpieczeństwa, niskiej wydajności, braku kompatybilności z ustalonym środowiskiem, błędnego przetwarzania danych albo niezgodności z wymaganiami prawnymi wskazanymi w umowie.

Nie każda drobna usterka uzasadnia odstąpienie od całej umowy. Kluczowe jest ustalenie, czy wada ma charakter istotny. W realiach IT wada będzie istotna zwłaszcza wtedy, gdy system nie może być normalnie wykorzystywany do uzgodnionego celu, a jej usunięcie wymaga zasadniczej przebudowy albo jest niepewne.

Jeżeli wada może zostać szybko i skutecznie usunięta, pierwszym krokiem powinno być zazwyczaj wezwanie wykonawcy do naprawy. Klient powinien wskazać sposób reprodukcji błędu, oczekiwany rezultat i termin usunięcia.

Gwarancja a odpowiedzialność ustawowa

Umowy IT często przewidują okres gwarancji albo stabilizacji po wdrożeniu. Software house zobowiązuje się wówczas do bezpłatnego usuwania błędów przez określony czas.

Gwarancja jest jednak uprawnieniem wynikającym przede wszystkim z umowy. Jej zakres może być szerszy albo węższy od odpowiedzialności ustawowej. Umowa może określać klasy błędów, czasy reakcji, czasy naprawy oraz wyłączenia. Nie należy automatycznie zakładać, że zakończenie okresu gwarancji pozbawia klienta wszystkich roszczeń. Nadal może istnieć odpowiedzialność za nienależyte wykonanie zobowiązania, rękojmia, odpowiedzialność za zapewnienia wykonawcy lub roszczenia wynikające z naruszenia praw autorskich. Z drugiej strony w relacjach B2B strony mogą w znacznym zakresie modyfikować albo wyłączać odpowiedzialność z tytułu rękojmi. Dlatego przed sformułowaniem żądania trzeba sprawdzić, czy umowa nie ogranicza określonych uprawnień.

Kary umowne za opóźnienie i niewykonanie

Jeżeli umowa przewiduje karę umowną za opóźnienie, zwłokę, niewykonanie kamienia milowego, brak usunięcia błędów albo odstąpienie z przyczyn leżących po stronie wykonawcy, klient może dochodzić określonej kwoty bez konieczności wykazywania wysokości szkody.

Kara umowna może zabezpieczać wyłącznie zobowiązania niepieniężne. Jej zapłata jest należna w wysokości ustalonej w umowie, niezależnie od wysokości poniesionej szkody, chociaż dłużnik może domagać się zmniejszenia kary, jeżeli zobowiązanie zostało w znacznej części wykonane albo kara jest rażąco wygórowana. (ELI)

Należy dokładnie sprawdzić, czy kara została zastrzeżona za opóźnienie, czy za zwłokę. Opóźnienie jest pojęciem szerszym i może obejmować przekroczenie terminu niezależnie od winy, natomiast zwłoka co do zasady oznacza opóźnienie, za które wykonawca ponosi odpowiedzialność.

Treść klauzuli ma decydujące znaczenie. Nie zawsze kara za opóźnienie w wykonaniu całego projektu może być naliczana po odstąpieniu od umowy albo obok kary za samo odstąpienie. Konieczne jest ustalenie, jakie naruszenia zabezpieczały poszczególne kary i czy ich kumulacja jest dopuszczalna.

W sprawie dotyczącej wdrożenia systemu informatycznego Sąd Najwyższy analizował między innymi odpowiedzialność za karę umowną oraz wpływ zachowania zamawiającego, który nie dostarczył części dokumentacji potrzebnej do wykonania prac. Orzeczenie pokazuje, że nawet przy przekroczeniu terminu trzeba badać, od kiedy wykonawca rzeczywiście pozostawał w zwłoce i w jakim stopniu sam klient przyczynił się do opóźnienia. (Sąd Najwyższy)

Czy można żądać odszkodowania ponad karę umowną?

Samo zastrzeżenie kary umownej nie zawsze pozwala dochodzić dodatkowego odszkodowania. Zgodnie z Kodeksem cywilnym żądanie odszkodowania przewyższającego wysokość kary nie jest dopuszczalne, chyba że strony postanowiły inaczej. (ELI) Jeżeli umowa przewiduje, że klient może dochodzić odszkodowania uzupełniającego, możliwe będzie żądanie naprawienia szkody w części niepokrytej karą. Jeżeli takiego postanowienia nie ma, kara może wyznaczać maksymalny poziom rekompensaty w odniesieniu do naruszenia, które zabezpiecza. Dlatego konstrukcja klauzuli ma bardzo duże znaczenie. Kara za przekroczenie terminu nie musi jednak automatycznie wyłączać roszczeń dotyczących innych naruszeń, przykładowo utraty danych, naruszenia poufności albo przekazania kodu obciążonego roszczeniami osób trzecich. Konieczne jest ustalenie, czy szkoda wynika z tego samego zdarzenia, które objęto karą.

Odszkodowanie za niewykonanie projektu

Niezależnie od kar umownych klient może posiadać roszczenie odszkodowawcze na podstawie ogólnych zasad odpowiedzialności kontraktowej.

Zgodnie z art. 471 Kodeksu cywilnego dłużnik powinien naprawić szkodę wynikłą z niewykonania lub nienależytego wykonania zobowiązania, chyba że jest ono następstwem okoliczności, za które nie ponosi odpowiedzialności. (ELI) Klient powinien wykazać istnienie zobowiązania, jego niewykonanie albo nienależyte wykonanie, powstanie szkody oraz adekwatny związek przyczynowy pomiędzy naruszeniem a szkodą. Szkodą może być między innymi koszt zatrudnienia nowego wykonawcy, koszt audytu i naprawy kodu, konieczność przedłużenia umów na dotychczasowy system, wydatki na dodatkową infrastrukturę, wynagrodzenie pracowników zaangażowanych w działania naprawcze, koszt odtworzenia danych albo kwoty zapłacone kontrahentom z powodu niewdrożenia systemu. W określonych przypadkach klient może również żądać utraconych korzyści. Może twierdzić, że gdyby aplikacja została uruchomiona terminowo, osiągnąłby określone przychody albo zawarł umowy z klientami.

Roszczenia o utracone korzyści są jednak trudniejsze dowodowo. Nie wystarczy przedstawienie optymistycznej prognozy. Konieczne jest wykazanie z odpowiednim prawdopodobieństwem, że korzyść zostałaby osiągnięta, gdyby software house prawidłowo wykonał umowę.

Koszt dokończenia projektu przez inną firmę

Jednym z najczęściej dochodzonych składników szkody jest różnica pomiędzy pierwotnie uzgodnionym wynagrodzeniem a kosztem dokończenia lub naprawy projektu przez nowy software house.

Jeżeli klient zapłacił pierwszemu wykonawcy 200 000 zł, a nowa firma żąda kolejnych 180 000 zł za poprawienie kodu i wykonanie brakujących elementów, nie oznacza to automatycznie, że cała druga kwota jest szkodą. Trzeba ustalić, jaka część wydatku rzeczywiście służy naprawieniu następstw naruszenia, a jaka finansuje dodatkowe funkcje, zmianę technologii albo ulepszenie projektu. Nowy wykonawca powinien w miarę możliwości rozdzielić koszt audytu, naprawy wad, odtworzenia dokumentacji, dokończenia pierwotnego zakresu oraz rozwoju ponad zakres umowy. Jeżeli klient wykorzystuje konflikt do zbudowania rozwiązania znacznie lepszego lub szerszego, software house może podnosić, że żądane koszty nie pozostają w adekwatnym związku z jego naruszeniem.

Utracone przychody z niewdrożonej aplikacji

Klienci często wskazują, że przez opóźnienie nie mogli rozpocząć sprzedaży, pobierać abonamentów albo obsługiwać nowych użytkowników.

Co do zasady utracone korzyści mogą stanowić szkodę, jeżeli są normalnym następstwem naruszenia. Ich wykazanie wymaga jednak czegoś więcej niż biznesplanu. Pomocne mogą być podpisane umowy lub listy intencyjne, istniejąca baza klientów, wyniki wcześniejszej sprzedaży, zamówienia uzależnione od uruchomienia systemu, historyczne dane dotyczące podobnej usługi oraz opinia biegłego.

Znaczenie ma również to, czy software house znał cel i gospodarcze znaczenie terminu. Jeżeli wykonawca wiedział, że aplikacja ma obsługiwać określony kontrakt albo wejść na rynek w konkretnym sezonie, związek pomiędzy opóźnieniem a utraconym przychodem może być łatwiejszy do wykazania. Software house może bronić się, że produkt nie odniósłby sukcesu niezależnie od opóźnienia, klient nie przygotował marketingu, nie posiadał finansowania albo nie spełnił innych warunków potrzebnych do rozpoczęcia działalności.

Przyczynienie się klienta do opóźnienia

Jednym z najważniejszych elementów sporu jest ustalenie, czy klient prawidłowo współdziałał przy realizacji projektu.

Zamawiający może być zobowiązany do dostarczenia treści, dostępów, dokumentacji API, informacji biznesowych, środowiska testowego, decyzji projektowych, danych do migracji albo akceptacji makiet. Jeżeli klient przekazywał materiały z opóźnieniem, wielokrotnie zmieniał wymagania albo nie podejmował decyzji, software house może twierdzić, że nie ponosi odpowiedzialności za część przekroczenia terminu. Kodeks cywilny nakłada na wierzyciela obowiązek współdziałania przy wykonaniu zobowiązania, jeżeli jest ono potrzebne do prawidłowej realizacji umowy. (ELI) W sporze dotyczącym projektu systemu informatycznego Sąd Najwyższy uwzględnił znaczenie niedostarczenia przez zamawiającego dokumentacji potrzebnej do ukończenia prac. Samo przekroczenie pierwotnego terminu nie oznaczało automatycznie, że wykonawcy pozostawali w zwłoce przez cały sporny okres. (Sąd Najwyższy)

Klient powinien więc przed wystąpieniem z roszczeniami ocenić również własny udział w projekcie. Przemilczenie problemów po swojej stronie może osłabić wiarygodność całego żądania.

Zmiana zakresu projektu i scope creep

Software house często broni się zarzutem, że pierwotny zakres został znacznie rozszerzony. Klient może uważać nowe funkcje za oczywiste elementy projektu, podczas gdy wykonawca traktuje je jako dodatkowe prace.

Podstawowym dowodem jest procedura change request. Umowa powinna określać, kiedy dochodzi do zmiany zakresu, kto może ją zatwierdzić, jak wpływa ona na termin i wynagrodzenie oraz czy software house może rozpocząć dodatkowe prace bez formalnego zamówienia. Jeżeli strony nie przestrzegały własnej procedury, znaczenie będzie miała korespondencja i praktyka. Akceptacja zadania w systemie projektowym, zgoda na estymację albo polecenie rozpoczęcia prac mogą zostać uznane za zmianę zakresu, nawet jeśli nie podpisano formalnego aneksu. Z drugiej strony wykonawca nie może automatycznie uznawać za zmianę zakresu naprawy funkcji, które miały realizować pierwotne wymagania. Poprawienie błędnie działającego modułu nie jest tym samym co rozwój nowej funkcjonalności.

Warto sporządzić tabelę porównującą zakres podstawowy, późniejsze zmiany, ich akceptację, wpływ na harmonogram oraz to, które prace miały charakter naprawczy.

Odbiór projektu i protokół bez zastrzeżeń

Wiele umów uzależnia płatność lub przejście do kolejnego etapu od podpisania protokołu odbioru.

Podpisanie protokołu bez zastrzeżeń może być ważnym dowodem prawidłowego wykonania etapu, ale nie zawsze całkowicie zamyka drogę do roszczeń. Znaczenie ma treść protokołu, zakres przeprowadzonych testów, charakter wad i postanowienia umowy. Wada ukryta albo ujawniająca się dopiero przy większym obciążeniu może nie być możliwa do stwierdzenia podczas krótkiego odbioru.

Niektóre umowy przewidują odbiór automatyczny, jeżeli klient nie zgłosi uwag w ciągu kilku dni. Taka klauzula może istotnie pogorszyć jego sytuację, zwłaszcza jeżeli termin na testy jest zbyt krótki w stosunku do złożoności systemu. Klient nie powinien podpisywać protokołu wyłącznie po to, aby zachować dobre relacje lub umożliwić software house’owi wystawienie faktury. Jeżeli istnieją błędy, powinny zostać wpisane do dokumentu wraz z terminem ich usunięcia i informacją, czy blokują odbiór.

Jeżeli odbiór został podpisany pod presją, ale strony równocześnie wymieniały korespondencję o licznych wadach, ocena nie musi ograniczać się do samej treści protokołu. Takie działanie niepotrzebnie komplikuje jednak spór.

Milczący odbiór i korzystanie z aplikacji

Software house może twierdzić, że klient odebrał system przez samo rozpoczęcie korzystania, wdrożenie go produkcyjnie albo brak zgłoszenia uwag. Korzystanie z aplikacji może świadczyć o jej przyjęciu, ale nie zawsze oznacza rezygnację z roszczeń. Klient może używać systemu, ponieważ nie posiada alternatywy, musi obsługiwać istniejących klientów albo chce ograniczyć szkodę. Ważne jest, czy klient równocześnie zgłaszał wady, zastrzegał brak odbioru i wzywał do naprawy. Jeżeli klient przez wiele miesięcy korzystał z rozwiązania, opłacał faktury i nie zgłaszał problemów, późniejsze twierdzenie, że system od początku był całkowicie bezużyteczny, może zostać uznane za mało wiarygodne.

Wydanie kodu źródłowego i repozytorium

W razie konfliktu jednym z najważniejszych pytań jest to, czy klient może żądać wydania kodu źródłowego.

Odpowiedź zależy od umowy. Samo zamówienie aplikacji nie zawsze oznacza, że klient automatycznie uzyskuje prawo do kompletnego repozytorium, historii zmian, narzędzi deweloperskich, pipeline’ów i dokumentacji technicznej. Umowa powinna określać, jakie elementy są przekazywane, kiedy następuje wydanie, w jakiej formie oraz czy klient otrzymuje dostęp na bieżąco, czy dopiero po zapłacie. Jeżeli repozytorium było prowadzone na koncie software house’u, klient powinien zabezpieczyć jego kopię przed zakończeniem współpracy. Dostęp może zostać zablokowany natychmiast po powstaniu sporu.

Brak wydania kodu może stanowić odrębne niewykonanie umowy, jeżeli obowiązek wynikał z kontraktu. Klient może wówczas żądać wydania, naprawienia szkody, a w odpowiednich sytuacjach także skorzystać z prawa odstąpienia.

Prawa autorskie do niedokończonego kodu

Uzyskanie fizycznego dostępu do repozytorium nie jest tym samym co nabycie praw pozwalających na dalsze rozwijanie oprogramowania. Programy komputerowe mogą stanowić utwory chronione prawem autorskim. Umowa o przeniesienie autorskich praw majątkowych wymaga zachowania formy pisemnej pod rygorem nieważności i powinna wskazywać pola eksploatacji. (ELI) Jeżeli umowa nie przenosi skutecznie praw, klient może dysponować jedynie licencją. Zakres tej licencji może nie pozwalać na przekazanie kodu innemu software house’owi, wprowadzanie zmian, rozpowszechnianie rozwiązania albo korzystanie z niego po zakończeniu umowy. Szczególnym problemem są prawa do utworów stworzonych przez podwykonawców i osoby współpracujące z software house’em. Wykonawca powinien posiadać odpowiedni łańcuch praw pozwalający przenieść je na klienta albo udzielić wymaganej licencji. W sporze warto ustalić, czy przejście praw było powiązane z zapłatą całości wynagrodzenia, odbiorem konkretnego etapu, przekazaniem utworu czy podpisaniem protokołu. Jeżeli klient odstępuje od umowy i żąda zwrotu ceny, powinien równocześnie ocenić, czy chce zachować możliwość korzystania z części kodu. Nie można zawsze jednocześnie traktować świadczenia jako całkowicie bezużytecznego, żądać zwrotu całego wynagrodzenia i korzystać z rezultatu bez odpowiedniego rozliczenia.

Komponenty open source i rozwiązania osób trzecich

Niedokończona aplikacja może zawierać biblioteki open source, gotowe komponenty, płatne wtyczki, modele AI, fonty, grafiki, API i inne elementy osób trzecich. Klient powinien otrzymać informacje o licencjach, ograniczeniach, opłatach i warunkach dalszego korzystania. Nowy software house może odmówić przejęcia projektu, jeżeli nie wiadomo, które komponenty można legalnie modyfikować i dystrybuować. Niektóre licencje open source mogą nakładać obowiązek udostępnienia kodu albo zachowania określonych informacji.

Jeżeli wykonawca zapewnił, że klient otrzyma pełne prawa do systemu, a następnie okazuje się, że istotne elementy pochodzą od osób trzecich i podlegają ograniczeniom, może to stanowić nienależyte wykonanie umowy oraz wadę prawną.

Dane, infrastruktura i dostęp administracyjny

Przed zakończeniem współpracy klient powinien zabezpieczyć nie tylko kod, ale również dane i infrastrukturę.

Należy przejąć dostęp do domen, serwerów, chmury, repozytoriów, baz danych, narzędzi analitycznych, paneli płatniczych, kont deweloperskich, sklepów z aplikacjami, usług pocztowych, certyfikatów, kluczy API i systemów monitoringu. Jeżeli konta zostały założone na dane software house’u, ich przeniesienie może być problematyczne. Dostawca może technicznie kontrolować środowisko, nawet jeżeli klient pokrywa wszystkie koszty. Brak wydania danych może prowadzić nie tylko do odpowiedzialności kontraktowej, ale także do problemów wynikających z RODO, jeżeli software house działa jako podmiot przetwarzający. Umowa powierzenia powinna regulować zwrot lub usunięcie danych po zakończeniu świadczenia usług.

W sytuacji konfliktowej należy także ograniczyć ryzyko usunięcia lub zmiany danych. Klient powinien możliwie szybko wykonać niezależne kopie zapasowe, ale nie powinien samowolnie uzyskiwać dostępu w sposób naruszający zabezpieczenia albo uprawnienia innych osób.

Audyt techniczny jako podstawowy dowód

W sporach IT sama korespondencja często nie wystarcza. Konieczne jest techniczne ustalenie, co zostało wykonane, czego brakuje, jakie wady występują oraz jaki jest koszt ich usunięcia.

Audyt powinien być przeprowadzony przez niezależną osobę posiadającą doświadczenie w odpowiedniej technologii. Nie powinien ograniczać się do ogólnego stwierdzenia, że kod jest słabej jakości. Raport powinien odnosić się do umowy i dokumentacji wymagań. Powinien wskazywać konkretne brakujące funkcje, błędy, problemy bezpieczeństwa, stan testów, dokumentacji, infrastruktury oraz możliwość dalszego rozwoju.

Warto opisać metodologię, wersję kodu, środowisko, datę badania, sposób reprodukcji błędów oraz materiały udostępnione audytorowi. Audyt powinien rozróżnić brak funkcji od wady, dług techniczny od błędu uniemożliwiającego użycie oraz pierwotny zakres od późniejszych zmian.

W postępowaniu sądowym ostateczna ocena techniczna może wymagać opinii biegłego sądowego, ale prywatny audyt pomaga prawidłowo sformułować roszczenia, zabezpieczyć dowody i ocenić opłacalność sporu.

Jak zabezpieczyć dowody przed sporem?

Klient powinien zachować wszystkie wersje umowy, załączniki, oferty, specyfikacje, makiety, harmonogramy, kosztorysy, protokoły odbioru, faktury i potwierdzenia płatności.

Należy wyeksportować korespondencję e-mail, komunikatory, systemy zarządzania zadaniami, komentarze do projektów i notatki ze spotkań. Szczególne znaczenie mają dowody wskazujące, że software house znał termin i cel biznesowy, akceptował wymagania, deklarował określony poziom zaawansowania albo przyznawał istnienie błędów. Należy zachować kopię repozytorium z historią commitów, oznaczeniami czasu i informacjami o autorach. Warto wykonać obrazy środowisk lub kopie baz danych, o ile jest to prawnie i technicznie dopuszczalne. Błędy należy dokumentować za pomocą zrzutów ekranu, nagrań, logów i instrukcji reprodukcji. Sam zrzut ekranu może być niewystarczający, jeżeli nie wiadomo, z jakiej wersji aplikacji pochodzi.

W przypadku ryzyka utraty dowodu można rozważyć sądowe zabezpieczenie dowodu jeszcze przed wniesieniem pozwu.

Wezwanie do wykonania albo usunięcia naruszeń

Przed odstąpieniem lub pozwem zazwyczaj warto wysłać formalne wezwanie.

Dokument powinien opisywać podstawę umowną, dotychczasowy przebieg współpracy, niewykonane obowiązki, zgłoszone wady oraz oczekiwany sposób naprawy. Termin powinien być realny, ale nie nadmiernie długi. Przy prostym wydaniu repozytorium może to być kilka dni, natomiast przy usunięciu złożonych błędów potrzebny będzie dłuższy okres. Wezwanie powinno wskazywać konsekwencje braku wykonania, przykładowo odstąpienie, naliczenie kar, wykonanie zastępcze albo skierowanie sprawy do sądu.

Nie należy formułować sprzecznych żądań. Jednoczesne oświadczenie o natychmiastowym odstąpieniu i wyznaczenie terminu na dalsze wykonanie może powodować wątpliwości co do intencji klienta. Warto oddzielić wezwanie do wykonania umowy od propozycji ugodowej. Próba ugody nie powinna nieświadomie prowadzić do uznania, że klient akceptuje zmieniony termin albo rezygnuje z kar.

Czy klient może wstrzymać płatność?

Możliwość wstrzymania kolejnej płatności zależy od konstrukcji umowy i wymagalności faktury.

Jeżeli wynagrodzenie jest należne dopiero po prawidłowym wykonaniu i odbiorze etapu, brak odbioru może oznaczać, że roszczenie software house’u jeszcze nie powstało. Jeżeli klient zaakceptował etap albo płatność jest powiązana wyłącznie z upływem czasu, jednostronne wstrzymanie może zostać uznane za naruszenie umowy. Klient może również posiadać wierzytelność z tytułu kar albo odszkodowania i złożyć oświadczenie o potrąceniu, jeżeli spełnione są ustawowe przesłanki. Nie należy automatycznie przestawać płacić wszystkich faktur tylko dlatego, że projekt ma problemy. Software house może wstrzymać dalsze prace, wypowiedzieć umowę i argumentować, że to klient pierwszy naruszył kontrakt.

Przed wstrzymaniem płatności warto ustalić, które świadczenie nie zostało wykonane, jaka kwota odpowiada spornemu etapowi oraz czy umowa przewiduje procedurę reklamacyjną.

Przedawnienie roszczeń

Klient nie powinien zbyt długo odkładać decyzji o dochodzeniu roszczeń.

Termin przedawnienia zależy od podstawy roszczenia, charakteru umowy, statusu stron oraz tego, kiedy roszczenie stało się wymagalne. Dla roszczeń związanych z prowadzeniem działalności gospodarczej ogólny termin wynosi co do zasady trzy lata, ale przepisy dotyczące umowy o dzieło przewidują także szczególny dwuletni termin dla roszczeń wynikających z takiej umowy. (ELI)

Ustalenie właściwego terminu w umowie IT może być skomplikowane, zwłaszcza gdy kontrakt ma charakter mieszany, obejmuje wiele etapów i kilka rodzajów roszczeń. Negocjacje i wysyłanie wezwań do zapłaty nie zawsze prowadzą do przerwania biegu przedawnienia. Klient nie powinien zakładać, że sama wymiana propozycji ugodowych zabezpiecza jego sytuację.

Czy można pozwać członków zarządu albo programistów?

Zasadniczo roszczenia kontraktowe kieruje się przeciwko podmiotowi, który zawarł umowę, najczęściej spółce będącej software house’em.

Programiści i podwykonawcy nie stają się automatycznie odpowiedzialni wobec klienta tylko dlatego, że wykonywali kod. Ich odpowiedzialność może powstać w szczególnych sytuacjach, przykładowo przy bezpośrednim czynie niedozwolonym, naruszeniu praw autorskich albo ujawnieniu tajemnicy. Członkowie zarządu spółki z ograniczoną odpowiedzialnością mogą ponosić odpowiedzialność za jej zobowiązania na zasadach określonych w Kodeksie spółek handlowych, ale dopiero po spełnieniu szczególnych przesłanek, między innymi bezskuteczności egzekucji przeciwko spółce. Klient powinien więc najpierw ustalić, kto dokładnie był stroną umowy, czy podmiot nadal istnieje, posiada majątek i czy nie znajduje się w restrukturyzacji albo likwidacji.

Ugoda z software house’em

Spór IT nie zawsze powinien kończyć się procesem. Postępowanie sądowe może trwać długo i wymagać opinii biegłych, a w tym czasie produkt traci wartość biznesową.

Ugoda może przewidywać dokończenie ograniczonego zakresu, wydanie wszystkich materiałów, przekazanie projektu nowemu wykonawcy, zwrot części wynagrodzenia, rezygnację z części kar oraz rozliczenie praw autorskich. Najważniejsze jest zapewnienie wykonania ugody. Samo zobowiązanie, że software house „przekaże projekt” jest zbyt ogólne. Należy wskazać dokładną listę repozytoriów, środowisk, dokumentów, kont, kluczy, danych, elementów infrastruktury i praw. Warto określić format, termin, procedurę weryfikacji i konsekwencje braków.

Część płatności albo rezygnacji z roszczeń można uzależnić od skutecznego przejęcia projektu przez nową firmę.

Jak klient powinien działać krok po kroku?

Pierwszym etapem powinna być analiza umowy i zebranie dokumentacji. Należy ustalić pierwotny zakres, późniejsze zmiany, terminy, zasady odbioru, kary, prawa do kodu oraz podstawy wypowiedzenia i odstąpienia. Następnie warto przeprowadzić niezależny audyt techniczny i zabezpieczyć kod, dane oraz infrastrukturę. Dopiero na tej podstawie można zdecydować, czy celem klienta jest dokończenie projektu przez dotychczasowy zespół, przejęcie go przez nową firmę, obniżenie ceny, czy pełne zakończenie współpracy. Kolejnym krokiem jest formalne wezwanie zawierające precyzyjne zarzuty, termin i konsekwencje.

Jeżeli wykonawca nie reaguje, klient może naliczyć kary, złożyć oświadczenie o odstąpieniu albo wypowiedzeniu, dokonać potrącenia oraz wystąpić z roszczeniem o zapłatę lub wydanie materiałów. Kolejność działań jest istotna. Zbyt wczesne odstąpienie, nieuprawnione wstrzymanie płatności albo ingerencja nowej firmy w kod bez wcześniejszego zabezpieczenia dowodów mogą osłabić roszczenia.

Podsumowanie

Klient, któremu software house nie dostarczył uzgodnionego projektu, może posiadać kilka równoległych roszczeń. Może żądać dokończenia prac, usunięcia wad, wykonania zastępczego, obniżenia wynagrodzenia, zwrotu zapłaconych środków, zapłaty kar umownych i naprawienia szkody. W odpowiednich okolicznościach może także odstąpić od umowy.

Zakres uprawnień zależy jednak od konstrukcji kontraktu, rodzaju zobowiązania, przyczyn opóźnienia, stopnia wykonania projektu i zachowania samego klienta. Podstawowym błędem jest podejmowanie radykalnych działań bez wcześniejszej analizy. Natychmiastowe zablokowanie płatności, odcięcie software house’u, przekazanie kodu nowej firmie albo nieprecyzyjne odstąpienie mogą utrudnić późniejsze dochodzenie roszczeń.

Klient powinien najpierw zabezpieczyć kod, dane, dostęp do infrastruktury i dokumentację, a następnie przeprowadzić niezależny audyt techniczny. Dopiero na tej podstawie można ocenić, czy bardziej opłacalne jest dokończenie projektu, migracja do nowego wykonawcy, ugoda czy postępowanie sądowe. Szczególną uwagę należy poświęcić prawom autorskim. Dostęp do kodu nie oznacza automatycznie prawa do jego zmiany i przekazania innemu wykonawcy. Brak skutecznego przeniesienia praw albo odpowiednio szerokiej licencji może uniemożliwić uratowanie projektu, nawet gdy klient zapłacił znaczną część wynagrodzenia.

O powodzeniu sporu często decyduje nie sam fakt, że aplikacja nie działa, lecz możliwość precyzyjnego wykazania, co software house miał wykonać, czego nie wykonał, dlaczego odpowiada za opóźnienie i jaką konkretną szkodę poniósł klient.