'MAKE THE LOGO BIGGER!', czyli jak radzić sobie z klientami z piekła rodem

Każdy, kto pracuje w jakimkolwiek designie (nieważne, czy to print, czy web) spotkał się na pewno przynajmniej raz z „klientem z piekła rodem”, nazywanym czasem pieszczotliwie ECFH. Sztuka bycia projektantem dla takiego klienta polega na znajdowaniu kompromisów pomiędzy własną ideą, a pomysłami klienta lub na umiejętnej „inżynierii socjologicznej”, czyli takim wmanipulowaniu gościa we własny pomysł, aby uwierzył, że to jego własny. Oto jakie rozwiązania stosuję ja.

Kontrprzykłady

Jeśli projektujesz coś dla ECFH, staraj się znajdować podkładkę pod swoje działania. Jeśli projektujesz — powiedzmy — serwis społecznościowy, przejrzyj inne serwisy o podobnej tematyce, gdzie wykorzystane są Twoje pomysły. Dobrze jest też powoływać się na takie sztandarowe serwisy jak Flickr, mając zawsze w zanadrzu odpowiedź „serwis X ma to rozwiązane, tak jak wygląda moja propozycja, a mają miliony użytkowników”

Mądrość ludowa

Fajnie jest mieć gdzieś (np. w del.icio.us) zachomikowane parę artykułów o designie i badań dot. user experience i usability. Sporo magazynów i blogów dot. designu i UX (m.in. Smashing Magazine) cyklicznie robi badania dot. przyzwyczajeń użytkowników do różnych typowych elementów serwisów. Oczywiście, jako designer powinieneś je znać (użyteczność, głupcze), natomiast Twój klient niekoniecznie. Jeśli zasugerujesz mu rozwiązanie bardziej użyteczne, a do tego podeprzesz się jakimiś naukowo brzmiącymi badaniami, zwykle postawisz na swoim.

Logika

Często (a przynajmniej mnie) zdarzają się klienci, którzy najchętniej zobaczyliby na stronie głównej kwiecisty opis serwisu wraz ze wszystkimi szczegółami implementacji. Oczywiście, nie należy mieć nic przeciwko temu, jednak żeby zainteresować użytkownika mamy tylko tzw. „pierwsze wrażenie”, czyli kilka(naście) pierwszych sekund jego pobytu na stronie. W takich przypadkach cztery tysiące znaków tekstu na start mogą nam jedynie odstraszyć potencjalnego klienta końcowego, na co też możemy się powołać przy rozmowie z naszym „ukochanym” zleceniodawcą. Dobrze sprawdzają się pytania logiczne w stylu „Ile czasu średnio spędza Pan/i na zapoznanie się z nowym serwisem? Poniżej minuty, prawda? No właśnie.” tudzież „A czy wchodząc pierwszy raz na stronę firmy, o której nie wie Pan/i nic, chciałoby się Pan/i to wszystko czytać? No właśnie.”.

Wzorce

Ostatnio odkryłem niesamowicie wręcz pomocny w walkach z uporczywymi klientami serwis Pattern Tap. Serwis z grubsza zajmuje się zbieraniem swoistych „wzorców projektowych” dla WWW wraz z przykładami użycia. Zwykle argument wzorca wraz z przykładami, lub skierowanie klienta wprost na Pattern Tap przynosi spektakularne wręcz efekty.

Kompromisy

Kiedy wszystko inne zawodzi, musimy iść na kompromisy. Kompromis w takim przypadku nie polega jednak na „zrobię tak jak on chce, byle to odwalić”, bo to nie jest kompromis, tylko okopanie się i wywieszenie białej chorągwi. Kompromis powinien polegać na takiej modyfikacji pomysłu klienta, aby pasowała do ogólnego konceptu projektanta, co zwykle po dłuższym lub krótszym namyśle da się zrobić, a w ten sposób i wilk jest syty, i owca cała.

Podsumowanie

