Chcąc skorzystać z usług programistów mamy do wyboru dwa podstawowe modele rozliczenia: Fixed Price i Time + Material. W zależności od przypadku możliwe jest uzgodnienie modelu hybrydowego, łączącego najlepsze cechy obu modeli – zdarza się to jednak zdecydowanie rzadziej.

We FROGRIOT testowaliśmy już wszystkie metody rozliczeń – od standardowych umów SLA, przez Fixed Price i Time + Material, po hybrydowe rozwiązanie szyte na miarę… i żadne z nich nie okazało się równie uniwersalne jak Time + Material ??‍♀️

Rozumiemy jednak, że wybór odpowiedniego modelu rozliczeń dla projektu z branży IT bez podobnego doświadczenia może nie być oczywisty dla każdego ?Właśnie dlatego przygotowaliśmy szczegółowe porównanie dwóch najpopularniejszych typów : Fixed Price oraz Time + Material.

Estymacja projektu – od czego zależy?

Zacznijmy od podstaw, czyli tego w jaki sposób firmy programistyczne ustalają stawkę za zlecenie.

Estymowanie ostatecznej ceny projektu, który jeszcze nie istnieje przypomina próbę przewidywania przyszłości – w zależności od posiadanej na starcie wiedzy, Twoje przewidywania będą mniej lub bardziej dokładne. 

Co jest brane pod uwagę przy estymacji?

• Jaki jest cel projektu?
• W jaki sposób Zlecający oraz Wykonawca będą w stanie ocenić, czy projekt został zrealizowany?
• Jakie materiały są potrzebne do realizacji i kto je dostarcza?
• Jakie informacje są potrzebne do realizacji i kto je dostarcza?
• Jaki jest zakres projektu – jakie funkcjonalności mają się w nim znaleźć?
• Jaki jest zakres projektu – jakie usługi/umiejętności są potrzebne do realizacji projektu?
• Jaki jest budżet?
• Jaki jest deadline?
• Jaka technologia ma zostać użyta?
• Jaki jest poziom skomplikowania projektu?
• Czy Zlecający deleguje osobę z wiedzą techniczną wymaganą do konsultacji przy projekcie?
• Czy potrzebne będą usługi po dostarczeniu projektu?
• Kto będzie realizował projekt (zasoby po stronie Wykonawcy)
• Jaki jest koszt materiałów?
• Jaki jest minimalny koszt projektu po stronie Wykonawcy?
• Jaki jest poziom ryzyka i niewiadomych?
• Czy testy są uwzględnione i jeżeli tak, to jak mają wyglądać?
• Czy projekt będzie ulegał zmianom w trakcie realizacji? Jeżeli tak, to ile będzie takich zmian, czego mogą dotyczyć?
• Ile konsultacji ze Zlecającym powinno zostać uwzględnionych w estymacji? Ile jest kamieni milowych, które będą wymagały akceptacji Zlecającego w celu kontynuacji realizacji projektu? 
• Czy Wykonawca ma już doświadczenie w realizacji podobnych projektów i funkcjonalności?
• Czy projekt posiada dokumentację projektową? Czy scope jest jasno rozpisany, a wszystkie niezbędne informacje są przekazane Wykonawcy?
• Jaka jest historia współpracy ze Zlecającym? Jak wygląda dotychczasowy kontakt z nim?
• Jak ma wyglądać licencja na wytworzone oprogramowanie?
• Do kogo mają należeć prawa autorskie?
• Czy projekt wymaga podpisania SLA?
• Ile ma być wersji językowych, kto zajmie się tłumaczeniem i wprowadzaniem kontentu?
• Czy będzie obowiązywała gwarancja? Jeżeli tak, to jak długo, na jakich podstawach (jakie testy zostaną wykonane przed oddaniem projektu, jaki jest na to budżet)?
• Jaki będzie przewidywany ruch i koszt infrastruktury?
• Jak ma wyglądać deployment? Czy konieczna jest wersja testowa projektu?
• Jakie jest otoczenie biznesowe? Tworzenie sztywnych założeń (w dokumentacji) może spowodować, że cele biznesowe przeterminują się w czasie realizacji projektu ze względu na zmiany zewnętrzne (vide koronawirus) – jaki wpływ może to mieć na projekt?

