Stała cena vs stawka godzinowa. Który model rozliczeń realizacji projektów jest dla Klienta korzystniejszy?

fot. Startup Stock Photos

Pewnie wielu z Was po przeczytaniu tytułu zna już jedyną słuszną odpowiedź i powie „oczywiście stała cena!”.  W tym miejscu dla wielu osób odpowiedzialnych za zamawianie i realizację projektów programistycznych ten artykuł mógłby się już zakończyć, ale spróbujmy jednak temat rozwinąć.

Przez wiele lat pracy przy różnej wielkości projektach programistycznych (w większości internetowych), a od dłuższego czasu decydując bardzo często o ofertach wysyłanych przez MERIXSTUDIO, cały czas spotykam się z dylematami: jak to wycenić, jaki przyjąć zapas, jakie ryzyko niesie za sobą ten konkretny projekt…

Na podstawie szacunkowej czasochłonności projektu i przy uwzględnieniu powyższych czynników powstaje cena końcowa, która wysyłana jest do klienta. Jestem przekonany, że w taki sam sposób podchodzi do wycen większość agencji, od których aktualni i potencjalni klienci oczekują podania stałej ceny za realizację.

Jaki jest tego skutek dla odbiorcy projektu? Ceny przedstawiane przez potencjalnych wykonawców nie są możliwie najniższymi stawkami za dany projekt. Nie oszukujmy się, to wykonawca w większości przypadków posiada większą wiedzę i bierze pod uwagę ryzyko, które niesie za sobą projekt głównie z jego perspektywy.

Autentyczne formaty mediów. Mikrotrend, który zmieni reklamę wideo online? [FELIETON]

Oczywiście lata pracy w z różnymi projektami pozwalają na coraz większe urealnianie tych szacunków, jednak nawet gdyby przy wycenach pomagał nam Wróżbita Maciej 🙂 , nie jesteśmy w stanie przewidzieć wszystkiego, a przykładów takich sytuacji jest więcej niż znaków w tym artykule. Mimo ogromnego doświadczenia w dedykowanych realizacjach nie da się przewidzieć niepoprawnego działania gotowych komponentów czy chociażby komplikacji w integrowaniu oprogramowania z zewnętrznym systemem CRM.

Można powiedzieć zatem: zróbmy specyfikację, wszystko będzie jasne i wtedy możemy to ładnie wycenić. Zatem robimy!

Tak – bez większych problemów i w rozsądnie kalkulowanych budżetach – realizowane są projekty nisko- i średniobudżetowe, oparte o gotowe rozwiązania, takie jak chociażby Drupal czy Magento. Przy dedykowanych projektach zaczynają się „schody”, bo wdrażając się w coraz bardziej szczegółowe oczekiwania klienta odkrywamy, że projekt niebezpiecznie się rozrasta. Wtedy podejmujemy pierwsze, nieśmiałe próby dopasowania projektu do budżetu na siłę albo ustalamy czy oczekiwania pokrywają się z przekazanym wcześniej „scopem”.  Zamiast realizować projekt, wciąż nad nim pracujemy: przeprowadzając rozmowy, negocjując i w nieskończoność doprecyzowując specyfikację tracimy kolejne dni, a nawet tygodnie.

A gdyby tak rozliczyć się za faktycznie poświęcony przez agencję i programistów czas? Gdyby móc zapomnieć o pełnej specyfikacji i sterować projektem w trakcie jego realizacji? Niemożliwe! Jest jednak na to sposób – metodyki Agile i rozliczanie projektu według stawek roboczogodzinowych.

Agile (programowanie zwinne), czyli alternatywa dla realizacji w modelu waterfall (z reguły wykorzystywany przy stałej cenie) to przyrostowy sposób wytwarzania oprogramowania opierający się na założeniu, że wymagania odbiorcy ewoluują w trakcie powstawania projektu (czyż tak nie jest?).

Praca w modelu Agile opiera się na bardzo zdyscyplinowanym zarządzaniu projektem, stałym monitorowaniu jego przebiegu i efektów prac. Projekt jest przedstawiany systematycznie odbiorcy i na tej podstawie następuje weryfikacja czy produkt spełnia wszystkie jego wymagania, czy może warto coś już teraz zmienić – zanim będzie za późno.

