freelancer i umowa, czyli jak nie zwariowac

zabierajac sie za robienie stron, umowa jest podstawowa rzecza od ktorej powinno sie zaczynac prace. nie ma umowy - nie ma pracy. koniec i kropka. poczatkujace osoby lubia wierzyc na slowo i np. wykonac polowe serwisu bez umowy, ale takie postepowanie w koncu sie zemsci, a jedyna stratna na tym osoba bedzie programista. dlatego warto sie zastanowic co tak na prawde powinno byc w umowie aby on tez byl zabezpieczony w razie konfliktu.

0) wszystko musi byc ustalane na pismie, mozna w to wliczyc email. nie mam emaila z informacja o czyms - nie bede tego robil. na wszelki wypadek, klient nie powie pozniej, ze czegos nie chcial, albo chcial inaczej.

1) umowa zawsze powinna miec zakres prac oraz specyfikacje dokladnie wyjasniajaca (strona po stronie) funkcjonalnosc wszystkich elementow strony. bez tego mozna ocenic strone na xx godzn pracy, a w trakcie zorientujemy sie, ze na polowie podstron wymagane sa fikusne animacje js plus zaleznosci miedzy obiektami w bazie maja byc znacznie bardziej skomplikowane niz poczatkowo deklarowano i... jestesmy yyy godzin pracy  (i zzz PLN) w plecy - bo miesci sie to w zakresie umowy i ogolnych ustaleniach, ale nie bralismy tego pod uwage przy wycenie.

2) specyfikacja to jedno, ale wazne jest jasne postawienie sprawy: specyfikacja zawiera podstawowa funkcjonalnosc i to programista okresla co to znaczy 'podstawowa funkcjonalnosc'. czyli nikt nam nie wcisnie finezyjnego prezentowania wynikow wyszukiwania na stron, gdzie animowany renifer przeskakuje przy stronicowaniu. w umowie bylo 'wyszukiwanie i stronicowanie' i to ja okreslam co to znaczy (chyba, ze w specyfikacji jest uwzgledniony renifer)

i chyba tyle jesli chodzi o to aby nie dac sie zrobic w bambuko i nie pracowac 50% wiecej za ta sama kase. pozostale punkty sa juz tylko emanacja rownouprawnienia w umowie.

3) akceptacja dziela. czesto wymagana do zaplaty. warto dac zapis, ze musi byc on np. w przeciagu 7 dni od daty przekazania dziela, po tym terminie dzielo uznaje sie za zaakceptowane. inaczej mozemy sporo czekac az laskawie nam panujacy klient przeleje pieniadze.

4) termin oddania. czesto jest zwiazany z karami za opoznienia. ok, ale co z karami za brak wynagrodzenia? czyli np. wynagrodzenie jest platne w przeciagu 14 dni od daty akceptacji. kazdy dzien spoznienia wiaze sie kara umowna xxx - gdzie xxx to kara adekwatna do spoznienia z terminem oddania dziela

5) konsultacje. jesli nie ma kwoty za dzielo, a np. kwota za godzine pracy nad strona, to zawsze musi tam byc informacja, ze w ramach pracy nad strona rozumiane sa rowniez wszelkie konsultacje w tej sprawie. konsultacja rowna sie niemal zawsze przekazaniu wiedzy, a od kiedy to jest darmowe? (ok, sa instytucje  pro publico bono, prawnicy tez maja czasami darnowe porady... ale nie kazdy musi)

6) klient ma strone, a jeszcze nie zaplacil. zamiast siedziec i plakac warto dac w umowie podpunkt informujacy, iz do czasu pelnego rozliczenia dziela prawa autorskie i wszystkie inne naleza do wykonawcy, zamawiajacy nie ma prawa dysponowac dzielem bez zgody wykonawcy. do czasu wyplaty pelnego wynagrodzenia wykonawca ma prawo usunac wczesniej przekazane dzielo w stanie w jakim ono jest w dniu skasowania. do czasu zaplaty pelnego wynagrodzenia zamawiajacy nie ma prawa do samodzielnego dysponowania dzielem oraz na zadanie powinien w terminie 24h dzielo usunac z serwera, tak aby nie bylo ono dostepne w internecie. tak na wszelki wypadek jak by zmienili hasla na ftp.