… a to jedynie najważniejsze elementy. Dobrym przykładem tego jak szczegółowe elementy mogą podlegać wycenie przy tworzeniu np. MVP jest nasz wpis o tym z czego składa się dokumentacja projektowa.

Na czym polega ocena ryzyka projektowego?

Projekty webdeveloperskie zawsze niosą ze sobą pewien poziom ryzyka; ryzyko z kolei jest nieodłącznie związane z dodatkowymi kosztami. 

Istnieje wiele czynników, które są niepewne przy szacowaniu kosztów. Przykładowo, jeżeli projekt nie jest podobny do poprzednich realizacji, Wykonawca nie będzie w stanie oprzeć wyceny na swoim doświadczeniu. Z drugiej strony, jeżeli projekt jest podobny do wcześniejszych realizacji, Wykonawca powinien przeanalizować historyczne dane i na ich podstawie wyciągnąć wnioski o możliwym poziomie ryzyka. Im bardziej projekt jest skomplikowany i rozłożony w czasie, tym większa będzie niepewność przy planowaniu harmonogramu – wystarczy pojawienie się jednego buga, aby każdy następny etap przesunął się w czasie. 

Jest jeszcze zespół: dostępny poziom umiejętności i doświadczenia będzie miał duży wpływ na ogólne koszty projektu. Jeżeli jakikolwiek element projektu jest nowością dla zespołu (np. nowa infrastruktura, nowy język programowania, integracje z nieznanym oprogramowaniem trzecim), szanse na nieprzewidziane problemy wzrastają – a wraz z nimi poziom ryzyka. Do tego dochodzą jeszcze takie elementy jak dostępność zasobów ludzkich (w tym nie tylko programistów, ale także PM’a z odpowiednim dla projektu doświadczeniem) oraz poziom zgrania zespołu, który miałby zostać oddelegowany do tego konkretnego zlecenia.

Co jest brane pod uwagę przy ocenie ryzyka projektowego? 

Ryzyko projektowe bierze pod uwagę dwa typy niewiadomych: znane niewiadome i nieznane niewiadome. Identyfikacja jednych i drugich może się odbywać różnymi metodami, ale co do zasady – każdy Wykonawca będzie robił to po swojemu.

W dużym skrócie elementy ryzyka można podsumować następująco:

• bugi, ich naprawa oraz ewentualne koszty dochodzenia odpowiedzialności za nie;
• problemy z konfiguracjami (szczególnie w wypadku integracji oprogramowania stron trzecich);
• problemy z kompatybilnością poszczególnych elementów (szczególnie oprogramowania stron trzecich);
• nieprzewidziane problemy techniczne;
• drobne zmiany w projekcie po stronie Zlecającego;
• większe zmiany w projekcie po stronie Zlecającego;
• czas potrzebny na konsultacje wewnętrzne;
• czas potrzebny na konsultacje ze Zlecającym – jaka jest responsywność i merytoryczność osoby oddelegowanej do projektu po stronie Zlecającego?
• czas uzyskania materiałów (bezpośrednio powiązane z pytaniem wyżej). Czy elementy, które ma dostarczyć Zlecający pojawią się na czas i jeżeli nie, to co w takim przypadku?
• elastyczność projektu i budżetu – jeżeli w trakcie realizacji okaże się, że wybrana przez Zlecającego technologia lub funkcjonalność nie będzie kompatybilna z innymi uzgodnionymi elementami – co wtedy?
• brak doświadczenia lub konkretnych umiejętności (a co za tym idzie, konieczność outsourcingu poszczególnych elementów i zadań oraz ryzyko z tym związane).

Podsumowując, im więcej jakościowych informacji Wykonawca otrzyma od Zlecającego, tym łatwiejsze będzie obliczanie kosztów i czasu wytworzenia oprogramowania. Nasze doświadczenie jasno pokazuje, że większość zapytań estymacyjnych zwykle wiąże się z koniecznością wspólnego ustalania i doprecyzowania wymagań – bardzo rzadko trafia się Klient z gotową dokumentacją projektową, na której możemy oprzeć wycenę realizacji.