W realizacji projektu udział biorą zespoły, których kompleksowe kompetencje są idealnie dopasowane do projektu. Zespół jest możliwie mały, co ma na celu uniknięcie problemów komunikacyjnych i budowania rozbudowanej dokumentacji – dzięki temu można szybko wytwarzać oprogramowanie o bardzo wysokiej jakości i w zgodzie z oczekiwaniami odbiorcy. Członkowie zespołu samodzielnie podejmują decyzje jak osiągnąć postawione przed nimi cele, zarówno funkcjonalne, jak i terminowe.

Oprogramowanie powstaje w sposób iteracyjny (w tzw. sprintach), a zadaniem każdej iteracji jest dostarczenie ustalonego produktu (np. wybranej pojedynczej funkcjonalności). Za każdym razem po takim sprincie przeprowadza się testowanie oraz weryfikację zgodności z założeniami biznesowymi odbiorcy. Już wtedy można skorygować realizację danej funkcji projektu lub nawet zmienić jego kierunek.

O Agile powstała już niejedna książka, ale myślę, że sedno udało się ująć powyżej – spróbujmy odpowiedzieć zatem na pytanie: jakie są powody dla których rozliczanie według stawki godzinowej jest jednak lepsze od stałej ceny?

1. Określanie wymagań

Rozpoczęcie projektu od stworzenia  pełnej specyfikacji oznacza, że już na samym początku podejmujemy najważniejsze decyzje . Pytanie, czy wiemy wtedy na tyle dużo o projekcie. Późniejsza zmiana tych decyzji może być bardzo trudna, nie mówiąc już o tym, że na pewno kosztowna.

Przy podejściu Agile tak naprawdę określamy na wstępie wymagania biznesowe, kluczowe funkcjonalności i rozpoczynamy prace, podejmując decyzje o kolejnych funkcjonalnościach wtedy, gdy mamy już gotowy ich „core” i posiadamy niezbędne informacje. Zmiana w projekcie w tej metodyce jest po prostu czymś naturalnym.

2. Ryzyko finansowe

Chyba zgodzicie się ze mną, że dokładne i jednocześnie długoterminowe szacunki to dwa słowa, które nie tworzą rozsądnego zwrotu. Co robimy, żeby je urealnić? Przyjmujemy czynniki ryzyka projektowego; w przypadku rozliczenia według stawki roboczogodzinowej płacimy wyłącznie za czas poświęcony na osiągnięcie oczekiwanych przez nas efektów.

3. Wspólne priorytety

W modelu o stałej cenie priorytety odbiorcy i wykonawcy, mimo że są zbieżne – zrobić jak najlepszy projekt – to wykonawca chciałby jak najefektywniej zrealizować projekt i wypracować zakładany zysk (który zależy przecież wyłącznie od liczby przepracowanych godzin). Odbiorca za to chce uzyskać projekt o oczekiwanej jakości i chce spędzić nad projektem tak wiele czasu, jak to tylko będzie możliwe, ponieważ „nic go to nie kosztuje”.

Jak zatem to rozwiązać? Ujednolicić cele. Postawić na realizację najlepszego projektu i rozliczać to z agencją za faktycznie poświęcony przez nich czas.

4. Zgodność z oczekiwaniami

W modelu waterfall odbiory prac odbywają się wyłącznie etapowo, zatem trudniej jest śledzić postępy w projekcie. Zmiana kierunku w tak późnym momencie może powodować „wyrzucenie do kosza” części już wykonanej pracy. W modelu Agile efekty prac widać dużo częściej (sprinty są raczej tygodniowe niż miesięczne) i już wtedy możemy ocenić, czy wszystko jest tak jak oczekiwaliśmy.

5. Projekt można rozpocząć szybciej

Nie skupiamy się na stworzeniu pełnej specyfikacji już na samym początku. Wystarczą określone wymagania biznesowe i etapowe tworzenie rozwiązania – od kluczowych funkcjonalności w stronę coraz większej ilości szczegółów.  Sprawa jest dość prosta, a dokumentacja krótka i zrozumiała, ponieważ mówi tylko o kolejnym etapie projektu.

6. Śledzenie postępów realizacji i weryfikacja oczekiwań

Przy realizacji projektu w modelu stałej ceny efekty poszczególnych etapów prac otrzymujemy do wglądu, gdy te są według wykonawcy zakończone. W rzeczywistości dopiero wtedy mamy możliwość oceny czy produkt spełnia nasze oczekiwania. W modelu Agile postępy śledzimy na bieżąco, mamy stale do dyspozycji informacje na ich temat, dużo częściej możemy kontrolować bieżące efekty prac i reagować na to, co się dzieje w projekcie, zarówno pod względem spełnienia oczekiwań, jak i chociażby z punktu widzenia finansowego.

