Dodano: 19.12.2009
Od dłuższego czasu nie jestem zadowolony zarówno ze społeczności Joggerowej, która jak z przykrością stwierdzam jest zbyt zajęta trolowaniem, a i strona główna Joggera nie jest tym co dawniej. Niestety również developowanie tego serwisu nie sprawia mi takiej przyjemności jakiej się spodziewałem - straszny narzut ze strony community, marudzącego o każdą zmianę, która mu nie odpowiada oraz ogrom zadań, których nie mogę połaczyć z życiem osobistym. Może to po prostu zmęczenie materiału?
Nie czuję też już takiej przyjemności z blogowania tutaj jaką miałem jeszcze rok, dwa lata temu - blog stał się aż za bardzo popularny jak na moje skromne gusta, a wiele wpisów tutaj jest szczerze mówiąc nieodpowiednich dla szerszego grona. Z tego powodu postanowiłem zamknąć bloga na czas nieokreślony. Może jeszcze tutaj wrócę, a może nie. W międzyczasie zapraszam na mój nowy, tym razem w pełni techniczny i pisany oficjalnie pod imieniem i nazwiskiem dziennik. Nie posiada on komentarzy dzięki czemu będzie mi prościej zachować spokój, a platforma jest równie wygodna co Jogger, nawet bez bota.
Administratorem, moderatorem, sekretarką oraz niańką na Joggerze nadal pozostaję.
Dodano: 24.08.2009
I. Podekscytowanie
Wszystko zaczyna się gdy dostajemy nowe zlecenie. Pieniążki nęcą, wszystko wydaje się być proste, klient ma nawet ciekawe pomysły. Ustalamy terminy, może nieco zbyt optymistycznie, ale z nadzieją, że w najgorszym razie zarwie się kilka nocek. Wszystko jest cud, miód i orzeszki.
Zaczynamy pisać kod. Na początku tłucze się sam, wszystko jest banalne i idzie samo. Klient czasami coś tam doda od siebie, może pomarudzi, ale ogólnie nadal jest sympatycznie. Na wszystkie maile odpowiadamy błyskawicznie, odpisujemy klientowi na smsy, rozwiewamy wszystkie wątpliwości i odpowiadamy na pytania. Gdy już mamy prawie gotowy serwis, nadchodzi druga faza.
II. Irytacja
Nagle okazuje się, że połowa z tego co zrobiliśmy "jednak klientowi nie pasuje". Zaczyna się żmudne poprawianie i przerabianie już istniejących rzeczy. Specyfikacja, która wcześniej wydawała się klarownie jasna nagle okazuje się zagmatwana, bo to jednak nie o to chodziło. Dopiero wtedy zauważamy, że mnóstwo znaczników typu jak w serwisie XYZ tak naprawdę oznacza tak jak sobie wymyśliłem i trzeba się zdrowo domyślać. Najczęściej dotyczy to frontendu, ponieważ funkcjonalności są w mniejszym lub większym stopniu kopią.
Zagryzamy zęby - jeszcze jest czas. Do deadline zostało parę dni / tygodni, zdążymy wszystko zrobić.
III. Zdenerwowanie
Deadline. Straszliwa, czerwona krecha, która straszyła nas przez całą fazę drugą właśnie nadeszła. Projekt nadal nie jest skończony, ponieważ klient zażądał funkcjonalności, których nie było w specyfikacji. Na dodatek w trakcie sprawdzania błędów nagle okazuje się, że w kodzie jest mnóstwo małych, złośliwych chochlików, które psują całokształt. Klient zaczyna wybrzydać, że to mu nie pasuje, tamto nie działa, być może zaczyna nawet grozić zerwaniem umowy albo karami finansowymi. Poprawki zaczynamy robić na odwal się i przestajemy przejmować się optymalizacją.
IV. Frustracja
Tydzień po deadline. Dwa tygodnie po deadline. Klient nadal marudzi, nagle przestaje mu się podobać cały design. Wkurzasz się i przerabiasz. Zaczyna mu przeszkadzać to jak wcześniej działał serwis, też przerabiasz. Prawie każdy mail zaczyna być oznaczony pilne albo na dziś / do jutra musi być. Gdy siadasz do projektu, zaciskasz zęby i masz ochotę uderzyć monitor. Pieniądze, które w pierwszej fazie cię nęciły, teraz wydają ci się śmiesznie małe w porównaniu z tym przez co przechodzisz. I tak powoli, powoli przechodzisz do ostatecznej fazy.
V. Zniechęcenie / olewactwo
Masz już dość. Pieprzysz pieniądze, pieprzysz klienta, pieprzysz wszystko. Zaczynasz zajmować się pierdołami lub innymi zleceniami, bo nie możesz już patrzeć na dzieło twoich rąk, które jeszcze kilka tygodni wcześniej tak radośnie kodziłeś. SMSy od klienta zbywasz wciśnięciem przycisku, a na maila wchodzisz raz dziennie, żeby przejrzeć litanię poprawek. Dorzucasz je sobie do todo i idziesz się opieprzać. Od czasu do czasu skubniesz troche kodu lub nagłym zrywem nadziei poprawiasz wszystko tylko po to, żeby dostać kolejną listę. Etap ten kończy się w zależności od cierpliwości obu stron albo zakończeniem zlecenia, które jakościowo mocno odstaje od tego, co chcieliśmy uzyskać (głównie ze względu na poprawki klienta) albo zerwaniem umowy i utratą zlecenia, co kwitujemy krótkim łatwo przyszło, łatwo poszło i idziemy pracować nad czymś ciekawszym.
Uzupełnienie
W jaki sposób uniknąć takich sytuacji? Poniżej tłumaczenie tekstu 10 Reasons to Politely Decline a Web Design Gig. Oto lista czerwonych lampek, które powinny nam zaświecić podczas przyjmowania zlecenia. Właściwie jest to lista dla webdesignerów, ale poza 4, 8 i 9 dotyczy również developerów.
- 10. Klient wciąż powtarza ci jak bardzo jego poprzedni developer był do d...
- 9. Chce mieć pewność, że zrobisz stronę tak, żeby pojawiła się na pierwszych miejscach w Google
- 8. Ma już listę ponad 100 słów, które chce wrzucić w meta tagi
- 7. Nie ma aż tyle kasy za to zlecenie, ale jest sporo ukrytych drobiazgów, które spowodują nawał dodatkowej pracy
- 6. Klient chce wiedzieć czy jesteś elastyczny jeśli chodzi o pieniądze
- 5. Mówi ci, że za stronę będzie odpowiedzialny u swoich przełożonych
- 4. Chce wiedzieć, czy znasz się na Flashu
- 3. Chce, żeby jego strona była taka jak eBay (patrz fazę II wyżej)
- 2. Właściwie to sam mógłby zrobić stronę, ale nie ma czasu
- 1. Szuka nowego "webmastera"
Dodatkowo, przed chwilą znalazłem piękny filmik obrazujący sytuacje znaną z webdeveloperki/webdesignu, ale w odniesieniu do innych zawodów:
D4rky