Umowa na projekt IT powstaje zwykle na samym końcu rozmów, kiedy obie strony są już zmęczone i chcą wreszcie zacząć pracę. Tymczasem to, co w niej zapisano, decyduje o tym, co się stanie, gdy coś pójdzie nie tak. Piszę jako wykonawca, który sam układał umowy na stałą obsługę i poprawiał je po własnych potknięciach, więc te pytania mają sens po obu stronach stołu.
Uwaga: to nie jest porada prawna. Zbieram pytania wynikające z mojej praktyki. Zapisy o karach, odpowiedzialności i prawach do kodu warto przed podpisaniem skonsultować z prawnikiem.
1. Co dokładnie jest przedmiotem umowy i po czym poznamy, że jest wykonane?
Dla programisty praca zwykle działa albo nie działa. Dla zamawiającego bywa jeszcze „działa, ale…”. Zlecenie „dorób do strony obracający się element” można wykonać bezbłędnie, a zamawiający i tak powie, że kręci się za wolno albo ma zły kolor. Jeśli umowa mówi tylko o „należytym wykonaniu”, każda strona rozumie to po swojemu. Opisz rezultat tak, żeby dało się go sprawdzić: co ma się pojawić, w jakim zakresie i w jakim środowisku.
2. Jak wygląda odbiór i ile mam czasu na uwagi?
Dobra umowa przewiduje, że po zakończeniu prac zamawiający ma określony czas na zgłoszenie uwag (na przykład kilka dni roboczych), a wykonawca ma określony czas na poprawki. Dopiero po tych krokach można mówić o nienależytym wykonaniu. Najpierw furtka na naprawienie błędu, potem konsekwencje. Dzięki temu nikt nie jest zaskoczony, a drobna niezgodność nie kończy się od razu sporem. O tym, co sprawdzać przy odbiorze strony, pisałem osobno: odbiór strony www od wykonawcy.
3. Co robimy, gdy się nie zgadzamy?
Przy współpracy rozliczanej godzinami albo miesięcznym ryczałtem łatwo o spór typu „te pięć godzin z piętnastu uznaję za wykonane źle”. Lepiej, gdy umowa pozwala odbierać prace etapami albo partiami godzin, a spór dotyczy wyłącznie spornej części. Bez takiego mechanizmu jedna sporna pozycja potrafi zablokować rozliczenie całego miesiąca.
4. Za co jest kara umowna i jak wysoka może być?
To jeden z najczęściej źle sformułowanych zapisów. Zwróciłbym uwagę na cztery rzeczy:
- Ogólniki nic nie wnoszą. „Nienależyte wykonanie” albo „bez wyraźnej przyczyny” to sformułowania, które każdy odczyta inaczej. Lepiej wskazać konkretną sytuację, na przykład niewykonanie prac z przyczyn leżących po stronie wykonawcy.
- Wyłączenia. Uczciwy zapis uwzględnia, że wykonawca, zwłaszcza jednoosobowy, może zachorować albo mieć wypadek.
- Górna granica. Kara ograniczona do określonego procentu miesięcznego wynagrodzenia i proporcjonalna do prac niewykonanych lub wykonanych źle jest przewidywalna dla obu stron. Kara bez limitu to ryzyko, którego trudno racjonalnie wycenić.
- Kolejność. Kara powinna działać dopiero po upływie czasu na poprawki, o którym pisałem wyżej.
5. Czy kara wyczerpuje roszczenia?
W wielu umowach znajdziesz zapis, że zamawiający może dochodzić odszkodowania przewyższającego karę umowną. To częsta praktyka, ale warto zapytać wprost, jak ma to działać. Zwykle ten, kto chce więcej niż kara, musi wykazać wysokość szkody oraz to, że powstała z winy drugiej strony. Szczegóły to temat dla prawnika, ale dobrze wiedzieć, że ten zapis w umowie jest i co z niego wynika.
6. Czy terminy z SLA są Ci naprawdę potrzebne i kto je liczy?
SLA, czyli umowne terminy reakcji i naprawy, brzmi bezpiecznie. Problem zaczyna się wtedy, gdy terminy są krótkie, a w praktyce nikt ich nie pilnuje. Typowa pułapka wygląda tak: drobne usterki zbierają się, wykonawca dostarcza poprawki w paczkach, wdrażacie je raz w miesiącu, bo nic się nie pali. Po roku trzeba odpowiedzieć, czy w każdym przypadku dotrzymano terminu, i okazuje się, że nie ma jak tego sprawdzić. Dla zgłoszenia naprawionego w paczce widać tylko datę paczki.
Co z tym zrobić:
- ustal terminy zależnie od kategorii zgłoszenia i uzgadniaj je w razie potrzeby osobno, na piśmie (w zgłoszeniu albo mailem),
- dla każdego zgłoszenia zapisuj datę zgłoszenia, uzgodniony termin i datę dostarczenia poprawki,
- jeśli sprawa nie jest pilna, zapisz, że termin jest dłuższy, zamiast po cichu go przeciągać,
- nie bój się zmieniać terminów, jeśli umowa na to pozwala.
Inaczej po roku spędzisz kilka dni na odtwarzaniu z maili i arkusza, kto komu co obiecał.
7. Kto jest właścicielem kodu, danych i kont?
Zapytaj, kto po zakończeniu współpracy będzie miał kod źródłowy, bazę danych, dostęp do serwera i domeny oraz kopie zapasowe. Najlepiej, gdy domena i hosting są zarejestrowane na Ciebie, a wykonawca pracuje na nadanych dostępach. Zdarza się, że klient po latach odkrywa, że niczego nie może zmienić bez dawnego wykonawcy. Taką historię opisałem we wpisie Jak u(nie)zależnić od siebie klienta.
8. Co się dzieje, gdy wykonawcy zabraknie?
Jednoosobowa firma jest szybka i elastyczna, ale ma słabe miejsce: chorobę, urlop, wypadek. Zapytaj, kto zastępuje wykonawcę, gdzie jest dokumentacja i czy ktoś poza nim potrafi uruchomić Twoje rozwiązanie. Sam prowadzę jednoosobową firmę, więc to pytanie zadaję także sobie. Uczciwy wykonawca odpowie wprost, nawet jeśli odpowiedź brzmi „na razie nikt” i trzeba to zorganizować.
9. Jak zakończyć współpracę?
Okres wypowiedzenia, przekazanie dostępów i dokumentacji, rozliczenie prac w toku. Najgorszy moment na ustalanie tego jest wtedy, gdy współpraca już się psuje.
Zamiast podsumowania
Nie chodzi o to, żeby umowa była długa albo groźna. Chodzi o to, żeby obie strony rozumiały ją tak samo, zanim zaczną pracę. Jeśli chcesz mieć po swojej stronie kogoś, kto przeczyta wycenę, sprawdzi etapy i technicznie odbierze prace, zajrzyj do usługi nadzór nad wykonawcą i odbiór prac. Warstwę prawną umowy zawsze oceni lepiej prawnik.