7. Zmiany w projekcie

Przy podejściu rozliczania godzinowego priorytety można zawsze zmienić w trakcie tworzenia projektu. Czy w jakimkolwiek realizowanym projekcie w trakcie podjęto decyzję, aby zmienić kierunek projektu? Przy Agile nie ma problemu – można wstrzymać to, co robimy teraz i zwyczajnie zmienić kierunek, widząc efekty prac możemy ulepszać projekt na bieżąco: nowe pomysły na ulepszenia pojawiają się często dopiero wtedy, gdy zobaczymy jak wygląda dane rozwiązanie. Agile pozwala nam je wszystkie wdrożyć bez konieczności renegocjacji, spotkań, wycen i zbędnej dokumentacji.

8. Ostatecznie jest to tańsze

Tak jest! Jak już pisałem, agencja podając stałą cenę w ofercie musi obliczyć ewentualne ryzyka i problemy, czyli w rzeczywistości oferta nie jest najniższą możliwą ceną za daną realizację. Pracując w modelu rozliczenia godzin pracy tak naprawdę oszczędza się pieniądze i płaci tylko za wykonane prace, czyli osiągnięte wspólnie wyniki.

9. Czas, którego nigdy nie liczymy

Szkoda czasu na dyskusje, czy ten zapis w specyfikacji rozumiemy tak czy inaczej, czy ta funkcja jest w zakresie projektu czy też nie. Policzyliście kiedyś ile wart jest czas poświęcony na takie negocjacje i rozmowy? Nie wspominam już o czasie, jaki tak naprawdę marnujemy myśląc, że zaplanowanie wszystkich najdrobniejszych szczegółów w projekcie jest możliwe przed rozpoczęciem jego realizacji.

OK – wielu z Was pewnie przekonałem do tego, że model rozliczeń  Agile jest najefektywniejszy. Jestem jednak przekonany, że podczas wstępnych rozmów o realizacji projektu usłyszę po raz kolejny: „Agile super, sprinty rewelacja, w ogóle świetna koncepcja – robimy! Tylko musi mi Pan powiedzieć, ile będzie to kosztować”.

Nie ma możliwości, by realizować projekt w Agile przy stałej cenie – tak to po prostu nie działa. Zdaję sobie jednak sprawę z tego, że finanse w większości przypadków muszą być chociaż oszacowane (budżety, budżety), dlatego najlepiej wykonać kilka warsztatów organizacyjnych i uściślić wszystkie wymagania biznesowe. Na tej podstawie oszacowana zostanie liczba sprintów niezbędnych do realizacji zadań przez wybrany zespół, co pozwoli na  wstępne określenie kosztu realizacji projektu.
Niestety nikt nie będzie w stanie obiecać, że oszacowany budżet pozostanie bez zmian. Nie da się przecież przewidzieć modyfikacji ani określić tego, co w trakcie realizacji będzie wymagało doprecyzowania.

Ważna jest jednak możliwość stałego wglądu i kontroli prac nad projektem i również z finansowego punktu widzenia jest w stanie sterować realizacją tak, aby uwzględniono wszystkie priorytety.

Brzmi zachęcająco? Zapewne tak, jednak rodzi się tutaj kolejna wątpliwość: skoro mam płacić za każdą godzinę pracy specjalistów agencji, to czy będę uczciwie rozliczany?
Niezbędna jest tutaj rzetelna analiza agencji, z którą będziemy współpracować: żeby zrealizować projekt w Agile musimy znaleźć zespół, któremu będziemy ufać. Tylko w ten sposób powstanie projekt najwyższej jakości, spełniający nasze oczekiwania.

Na co na pewno warto zwrócić uwagę przy wyborze wykonawcy? Na wielkość agencji i jej  doświadczenie. Jeśli agencja istnieje na rynku od wielu lat,  w swoim portfolio chwali się dużymi projektami, jeśli pracowała z rozpoznawalnymi markami i ma w swojej strukturze osoby o odpowiednich kompetencjach, z pewnością godna jest zainteresowania.  Warto nawiązać kontakt i zapoznać się z narzędziami, jakie wykorzystuje w monitorowaniu efektów swoich prac.

Co teraz? Jeśli masz doświadczony zespół któremu zaufasz, zaangażujesz się w projekt, aby na bieżąco go konsultować i korygować, to sukces masz gwarantowany.  Osiągnięty wynik (również finansowy) będzie o wiele  bardziej satysfakcjonujący,  aniżeli w przypadku projektu realizowanego w modelu stałej ceny.