Na co zwracać uwagę przy podpisywaniu umowy projektowej

Niejedną już umowę w swoim “wolnostrzelcowym” życiu podpisałem… i właściwie ani razu nie była ona taka jak być powinna. Co prawda za każdym razem następuje pewien postęp, jednak mimo to zawsze w praniu okazuje się, że jednak o czymś – ja lub Klient – nie pomyśleliśmy. Nie wynikało to bynajmniej z chęci jednej strony do oskubania drugiej strony, co raczej z braku doświadczenia lub zbyt nieformalnego podejścia do bardzo ważnych kwestii.

Postaram się tutaj zebrać garść porad wyniesionych zarówno z praktyki jak i rozmów z innymi “stronami umów wszelakich”. Będzie to dla mnie referencja na przyszłość, a mniemam że i Wam może się przydać. Nieraz dostawałem maile z pytaniami o kształt podpisywanych umów czy prośby o recenzje gotowych już dokumentów, więc zapotrzebowanie na takie informacje można zauważyć.

Jak zawsze liczę na komentarze, które niejednokrotnie większą mają wartość niż tekst przeze mnie przedstawiony. Może jakieś uzupełnienie, uwagi, dodatkowe porady?

A więc jadziem z dziadziem…

Dbałość o szczegóły

Pierwszą i najważniejszą zasadą, którą należy kierować się przy podpisywaniu umowy, jest dokładna analiza każdego punktu w niej zapisanego. Nie może mieć miejsca sytuacja, w której zgadzamy się na coś, czego nie rozumiemy w 100%. Albo z akceptacją czego mamy pewien wewnętrzny problem. Ważne: nie ma głupich pytań! Jest to za poważna sprawa, żeby ją sobie olać.

Może zdarzyć się, że klient nalega na szybkie podpisanie niechlujnej umowy i rozpoczęcie prac, bo “projekt jest bardzo pilny“. Bo “dogadamy się w trakcie“. Bo “przecież na pewno wszystko będzie OK“.

Pamiętajmy: KAŻDY projekt jest bardzo pilny – czy to znaczy że każda umowa ma być byle jaka? Nie ma czegoś takiego jak “się zobaczy“. Przed rozpoczęciem prac trzeba ustalić co dzieje się w sytuacji, gdy jednak wcale wszystko nie jest OK (jest to nie tylko możliwe, ale nawet dość prawdopodobne). Oczywiście możemy zostać odebrani jako formaliści, urzędasy i faszystowskie papierofile – ale to jest nieważne. To co nie jest zatwierdzone, wydrukowane i podpisane – nie ma żadnego znaczenia. Czy klientem ma być kumpel, kumpel kumpla, rodzina czy ktoś z ulicy – nie można dać się zbajerować

Oczywiście wszystko jest ładnie i cacy dopóki współpraca układa się po myśli obu stron. Żadne umowy nie są potrzebne jeśli obie strony są zadowolone. Ustne ustalenia, kilkulinijkowe maile, tu i ówdzie jakiś domysł – i gra muzyka. Ale w razie jakichkolwiek problemów zaczyna się robić nieciekawie. Gdy nagle jakiś trybik współpracy przestaje śmigać jak naoliwiony noworodek na szpitalnej podłodze to jedynym ratunkiem jest umowa. Jeżeli dana sytuacja została przewidziana i obgadana – to dalej jest ładnie i cacy, w końcu wszyscy się zgodzili na jakieś dalsze postępowanie. A jak nie? Jak nie, to wygrywa ta strona, która bardziej się do umowy przyłożyła i ma fajniejsze “ogólniki”. I zwykle nie jest to wykonawca, który bezmyślnie podpisał co dostał bo “przecież wszystko na pewno będzie OK”.

A na zarzuty typu “ale z ciebie trudny człowiek” czy “przecież umowa to tylko formalność” należy odpowiedzieć jasno: “to tak dla Twojego, jak i mojego dobra“. Koniec, kropka.

Szczegółowa specyfikacja

