Nerdblog.pl - Pięć faz nieudanego zlecenia

Ło, ale Ci się udało ;)

Ogólnie dobrą metodą jest umówienie się naprawdę konkretnie. I jakaś umowe wstępna, na piśmie to dostać, poświęcić nawet i dzień na dowiedzenie się, o co komuś chodzi.

Znam ja to, nagle trzeba coś poprawić, bo jednak "chcę inaczej" albo własnie "nie tak sobie to wyobrażałem". Na takie zdania jest jedna odpowiedź: kasa++. I dobre zabezpieczenie w umowie: zamrażamy co jest do zrobienia i już.

Caladan - niestety robię to przez 'pośrednika', więc nie da rady. Chociaż chyba zacznę wymagać wglądu w treść umowy.

Dokładnie. Na problemy "deadline jest zagrożony, bo klient zaczął dorzucać kolejne rzeczy do zrobienia" rozwiązanie jest jedno -- obie strony podpisują dokładną specyfikację produktu przed napisaniem pierwszej linii kodu. Nie wszyscy tak robią, bo analiza i spisanie tego wszystkiego też kosztuje.

Ale potem rosną też wymagane godziny pracy, a już za nerwy na pewno nikt nie zapłaci ;]

A, ale teraz śledzisz związek przyczynowo-skutkowy. Wielu "ludzi biznesu" tego nie robi. Klientowi się spieszy? No to przecież nie będziemy marnować tygodnia na rozmawianie z nim i analizowanie jego potrzeb. Spisze się umowę żeby zaklepać zlecenie, a "detale" się jakoś w trakcie ustali ;)

Przechodziłem ostatnio przez pierwsze moje (prawie) na serio zlecenie i niestety rzeczywistość była bardzo brutalna ;). Ale dałem radę, część pieniędzy już zdążyłem wydać :D. Jakby z tymi klientami nie było - póki co podoba mi się taka robota - robię to co lubię, rozwijam się, zdobywam doświadczenie i w dodatku mi za to płacą. A dla nastolatka każde pieniądze są ważne :D.

Bez tego ani rusz. Bo to się nie zdarza od czasu do czasu, a cholernie często. Już ja się przkonałem. Na wypłatę z początku roku czekam do tej pory, projekt nie jest dalej skończony (właściwie nie wiem na jakim jest etapie), dostałem trochę kasy (ale wciąż mniej niż połowę), a reszta 'będzie stopniowo w miarę uruchamiania projektu'.

Teraz - jeśli bez umowy, to komuś, komu ufam.

"Poprawki zaczynamy robić na odwal się i przestajemy przejmować się optymalizacją", twardy jesteś że przejmujesz się optymalizacją przed otrzymaniem potwierdzenia że zmian już nie będzie... w sumie to się nie znam ale kiedyś podejrzałem że ludzie wpierw kodzą makiety, a piszą na serio od nowa dopiero jeśli okaże się klient miał orgazm i potwierdzi to na piśmie.

Szymon - nawet nie mówię o jakiejś cięższej optymalizacji, ale np minimalizowaniu zapytań SQL.

Nawet drobiazgowa analiza przedwdrożeniowa nie ustrzeże przed niespodziankami. Dotyczy to nie tylko webdeveloperki ale również szeroko rozumianego programowania.

Chyba każdy pracujący w webtechnologiach (czy ogólnym IT) zdaje sobie sprawę z tego, że JAKIEŚ ryzyko jest zawsze :)

Hmm przedewszsytkim umowa powinna w miarę dokładnie zawierać wszystko co ma być wykonane - potem to może być gadka typu "tego nie ma w specyfikacji, albo to robię rezygnując z czegoś innego, albo dopłacacie".

Poza tym (odnośnie frontendu) naprawdę fajnie jest mieć zrobiony prototyp. To jest akurat rzadkość, ale warto. Firma, w której pracuję oferuje wykonanie prototypów strony z klientem. Po wykonianiu prototypu klient będzie lepiej wiedział czy to jest to co chce. Oczywiście ten etap jest również płatny. Nawet gdy delikwent odmówi dalszej współpracy masz kasę za makietę :)

