Zalety stawki godzinowej dla klienta [zamknięte]

Dla programisty dobrze jest pracować na godzinę, ale trudno jest wyjaśnić klientowi zalety stawki godzinowej.

Jakie są twoje argumenty dotyczące stawki godzinowej dla klienta? Jak wytłumaczysz mu jego zalety i jak spierasz się na temat „Chcę poznać dokładny koszt projektu”?

Old Joke: Linia montażowa psuje się i zostaje przywieziony mechanik. Po obejrzeniu maszyny wyciąga młotek, uderza w maszynę i zaczyna biec. Kierownik sklepu jest zdumiony, dopóki mechanik nie powie: „To będzie 500 $”. Zaskoczony forman odpowiada: „Chcesz pobrać 500 USD za uderzenie młotkiem w maszynę? Mój CFO będzie potrzebował wystawionej faktury”.

Faktura jest wysyłana pocztą:

• Trafienie młotkiem: 5,00 $
• Wiedząc, gdzie trafić maszynę: 495,00 $

W pewnym sensie stawka godzinowa jest sposobem kontroli kosztów. Ile warta jest aplikacja, która oszczędza firmie konieczności zatrudniania pełnego płacy minimalnego pracownika? Całkowite roczne koszty dla tej osoby, w tym wynagrodzenie, świadczenia, urlop, zwolnienie chorobowe, mogą wynieść 20 000 USD. To musi być warte 15 000. Jeśli rozwiązaniem okaże się import do bazy danych, którą można utworzyć w ciągu 30 godzin lub krócej, wątpię, by stawka wynosiła 500 USD / godzinę.

Klient może kontrolować koszty przez cały czas trwania projektu.

Wiele projektów, które mają stałą opłatę, zwykle wymaga wpłaty z góry. Klient może płacić według stawki godzinowej.

Ładowanie za godzinę wydaje mi się po prostu złe. Chcę być ceniony za to, że wiem, gdzie wymachnąć młotem.

Stawka godzinowa nie przynosi korzyści klientowi. Jest to korzystne dla programisty, ponieważ nie ma znaczenia, ile zmian zażąda klient.

Podobnie jak umowa ze stałą ceną nie przynosi korzyści deweloperowi. Przynajmniej nie bez zleceń zmian. :-)

W budownictwie istnieje wyraźny rozdział między analizą a projektowaniem (architektura) i implementacją (konstrukcja). Nawet przy takim podziale i ponad stuleciu informacji o kosztach wdrożenia projekty budowlane mogą przekraczać budżet.

W rozwoju komputerów nie ma tak wyraźnego podziału między analizą, projektowaniem i implementacją. Klient nie zdaje sobie sprawy z tego, ile kosztuje zmiana ekranu po zakończeniu kodowania, w porównaniu z wyburzeniem ściany.

Deweloper ma obowiązek edukować swojego klienta i upewnić się, że klient rozumie wartość, a nie cenę.

Główną różnicą między ceną stałą a godzinową jest to, kto ponosi ryzyko. Szczególnie w tej dziedzinie szacunki projektu są jedynie przybliżone i mogą być w nich bardzo niepewne.

Dlatego po ustalonej cenie deweloper musi upewnić się, że oszacuje wysoką kwotę na pokrycie nieprzewidzianych trudności. Jest to uzasadnione, ponieważ w większości działań biznesowych konieczność pokrycia ryzyka jest warta pieniędzy (tak działa działalność ubezpieczeniowa).

Jeśli klient w wystarczającym stopniu ufa deweloperowi, stawka godzinowa pozwoli mu zaoszczędzić pieniądze, jeśli projekt zakończy się wcześniej niż wspomniane wysokie szacunki, chociaż jeśli przekroczy, klient traci pieniądze. W takim przypadku klient pokrywa ryzyko i średnio oszczędza pieniądze.

W szczególności, jeśli klient jest dużą firmą, a deweloper jest osobą fizyczną, klient będzie prawdopodobnie w lepszej pozycji do podjęcia ryzyka. Konieczność zapłacenia dodatkowych 160 godzin może raczej zaszkodzić większej firmie mniej niż konieczność przepracowania dodatkowego miesiąca za darmo może zaszkodzić samotnemu deweloperowi.

Ułatwia także negocjowanie zmian specyfikacji, gdy programista nie musi dokonywać dokładnej ponownej oceny każdej zmiany.

Stawka godzinowa jest korzystna dla klienta w przypadkach, w których istnieje duże prawdopodobieństwo, że będzie chciał dodać dodatkowe funkcje ponad te, które początkowo określono. Będzie to również korzystne dla klienta, gdy proces programowania obejmuje współpracę ze stronami trzecimi i gdzie rola dewelopera może obejmować inne zadania, które są tylko stycznie związane z zadaniem programowania.

Stawka godzinowa pozwala deweloperowi powiedzieć „Zajmę się tym”. Zamiast „To nie jest objęte uzgodnioną ceną. To będzie dodatkowe X dolarów. ”

W takich przypadkach stawka godzinowa eliminuje potrzebę ciągłych negocjacji i może pomóc w zapobieganiu nieporozumieniom wynikającym z odmiennych poglądów na to, co pierwotnie uzgodniono.

Przy stawce godzinowej klient musi upewnić się, że pracujesz wydajnie. W umowie o stałej cenie klient musi dokładnie opisać, czego chce. Jeśli klient chce poznać dokładny koszt projektu, musisz dokładnie wiedzieć, co należy zbudować. Zwykle klient nie wie lub myśli, że wie, ale później zmienia zdanie.

W obu sytuacjach dron sprzedażowy znajdzie sposób na przeładowanie klienta: nisko licytuj stałą część projektu, a potem zrekompensuj to ogromnymi rachunkami za każdą drobną zmianę lub uzupełnienie lub pozwól najbardziej kompetentnym osobom wygrać licytację i zamień je później na programistów bzdur (według tej samej stawki godzinowej).

Gdybym był klientem, wolałbym:

• płacić stawkę godzinową
• poproś programistów o dostarczenie działającego kodu, sprawdzonego przez automatyczne testy, w krótkich odstępach
• być w stanie zastąpić programistów, którzy nie działają (obejmujący prawa autorskie itp.)

W ten sposób mogę swobodnie podejmować decyzje i wiedzieć, za co płacę.

Rozważ zadanie klientowi takiego pytania:

Jak pewni są swojej specyfikacji? Czy oni naprawdę pomyśleli o wszystkim? Co może się zmienić od teraz do momentu uruchomienia produktu? Wyjaśnij, że ze stałą ceną dostarczana jest stała specyfikacja. wszelkie zmiany, a cena się zmieni.

Następnie zaproponowałbym alternatywę. Podaj cenę i dodatek za zmianę specyfikacji wynoszący może 20%. W ten sposób klient już zaplanował w budżecie miejsce na zmiany, a jeśli uda mu się w pierwszej kolejności uzyskać poprawną specyfikację, doprowadzi projekt do niewystarczającego budżetu!

Jeśli klient chce kierować i kontrolować proces rozwoju i / lub dokonywać częstych zmian w produkcie, może to zrobić, ale musi zgodzić się na stawkę godzinową / dzienną.