Każdy klient w trakcie procesu potrafi się przeistoczyć w ECFH-a, ale poprzez znajdowanie kompromisów i dobre argumentowanie swoich decyzji można sprowadzić nawet uporczywą z początku współpracę do gładkiej i spokojnej wymiany opinii i inspiracji. Wymaga to jednak uporu i sporej cierpliwości, której sobie i wam życzę.

Podsumowanie ankiety dot. zarobków

Tydzień minął, ankieta zamknięta, zgodnie ze zobowiązaniem, zamieszczam opracowane wyniki ankiety dot. zarobków w webdesignie i szeroko pojętym front-end developmencie. Niestety, nie mogę powiedzieć, żeby próbka była reprezentatywna, ponieważ odpowiedziało łącznie jedynie 63 osoby, z czego tylko nieco ponad połowa wypełniła wszystkie strony ankiety. Wykresów chwilowo nie mam, bo Google Charts API rzuca jakieś dziwne wyjątki, dorzucę jak się z nim uporam. ;^)

O respondentach

Zdecydowana większość ludzi odpowiadających na ankietę, to młodzi (18-24 lata) ludzie mieszkający w dużych (500.000+ mieszkańców) miastach. Ponad połowa specjalizuje się we front-end developmencie, pracując w zawodzie od dwóch do pięciu lat. Prawie 3/4 odpowiadających to freelancerzy, pracujący wg indywidualnego czasu pracy.

O projektach

Niespełna połowa respondentów robi góra 5 projektów na rok, co nie jest jakimś imponującym wynikiem, co może świadczyć o dwóch rzeczach — albo robicie mało dużych projektów, albo po prostu jest ciężko o projekt na naszym rynku.

O stawkach

Zdecydowana większość (niecałe 64%) projektantów preferuje płaskie stawki z płatnością za cały projekt, co świadczy o sporym zaufaniu do klientów, dla których pracujecie. Ja osobiście w moich freelancerskich projektach zdecydowanie psuję statystykę, pracując wg stawki godzinowej i rozliczając się z klientami za każdą godzinę pracy ;^)

Niestety, państwo designerzy i developerzy — nie cenicie się. Większość na pytanie o stawkę za godzinę pracy odpowiada poniżej 50PLN, chociaż sporo też rokuje poprawę deklarując 50-100PLN. Ciekawi mnie ile poniżej 50PLN ceni się ta większość i chyba zrobię bardziej dokładne badania w tym kierunku.

Mniej więcej pół na pół z tendencją na nie rozkładają się wyniki pytania o wliczanie licencji w koszty — tu moja rada: nie wliczanie takich rzeczy w koszty powoduje, że tracimy czasem całkiem spory kawałek tortu. Warto zastanowić się, czy nie lepiej rozłożyć sobie koszt zakupionego softu, licencji, fontów i tym podobnych spraw na średnią ilość projektów w roku i o tyle drożej liczyć klientów.

Mała ankieta dot. zarobków

W nawiązaniu do posta na temat wyceny projektów postanowiłem uruchomić małą ankietę w temacie — jak pracujemy i ile zarabiamy?

Ankieta będzie aktywna przez 7 dni pod tym adresem, po jej zakończeniu postaram się jak najszybciej przeanalizować wyniki i podzielić się nimi na blogu — kto chętny, niech wypełnia.

PS. Mam szczerą chęć uruchamiania takich ankiet co jakiś czas, jeśli będzie zainteresowanie, bo jak przekonałem się czytając komentarze, część ludzi nie wie, na ile tak naprawdę można wyceniać projekty.

Jak wyceniać projekty?

