Umowa projektu IT – co powinien zawierać wzór?
W dzisiejszym wpisie chcę podzielić się z Tobą doświadczeniami we współpracy z klientami nad projektami IT. Dam wskazówki na temat tego jak zabezpieczyć się umową przed nieetycznym zachowaniem klienta.
Podzielę się z Tobą przemyśleniami zarówno z perspektywy firmy wykonującej projekty, jak i perspektywy firmy zlecającej projekt.
Przeszedłem w swojej karierze przez kilka większych i mniejszych „rewelacji” z klientami, dzięki temu udało mi się wypracować wzór bezpiecznej umowy na wykonanie projektu IT.
Słyszałem wielokrotnie od znajomych, że „działamy z wieloma rzeczami na gębę z klientem bo sobie ufamy”. Uwierz mi, że przy pierwszym „konflikcie” zmienisz swoje nastawienie do ustaleń „na gębę”.
Musisz pamiętać, że umowę podpisuje się na złe czasy.
W tym wpisie pominę rzeczy oczywiste, które powinna zawierać umowa. Skupię się na „smaczkach” i różnych dziwnych sytuacjach z klientami, przez które przeszedłem.
Mam nadzieję, że uda Ci się uniknąć kilku siwych włosów stosując wskazówki z tego wpisu.
Klient wstrzymuje prace przez brak odpowiedzi
O zgrozo. Wielokrotnie zdarzało mi się, dostawać naciski od klienta aby prace były rozpoczęte jak najszybciej. W momencie podpisania umowy kiedy ruszyły prace mieliśmy wiele pytań o detale.
Właśnie w tym momencie klient milczał. Przez kilka tygodni, nie potrafił zdecydować się na odpowiedź na nasze pytania. Było to o tyle problematyczne, że przez niezdecydowanie klienta prace stały w miejscu, a czas zbliżał się do terminu wpisanego w umowę. Byliśmy „w szachu”. Żeby było śmieszniej to klient wysyłał e-maile przypominające o terminie ukończenia projektu… ale nie mógł się zdecydować jak finalnie ma wyglądać.
Warto jest wpisać w umowę zapis, który mówi o tym, że zarówno klient jak i wykonawca mają określoną liczbę dni na odpowiedź. Wtedy w przypadku „konfliktu” można jednoznacznie wskazać kto zalegał z dostarczeniem informacji.
Oczywiście jakość odpowiedzi jest niezwykle ważna, ale ciężko to określić w umowie.
Klient nie chce odebrać projektu – auto akceptacja protokołu odbioru
Zdarzały mi się sytuację, że wykonaliśmy projekt według specyfikacji i nie mogliśmy wystawić faktury za wykonane prace bo nie mieliśmy podpisanego protokołu odbioru projektu przez klienta.
Problemy z niepłaceniem faktur w Polsce to nie rzadkość. Często zdarza się, że klient wstrzymuje wystawienie faktury tak długo jak to możliwe przez brak odbioru prac. Robi tak bo nie ma określonego czasu w jakim ma te prace odebrać.
Warto wpisać w umowę, że brak zgłoszonych uwag od klienta do projektu przez X dni powoduje automatyczną akceptację projektu, gdzie możemy wystawić jednostronnie podpisany protokół odbioru, a kolejnie fakturę.
Klient ciągle zgłasza nowe rzeczy – Never Ending Project
Wiele software houseów, freelancerów, którzy zaczynają pracę z klientami uważają, że ciągłe dosyłanie nowych rzeczy do zrobienia bez podnoszenia ceny to standard i tkwią w tym.
To nie jest standardem – to patologia. Wielokrotnie pisałem i mówiłem o tym jak wyceniać projekty IT, próba dołożenia dodatkowej pracy powinna kończyć się podniesieniem ceny. Wykonawca powinien móc chociaż zdecydować czy chce podjąć się dodatkowego zakresu.
Bo często niestety jest tak, że klient rozpoczyna koncert życzeń z nowymi funkcjami do projektu, przez co nie możemy ukończyć pierwotnie ustalonego zakresu… co skutkuje tym, że nie możemy projektu zamknąć ani rozliczyć.
Dlatego kluczowe jest pisanie specyfikacji pod projekt. Jeśli brakuje Ci umiejętności z pisania dokumentacji projektowej sprawdź kurs Dokumentacja.Pro.
Kluczowe jest (jeśli pracujecie Fixed Price) żeby wpisać w umowę, że zakres projektu jest określony w dokumentacji, która jest załącznikiem do umowy.
Bez dokumentacji bardzo trudno określić jest czy rzeczy, które podsyła klient są czymś nowym (change request) czy pierwotnym zakresem prac. Problem tworzenia dokumentacji przed podpisaniem umowy o realizację projektu wyjaśniłem w tym wideo: Wycena Projektu A – Z.
Pamiętaj aby określić w umowie proces w jaki sposób podejmujecie się realizacji dodatkowego zakresu. Chodzi o coś takiego:
- Tworzenie specyfikacji pod zmiany w zakresie;
- Akceptacja opisu i dodatkowych kosztów przez klienta;
- Ustalenie harmonogramu z klientem;
- Plan realizacji i wdrożenia.
Ważne jest, aby ustalić kiedy wprowadzicie dane zmiany w zakresie – jeśli będziecie nad nimi pracować „od razu”, pewnie trzeba przesunąć termin ukończenia projektu (bo rozciągnie się zakres). Możliwe jest również wprowadzenie zmian zakresu po ukończeniu pierwotnego zakresu. Pamiętaj aby określić to w umowie.
Błędy, które nie są błędami
Klient przed odebraniem projektu będzie sprawdzał, czy został wykonany zgodnie z założeniami. Nie ma w tym nic dziwnego – wspominałem kilka akapitów wcześniej o protokole odbioru.
Problem ze zgłaszaniem uwag był taki, że często klienci starają się w etapie testów przemycić zmianę zakresu.
Oprócz oficjalnego zgłoszenia zmiany zakresu (Change Request – opisane w poprzednim punkcie), warto dać zapis w umowie, że naprawicie wyłącznie błędy i nieprawidłowości w działaniu. Czyli to na co się wcześniej umówiliście. Wszystko poza błędami w pierwotnym zakresie będzie traktowane jako zmiana w zakresie.
Tutaj bez dobrej dokumentacji się nie obędzie, bo w przypadku niejednoznacznego opisu nie będziecie w stanie stwierdzić czy to bug czy feature.
Ułatw sobie pracę – unikaj placeholderów
W zależności o co chodzi w Twoim projekcie, możesz ułatwić sobie pracę określając w umowie terminy podesłania przez klienta etykiet i tekstów w aplikacji.
U nas w jednym projekcie wstawialiśmy placeholdery (lorep ipsum itp), później ze względu na specyfikę projektu podmiana wszystkich tesktów i dostosowań formatowania zajęła nam dodatkowe 5% czasu projektowego.
5% wydaje się niedużo, ale jeśli można to zredukować to warto.
Sprawdź jak mogę Ci pomóc osiągnąć Twoje cele 🎯
Zaliczka i wynagrodzenie
Jeśli pracujecie etapowo nad projektem. Tzn. najpierw realizujecie pierwszy etap i go rozliczacie, później drugi… później trzeci.
To polecam Ci dodać zapisek w umowie, że nieopłacenie faktury za poprzedni etap wstrzymuje następny. W praktyce dobrze jest być zabezpieczonym przed tym aby według umowy nie były liczone dni opóźnienia (kolejny etap), który nie został opłacony przez klienta.
Ja zawsze w podejściu etapowym naciskam na to aby prace nad kolejnym etapem rozpoczęły się w momencie zamknięcia i rozliczenia poprzedniego. Jest to dodatkowa motywacja dla klienta do płacenia w terminie i nie zwlekania z odebraniem projektu.
Serwer, architektura – kto kupuje, kto utrzymuje?
Ja osobiście z tą kwestią nie miałem problemów, ale postanowiłem wpisać ten punkt po rozmowie z moim kolegą freelancerem, który naciął się na to, że w umowie nie było wpisane kto ma kupić i utrzymywać serwer.
Klient myślał, że aplikacja będzie hostowana na serwerze freelancera, on z kolei, że na serwerze klienta. Później wyniknęło sporo konfliktów gdy klient zrozumiał, że opłata za serwer jest cykliczna.
Dlatego warto takie kwestie umieścić w umowie żeby była 100% jasność kto za co płaci i odpowiada.
Termin wykonywania projektu
Ten akapit piszę z perspektywy zlecającego pracę zewnętrznej firmie. Warto określić, w jakich terminach wykonawca będzie pracował nad projektem – np. poniedziałek – piątek, 8-16.
Dawno temu naciąłem się na to, że wykonawca zadeklarował mi dni jakie potrzebuje do ukończenia projektu. W momencie gdy termin minął zaczął się tłumaczyć, że liczba dni jeszcze nie minęła, bo on w piątki nie pracuje.
Oczywiście nie miałem pojęcia o niestandardowym systemie pracy wykonawcy – dlatego zawsze warto wpisać tę informację aby nie być zaskoczonym.
Prawa autorskie i majątkowe
Często gdy podsyłałem umowę do weryfikacji prawnikowi – dostawałem feedback, że prawa autorskie nie są poprawnie zdefiniowane. Musiliśmy wprowadzać korekty zapisów w umowach klientów.
Często spotyka się ogólny zapis, że wykonawca przekazuje prawa autorskie i majątkowe zleceniodawcy, ale w praktyce często jest to wpisane zbyt lakonicznie i mało precyzyjnie.
Polecam Ci rzucić okiem na ten wzór umowy – tam przekazanie praw autorskich i majątkowych jest poprawnie zapisane.
Używasz bibliotek open source – wpisz to w umowę
Ważne jest (ma to związek z prawami autorskimi i majątkowymi), aby wysłać listę rozwiązań open source, których używamy w projekcie.
Takimi rozwiązaniami mogą być różnego rodzaju frameworki, biblioteki itp. Warto dać zapis o tym, że projekt będzie z takich rozwiązań korzystał, a listę prześlemy użytych bibliotek prześlemy przed podpisaniem protokołu odbioru.
Rękojmia i górna granica odpowiedzialności kontraktowej
W zależności jako kto podpisujesz umowę – czy jako DG, czy jako Sp. z o. o. kwestia odpowiedzialności wygląda inaczej.
Ja jestem wielkim zwolennikiem, aby wpisać górną granicę z tytułu rękojmi + określić górną granicę odpowiedzialności kontraktowej.
Z opowiadań prawników wiem, że nawet jeśli wpiszemy górną granicę roszczeń – w sądzie może być ten zapis nieuwzględniony.
Mimo wszystko czuję się bezpieczniej wpisując tę kwestię w umowę.
Zakaz konkurencji – podbieranie programistów
Warto wpisać do umowy kwestię związaną z zakazem konkurencji.
Wykonawca powinien zadeklarować się, że nie wykona podobnego projektu jak ten, który zlecił mu klient.
Klient powinien zadeklarować się, że nie będzie „podbierał” programistów wykonawcy, którzy pracowali nad projektem.
Często programiści zgłaszali mi, że przychodził do nich klient (nieoficjalnie) i proponował współpracę. Warto się przed takimi sytuacjami zabezpieczyć, żeby nie stracić cennych specjalistów.
Podsumowanie
Jak widzisz „smaczków” podczas współpracy może być wiele. Niektóre wynikają z braku etyki klienta, inne z niewiedzy.
Przez niewiedzę mam na myśli klątwę wiedzy – część rzeczy wydaje się dla nas tak oczywistych, że nie wspominamy o tym „bo to oczywiste”. Jednak dla osób z poza branży IT nie jest to oczywiste. Powoduje to często konflikty.
Musisz pamiętać, że warto precyzyjnie określić umowę nawet jeśli macie bardzo przyjacielskie relacje z klientem. Umowę podpisuje się na złe czasy.
Warto zabezpieczyć się kwestiami, które opisałem powyżej – w przypadku gdy będziesz chciał pójść klientowi na rękę, możesz nie skorzystać z zapisu.
Przeszedłem wiele umów projektowych, które dopracowywałem z prawnikami. Dzięki temu udało mi się opracować wzór bezpiecznej umowy na wykonanie projektu IT, od którego zawsze zaczynam.
Zachęcam Cię do zapoznania się moim wzorem.
Dziękuję, że przeczytałeś ❤️
Pssst... przygotowałem dla Ciebie kilka prezentów - wybierz co Ci się przyda! 👍