Kiedyś miałem taką sytuację, jak opisaną. Sporo nerwów, lecz później nauczyłem się mówić, co było, a co nie w specyfikacji. Mój "pośrednik" wtedy zaczął inaczej załatwiać sprawy.

Jedyną rzecz niezmienną i pewną w projektach IT jest to, że będą zmiany.
1. Umowa na piśmie - robimy biznes, a nie gramy w ciuciubabkę
2. Specyfikacja techniczna - czego nie ma w niej to zaistnieje po zaaneksowaniu i opłaceniu
3. Najważniejszy zapis - termin realizacji to X dni od dnia zaakceptowania specyfikacji. Zmiana zaakceptowanej specyfikacji oznacza, że termin liczony jest od nowa.
4. Jeżeli zadanie jest warte więcej niż 1000PLN rozejrzeć się nad prawnikiem. Niech on negocjuje.

ps. a i tak na koniec będzie jakaś zmiana...

Chyba najwyższy czas odblokować komentarze dla niezalogowanych, wpis jest na topce w ilości odwiedzin, a mam tylko 13 komentarzy ;)

(no tak, czego się nie robi dla lansu ;) )

Nie w tym rzecz ;) Chodzi o to, że komentarze pod tym wpisem są ciekawe, rzadko mi się to ostatnio zdarza ;)

Polecam spojrzenie łaskawym wzrokiem na podejście typu Agile i zastosowanie tego do siebie/swoich projektów. Przyda się zwłaszcza do zarządzania częstymi (i niespodziewanymi) zmianami. A co do umowy - no cóż, trzeba pilnować swoich interesów, nikt tego za Ciebie nie zrobi - to żelazna zasada biznesu. Jasno określacie zakres pracy i to wyceniasz. Jeśli klient chce dodać coś nadmiarowego, to musi dopłacić, nie jesteś przecież instytucją charytatywną (no chyba, że jest inaczej ;)).

Tak jak już zostało wcześniej powiedziane - umowa na piśmie, w której spisujecie wszystko, co ma być wykonane. Ja też dosyć często mam "a może by dodać jeszcze ..., byłoby chyba lepiej.", "wie Pan co, to mi się nie podoba, jednak zróbmy tak...". Obowiązuje Cię to, co jest w umowie. Jeśli tego nie ma - niech dopłaca. Gdyby tak podliczyć ceny tych wszystkich małych poprawek, to byś uzbierał więcej kasy niż za niejeden cały projekt.
Co do ciągłego poprawiania kodu - jest to nieuniknione i też tego nienawidzę, gdy już wszystko jest ładne i gotowe, to klient wymyśla i musisz wprowadzić takie poprawki, że z całego kodu robi się kaszana. I moim zdaniem to się tyczy nie tylko kodzenia, ale też projektów graficznych, no ale komu nie zależy na tym, aby klient był zadowolony, a i my abyśmy się nie wstydzili pochwalić się takim projektem? :)

I zaliczka. Ustrzega przed wypadkami typu "odechciało mi się" od strony praktycznej. Jeśli klient zapłacił już jakąś kasę, rzadko kiedy przyjdzie mu do głowy nagle zacząć olewać całe zagadnienie, bo ma nowe wspaniałe plany. Umowa przed takimi zachowaniami zabezpieczy... no, średnio zabezpieczy, komu przy robocie za <2-3k chce się biegać po sądach?

Zaliczka oczywiście, przecież tworząc projekt ponosimy koszta. Umowa zabezpiecza przed "odechceniem się", ale i tak zaliczka jest potrzebna na kontynuację prac ;)

Komu? Klientowi :D

"4. Jeżeli zadanie jest warte więcej niż 1000PLN rozejrzeć się nad prawnikiem. Niech on negocjuje."

