Na co zwracać uwagę przy podpisywaniu umowy projektowej

15

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
Share.

About Author

Programista, trener, prelegent, pasjonat, blogger. Autor podcasta programistycznego: DevTalk.pl. Jeden z liderów Białostockiej Grupy .NET i współorganizator konferencji Programistok. Od 2008 Microsoft MVP w kategorii .NET. Więcej informacji znajdziesz na stronie O autorze. Napisz do mnie ze strony Kontakt. Dodatkowo: Twitter, Facebook, YouTube.

15 Comments

  1. Dodałbym od siebie coś, o czym krótko wspominasz a co dla każdej (nie tylko w świecie IT) umowy jest kluczowe. Jeżeli zawieramy w umowie jakiekolwiek ustalenie "CO", to razem z nim _musi_ być gdzieś zapisane "DO KIEDY" i "CO, JAK NIE".
    Czyli sformułowanie "strona X zobowiązuje się do Y" będzie w praktyce kulawe, dopóki gdzieś nie zostanie zapisana data i co ma się wydarzyć, jeżeli to Y jednak nie zostanie zrobione mimo zobowiązania.
    Ot tak na wszelki wypadek.

  2. gt,
    W szkicu posta miałem nawet specjalną sekcję "CO JEŚLI oraz CO JEŚLI NIE", ale doszedłem do wniosku że "niejawnie" wystarczająco to podkreślam w pozostałych akapitach – dzięki za podkreślenie jawne:).

  3. Makaryczny_Boo on

    "dla "dużych" projektów (dla jednego 50tys, dla innego 500tys) warto zainwestować w prawnika"
    Nie bardzo rozumiem, co masz na myśli w tych nawiasach? Czy mógłbyś to jaśniej wytłumaczyć?

  4. Makaryczny_Boo,
    Chodzi o to, że dla każdego pojęcie "duży projekt" może znaczyć coś innego. Dla jednego freelancera warto rozważyć konsultację u prawnika jeśli mówimy o kwocie 50k, dla innego – 3k, a dla firmy – 100k czy 500k. Widocznie średnio mi się udało ująć to w treści posta:).

  5. "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(…)"

    Rozumiem celowość takiego zapisu przy realizacji projektu i wypłatach za realizacje kolejnych kroków. Możemy jako wykonawca śmiało zerwać umowę już na początku, jak klient nie zapłaci za pierwszą fazę. Nie możemy powiedzieć, że w takim razie nie robimy i wydłużamy termin realizacji, chyba, że właśnie to zawrzemy w umowie(coś w stylu "Czas realizacji projektu zostanie wydłużony o czas zwłoki klienta z wypłatami za kolejne fazy projektu").

    Moje pytanie jak zmieniłeś ten zapis w swojej umowie ?

  6. frymi,
    Zerwanie umowy po pierwszej fazie… no dobra, ale w końcu ktoś za tą pierwszą fazę chyba musi zapłacić? Taki zapis moim zdaniem nie ma racji bytu w żadnym przypadku. Czy mi ktoś nie zapłacił za jedną fazę (np miesiąc) czy za cały projekt (np pół roku) – jaka to różnica? Rozejście się nie jest w tym momencie wyjściem z sytuacji.
    Nie zmieniłem tego zapisu w ogóle – poprosiłem o jego całkowite usunięcie.

  7. Świetny wpis!
    Jeśli chodzi o fragment "Klient chce "to samo tylko inaczej"", to w firmie w której pracuję określa to specyfikacja wymagań funkcjonalnych (opisane jest co i jak ma działać), wybór sposobu realizacji należy do programisty. Jeśli coś przejdzie przez testy wewnętrzne (gdzie czasem wyłapywane są dziwne pomysły programistów), to idzie bezpośrednio do klienta, wszelkie dodatkowe zmiany płatne ekstra.
    _______
    Tomek

  8. Teres,
    Czyli w konkretnym przypadku który opisałem (z uploadem plików) Wasza praktyka wygląda tak:
    * robimy upload jak uważamy (czyli prawdopodobnie: najprościej jak się da, tak jak i ja zrobiłem za pierwszym podejściem)
    * odsyłamy do klienta
    * klientowi się nie podoba (pomimo że nie było w specyfikacji szczegółów)
    * klient albo akceptuje mimo że się nie podoba, albo płaci dodatkowo za zrobienie tego tak jak sobie wymyślił (tutaj: upload przez "jedno kliknięcie")

    Tak? Jesli tak to czy macie to w umowie jakos zawarte?

  9. Procent,
    tak, dokładnie tak to wygląda. W umowie (opis wymagań) mamy najczęściej opisane co i jak ma działać. Jeśli działa tak jak jest to opisane, to klient płaci za ew. zmiany. Często w geście dobrej woli udzielamy dużych rabatów na zmiany (jeśli nie są zbytnio pracochłonne).
    Klient widzi co podpisuje i ma możliwość dokładnego sprecyzowania co i jak ma działać (tylko prawie żaden tego nie robi).

  10. Bardzo dobry wpis. Mam kilka uwag:
    -dobrze jest uwzględniać docelowe "obciążenie" systemu. Np. z systemu będzie korzystać jednocześnie X userów, postów będzie do 200k, etc. Często determinuje to sposób rozwiązania danej funkcjonalności ("ok, postów będzie docelowo nie więcej niż 10k to robię to tak, ale jeżeli ma być ich 10mln to trzeba zrobić to inaczej").
    -w kwestii niedospecyfikowanych funkcjonalności: najlepszym moim zdaniem rozwiązaniem jest aby wykonawca w momencie w którym napotyka na funkcjonalność, która jest niedospecyfikowana, przed implementacają, proponował klientowi swoje rozwiązanie (najlepiej takie które nie naraża budżetu), klient akceptuje? super. Chce inaczej – piszecie CR’a. Oczywiście na wszystko dobrze mieć kwity.

  11. Zaraz po studiach I stopnia wrąbałem się właśnie w takie zlecenie/umowę, która nie precyzowała szczegółowych wymagań co do formatek (były to z grubsza opisy). Skutkiem czego były ciągłe modyfikacje już zaimplementowanych elementów. Finalnie wydaje mi się, że ta umowa mogła trwać w nieskończoność, a honorarium przecież ciągle takie same. Na szczęście udało mi się "uciec";)
    Dlatego też osobiście nie bardzo chcę być freelancerem. Chyba wolę pracować dla kogoś, a tym samym nie brać całej odpowiedzialności na swoje barki. Na pewno jeszcze nie teraz;)

  12. Łukasz,
    No niestety, "with great power" (teoretyczna dowolność wyboru klientów i zleceń) "comes great responsibility" (jak czegoś nie dopilnujesz to sam siedzisz po nocach – nie możesz powiedzieć "nie"). Jest to pułapka w którą sam wpadłem, no ale cóż…

  13. Napisanie dobrej umowy jest możliwe tylko z uwzględnieniem prawników, bez tego ani rusz. Zawsze znajdzie się coś co może nas zaskoczyć a w takim wypadku można sporo stracić. Fajny i ciekawy artykuł. Pozdrawiam

Newsletter: devstyle weekly!
Dołącz do 1000 programistów!
  Zero spamu. Tylko ciekawe treści.
Dzięki za zaufanie!
Do przeczytania w najbliższy piątek!
Niech DEV będzie z Tobą!