A więc masz klienta. Gratuluję!

Po długich staraniach udało się nareszcie pozyskać kolejne zlecenie. Klient poprosił o przesłanie umowy. Patrzysz na swój standardowy kontakt przygotowany przez laty. Przed oczami przelatują ci wspomnienia. Chwile kiedy nie dostaliście transzy na czas. Klienci którzy nie odbierali projektu przez tygodnie. Klienci, którzy nie wysyłali materiałów na czas. Wtedy stwierdzasz że czas przygotować nową umowę. Pozwól, że Ci pomogę.

Zanim zaczniemy. Ten poradnik przeznaczony jest dla vendorów dostarczających oprogramowanie w modelu Time & Material w metodykach zwinnych (szczególnie scrum). Duża część wskazówek odnosi się również do pracy w modelu waterfall, jednak nie wszystkie będą miały przełożenie jeden do jednego.

Zaczynamy!

Umowa jak mapa
Dobry kontrakt to taki, który rozwiązuje problemy. To prawda, że umowy pisze się na trudne czasy, a nie na proste. Ale nie jest żadną sztuką napisać dokument, który będzie pełen pułapek i celowych niedomówień. Takie tworzenie dokumentów ma ma to oczywiście pewien sens w przypadku znaczącej pozycji dominującej w stosunku do drugiej strony.  Kiedy jednak relacje są w miarę równe, to konsekwencje takiego podejścia będą głównie negatywne. Po pierwsze prawie pewne, że twoje podchwytliwe podejście zostanie zauważone już na etapie negocjacyjnym przez drugą stronę. Umowy wdrożeniowe to nie przelewki, a kontrakty mają często wartość wielu setek tysięczy, czy milionów zlotych. Zatem na ogół z drugiej strony znajduje się jakiś kompetentny prawnik, który czyta to co zostało zaproponowane. Po drugie, nawet jeżeli jakimś cudem uda ci się przepchnąć te wszystkie podstępne zapisy, to musisz mieć świadomość że ewentualne dochodzenie tych zapisów siłą tj. przed sądem wiąże się z ogromnymi kosztami i jest bardzo czasochłonne. Najczęściej spory sądowe dotyczące produkcji oprogramowania trwają jeszcze długo po planowanym zakończeniu wdrożenia. Stąd negocjując zapisy umowy, należy mieć na uwadze aby był to przewodnik po tym jak w przyszłości rozwiązywać sytuacje konfliktowe.

Flow projektu
Metodyki zwinne nie są znane polskiemu systemowi prawnemu. Wiele gotowych rozwiązań prawnych (umowa o dzieło, zlecenie) nie znajduje zatem prostego zastosowania do umów wdrożeniowych. Polskie prawo zaprojektowane jest pod klasyczny project management (waterfall). Zmiany scope projektu, praca w sprintach, czy brak określenia efektu końcowego wymaga zaten dokładnego opisania. Bardzo potrzebne jest aby w treści umowy bądź w załączniku do niej umieścić opis metodyki pracy (scrum) wg. której realizowane będzie wdrożenie.

Procedura dostarczania materiałów / informacji / decyzji
Jedną z podstawowych bolączek produkcji oprogramowania jest zwłoka klienta w dostarczeniu wytycznych i materiałów, bądź podejmowaniu decyzji. Z perspektywy vendora należy jasno ustalić reguły według których te rzecz się dzieją. Dobrze sięgnąć po jedno z następujących rozwiązań.
1) możliwość podjęcia decyzji za klienta jeżeli ten nie będzie trzymał się terminu;
2) możliwość zawieszenia projektu za wynagrodzeniem (postojowe);
3) możliwość zajęcia się innymi zadaniami z backlogu w przypadku braku bierzący w decyzji.

Procedura odbioru
Z drugiej strony, przy projektach wdrożeniowych szalenie istotna jest kwestia odbioru dostarczanych przyrostów pracy. Częstym problemem z którymi spotykają się dostawcy oprogramowania, jest przeciąganie w czasie odbioru, funkcjonalności, bądź modułu. Drugim, podobnie istotnym jest wracanie z zastrzeżeniami do zamkniętych już etapów produkcji. Problemy te wymagają zaadresowania w zdecydowany i realny sposób, ucinając takie praktyki. Ponadto należy sobie odpowiedzieć kto odpowiedzialny jest za testowanie oprogramowania przed jego odbiorem. W większości przypadków klient nie dysponuję własnym teamem testowym i nie jest w stanie samodzielnie przeprowadzić UATów. Zalecane jest zatem współdziałanie między z nim w tym zakresie i przewidzenie wynagrodzenia za pracę testerów.