wiem, temat rzeka. mozna sie zastanawiac po co to miec, po sadach sie ciagac potem? nigdy nie wiadomo. lepiej nosic niz sie prosic - lepiej miec, niz potem zalowac. to jest kilka podpunktow w umowie dajacych oparcie prawne przed podpisaniem umowy oraz w razie problemow wieksze szanse pomyslnego jej zakonczenia. dzieki nim mamy prawo (a nie tylko mozliwosc, co jest istotna roznica) skasowania klientowi strony jesli nie chce placic. mozemy smialo mowic, ze reniferka nie bylo w umowie i jak chce go miec to musi doplacic. a w razie ciagania sie po sadach mozemy spokojnym krokiem wejsc na sale rozpraw ;)

oczywiscie sa to tylko luzne uwagi, a nie gotowe do wstawienia paragrafy. uwagi majace na celu li tylko pokazanie potencjalnych problemow jakie moga sie pojawic oraz jak moze wygladac przykladowe ich unikniecie poprzez odpowiedni zapis w umowie. to, ze umowy nalezy czytac ze zrozumieniem jest chyba oczywiste. inaczej moze sie okazac, ze zrobilismy komus strone za free :)

EDIT
kilka pomyslow jeszcze mam, zamieszcze tez ten z komentarza.

7) minimalne wymagania serwera. musza byc w umowie, kazdy framework je ma, a serwer musi je spelniac. oczywista oczywistosc.

8) nowa wersja strony. jesli robimy nowa wersje strony, tzn. ze istnieje stara, sa dane w bazie itd. wtedy przed wycena konieczne jest uzyskanie dostepu do ftp oraz bazy danych w celu analizy istniejacych rozwiazac. na przyklad czy trzeba baze danych przepisac na nowo, czy tez istniejaca struktura jest ok.

9) zwrot kosztow. jesli w umowie jest jakis zapis o tym, ze w razie jakiejs wpadki musimy zwrocic zleceniodawcy wszelkie poniesione przez niego koszta (czyli np. nasze wynagrodzenie) to brakuje tam jednego zdania: co rowniez wiaze sie ze zwrotem dziela wykonawcy. skoro cos poszlo nie tak i jest zle, musimy oddac kase, moze jeszcze jakas kara bedzie, to dlaczego zleceniodawca ma dostac gratis owoc naszej ciezkiej pracy? sam fakt zwrotu kosztow oraz bonus w postaci kary umownej powinien byc dla niego wystarczajacy.

10) dobra praktyka: tam gdzie sie da, strony trozymy na wlasnym serwerze, dopiero na sam koniec przegrywamy gotowy produkt do klienta. wtedy jest prosta zasada: nie ma pieniedzy, nie ma strony.

i na koniec - wiadomo, to sa umowy. kto nie przeczyta dokladnie, ten bedzie stratny. wiadomo, ze klient nawet jesli sie nie zna, a tym bardziej jesli sie zna, to bedzie w umowie dbal o swoje interesy. wiec kazda umowe nalezy czytac i dbac o swoje. proponowane zmiany sa to tak na prawde wpisy dajace programiscie prawa do terminowej zaplaty, pokrycia kosztow zmian w projekcie czy tez dajace podstawy do uznania, ze strona jest zrobiona jesli spelnia wymagania ze specyfikacji, bez koniecznosci czekania miesiac czy dwa na klienta, az on ja 'klepnie'. wszystko jest dla ludzi, umowy tym bardziej. na koniec moze moral: trzeba tak pracowac i wspolpracowac, aby nie trzeba bylo sie umowami przejmowac. czego wszyskim zycze :)

EDIT2
11) walidacja. wiadomo jak jest. strony pod jednymi przegladarkami dzialaja poprawnie, pod innymi nie. wygodnie jest miec zapis np. o uznaniu poprawnosci wyswietlania stworzonej strony www w przegladarkach internetowych decyduje poprawna walidacja wc3 pozwalajaca okreslic czy strona jest zgodna z ogolnie przyjetymi standardami. wyjatek stanowic moga specyficzne skrypty niezbedne do poprawnego dzialania tworzonej strony www.