Po każdym etapie negocjacji pomiędzy wykonawcą a zamawiającym oprogramowanie dochodzi do momentu podpisania umowy. Umowy, która przede wszystkim ma na celu zadbanie o to aby Zamawiający otrzymał to czego potrzebuje w stosownym terminie, wymaganej jakości i satysfakcjonującym przebiegu projektu a z drugiej strony Wykonawca miał zapewniony komfortowy przebieg prac. Z pozoru sprawa jest dość oczywista, natomiast każdy kto kiedykolwiek podpisywał umowy na realizację dedykowanego oprogramowania zdaje sobie sprawę ze złożoności i możliwości interpretacji takich umów.

W tym artykule chciałbym poruszyć ogólne zagadnienia związane z zawieraniem umów na systemy informatyczne tak aby obie strony projektu miały poczucie bezpieczeństwa i przejrzystości w zobowiązaniach i oczekiwaniach. Artykuł opieram na naszych ponad 10-letnich doświadczeniach w realizacji niekiedy bardzo skomplikowanych prawnie zasadach współpracy. Skupie się moim zdaniem na najważniejszych aspektach i opisze je bardzo ogólnie gdyż o każdym podpunkcie można by napisać osobny artykuł.

Pierwsza zasada: Projekt realizujemy po podpisaniu umowy.

Oczywiste, prawda? A jednak, wiele podwykonawców ulegając presji Zamawiających polegających na realizacji prac natychmiast odkłada „papierologię” na później. Błąd. I to poważny, który wielu kosztował nieprzespane noce i stres. Nigdy, bez względu jak bardzo chcesz już zacząć realizację projektu nie zaczynaj bez podpisanej obustronnie umowy. Niestety z doświadczenia współpraca bez umowy nawet z wieloletnimi partnerami może zakończyć się nieporozumieniami.

Przedmiot umowy

Tu zasada jest jasna – im krótszy i bardziej ogólny opis zadania tym większe pole do (nad)interpretacji zakresu zadania i większe pole do nieporozumień na linii Wykonawca-Zamawiający. Im opis szerszy i dokładniejszy tym lepiej. Precyzyjna specyfikacja projektu, prototypy i inne dokumenty są dobre ale do pewnego stopnia. Często bowiem okazuje się iż w bardzo dokładnie opisanym przedmiocie umowy brakuje miejsca na elastyczność, która uwzględniała by drobne i nieuniknione błędy na etapie projektowania. Restrykcyjne podejście do realizowanego projektu jest dobre z punktu widzenia Wykonawcy (jasno określone zadania i praktycznie zapewniony etap „rozwoju” po zakończeniu realizacji umowy polegający na zmianach niedociągnięć) ale niestety szkodliwe dla Zamawiającego. Moim zdaniem strony powinny znaleźć wspólną płaszczyznę w której projekt jest wystarczająco precyzyjny oraz założyć sobie pewną przestrzeń czasową na drobne modyfikacje w trakcie realizacji umowy. Wymaga to jednak rozsądku i sporego doświadczenia tak agencji realizującej projekt jak zleceniodawcy.

Harmonogram realizacji i wynagrodzenie

Klient chciałby zapłacić za gotowe oprogramowanie a wykonawca chciałby ograniczyć ryzyko niewypłacalnego zamawiającego (dość częsty przypadek, nieprawdaż?). Rozwiązanie, które stosuje od lat jest dość proste:

• Etapowość, gdzie jeden etap jest nie dłuższy nić 4 tygodnie / 1 miesiąc
• Każdy etap dokładnie opisuje zakres prac, który może być zaprezentowany klientowi. Rekomenduje raczej elementy klikalne jak np. „Zarządzanie użytkownikami” aniżeli „Projekt bazy danych” czy „moduł obsługi bazy danych” etc. Jeśli w coś można kliknąć i zobaczyć efekt – jest 100x lepsze niż wydruki dokumentacji kodu.
• Rozliczenia powiązane z etapami, czyli „widzę za co płacę”. Po każdym etapie krótka prezentacja o postępach w realizacji projektu (jeśli możliwe, również dostęp do środowiska DEV). Klient widząc faktyczny postęp jest spokojniejszy płacąc agencji kolejną fakturę.

