Firma zamawia u software house'u aplikację mobilną do obsługi klientów, płaci część wynagrodzenia zaliczkowo i czeka na finalny odbiór. Wykonawca ogłasza gotowość produktu, zamawiający po testach wskazuje kilkanaście błędów i odmawia zapłaty pozostałej części wynagrodzenia, twierdząc, że aplikacja nie nadaje się do użytku. Wykonawca odpowiada, że zgłoszone błędy to w większości nowe funkcje, których w umowie nigdy nie było. To scenariusz hipotetyczny, ale bardzo typowy dla sporów wynikających z umów wdrożeniowych, w których strony nie ustaliły jasno, czym w ogóle jest „gotowy produkt”.
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