Fixed price – definicja, wady i zalety

Definicja:

Fixed Price – rozliczenie za część lub całość zlecenia po ustalonej z góry cenie, w ustalonym z góry terminie. 

Zalety: 

• z góry ustalona cena, którą łatwiej zabudżetować w czasie po stronie Zlecającego;
• z góry ustalone wytyczne, które zapewniają plan działania dla obu stron (Wykonawca ma pełne zrozumienie wymagań dotyczących projektu, ponieważ każdy jego element jest już zdefiniowany; Zlecający wie czego wymagać przy odbiorze projektu);
• z góry ustalony harmonogram (nieprzesuwalny deadline dostarczenia projektu);
• odpowiedni dla małych projektów o ograniczonym zakresie;
• odpowiedni dla MVP o małej skali i/lub jasno określonej funkcjonalności (przy założeniu wykonania dokumentacji projektowej);
• mniejsze zaangażowanie po stronie Zlecającego (po jego stronie zostaje głównie zlecenie projektu, dostarczenie materiałów, a następnie odebranie projektu).

Wady:

• wymaga szczegółowej dokumentacji projektowej;
• wymaga określenia zaawansowania i rodzaju testów, jakie powinny zostać wykonane przed oddaniem projektu (co ma bezpośrednio wpływ na wysokość estymacji po stronie Wykonawcy); każda zmiana (poszerzenie) tych ustaleń będzie podlegała dodatkowej estymacji;
• start prac opóźniony w czasie do momentu dostarczenia dokumentacji projektowej;
• Zlecający nie ma kontroli nad projektem w trakcie jego realizacji – otrzymuje gotowy produkt;
• nieelastyczny – jakakolwiek zmiana wymaga konsultacji po obu stronach odnośnie propozycji zmiany, ponownej estymacji i planowania harmonogramu prac, konsultacji w celu zaakceptowania (lub nie) nowej estymacji i harmonogramu i dopiero wtedy wznowienia prac;
• wyższa cena. Estymacja podawana jest „z górką” – Wykonawca dodaje do estymacji X godzin pracy poszczególnych członków zespołu, w zależności od tego jak wysoko ocenia ryzyko napotkania przeszkód podczas realizacji projektu – bez względu na to, czy ostatecznie te przeszkody się pojawią, czy nie. Przykładami niewiadomych wpływających na poziom ryzyka mogą być: bugi, konfiguracje, problemy z kompatybilnością poszczególnych elementów, problemy techniczne, drobne zmiany w projekcie, większe zmiany w projekcie, czas konsultacji, czas uzyskania materiałów itd.;
• Niewiadomą może też być otoczenie biznesowe; tworzenie sztywnych założeń (w dokumentacji) może spowodować, że cele biznesowe przeterminują się w czasie realizacji projektu ze względu na zmiany zewnętrzne (vide koronawirus);
• Wymaga od Zlecającego posiadania wiedzy technicznej, w celu oceny prawdopodobieństwa/rzeczowości estymacji przed zawarciem umowy i rozpoczęciem realizacji;
• w wypadku jakichkolwiek bugów/problemów, przed ich rozwiązaniem musi nastąpić badanie przyczyny (ustalenie czy odpowiedzialność leży po stronie Wykonawcy, Zlecającego czy problem jest wynikiem np. oprogramowania strony trzeciej), następnie zdefiniowanie i estymacja czasowa wymaganych prac naprawczych, a potem konsultacja odnośnie dalszych kroków po obu stronach (przesunięcie harmonogramu, przesunięcie priorytetów prac, ewentualna dodatkowa estymacja kosztów) – w rezultacie realizacja projektu jest wstrzymana na czas dochodzenia i konsultacji, co znacznie opóźnia jego ukończenie*.

*Firmy informatyczne często uznają podobne sytuacje za element ryzyka, a tym samym odpowiednio podnoszą cenę przy Fixed Price.

Wymagania:

– szczegółowo rozpisane wymagania, zakres projektu, technologie, user journeys i inne elementy po stronie Zlecającego; innymi słowy: przygotowanie i dostarczenie dla Wykonawcy pełnej dokumentacji projektowej.