Koziołek zacznijmy od tego, że zlecenie poniżej 1k PLN to jest albo dopisanie funkcjonalności do serwisu, albo jakaś prosta strona z 2-3 podstronami, a nie poważny serwis. Zresztą po co komu prawnik, w internecie jest cała masa umów które można wykorzystać (w przypadku stron internetowych warto podpisywać umowy o dzieło, z przekazaniem praw autorskich, generalnie suma brutto wtedy nie jest dużo wyższa od tej którą oczekujemy, jak się ma własną firmę to już tylko fakturka + VAT).

@D4rky nie łam się, ja też tak mam, nawet jak klient dostaje od razu orgazmu bo mu się podoba, to w późniejszym okresie okazuje się, że połowa rzeczy nie jest taka jak chciał.
No i piękne zdanie: "my to testowo wdrażamy i ta strona musi zarobić na siebie, więc teraz mniejsze pieniążki a potem jak się rozrośnie to będą większe płynęły" <- nie dajcie się nabrać, bo skusicie się szybką kasą i jakąś extra później, a i tak się okaże, że po zrobieniu klient olewa lub nie robi nic nad rozwojem strony i tak nie dostaniemy więcej.

Zresztą jeszcze trzeba wziąć pod uwagę to, że firmy bywają niewypłacalne i zamawiają stronę, podpisują umowę, mają deadline zapłaty od momentu otrzymania dzieła, ale nie mają pieniędzy to Cię zwodzą ... wtedy jeśli projekt jest warty minimum 2-3k to warto się rozejrzeć za firmą windykacyjną, co ściągnie taką należność ;-)

true. nic dodać nic ująć a wiem coś o tym jak mi klient wyskoczył, że mam mu zrobić layout ale moge podarować sobie kilka rzeczy żeby było taniej O_o

:: Agile od podstaw ::, nie zawsze agile daje radę. Na przykład gdy zmiany wpadają na dzień przed terminem oddania i dotyczą wielu elementów. W dodatku agile wymaga zespołu, bo dla pojedynczego programisty nawet w swojej najprostszej wersji nie jest super wydajne. Sebastian Szary, papuga zawsze się przyda. Wzory umów z internetu nie zawsze są dobre. Warto mieć więc na podorędziu jakiś cięższy argument.

IMO dzień przed oddaniem serwisu już nie powinno się robić wielu zmian. My zazwyczaj mówimy, że ok, ale po oddaniu, bo to za dużo roboty jest a jeszcze kolejne błędy wyjdą..

Hmmmm, znane motywy. :) Cóż, prawda jest taka, że bez umowy - ani rusz. A jak jest umowa, to zupełnie inna bajka:
- jak klient zmienia zdanie, to wszelkie odstępstwa liczymy jako dodatkową pracę, czyli dodatkową kasę.
Nie wkurzamy się, tylko mówimy: OKeeeeeeeej mogę to zrobić, ale to będzie kosztowało dodatkowo tyle a tyle.
A umowa jest po to, żeby nagle się nie okazało, że klientowi się nie podoba i woli uciec i nie zapłacić za w połowie zrobiony projekt.
Bez umowy, to Ty musisz się starać żeby nie uciekł, ergo robisz dodatkowe poprawki extra za darmochę.

Test

1. abc
2. def

• TEST*

a tata marka powiedzial
no co takiego?

1. abc
2. def

• TEST*
  >aaaaaaaaaaaa
  aaaa

aaaaaa
aaaaaa
aa
aaa

1. abc
2. def

• TEST*

aaaaaaaaa
aaaaaaaa
aaaaaa
aaa
a
aa
a
aaaaaaaaaaaaaaaaaaa
aaa
fajnie

Z klientami zawsze sa problemy :) Ten typ tak ma.
D4rky, odezwij sie na priv jesli szukasz roboty.

no tak... chyba o czyms zapomnialem:
JID: ramzes@jab.ber.pl

O, a może dla mnie coś znajdziesz ;P ?