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?

Komentarze

Co do złotej zasady – początkujący nie ma praktycznie miejsca w którym mógłby dowiedzieć się ile powinien zarządać. O ile rynki światowe dorobiły się jakichś porównywarek, tak u nas w dalszym ciągu panuje jakaś głupia moda na to, żeby nie mówić o pieniądzach.

# zx, 12 lipca 2008 o 22:47

@zx: no to mamy lukę w rynku — trzeba coś takiego zrobić, a potem sprzedać np. interii za milion dolarów. ;^)

# Mariusz, 12 lipca 2008 o 22:49

IMO na tym nie ma jak zarabiać. :P Jak dla mnie to właśnie rolą blogujących developerów jest napisanie o tym ile biorą, jak wyceniają itp. Oczywiście jak już zajmą dobrą pozycję na rynku – w końcu nikt sobie konkurencji robić nie będzie.

# zx, 12 lipca 2008 o 22:55

Jest szansa na coś więcej niż sam tytuł w RSS? ;]

# Hadret, 13 lipca 2008 o 09:31

Swego czasu na freelanceswitch.com i wakeuplater.com było kilka fajnych artykułów o wycenianiu projektów, nawet ze ‘wzorami’ na wyliczanie cen, ale oczywiście tylko w amerykańskich warunkach. U nas niestety nadal każdy powie tylko ‘dowiedz się, popytaj, poszukaj’ ale nikt nie chce się przyznać. ;) A zgadzam się z zx, że to blogerzy powinni o tym pisać, bo kto inny?

# art.stk, 13 lipca 2008 o 12:03

@Hadret: poprawione.

# Mariusz, 13 lipca 2008 o 13:04

No właśnie, w którym miejscu kończy się konkurencja i zaczyna tzw. „psucie rynku”? :)

# jam łasica, 13 lipca 2008 o 13:15

@jam łasica: wszystko zależy od warunków. Spróbuję dziś wzorem FreelanceSwitch wykrzesać ankietę dotyczącą średnich stawek, wliczania licencji i tych spraw i wrzucić na bloga, a potem podzielić się wynikami.

# Mariusz, 13 lipca 2008 o 13:22

‘estymować’ to zapewne od estimate – oszacować? zazwyczaj sam zangielszczam, ale tutaj chyba trochę przesadziłeś :D A sam wpis ciekawy :) Osobiście nigdy nie potrafię wycenić ile powinenem wziąć za jakąś robotę – jakoś nie potrafię :|

Umm, i jeszcze coś: © 2008 © 2008 Mariusz Cieśla – chyba ci się pomieszało :)

# D4rky, 13 lipca 2008 o 19:33

D4rky: jeśli istnieje funkcja matematyczna ‘estymator’ do szacowania, to pewnie można też użyć tej nazwy w formie czasownika.

# zx, 13 lipca 2008 o 19:35

zx – no proszę, codziennie człowiek uczy się czegoś nowego

# D4rky, 13 lipca 2008 o 19:36

@D4rky: określenie ‘estymacja’ jak i ‘estymować’ jest jak najbardziej po polsku i używa się go w większości publikacji o zarządzaniu projektami, które czytałem ;^)

# Mariusz, 13 lipca 2008 o 19:52

Do formatowania komentarzy można używać Textile Lite (HTML nie działa).

Komentarze obraźliwe, wulgarne czy nie na temat, a także robienie z komentarzy czata będzie sukcesywnie moderowane.

Dodaj komentarz