Spór o to, czym jest „gotowy produkt”, to najczęstszy punkt zapalny w umowach wdrożeniowych. W zależności od charakteru projektu, umowa na aplikację mobilną kwalifikuje się jako umowa o dzieło (art. 627 KC) albo umowa o świadczenie usług (art. 750 KC). To, do której kategorii należy zgłoszona przez zamawiającego uwaga, decyduje, czy jest ona błędem obciążającym wykonawcę, czy nową funkcją wykraczającą poza pierwotny zakres. Jeśli w umowie brakuje precyzyjnej specyfikacji funkcjonalnej, obie strony mają prawo inaczej rozumieć, co miało powstać: wykonawca patrzy na to, co zrealizował zgodnie z własną interpretacją briefu, zamawiający porównuje efekt z wyobrażeniem, które bywa bogatsze niż to, co realnie zamówił. Rozstrzygnięcie takiego sporu w sądzie zwykle wymaga powołania biegłego informatyka, który ocenia, czy sporne elementy mieściły się w pierwotnym zakresie zlecenia, co wydłuża postępowanie nawet o rok i generuje koszty często niewspółmierne do wartości samego kontraktu.
Skąd biorą się spory o odbiór
Źródłem większości takich konfliktów jest brak precyzyjnej specyfikacji funkcjonalnej na etapie podpisywania umowy. Jeśli zakres aplikacji opisano ogólnikowo, na przykład jako „aplikację do zarządzania zamówieniami z panelem klienta”, obie strony mają prawo inaczej rozumieć, co dokładnie miało powstać. Wykonawca patrzy na to, co technicznie zrealizował zgodnie z własną interpretacją briefu, zamawiający porównuje efekt z wyobrażeniem, jakie miał w głowie, często bogatszym niż to, co realnie zamówił.
Drugim częstym źródłem sporu jest mylenie błędów, czyli wad uniemożliwiających prawidłowe działanie uzgodnionych funkcji, z życzeniami dotyczącymi nowych funkcjonalności, które nie były częścią pierwotnego zakresu. Prawnie to fundamentalna różnica, bo błędy obciążają wykonawcę i uzasadniają wstrzymanie płatności, a dodatkowe funkcje stanowią odrębne zlecenie podlegające osobnej wycenie.
Co powinna zawierać umowa, żeby ograniczyć ryzyko sporu
Dobrze skonstruowana umowa wdrożeniowa powinna zawierać szczegółową specyfikację funkcjonalną, najlepiej w formie załącznika z listą konkretnych funkcji i scenariuszy użycia, a nie tylko opisu słownego w kilku zdaniach. Powinna też precyzować procedurę odbioru, w tym termin na zgłoszenie uwag przez zamawiającego, formę takiego zgłoszenia oraz konsekwencje milczenia zamawiającego po upływie terminu testów. Istotny jest podział na wady istotne, uniemożliwiające korzystanie z podstawowych funkcji, i wady nieistotne, które nie blokują odbioru, ale podlegają naprawie w uzgodnionym terminie po podpisaniu protokołu. Wreszcie umowa powinna definiować procedurę zmian zakresu, czyli jasny mechanizm wyceny i akceptacji dodatkowych funkcji zgłoszonych już po rozpoczęciu prac.
Jak wygląda spór, gdy tych zapisów zabrakło
Bez takich postanowień strony zwykle wpadają w impas: zamawiający wstrzymuje płatność do czasu naprawienia wszystkich zgłoszonych uwag, wykonawca wstrzymuje dalsze prace do czasu zapłaty zaległej części wynagrodzenia, a każda ze stron ma swoje wyobrażenie o tym, kto ma rację. Rozwiązanie takiego sporu na drodze sądowej wymaga zwykle powołania biegłego informatyka, który ocenia, czy sporne elementy mieściły się w pierwotnym zakresie zlecenia, co wydłuża postępowanie nawet o rok lub dłużej i generuje koszty niewspółmierne do wartości samego kontraktu.
Jak wyjść z patowej sytuacji, gdy spór już trwa
Jeśli do sporu już doszło, zanim sprawa trafi do sądu warto rozważyć niezależny audyt techniczny wykonany przez zewnętrznego specjalistę, który oceni, które ze zgłoszonych uwag są realnymi błędami, a które nowymi funkcjami. Taka opinia, sporządzona jeszcze przed procesem, często staje się podstawą do ugody, ponieważ obiektywizuje spór, który wcześniej opierał się wyłącznie na wzajemnych oskarżeniach. W wielu przypadkach ugoda z częściową zapłatą i ustalonym harmonogramem poprawek okazuje się rozwiązaniem szybszym i tańszym niż wieloletni proces cywilny, w którym i tak finalnie decyduje opinia biegłego.
Powiązane strony