Bardzo istotne jest również określenie zasad rozliczeń i przedłużania czasu trwania projektu w przypadku zmian i modyfikacji na polecenie Zamawiającego w trakcie realizacji umowy. Jest to częsty przypadek kiedy dokładanie kolejnych funkcjonalności skutkuje tylko podniesieniem wartości wystawianych faktur przy niezmienionym czasie realizacji. Pamiętajmy, że każda zmiana powinna być aneksowana. Klient musi mieć pełną świadomość, że nowe pomysły opóźniają start projektu a podnoszą jego koszt.

Przebieg prac

W sytuacji kiedy Zamawiający jest zobligowany udzielać Wykonawcy informacji, dostarczać materiałów czy komunikować się, trzeba dopilnować aby w Umowie był zapis o terminach oraz procesie komunikacji z Zamawiającym. Niestety ale często się zdarza, że projekt jest opóźniany z winy klienta, który zwleka z przesłaniem materiałów, feedback’ów lub też przekłada spotkania. W takich sytuacjach powinien zdawać sobie sprawę z możliwości nałożenia na niego sankcji związanych z opóźnieniem projektu z Jego winy.

Nie zapomnijcie do Umowy dopisać sposobu komunikacji aby wystarczającym był konkretny e-mail a daty otrzymania/nadania bazowały na datach wiadomości.

Prawa autorskie

Temat jest bardzo złożony ponieważ z jednej strony obejmuje przeniesienie praw autorskich na różnych polach eksploatacji i filarach prawa z Wykonawcy na Zamawiającego lecz z drugiej zahacza o problemy:

• Wyjątki dla bibliotek i fragmentów kodu wykorzystywanych w tworzeniu dedykowanego oprogramowania a ujętych osobnymi licencjami zewnętrznych firm i innych autorów
• Moment przenoszenia praw (czy etapowo tak jak rozliczenia czy całościowo po zakończonym projekcie)

Osobiście rekomenduje pełne przeniesienie praw aniżeli wszelkiej maści licencje z tego względu, że Zamawiający nie ma poczucia uwiązania do Wykonawcy jako jedynej firmy mogącej obsługiwać i rozwijać dostarczane oprogramowanie.

Tak więc w umowie trzeba jasno wymienić co jest przenoszone, na jakich prawach, w którym momencie, jak klient może otrzymanym kodem obracać, należy wspomnieć o rozpowszechnianiu, kopiowaniu, odsprzedaży itd. W tym temacie planuje osobny artykuł gdyż prawa autorskie w dziedzinie oprogramowania są bardzo rozbudowaną kwestią.

Procedura odbioru projektu

Nie spotkałem jeszcze projektu pozbawionego jakiegokolwiek błędu w momencie odbioru. To jest naturalne. Dobrze kiedy klient to też rozumie a procedura odbioru projektu nie jest uzależniona od zbyt mocno przesuniętego buttonu w lewą stronę. Aby temu zaradzić opisuje się procedury odbioru przedmiotu umowy czyli scenariusze, według których, jeśli funkcjonują – stanową podstawę do przyjęcia oprogramowania jako wykonanego prawidłowo.

Procedur odbiorczych nie polecam przy małych realizacjach gdyż takie można przetestować i poprawić na tyle dobrze, że Zamawiający w momencie odbioru nie wyłapie żadnego rażącego błędu. Dla większych dobrze jest dodatkowo opisać całe scenariusze odbiorcze wykorzystujące znaczny procent wykonanych funkcjonalności. Każdy scenariusz przy odbiorze kończy się tylko jednym z dwóch rezultatów – działa / nie działa. Z chwilą przejścia przez wszystkie funkcjonalności z rezultatem działa jest podstawa do odbioru.

A co jeśli pojedyńcze funkcjonalności nie działają? Stosuje się wówczas procedurę odbioru warunkowego i zastrzega o znalezionych błędach, ustala się termin naprawy. Zazwyczaj odbiór warunkowy nie wstrzymuje rozliczenia projektu (zaznaczam ten aspekt ponieważ Zamawiający często nadużywają sytuacji w której błędy niskiego priorytetu blokują rozliczenie całej umowy).

Enterprise ma inne zasady.

