Jak się (NIE) zabezpieczać w umowach w ramach innowacyjnych projektów!

Każdy przedsiębiorca, szczególnie mały, dopiero rozwijający swój biznes, szuka możliwości rozwoju, stworzenia innowacyjnego produktu, nawiązania współpracy na nowych rynkach i w niszowych obszarach.

Często wejście w potencjalnie ciekawy i rozwojowy projekt wiąże się z istotną ilością ustępstw z jednej strony, często projekty realizowane są w ramach sieci kontaktów, oparte na obopólnym zaufaniu i współpracy w dobrej wierze, a strony w czasie negocjacji ustalają, że szczegóły ,,dograją” później. Liczy się przecież cel i szybkość, nie ma czasu na wielkotygodniowe negocjacje umowy – która to będzie nas ograniczać. Mimo, że często w projektach pojawia się jakiś czynnik zewnętrzny, nie analizujemy go na tym etapie – kto miałby na to czas i zasoby.

Przystępujemy więc do współpracy, która może skończyć się 2 scenariuszami:

1. Wszystko się udało, obie strony są zadowolone – podstawowe założenia strony już ustaliły więc rozliczają się terminowo, wypuszczają produkt w świat i obie strony cieszą się korzyściami z wykonanego projektu.
2. Coś się nie udało… i tu znowu mamy 2 scenariusze:
1) Strony dokładnie widzą co poszło nie tak i ustalają kto ponosi winę za to niepowodzenie i naprawdę poszukują wspólnego wyjścia z sytuacji zadawalającego obie strony;
lub bardziej prawdopodobne
2) Żadna ze stron nie poczuwa się do winy i… całą winą obarcza drugą Stronę.

I tu zaczyna się retrospektywa – co można było zrobić, aby nie doprowadzić do tej sytuacji. Czy jednak te kilka tygodni negocjacji i wydatek na kilka/naście godzin pracy prawnika były nam potrzebne?

Na przykładzie projektu na stworzenie oprogramowania mieliśmy do czynienia z następującą sytuacją:
1. Wykonawca będąc przekonany, że pliki dostarczane przez Zamawiającego będą jednakowego formatu i jednakowej / zbliżonej struktury, wycenił na kwotę X wykonanie projektu, który później określił jako projekt na pograniczy R&D.
2. Strony podpisały umowę, w której nie zawarły właściwie żadnych zastrzeżeń, zagrożeń projektu czy też podziału ryzyka niepowodzenia, mimo że żadna ze Stron nie miała pełnej wiedzy technicznej na temat plików, które oprogramowanie miało obsługiwać. Zawierała jednak całe multum zastrzeżeń dotyczących kar za opóźnienie.
3. Wykonawca dostał od Zamawiającego zbiór plików testowych i dla nich stworzył oprogramowanie.
4. Wykonawca w trakcie prac nad oprogramowaniem wskazywał na jakiej podstawie tworzy oprogramowanie, a Zamawiający pisemnie ani nie podważył ani nie potwierdził tych założeń.
5. Oczywiście część z ustaleń ze spotkań czy rozmów telefonicznych nigdy nie doczekała się spisania w formie utrwalonego potwierdzonego przez obie strony dokumentu/pliku.
6. Doszło do oddania oprogramowania do odbioru i tu… coś jednak poszło nie tak:
1) Wg wykonawcy oprogramowanie działa jak należy – przecież dla plików testowych wszystko się zgadza;
2) Wg Zamawiającego, w znacznej części innych plików, oprogramowanie jednak nie działa, a więc Zamawiający nie odbierze oprogramowania.
7. Po analizie dodatkowych rodzajów plików okazało się, że czasochłonność zmian w ramach projektu znacznie przekroczy już niedoszacowany budżet, a części z nich nie da się (a co najmniej w ramach czasochłonności nie przekraczającej kilkukrotnie budżetu projektu) zaimplementować.

Kto zawinił? Nie wiadomo… może sąd przesądzi?

Tyle tylko, że postępowanie sądowe może trwać latami, co już samo w sobie może pogrążyć nawet całkiem dobrze prosperujące przedsiębiorstwo.

Wiadomo jednak, że umowa mogła wszystkie te ryzyka zabezpieczyć, a w takiej sytuacji spór sądowy byłby zbędny dla ustalenia winy. Co należało więc zrobić?:
1) Wskazać na charakter projektu jako R&D – zależny od czynników zewnętrznych, których wpływ na projekt będzie badany w pierwszym etapie projektu – po którym strony mogą się rozejść lub prowadzić prace dalej.
2) Wskazać na podział ryzyka pomiędzy partnerów biznesowych lub wyraźnie wskazać, która ze stron jest obarczona zgodnością plików testowych z zewnętrznymi plikami, które będą używane przez użytkowników.
3) Ustalić zasady odstąpienia od realizacji projektu w trakcie jego trwania.
4) Ustalić sposób realizacji projektu w metodyce agile (WYRAŹNIE W UMOWIE) i zastrzec za co odpowiada Wykonawca.
5) W interesie Wykonawcy – ustalić postanowienia umowne jak najbardziej zbliżone do umowy zlecenie – wymagającą od Wykonawcy jedynie należytej staranność.
6) Ustalić ryzyka dla powodzenia projektu lub zasady ich ustalenia w pierwszych etapach realizacji projektu.
7) Ustalić dokładnie, która ze stron odpowiada za tzw. wymagania techniczne konieczne do poprawnego działania oprogramowania.
8) Ustalić warunki odbioru i podstawy testowania oraz co strony rozumieją jako wady istotne oprogramowania uprawniające Zamawiającego do odmowy dokonania odbioru.
9) Wreszcie najprostsze, ale z jakiegoś względu zaniedbywane – potwierdzanie wszystkich ustaleń, ryzyk, założeń w formie umożliwiającej odczyt w przyszłości.

Czy bez prawnika (lub innego specjalisty od projektów innowacyjnych) mogło się udać?

Mogło… ale czy warto ryzykować?