Time + material – definicja, wady i zalety

Definicja:

Time + Material – rozliczenie według faktycznie przepracowanych godzin (liczonych dla każdego członka zaangażowanego w zlecenie zespołu po stronie Wykonawcy) oraz ewentualnych kosztów materiałowych (np. koszty serwerów, domen, wtyczek WordPress itd.).

Zalety: 

• nie wymaga szczegółowej dokumentacji projektowej – można ją wypracować wspólnie w trakcie realizacji projektu;
• realizację można zacząć „od zaraz”;
• Zlecający ma pełną kontrolę nad każdym aspektem projektu podczas jego realizacji
• elastyczny. Klient oraz Wykonawca są w stałym kontakcie i pracują nad realizacją zlecenia wspólnie – jak jeden, zgrany zespół. Dzięki temu, wszelkie zmiany (wywołane problemami technicznymi lub niekompatybilnością elementów, ale także m.in. zmianami deadline’u, budżetu, otoczenia biznesowego czy dotyczące nieprzewidzianych wcześniej możliwości usprawnień) są omawiane na bieżąco i bezproblemowo wprowadzane. Co więcej, możliwe jest rozpoczęcie prac nad ustalonymi już funkcjonalnościami, bez konieczności jednoczesnego doprecyzowania pozostałych elementów (np. postawienie środowiska i szablonów najważniejszych widoków, bez doprecyzowanego jeszcze widoku graficznego);
• niższa cena (Zlecający płaci wyłącznie za realnie przepracowane godziny Wykonawcy i nie ponosi kosztów „ryzyka”);
• nie wymaga od Zlecającego posiadania wiedzy technicznej, w celu oceny prawdopodobieństwa/rzeczowości estymacji przed zawarciem umowy i rozpoczęciem realizacji (wszelkie techniczne aspekty, narzędzia i rozwiązania są omawiane ze Zlecającym w trakcie realizacji i odpowiednio dostosowywane do jego potrzeb);
• dobry dla projektów, które nie mają jeszcze w pełni zdefiniowanych wymagań;
• dobry dla projektów rozłożonych w czasie (trwających dłużej niż np. miesiąc);
• szybszy czas realizacji projektu – w sytuacji pojawienia się jakichkolwiek problemów/bugów, Wykonawca natychmiast je rozwiązuje, nie tracąc czasu na dochodzenie ws. odpowiedzialności;
• testy przed oddaniem projektu mogą być pogłębione lub zawężone – w zależności od potrzeb i decyzji Zlecającego;
• możliwe jest ciągłe dostarczanie, dzięki czemu Zlecający otrzymuje ciągle nowe, działające elementy produktu;
• możliwa jest ciągła weryfikacja i adaptacja, Zlecający może dostosowywać produkt do zmiennych warunków otoczenia biznesowego, szybko reagować na zmiany i wprowadzać korekty.

Wady: 

