Umowa na wykonanie oprogramowania: 8 zapisów, które musisz zrozumieć

Większość sporów między firmą a wykonawcą oprogramowania nie bierze się ze złej woli. Bierze się z niedomówień, które umowa na wykonanie oprogramowania miała rozstrzygnąć - a milczy. Co znaczy „gotowe”? Czyj jest kod? Kto płaci za poprawki po odbiorze? Jeśli umowa nie odpowiada na te pytania, odpowiedzą emocje - zwykle w najgorszym momencie projektu. Nie musisz być prawnikiem. Musisz zrozumieć 8 zapisów i wiedzieć, o co dopytać. Ten tekst to praktyka z projektów, nie porada prawna - nietypową umowę warto pokazać prawnikowi.

Umowa na wykonanie oprogramowania: zakres i pieniądze

1. Zakres i kryteria odbioru

„Aplikacja do obsługi zamówień” to nie jest zakres - to życzenie. Dobra umowa odsyła do specyfikacji: listy funkcji, scenariuszy użycia i tego, co jest poza zakresem. Do tego kryteria odbioru: po czym obie strony poznają, że etap jest skończony, ile trwa odbiór i co się dzieje ze zgłoszonymi uwagami. Jak przygotować taki dokument, pisaliśmy w przewodniku po specyfikacji aplikacji.

2. Wynagrodzenie i model rozliczenia

Fixed Price daje przewidywalną kwotę za ustalony zakres, Time and Material - elastyczność przy zmiennych wymaganiach. Oba modele są uczciwe, każdy przenosi ryzyko gdzie indziej. Umowa musi jasno mówić, co jest w cenie (testy? wdrożenie? dokumentacja?) i jak wyceniane są zmiany zakresu. Szczegółowo porównaliśmy je we wpisie o Fixed Price i Time and Material.

3. Prawa do kodu: przeniesienie praw albo licencja

Zapis, wokół którego narosło najwięcej mitów. W praktyce funkcjonują dwa uczciwe modele. Przeniesienie autorskich praw majątkowych: kod staje się Twoją własnością i możesz go rozwijać z dowolnym wykonawcą. Licencja: prawa zostają u wykonawcy, a Ty korzystasz z oprogramowania w zakresie opisanym w umowie - często taniej i z jasno określoną odpowiedzialnością wykonawcy za rozwój. Żaden z modeli nie jest „jedynym słusznym” - różnią się ceną, swobodą zmiany wykonawcy i podziałem odpowiedzialności, a o wszystkim decyduje umowa. Dopytaj: co dokładnie obejmuje przeniesienie albo licencja (kod, dokumentacja, projekt graficzny), co z komponentami open source oraz kiedy i w jakiej formie dostajesz kod lub dostęp do repozytorium. Czerwona flaga jest jedna: brak jakiegokolwiek zapisu na ten temat.

Gwarancja, poufność, odpowiedzialność

4. Gwarancja to nie to samo co SLA

Gwarancja obejmuje naprawę błędów w tym, co odebrano - zwykle przez określony czas po wdrożeniu. SLA to umowa o czas reakcji i dostępność: co się dzieje, gdy system padnie w piątek wieczorem. Rozwój aplikacji to trzecia, osobna sprawa. Te pojęcia lubią się mieszać, a każde kosztuje inaczej.

5. Poufność (NDA)

Wykonawca pozna Twoje procesy, marże i dane klientów. Zapis o poufności powinien działać w obie strony i obowiązywać także po zakończeniu współpracy. Sprawdź, czy obejmuje podwykonawców.

6. Odpowiedzialność i kary umowne

Kary dyscyplinują, ale zdrowe umowy są symetryczne: kara za zwłokę wykonawcy ma odpowiednik w karze za przeciąganie odbiorów czy niedostarczanie materiałów po Twojej stronie. Jednostronne kary to sygnał, że ktoś przerzuca całe ryzyko na Ciebie.

7. Plan wyjścia: co dostajesz na koniec

Współprace się kończą - dobre umowy to przewidują. Sprawdź, czy Twoja opisuje:

• przekazanie kodu lub dostępu do repozytorium - zgodnie z modelem z punktu 3,
• dostępy: domena, hosting, baza danych, konta zewnętrznych usług,
• dokumentację techniczną i instrukcję uruchomienia projektu,
• okres przejściowy, w którym wykonawca odpowiada na pytania następcy.

O dostępy i procedurę zakończenia współpracy warto dopytać jeszcze przed podpisaniem - podpowiadamy jak w 10 pytaniach o bezpieczeństwo aplikacji.

8. Trzy zapisy, które powinny zapalić czerwoną lampkę

• Ani słowa o prawach do kodu. Nieważne, który model wybierzecie - ma być opisany. Cisza w umowie oznacza spór w przyszłości.
• Kary tylko w jedną stronę albo odpowiedzialność wykonawcy ograniczona do symbolicznej kwoty przy dużym projekcie.
• „Szczegóły ustalimy w trakcie” - brak zakresu, kryteriów odbioru i procedury zmian. To nie jest elastyczność, to pole minowe.

Jak my to ustawiamy - i co dalej

W Exmoor Software zakres, kryteria odbioru, model praw do kodu i plan wyjścia opisujemy w umowie standardowo - klient świadomie wybiera model rozliczenia i praw, znając konsekwencje obu opcji. Masz już ofertę albo umowę i chcesz ją przejrzeć okiem inżyniera przed podpisaniem? Umów konsultację techniczną. A jeśli dopiero planujesz projekt, opisz go w kalkulatorze wyceny - wstępny przedział cenowy zobaczysz od ręki, pierwszą odpowiedź dostaniesz w ciągu 24h, a wiążącą wycenę przygotujemy po krótkiej rozmowie.