Jednym z najważniejszych elementów umowy jest opis tego, czego ona właściwie dotyczy. W przypadku nas, programistów, będzie to oczywiście specyfikacja systemu. Powiedzmy sobie od razu: jedna strona notatek w Wordzie NIE JEST wystarczającą specyfikacją, nawet jeśli mamy napisać tylko Sapera. Podobnie nierealnym oczekiwaniem potencjalnego klienta może być stworzenie “portalu o funkcjonalności takiej jak xxx.yyy.com”. Takie coś jest po prostu niepoważne.

Specyfikacja powinna być wystarczająca do podziału całego procesu implementacji na poszczególne zadania. Powinna zawierać dokładne wytyczne dla programisty. Im mniej wątpliwości i niedomówień – tym lepiej. I chodzi mi o naprawdę bardzo “niskopoziomowe” detale. Jaki format daty ma być zastosowany w systemie? Jeśli użytkownicy będą mogli wgrywać pliki na serwer – to jak dokładnie ma wyglądać ten proces? Jeśli jakieś prezentowane tabele mają być sortowane/filtrowane – to po których kolumnach? I, w przypadku aplikacji www, czy to sortowanie/filtrowanie ma być ajaxowe, czy jako postback? A jeśli portal ma zawierać edytor WYSIWYG – to który? Ma to być HTML, Markdown, czy może BBCode?

Wielokrotne zwracanie specyfikacji z pytaniami do klienta ma, oprócz utworzenia w efekcie porządnej referencji oczekiwanych funkcjonalności, także bardzo pożądany efekt uboczny. Dzięki takiemu procesowi Klient uświadamia sobie jak baaardzo wiele decyzji trzeba podjąć podczas prac nad jakimkolwiek systemem.

Zdaję sobie sprawę, że takie czepialstwo może Klienta zniechęcić, ale osobiście wolę mieć mniej Klientów – za to świadomych wagi ustaleń spisanych przed rozpoczęciem prac – niż więcej projektów z wymaganiami zmieniającymi się jak szkiełka w kalejdoskopie. Nakłada to także na mnie dodatkowe obowiązki – jeśli stawiam Klientowi pytanie i oczekuję odpowiedzi, to muszę również jasno sprecyzować konsekwencje takiego czy innego wyboru.

A co gdy usłyszymy “nie obchodzą mnie takie pierdoły – rób tak żeby było dobrze“? I faktycznie darujemy takie ustalenia? Może być… różnie. Najlepszym wyjściem dla nas, wykonawców, jest dodanie wówczas do umowy zapisu o takiej mniej więcej treści:

“W przypadku braku szczegółowych informacji w dostarczonej specyfikacji finalna decyzja o sposobie realizacji funkcjonalności należy do Wykonawcy”

Z jednej strony zwalnia to Klienta z konieczności podejmowania takich decyzji, a z drugiej – daje nam zapewnienie, że nie będziemy jednej funkcjonalności implementować kilka razy, aż wreszcie trafimy w jego gust.

Szczerze się przyznam, że nie mam pewności jak z prawnego punktu widzenia wygląda sytuacja, gdy umowa nie zawiera takiego zapisu, a Klient chce “to samo tylko inaczej”. Sam niedawno miałem bardzo podobnie – zgodnie ze specyfikacją umieściłem na stronie możliwość uploadu plików. Klientowi się to jednak nie spodobało – bo wymagało trzech kliknięć (browse -> OK -> upload), a on chciał jedno. Dostosowałem portal do nowych wymagań (i zajęło mi to dużo dłużej niż teoretycznie powinno), jednak do dziś nie wiem czy zrobiłem to tylko i wyłącznie z dobrej woli, czy dlatego że byłem do tego zobligowany umową. Z jednej strony – wymagania specyfikacji zostały zrealizowane przy pierwszej implementacji. Z drugiej strony – spotkałem się z opinią, że w przypadku niedospecyfikowanych wymagań to “Klient ma zawsze rację” i wykonawca musi tyle razy implementować to samo, aż uzyska pełną akceptację Klienta. Może ktoś z Was się orientuje jak to jest na 100%?

UI – szkice lub cała grafika