Ostatnio na Design Talkboard ukazał się całkiem ciekawy artykuł dotyczący wyceniania projektów graficznych dla klienta. Poza wylistowaniem czynników, które powinniśmy brać pod uwagę przy wycenianiu projektu graficznego, porusza on także temat wyceny tzw. „płaskiej” (stała, zapisana w kontrakcie cena za projekt) kontra stawki godzinowej. Autor artykułu nie zagłębia się zbytnio w szczegóły, postanowiłem więc opisać mój punkt widzenia. a także rozszerzyć temat o front-end development, czy też development ogólny. Na pierwszy rzut weźmy…

Płaska stawka

Stosowanie płaskiej stawki za całość projektu lub jego część jest z mojego doświadczenia formą preferowaną przez klientów korporacyjnych, gdzie wszystko musi przejść przez machinę księgowo-biurokratyczną, podbite tysiącem pieczątek i podpisane zgodą pięciu dyrektorów, dwóch asystentów i czternastu księgowych. Z powodów wyżej wymienionych stawka godzinowa jest dla takiego klienta zwyczajnie niewygodna, więc unikają jej jak ognia. Jeśli zgodzisz się na taką formę współpracy z klientem, pamiętaj o jednej podstawowej zasadzie — naucz się estymować. Estymacja godzin ma jedną podstawową zasadę — zawsze estymuj „z górką”. Musisz zawsze rozpatrzyć najbardziej optymistyczny (klient jest zachwycony, nie ma poprawek, nie ma problemów), jak i najbardziej pesymistyczny (klient nie może się zdecydować, masa poprawek/update‘ów w każdej fazie projektu), a następnie wyestymować najgorszy scenariusz plus kilka(naście) godzin na zdarzenia nieprzewidywalne. W ten sposób masz pewność, że zdążysz i nie skończy się na siedzeniu po nocach i klęciu na czym świat stoi, że musisz pracować za darmo. Podczas estymacji możesz także zastosować starą zasadę wyceniania więcej, niż wyestymowałeś, bo często klient w toku negocjacji próbuje trochę spuścić z ceny.

Z mojego doświadczenia wynika, że na tym typie kontraktów można wyciągnąć zasadniczo wyższą średnią stawkę za godzinę pracy, jednak jest on obarczony ryzykiem dla projektanta — klient może być kapryśny i tracimy pieniądze, pracując za darmo.

Hourly rate, czyli stawki godzinne

Z mojego doświadczenia wynika, że jest to forma preferowana przez małe firmy i osoby prywatne. Jest to forma bardziej agile, niż płaskie stawki, zwykle wymaga częstego kontaktu z klientem w celu zapewnienia obustronnego zaufania. Jest ona mniej ryzykowna dla projektanta, natomiast bardziej ryzykowna dla klienta, dlatego należy się przyzwyczaić do faktu „zerkania przez ramię”, czy aby na pewno coś się w projekcie dzieje, czy też nabijamy puste godziny. Budowanie zaufania przy stawkach godzinnych zwykle jest długie i żmudne, dobrze sprawdza się w tym przypadku metodyka Scrum, dzięki której klient cały czas trzyma rękę na pulsie, natomiast projekt jest na bieżąco konsultowany z klientem, co podnosi znacznie wygodę pracy projektanta.

Projekty negocjowane na stawki godzinne zwykle przynoszą niższe zyski niż projekty „płaskie”, głównie ze względu na fakt, że nie da się estymować „z górką”, dlatego też zwykle negocjuję wyższą godzinną stawkę dla takich projektów, osobno doliczając koszty ew. licencji zakupionych dla klienta.

Złota zasada

Chciałbym jeszcze wspomnieć o złotej zasadzie przy dowolnej wycenie projektu — nie psuj rynku. Spójrz uczciwie na swoje doświadczenie i umiejętności, wliczaj w umowy koszty oprogramowania, czcionek, ikon, technologii, w które będziesz musiał zainwestować (nie jesteśmy organizacjami dobroczynnymi, tylko projektantami) zorientuj się w stawkach na lokalnym rynku, nie wyceniaj poniżej tego, na ile Cię stać — psujesz wówczas rynek innym, a poza tym… coś trzeba jeść, prawda?