Nigdy nie możesz znać dokładnej lub prawie dokładnej ceny, ponieważ zależy ona od wielu czynników. Przykład:
Studium przypadku
Otrzymałeś prośbę o małą stronę internetową opartą na WordPress. Jedyne, co musisz zrobić: współpracować z projektantem, aby stworzyć atrakcyjną grafikę, a następnie stworzyć samą stronę internetową (nic wysoce technicznego, tylko zestaw wtyczek do dodania do WordPress), a następnie wdrożyć ją. Praca jest naprawdę łatwa, zacytowałeś ją 600 $.
Twój projektant stworzył pierwszy szkic. Klient wyjaśnił, że w ogóle nie uważa tego za atrakcyjne. To samo dotyczyło drugiego, trzeciego i czwartego szkicu. Wreszcie, po dwóch tygodniach ciężkiej pracy, projektant otrzymał projekt, który został zaakceptowany przez klienta.
Niestety projektant został potrącony przez autobus i jedyne, co dostałeś, to przesłane przez Ciebie pliki JPEG, ale nie oryginalne PSD, więc musiałeś zacząć od nowego projektanta. Wreszcie masz grafikę i zacząłeś swoją pracę.
Niespodzianka: odkryłeś, że wtyczka A jest niezgodna z wtyczką B, że wtyczka C nie działa zgodnie z oczekiwaniami i że wtyczki D nie można zainstalować w najnowszej wersji WordPress, a wtyczkę A można zainstalować tylko w tej najnowszej wersji. Teraz musisz dużo ręcznie kodować PHP, a ponieważ jesteś programistą Python i nigdy nie napisałeś ani jednej linii kodu w PHP, nie jest to najłatwiejsze zadanie.
Tymczasem klient zaczyna wysyłać ci przerażające e-maile, pytając, dlaczego praca nie została jeszcze wykonana, a termin upłynął tydzień temu. W końcu kończysz kodowanie PHP i wszystko działa idealnie na twoim komputerze. Klient jest zadowolony.
Następnie zaczynasz wdrażać witrynę na serwerze hostingowym, aby odkryć, że nie tylko witryna zawiedzie z jakimś tajemniczym błędem, ale także firma hostingowa nie obsługuje funkcji PHP, której często używasz w kodzie.
Wreszcie, po wydaniu ponad 3000 USD na ten projekt, witryna jest uruchomiona. Klient jest zły z powodu terminów i dlatego, że „nic nie działa zgodnie z oczekiwaniami”. Czy poprosiłbyś o 600 $? 3000 $?
Dlaczego tak się dzieje?
To, co zilustrowałem w tym przykładzie, zdarza się znacznie częściej, niż możesz w to uwierzyć. Dlaczego? Ponieważ istnieje zbyt wiele zmiennych, których nie można przewidzieć i które zwiększają ryzyko. Tutaj ryzyko zostało zwiększone o:
- Niejasne specyfikacje związane z projektowaniem wizualnym,
- Śmierć projektanta,
- Niezgodność wybranych wtyczek,
- Złe wsparcie wybranych wtyczek,
- Fakt, że nie używałeś wcześniej PHP,
- Różnica między środowiskiem programistycznym a środowiskiem produkcyjnym oraz brak przemieszczania.
Można rozwiązać te problemy za pomocą określonych metod:
- Jasne i precyzyjne wymagania funkcjonalne i niefunkcjonalne,
- Zarządzanie scenariuszami hit-a-bus (tj. Projektant musiał udostępnić ci każdy dokument, aby w każdej chwili mógł umrzeć bez narażania projektu),
- Wcześniejsza znajomość narzędzi i języków, których musisz używać (co wymaga dużo pracy),
- Inscenizacja, intensywne testy itp.
Jedynym problemem jest to, że dzięki takiemu podejściu musisz powiedzieć klientowi, że w pierwszej kolejności zapłaciłby co najmniej 5000 USD, ponieważ w rzeczywistości jest to cena wymagań, specyfikacji, projektu, testowania itp. Szanse, aby ten klient zaakceptował Twoja wycena jest bardzo niska.
Więc nie ma nic do roboty?
Jeśli nie możesz podać bardzo dokładnej ceny, nadal możesz podać przybliżenie, które uwzględnia każdą część pracy do wykonania osobno, przy czym wskaźnik ryzyka ma wpływ na każdą część. Wyższe jest przewidywalne ryzyko, wyższa cena.
Możesz to zrobić na dwa sposoby:
1. Watefally sposób
Jeśli pracujesz nad projektami, które pasują do modelu Waterfall / V, może to działać:
Wymień funkcjonalne i niefunkcjonalne wymagania projektu. Uzyskaj dokument podpisany przez klienta w taki sam sposób, jak podpisuje umowę.
Po otrzymaniu tego dokumentu masz już:
Cena, którą już wydałeś, zbierając wymagania i tworząc ten dokument. Może to stanowić znaczną sumę pieniędzy, ponieważ dokumenty te mogą mieć od dwudziestu do stu stron w przypadku zwykłego projektu, a setki lub tysiące stron w przypadku dużych projektów.
Jasne, precyzyjne i pełne zrozumienie produktu, o który proszono.
Idź ze swoim zespołem krok po kroku, analizując każde wymaganie i oceniając:
Średnia cena tej części projektu,
Maksymalna cena bez uwzględnienia ryzyka,
Indeks ryzyka.
Wszystkie trzy zostaną uwzględnione w celu ustalenia ceny, którą podasz klientowi.
Określ ryzyko, które nie zależy od konkretnego wymagania, ale raczej od zgodności między wymaganiami lub ogólnie od systemu.
Zalety podejścia wodnego: klient otrzymuje cenę, która jest dość precyzyjna, biorąc pod uwagę, że masz bardzo jasną wizję pracy do wykonania i ryzyka, które może się pojawić.
Wady podejścia wodnego: musisz podać 200 stron dokumentu przed podaniem ceny. Co się stanie, jeśli klient tymczasem anuluje projekt lub przejdzie do Twojego współbieżnego? Cały proces jest również bardzo ciężki i wymagania nie mogą się później zmienić.
2. Zwinny sposób
Jeśli pracujesz nad projektami, które pasują do Scruma lub innych zwinnych modeli:
- albo nie podają ogólnej ceny projektu, ale raczej ceny każdego elementu,
- lub możesz podać bardzo przybliżoną cenę całkowitą na początku, a następnie podać cenę coraz bardziej precyzyjną.
W obu przypadkach powinieneś mieć silne zaufanie między tobą a klientem lub mieć doskonałych ludzi w dziale sprzedaży. Inaczej,
w pierwszym przypadku ta osoba uwierzyłaby, że kradniesz jej pieniądze, prosząc wciąż o małe kwoty, a to się nigdy nie skończy,
w drugim przypadku osoba nie zrozumie, dlaczego ciągle zmieniasz cenę, szczególnie jeśli cena rośnie przez większość czasu.
Zalety zwinnego podejścia: klient może anulować w dowolnym momencie. Ponadto, jeśli anuluje na wczesnym etapie, nadal ma jakiś kod źródłowy, który działa.
Wady podejścia zwinnego: cena jest zbyt nieprecyzyjna lub nawet nie podana. Większość klientów nie byłaby skłonna współpracować z tobą, jeśli nie powiesz im, ile będą musieli zapłacić.