Świetnym dodatkiem do suchego dokumentu ze specyfikacją jest wizja wyglądu systemu. Z moich doświadczeń wynika, że zażądanie szkiców UI (wykonanych np w Balsamiq Mockups http://www.balsamiq.com/products/mockups) lub wspólne nad nimi popracowanie doskonale uświadamia Klientowi, że sam tak naprawdę nie wie czego chce. I że musi się nad tym porządnie zastanowić, nie marnując mojego czasu.

Jak ma wyglądać dane okno? Jakie prezentować funkcjonalności? Co ma się dziać po kliknięciu tego linka, a co po wciśnięciu tego przycisku? W jaki sposób użytkownik będzie nawigował pomiędzy ekranami? Gdzie widzę rozwijaną listę, a gdzie tabelkę? I tak dalej, i tak dalej…

A już w ogóle idealnie jest, gdy Klient przychodzi z gotową grafiką gotową do podpięcia pod nowy system. Ale miałem taką sytuację tylko raz, a i tak nie zdecydowałem się na realizację projektu, więc na podobne cuda liczyć raczej nie można.

Zakres obowiązków

Przed rozpoczęciem prac trzeba także dokładnie ustalić za co Klient płaci i czego ma prawo od wykonawcy wymagać. Ja osobiście nie zajmuję się tworzeniem grafiki, nie dłubię w CSSach i po prostu nie potrafię zrobić, że coś było “ładne”. Powoduje to pewne problemy i niektórzy potencjalni Klienci od razu rezygnują z moich usług po takim wstępie, jednak cóż… taka prawda.

Trzeba więc jasno określić kto zrobi grafikę, kto ją potnie, kto przygotuje CSSy, a kto oprogramuje to na serwerze i w javascript. Do tego najlepiej dopisać jakie przeglądarki mają być wspierane, łącznie z numerami wersji i systemem operacyjnym – nie ma to jak dowiedzieć się pod koniec projektu “a ja chcę żeby to działało też w IE7“.

Na etapie spisywania umowy trzeba także podjąć decyzję co będzie się działo z systemem po zakończeniu fazy implementacji. Czy wykonawca zapewnia hosting? Jeśli tak – to na jakich zasadach? A jeśli nie – to kto zajmuje się wdrożeniem? I gdzie to wdrożenie będzie miało miejsce? Kto odpowiada za poprawne działanie aplikacji już PO udanym wdrożeniu? Kto czyta logi i reaguje na sytuacje alarmowe – nawet te spowodowane problemami na samym hostingu, a nie aplikacji? Jeżeli wszystkie te obowiązki spoczywają na wykonawcy – to przez jaki czas od oddania projektu? I czy jest to zawarte w cenie, czy dodatkowo płatne? Jaki czas reakcji na “sytuację alarmową” taki opiekun jest w stanie zadeklarować?

Trzeba też zwracać uwagę na niewinnie wyglądające potworki, takie jak ten:

“Zleceniobiorca zobowiązuje się do uwzględnienia przy realizacji Zlecenia uwag Zleceniodawcy”

Tak, dostałem kiedyś takie coś do podpisu. Heloł! To po co wozimy się od miesiąca ze specyfikacją i dogadujemy szczegóły? Po to żeby jeden zapis w umowie pozwalał na wprowadzanie potem dowolnych zmian? Nie żebym od razu podejrzewał jakieś niecne zamiary, ale zbyt dużo miałem już różnych dziwnych sytuacji żeby nie zmodyfikować lekko tego punktu:

“Zleceniobiorca zobowiązuje się do uwzględnienia przy realizacji Zlecenia uwag Zleceniodawcy niesprzecznych z ustaloną specyfikacją”

I teraz jest git – mam pewność, że to co ustaliliśmy wcześniej nie zostanie wywrócone do góry nogami.

Można pokusić się również o zdefiniowanie w umowie obowiązków Klienta – bo i po tej stronie muszą nastąpić przecież jakieś akcje. A to testowanie, a to podjęcie jakichś decyzji, a to odpowiedź na maila… Dobrze jeśli wspólnie ustali się maksymalny czas reakcji na pytanie programisty, aby projekt nie stał w miejscu bo wykonawca czeka 2 tygodnie na odpowiedź na kluczowe pytanie. Samo takie ustalenie nie jest oczywiście wiele warte bez zdefiniowania scenariusza “a co się dzieje jeśli taka reakcja nie nastąpi w określonym czasie“.

Terminy

Szacowanie czasu pracy nie jest zadaniem łatwym – a w umowie jakieś daty trzeba przecież wpisać. Jako wykonawcy pamiętajmy, aby zostawić sobie jakiś “bufor bezpieczeństwa”. Należy również określić konsekwencje ponoszone przez programistę, jeśli nie dostarczy rozwiązania na czas. Zwykle będzie to pewnie jakaś kara finansowa w wysokości X% za każdy dzień/tydzień opóźnienia. Nie lekceważmy tego! Szczególnie jako freelancer/samodzielny programista nie wiemy przecież co stanie się w nadchodzących tygodniach/miesiącach. Co w razie choroby? System sam się nie napisze. A co jeśli złamiemy obie ręce i pół kręgosłupa i nie będziemy w stanie w ogóle dokończyć projektu? Ile będzie kosztowało odstąpienie od umowy, a ile oddanie projektu 3 miesiące później? Ewentualnie czy umowa zezwala na wzięcie sobie podwykonawców i kupienie u nich dokończenie zlecenia?

Przy okazji dat i terminów pamiętajmy, że zwykle nie tylko nas one obowiązują! Jeśli jakąś część systemu (jak wspomniane wcześniej CSSy czy grafikę) będzie robił inny wykonawca, to siłą rzeczy od jego pracy zależy czas trwania naszego zlecenia. Pewnego razu bezmyślnie podpisałem taki zapis:

“Termin wykonania przedmiotu umowy zostanie wydłużony w przypadku opóźnienia prac podwykonawców zatrudnionych bezpośrednio przez Zamawiającego”

Czym to skutkowało? Grafika zaczęła powstawać na tydzień przed teoretycznym końcem moich prac – i grafik się wcaaale nie spieszył. A człowiek od CSS do tej pory nie był nawet jeszcze znaleziony. Całość przesunęła się w czasie dość znacznie, między innymi właśnie z tego powodu. Czy mogłem mieć pretensje do Klienta, że terminowe zakończenie projektu jest po prostu niemożliwe? Tak – ale tylko czysto “osobiste”, w końcu sytuacja taka była opisana w umowie. Do kogo zatem jeszcze mogłem mieć pretensje? Do siebie, że nie dodałem do umowy jakichś dat zobowiązujących Klienta do dostarczenia mi wszystkich potrzebnych materiałów (w tym grafiki i CSS) we wcześniejszym terminie. Nie ma znaczenia fakt, że ustnie mniej więcej wszystko rozplanowaliśmy i dogadaliśmy oczekiwane daty oddania kolejnych etapów i “sklejania” pracy mojej z innymi wykonawcami. Tak jak napisałem wyżej: to co nie jest zatwierdzone, wydrukowane i podpisane – nie ma żadnego znaczenia.

Płatności

To właściwie tak standardowy element umowy, że nie ma nawet za bardzo o czym gadać. Ile kasy dostajemy za wykonanie projektu i w jakich ratach? Ile zaliczki? Na jakie porcje zostanie podzielone całe wynagrodzenie, kiedy wypłacane i od czego ewentualna wypłata będzie zależeć?

Ile będziemy musieli zapłacić w razie rezygnacji z projektu? A ile będzie musiał zapłacić klient, jeśli w trakcie się jednak rozmyśli? Jakie poniesie konsekwencje, jeśli będzie spóźniał się z płatnościami?

Należy pamiętać również o zawarciu informacji o tym, co właściwie obejmuje zamieszczona w umowie kwota. Czy to tylko nasza praca, czy także koszty przyszłego hostingu, bazy danych, domeny? Może się wydawać oczywiste i “rozumiejące się samo przez się”, że wycena nie obejmuje takich elementów, jednak naprawdę warto precyzyjnie ustalić i wrzucić do umowy wszystko co może w przyszłości budzić jakiekolwiek wątpliwości. To co dla nas jest oczywiste, wcale nie musi takie być dla pana który ma pieniądze i chce uruchomić portal, nie mając pojęcia o naszej pracy.

Ciekawostka: w jednej z umów miałem taki punkt:

“Umowa może być wypowiedziana przez Zleceniobiorcę ze skutkiem natychmiastowym, jeżeli Zleceniodawca pomimo wykonania zgodnie z Umową (…) opóźnia się z płatnością o co najmniej 14 dni kalendarzowych(…)”

Moja luźna interpretacja: ja robię projekt i oddaję go. Projekt działa. Klient nie płaci. Wszystko jest ok, bo po 14 dniach mogę sobie rozwiązać umowę. Czy jest tu jakiś sens? Dodawać chyba nie muszę, że na moje stanowcze żądanie ten punkt został zastąpiony przez coś mniej absurdalnego.

Gwarancja

Dobrym zwyczajem (a często właściwie koniecznością) jest udzielanie gwarancji na wytworzone oprogramowanie. Wiadomo – środowisko programistyczne nie jest tożsame ze środowiskiem produkcyjnym. To samo środowisko testowe – nawet jak klient i jego testerzy poklikają po aplikacji działającej w warunkach produkcyjnych, to nie ma gwarancji że wszystko raptem nie padnie pod obciążeniem prawdziwych userów. Ktoś musi wtedy zareagować.

Bardzo ważnym elementem gwarancji jest jasne określenie co ona obejmuje – żebyśmy nagle nie obudzili się miesiąc po wdrożeniu systemu, przesuwając guziczki w interfejsie i zmieniając tło na stronie, bo “jednak jest brzydkie”. Gwarancja powinna obejmować poprawki błędów technicznych… a te oczywiście na 90% się pojawią. I należy to wyraźnie wpisać do warunków gwarancji. Trzeba również ustalić ile czasu taka gwarancja trwa – i kiedy się rozpoczyna oraz kiedy kończy.

Nie jest również dobrze zapomnieć o dość logicznym zapisie mówiącym, że gwarancja wygasa w momencie modyfikacji kodu systemu przez osoby trzecie. Powinien być “oczywistą oczywistością” fakt, że nie bierzemy na siebie odpowiedzialności za cudze grzebanie w naszym kodzie, jednak mimo wszystko, jak zwykle: lepiej mieć w umowie i spać spokojnie, niż się nadziać na brak takiego zapisu gdy będzie naprawdę potrzebny.

O gwarancji (nawet z przykładowym tekstem jaki dołączyłem kiedyś do umowy) pisałem już ponad rok temu w poście “Odpowiedzialność za oddany projekt“, więc zainteresowanych zapraszam także tam.

Podsumowanie

Cały ten tekst nie ma być pokazaniem “ale ci klienci są źli i tylko czyhają na nieświadomych programistów, żeby założyć im chomąto i orać nimi pole!“. Ma być raczej zwróceniem uwagi na kwestie, które jednym nie przyszłyby do głowy, a innym wydają się tak oczywiste, że niewarte wzmianki przy rozmawianiu o projekcie. Gruntowne obgadanie jak największej liczby kwestii i potencjalnych problemów przed rozpoczęciem realizacji systemu pozwala na zbudowanie podstaw pod udaną współpracę, prowadzącą w konsekwencji do sukcesu projektu. Sam znajdowałem się w sytuacjach zarówno dobrych (w ogromnej większości) jak i złych (niestety). Również od znajomych słyszałem opowieści, w których nieumiejętnie skonstruowana umowa prowadziła do wypłacania kilkudziesięcio- i kilkusettysięcznych kar/odszkodowań, pomimo dobrych początkowych intencji z obu stron. Dla wielkiej korporacji to pryszcz – ale dla freelancera czy niewielkiej programistycznej firemki może być zardzewiałym, zakażonym hivem gwoździem do trumny. A po co, skoro można było tego uniknąć?

Tak więc – nie wstydźmy się być dociekliwymi w tym aspekcie i drążyć tematu aż wszystko będzie jasne i odpowiadające dla każdej ze stron. Lepiej to, niż boleśnie się przejechać.

Kilka złotych myśli na koniec:

• to co nie jest zatwierdzone, wydrukowane i podpisane – nie ma żadnego znaczenia
• lepiej nie wziąć projektu niż narazić się na straty z powodu złej umowy
• szczegółowa i porządna umowa jest dobra zarówno dla wykonawcy, jak i klienta
• dla “dużych” projektów (dla jednego 50tys, dla innego 500tys) warto zainwestować w prawnika
• implementacja systemu informatycznego to nie jest jednostronna transakcja, tylko współpraca klienta i wykonawcy