• brak z góry ustalonej ceny, poza ustaleniem maksymalnej wysokości kosztów (trudniejsze do budżetowania w czasie po stronie Zlecającego);
• brak z góry ustalonego harmonogramu działań (poza wyznaczeniem kamieni milowych (eng. milestones);
• większe zaangażowanie po stronie Zlecającego (w naszej opinii jest to zaleta, ale rozumiemy, że nie każdy się z tym zgodzi 🙂 Wymieniamy więc zaangażowanie w wadach, ale jako kategorię subiektywną).

Wymagania:

– elastyczny budżet;
– osoba oddelegowana do kontaktu z Wykonawcą po stronie Zlecającego;
– gotowość na większe zaangażowanie w projekt po stronie Zlecającego (osoba oddelegowana bierze udział w konsultacjach dotyczących m.in. bieżących prac nad projektem w zakresie projektowania UX oraz UI, tworzenia funkcjonalności, rozpisywania person, ścieżek użytkowników itd.

Fixed Price vs. T+M – tabela najważniejszych różnic

Fixed price vs. T+M – kiedy stosować? (+ przykłady projektów/case’ów)

Kiedy stosujemy Fixed Price?

✅kiedy projekt posiada pełną dokumentację projektową, na której można oprzeć wycenę LUB kiedy mamy szczegółowo rozpisany zakres oraz harmonogram prac;
✅kiedy mamy zaufanego dostawcę, z którym realizowaliśmy już projekt o takim samym/bardzo podobnym zakresie;
✅kiedy mamy ograniczony, jasno określony z góry budżet;
✅kiedy chcemy zrealizować niewielki projekt o ograniczonym zakresie;
✅kiedy chcemy stworzyć MVP o małej skali i/lub jasno określonej funkcjonalności (oraz dokumentację projektową).

Kiedy stosujemy Time + Material?

✅kiedy projekt nie posiada dokumentacji projektowej, na której można oprzeć wycenę LUB kiedy nie mamy szczegółowo rozpisanego zakresu oraz harmonogramu prac (innymi słowy: kiedy w początkowej fazie mamy trudności z jasnym określeniem zakresu, harmonogramu i kształtu projektu);
✅kiedy prowadzimy długoterminowy projekt;
✅kiedy prowadzimy projekt, którego wymagania mogą ulec zmianie (dynamiczny);
✅kiedy potrzebujemy elastyczności i szybkich modyfikacji;
✅kiedy zależy nam na większej kontroli nad jakością prac;
✅kiedy zależy nam na szybszym starcie realizacji projektu;
✅kiedy zależy nam na niższej cenie końcowej projektu.

Podsumowanie

W zależności od charakteru projektu, jego skomplikowania oraz poziomu doprecyzowania wymagań (przed startem realizacji) dobierany jest odpowiedni model rozliczeniowy.

Jako firma pracowaliśmy wielokrotnie w obu modelach, a także rozwiązaniach hybrydowych (głównie spowodowanych nagłą potrzebą odejścia od Fixed Price na rzecz bardziej elastycznych działań); obecnie pracujemy prawie wyłącznie w modelu Time + Material.

Z naszego doświadczenia wynika, że Time + Material przynosi szybsze i bardziej jakościowe rezultaty, niż Fixed Price: start projektu nie wymaga dodatkowych przygotowań; Klient ma wgląd w wykonywane prace oraz kontrolę na każdym etapie realizacji; wszelkie problemy (oraz ulepszenia) są bezproblemowo uzgadniane “w locie”, a do tego stopniowa ewaluacja projektu zaczyna się właściwie równocześnie z jego developmentem. Nie bez znaczenia są też niższe koszty – Time + Material nie zawiera marginesu ryzyka, ponieważ jest ono rozłożone pomiędzy Wykonawcę oraz Zlecającego (w odróżnieniu od Fixed Price, gdzie Wykonawca bierze na siebie całe ryzyko jeszcze przed startem projektu).

Z drugiej strony, model Fixed Price jest zdecydowanie lepszy dla niewielkich, mało skomplikowanych i krótkotrwałych projektów, z którymi Wykonawca ma już spore doświadczenie (a więc jest w stanie bez problemu oszacować odpowiedni poziom ryzyka) – np. postawienie jednego landing page, dodanie elementu tekstowo-graficznego do istniejącej już strony, zapięcie SSL itp. 

Czas jednak na decydujący argument:

DOBRO PROJEKTU może być inaczej rozumiane i traktowane w przypadku obu modeli.

W modelu Fixed Price, od momentu zaakceptowania kosztów i podpisania umowy, Wykonawca robi wszystko, aby zmieścić się w założonym budżecie i nie szuka alternatywnych, lepszych rozwiązań. W praktyce można powiedzieć, że Wykonawca zmuszony jest (dla zachowania rentowności) stanąć po stronie budżetu, a nie projektu.

W modelu Time + Material najważniejszy jest projekt oraz sposób jego realizacji – nie budżet. Jest to kolosalna różnica w podejściu oraz jakości pracy! Bezsprzecznie i nieporównywalnie lepiej jest pracować zespołowo nad wspólnym celem, mając na uwadze dobro projektu i na każdym kroku szukając możliwości ulepszeń, aniżeli skupiać się na dostarczeniu wyłącznie niezbędnego minimum… ??‍♀️