Komunikacja i osoby decyzyjne
W każdym projekcie, a w szczególności w projekcie wdrożeniowym dochodzi do nieporozumień, szumów komunikacyjnych i sporów. Aby tego unikać, stosujemy szereg specjalistycznych narzędzi komunikacyjnych (Jira, Slack, Confluence itp.). Ponadto przypisujemy bardzo precyzyjnie role i odpowiedzialność poszczególnych osób uczestniczących w projekcie (Scrum Master, Product Owner itd.). Te ustalenia muszą znaleźć swoje odbicie również w zapisach umowy. Szczególnym istotnym punktu widzenia przepisów jest zapisanie upoważnienia dla poszczególnych osób do podejmowania decyzji w zakresie ich odpowiedzialności.

Prawa autorskie i własność intelektualna
Jest to może oczywistość, ale w tym przewodniku zalecenie to musi się znaleźć. Bardzo istotnym jest zapisanie sposobu przeniesienia autorskich praw majątkowych do wytworzonego oprogramowania i innych utworów powstałych w toku wdrożenia. Punktem zapalnym jest zazwyczaj moment przejścia autorskich praw majątkowych. Z perspektywy klienta najbardziej korzystnym jest przeniesienie ich z chwilą powstania. Takie rozwiązanie powoduje jednak pozbawienie vendora możliwość dochodzenia swojego wynagrodzenia, również z tytułu transferu IP. Zalecanym jest zatem korzystanie z rozwiązań hybrydowych, takich jak na przykład przeniesienie autorskich praw majątkowych pod warunkiem zapłaty wynagrodzenia za poszczególne przyrosty. Dobrze jest też zapisać możliwość wykorzystania projektu w portfolio. Nie po to tworzymy fajne projekty, żeby się nimi później nie pochwalić.

Siła wyższa (COVID i spółka)
Postanowieniem często traktowane po macoszemu jest klauzula dotycząca siły wyższej. Jak bardzo jest to lekkomyślne podejście, pokazały ostatnie miesiące i pandemia. Ewentualne problemy ekonomiczne i zaburzenia organizacji pracy będące jej powinny być oczywiście opisane w umowie. Jest to istotne głównie z tego powodu, iż brak odpowiedni zapisów powoduje konieczność zwracania się każdorazowo o rozstrzygnięcie do sądu. Szczególnie w sytuacjach nadzwyczajnych jest nieefektywne i powoduje zaognienie sytuacji. Stąd zamieszczenie procedury odpowiadającej na potrzebę zawieszenia wykonania umowy lub powierzenia wykonania zastępczego powinny być opisane w treści kontaktu.

Zakaz zatrudniania
Przy dużych projektach wdrożeniowych istnieje realna obawa, że w sytuacji konfliktowej klient będzie próbował podkupić team deweloperski i kontynuować realizację projektu z pominięciem vendora. Stąd silnie zalecanym jest zamieszczenie odpowiednich zapisów uniemożliwiających taką praktykę.

Poufność (NDA)
W toku projektu często dopuszczamy klienta do informacji, które wolelibyśmy aby pozostały niejawne. Nie chodzi tu tylko o system ofertowania ale także o rozwiązania biznesowe i organizacyjne, które nie chcielibyśmy aby stały się jawne dla konkurencji. W praktyce sama klauzula poufności nie jest wystarczająca. Koniecznym jest jej obwarowanie dodatkowa karą umowną za naruszenie takiego obowiązku. W przeciwnym razie, nie będzie możliwe skuteczne dochodzenie zachowania takiej poufności. Warunkiem zapłaty odszkodowania przez naruszającego, jest wykazanie wysokości szkody, a to bardzo problematycznym bez odpowiedniego zapisu.

Exit Plan
W każdym projekcie może okazać się, że nie będzie możliwe jego zakończenie z różnych powodów. Każda ze stron może mieć interes w tym, aby nie kontynuować współpracy, bądź przerwać ją przed zakończeniem projektu. Z perspektywy vendora dobrze wziąć pod uwagę przede wszystkim takie scenariusze jak opóźnienie płatności, zwłoka w odbiorze czy niedostarczenie decyzji i materiałów. Dodatkowo istotne jest zabezpieczenie wynagrodzenia nie tylko za czas realnie przepracowany, ale również za okres przestoju i wypowiedzenia.