W systemach klasy enterprise odbiory projektu są jeszcze bardziej złożone i podzielone na etapy. Udział w nim biorą całe zespoły, wykonywane są wszelkiego rodzaju testy na rzeczywistych danych a co za tym idzie trwają dość długo. Mechanizmy rozliczeń działają wówczas według innych zasad i ustalane są indywidualnie pomiędzy firmami. Zdarza się też, że w odbiorze uczestniczy jeszcze 3-cia firma audytująca bezpieczeństwo, jakość czy wydajność. Niezależnie od tego Wykonawca dostarcza Zamawiającemu szereg dokumentów projektowych uzupełniających przekazaną aplikację (pomijam w tym momencie dokumentacje techniczną czy użytkownika, mam na myśli głównie procedury serwisowe, awaryjne, testujące etc.)

Poufność

Bez względu, czy realizujesz prostą stronę wizerunkową firmy czy software klasy enterprise poufność informacji jest czymś podstawowym w tej branży. Bez względu na prowadzony projekt warto umieścić zapis dotyczący przekazywania i wymiany informacji, poziomów dostępu do nich czy autoryzacji Zamawiającego w ich przekazywaniu firmom i osobom trzecim (np. na cele realizacji umowy). Im pracujesz na bardziej wrażliwych danych tym dyscyplina w przechowywaniu i przetwarzaniu informacjami musi być większa. Wszystko to należy zapisać w umowie oraz co ważne zawrzeć ewentualne sankcje za nieprzestrzeganie tych zasad adekwatne do skali projektu. NDA na początku współpracy jest dzisiaj już chyba standardem.

Gwarancja i wsparcie techniczne

O gwarancji i wsparciu technicznym pisaliśmy w artykule: Wsparcie techniczne vs. Gwarancja – Podstawowe różnice natomiast w tym miejscu zaznaczę tylko, że prowadzenie gwarancji przez Wykonawcę jest podstawową i nieodzowną w umowie usługą, oferowaną na minimum 1 rok. Strony powinny ustalić dopuszczalne i akceptowalne sytuacje w których zasady gwarancyjne mogą być stosowane. Dla przykładu można gwarancją objąć jedynie prawidłowe działanie kodu oprogramowania natomiast jego logiki już nie (a złożona logika może się okazać błędna przy dłuższej pracy). Trzeba określić w jakim czasie Wykonawca zareaguje na zgłoszenie gwarancyjne, w jakim je wykona oraz jaką procedurę zastosuje przy obsłudze zgłoszenia. Zgłoszenia dodatkowo rozbija się na różne poziomy istotności i wpływu na procesy klienta. Do tego ustala się tak zwane okienka serwisowe. To wszystko czyni usługi gwarancyjne jako duży i istotny element umowy.

Pamiętaj również o określaniu zasad w przypadku nienależytego wykonywania lub złamania warunków gwarancji. Przydaje się 

Kary umowne

Nikt nie lubi ale są potrzebne. Nakładane na obie strony za nierzetelną, nieprofesjonalną lub niezdyscyplinowaną realizację postanowień umowy. O czym mowa? O opóźnieniach, opieszałości w komunikacji, niepodpisaniu protokołu odbioru, zerwaniu umowy czy odstępstwach dostarczonej apliakcji od założeń w dokumentacji projektu (dlatego tak wazne aby pisać dokumentacje!!!). Niestety takie sytuacje zdarzają się coraz częściej po stronie Zamawiających narażając Wykonawców na przestoje w pracy a co za tym idzie na dodatkowe koszty (które to właśnie powinny być pokryte z kar umownych).

Jakie są stosowane progi i zasady kar? Nie ma reguły, wszystko zależy od charakteru oraz skali i ryzyka projektu.

Podsumowując…

Miał to być bardzo krótki artykuł, będący wstępem do serii w której każdy akapit stąd byłby osobnym i wyczerpującym wpisem. Nie wyszło…

Jeśli jednak realizujesz system informatyczny po raz pierwszy i nie miałeś doświadczenia w podpisywaniu tego rodzaju dokumentów – mocno rekomenduje Ci konsultacje z kimś doświadczonym gdyż słaba/zła/błędna umowa może kosztować Ciebie nie tyle sporo pieniędzy co nieprzespane noce, nerwy  a nawet sprawy sądowe. Umowa na tworzenie oprogramowania jest nawet bardziej skomplikowana niż kupowanie domu w kredycie na  kolejne 30 lat. Warto poświęcić jej troszkę czasu.