Pliki cookies

Pliki cookies niezbędne zapewniają działanie strony. Analityczne i reklamowe (statystyki odwiedzin, pomiar skuteczności reklam) włączamy tylko za Państwa zgodą, którą można w każdej chwili zmienić lub wycofać w „Ustawieniach cookies” w stopce strony. Więcej: polityka cookies, polityka prywatności.

Blog

Fixed price czy time & material - który model rozliczenia wybrać (8 kryteriów)

Waga: zamknięta paczka z metką na poduszce buforu kontra klepsydra i klocki godzin - fixed price czy time & material

Fixed price wybierz, gdy zakres da się opisać do poziomu ekranu i nie zmieni się w trakcie; time & material - gdy produkt dopiero sprawdzasz na użytkownikach. Kwota stała zawiera bufor na ryzyko wykonawcy - według naszych szacunków z projektów zwykle 15–30% - a rozliczenie godzinowe przenosi to ryzyko na Ciebie. W większości projektów najlepiej działa model mieszany: stała cena za analizę i MVP, potem godziny z limitem. Aktualne stawki AppCreo znajdziesz w cenniku.

Poniżej 8 kryteriów wyboru, ten sam projekt policzony w obu modelach i zapisy, które chronią Cię w każdym z nich. Opis prawny jest poglądowy i nie stanowi porady prawnej.

Czym różni się fixed price od time & material?

W modelu fixed price wykonawca zobowiązuje się dostarczyć opisany zakres za z góry ustaloną kwotę. Płacisz za odebrane etapy, a ryzyko niedoszacowania pracy leży po stronie wykonawcy - i dlatego jest wliczone w cenę.

W Kodeksie cywilnym odpowiada temu wynagrodzenie ryczałtowe w umowie o dzieło. Wykonawca nie może żądać jego podwyższenia, nawet gdy nie dało się przewidzieć rozmiaru prac (art. 632 § 1). Wyjątek: gdy nieprzewidywalna zmiana stosunków grozi mu rażącą stratą, sąd może podwyższyć ryczałt albo rozwiązać umowę (art. 632 § 2).

W modelu time & material płacisz za faktycznie przepracowane godziny według stawek z umowy, na podstawie raportów. Taka umowa ma zwykle charakter umowy o świadczenie usług (art. 750 Kodeksu cywilnego): wykonawca odpowiada za staranne działanie, a zakres ustalacie na bieżąco.

Skąd popularność rozliczenia godzinowego

Zwinne metody wytwarzania oprogramowania zakładają zmianę planu w trakcie. Manifest programowania zwinnego ceni „reagowanie na zmiany” bardziej niż „realizację założonego planu”. Z kwotą stałą to się kłóci, bo każda zmiana wymaga aneksu.

Który model wybrać - 8 kryteriów?

Przejdź przez tabelę i zaznacz, który opis bardziej pasuje do Twojego projektu. Jeśli przeważa lewa kolumna, wybierz fixed price. Jeśli prawa - time & material. Remis oznacza model mieszany.

Fixed price czy time & material - 8 kryteriów wyboru modelu rozliczenia
Kryterium Fixed price Time & material
1. Zakres na starcie Opisany do poziomu ekranu i kryteriów odbioru Wystarczy cel, priorytety i pierwsze funkcje
2. Zmiany w trakcie Aneks i nowa wycena każdej zmiany Zmiana priorytetów w kolejnym cyklu pracy
3. Ryzyko przekroczenia budżetu Po stronie wykonawcy, wliczone w bufor Po stronie zamawiającego, ograniczane limitem
4. Cena końcowa Znana przed startem, z buforem na ryzyko - w naszych projektach zwykle 15–30% Znana po fakcie, bez bufora
5. Termin Zapisany w umowie, z karami za opóźnienie Zależy od decyzji podejmowanych w trakcie
6. Twój nakład pracy Skupiony na analizie i odbiorach Decyzje co tydzień przez cały projekt
7. Wpływ na priorytety Niski - wykonawca realizuje uzgodniony zakres Wysoki - Ty ustalasz kolejność prac
8. Rozliczenie Płatność za odebrane etapy Stawka z umowy × godziny z raportu

Kryteria 1 i 6 ważą najwięcej. Fixed price bez dokładnego zakresu to zgadywanie z doliczonym buforem. Time & material bez osoby, która co tydzień podejmuje decyzje, to płacenie za czekanie.

Typowe dopasowania

  • Fixed price: aplikacja odtwarzająca proces działający już w firmie, integracja o znanym API, strona lub panel według gotowego projektu.
  • Time & material: nowy produkt dla klientów, rozwój aplikacji po wdrożeniu, projekt z modułem AI, którego skuteczność trzeba sprawdzić na danych.
  • Model mieszany: większość projektów firmowych - stała cena za analizę i pierwszą wersję, godziny za dalszy rozwój.

Który model wychodzi taniej w tym samym projekcie?

Weźmy aplikację oszacowaną na 500 godzin. W rozliczeniu godzinowym płacisz za faktycznie przepracowane godziny według stawki z umowy. W fixed price wykonawca dolicza do szacunku bufor na ryzyko - w tym przykładzie 20% - i proponuje kwotę stałą. Co się dzieje w czterech scenariuszach?

Ten sam projekt (szacunek 500 h, bufor 20% w fixed price) w modelu fixed price i time & material - który model wychodzi taniej w czterech scenariuszach
Scenariusz Fixed price Time & material
Wszystko zgodnie z planem (500 h) Droższy - płacisz bufor ponad szacunek Tańszy - płacisz za 500 h
Praca trwała o 30% dłużej (650 h) Tańszy - kwota stała się nie zmienia Droższy - płacisz za 650 h
Zmiana zakresu o 100 h w trakcie (600 h) Droższy - kwota stała plus aneks za 100 h Tańszy - płacisz za 600 h
Obie sytuacje naraz (750 h) Tańszy - kwota stała plus aneks za 100 h Droższy - płacisz za 750 h

Fixed price działa jak ubezpieczenie: płacisz składkę w postaci bufora, niezależnie od tego, czy szkoda wystąpi. Opłaca się, gdy szacunek jest niepewny. Time & material wygrywa, gdy szacunek jest trafny, a zmiany zakresu i tak planujesz.

Tabela pokazuje też, dlaczego tak ważna jest analiza przed startem. Im dokładniejszy szacunek, tym mniejszy bufor w fixed price i mniejsze ryzyko w time & material. Jak sprawdzić, czy szacunek w ofercie jest wiarygodny, opisaliśmy w tekście o tym, jak czytać wycenę software house’u.

Jak działa model mieszany?

Model mieszany dzieli projekt na część, którą da się opisać, i część, której jeszcze nie znasz. Pierwszą rozliczasz kwotą stałą, drugą godzinami. W praktyce wygląda to tak:

  1. Analiza i warsztaty za kwotę stałą. Rezultat to lista funkcji, makiety i szacunek - Twój, niezależnie od dalszej decyzji.
  2. Pierwsza wersja produktu w fixed price. Zamknięty zakres MVP, z terminem i odbiorem. Tak prowadzimy budowę MVP.
  3. Odbiór i test na użytkownikach. Dopiero dane z użycia pokazują, co rozwijać dalej.
  4. Rozwój w time & material z limitem. Na przykład 80–120 h miesięcznie.
  5. Priorytety co dwa tygodnie. Krótki cykl pracy - w metodzie Scrum sprint trwa najwyżej miesiąc - i przegląd działającej wersji na końcu każdego cyklu.
  6. Raport godzin co tydzień, faktura co miesiąc. Z opisem zadań, a nie tylko sumą godzin.
  7. Większe moduły wyceniane osobno. Integracja z ERP czy płatności mogą dostać własny mini-fixed price, gdy ich zakres jest znany.
  8. Przegląd modelu co kwartał. Gdy produkt się stabilizuje, część prac może wrócić do kwot stałych.

Opisz aplikację w 3 zdaniach - odsyłamy przedział cenowy w 24 h w dni robocze. Napisz też, czy zakres jest już zamknięty - zaproponujemy model rozliczenia, który do niego pasuje. wypełnij formularz, napisz na biuro@appcreo.pl albo zadzwoń: +48 783 477 243.

Dwa warianty pośrednie

Time & material z pułapem. Rozliczasz godziny, ale umowa ustala maksymalną kwotę za etap. Jeśli zespół zmieści się w mniejszej liczbie godzin, płacisz mniej. Jeśli przekroczy pułap, nadwyżkę pokrywa wykonawca albo dzielicie ją w ustalonej proporcji.

Ten wariant sprawdza się, gdy zakres jest w większości znany, ale kilka elementów trudno wycenić z góry - na przykład integrację z nieudokumentowanym systemem. Wykonawca dolicza wtedy mniejszy bufor niż przy pełnej kwocie stałej.

Kwota stała za krótkie etapy. Projekt dzielisz na etapy po kilka tygodni i każdy wyceniasz osobno, dopiero po odebraniu poprzedniego. Ryzyko złej wyceny dotyczy jednego etapu, a nie całego projektu, a kierunek zmieniasz między etapami bez aneksów.

Minusem jest mniejsza przewidywalność całego budżetu: znasz cenę najbliższego etapu, a kolejnych tylko szacunkowo. Dlatego także w tym wariancie poproś na starcie o orientacyjny przedział dla całości.

Jak zabezpieczyć się w każdym z modeli?

Oba modele działają dobrze tylko z odpowiednimi zapisami w umowie. Szerzej o umowie piszemy w tekście umowa z software housem; tu zapisy związane z modelem rozliczenia.

Fixed price

  • Załącznik z zakresem, kryteriami odbioru i listą rzeczy, których w projekcie nie ma.
  • Procedura zmian: forma zgłoszenia, termin wyceny zmiany, stawka dla aneksów.
  • Płatności za odebrane etapy, a nie z góry za całość.
  • Definicja błędu objętego gwarancją - w odróżnieniu od nowej funkcji.
  • Kary za opóźnienie działające w obie strony, z limitem.

Time & material

  • Miesięczny limit godzin i próg, po którym wykonawca musi Cię uprzedzić - na przykład 80% limitu.
  • Stawki dla każdej roli zapisane w umowie i zasady ich zmiany.
  • Tygodniowy raport z opisem zadań i czasem pracy nad każdym z nich.
  • Wgląd w tablicę zadań przez cały czas trwania projektu i podgląd postępu na środowisku testowym.
  • Krótki termin wypowiedzenia i przekazanie kodu po zakończeniu współpracy.

Jakie błędy popełnia się przy wyborze modelu?

Pięć błędów, które najczęściej kończą się sporem o budżet:

  • Fixed price bez analizy. Wykonawca zgaduje zakres, więc albo dolicza duży bufor, albo zarabia na aneksach.
  • Time & material bez właściciela produktu. Nikt po stronie firmy nie ustala priorytetów, a godziny płyną.
  • Wybór po stawce godzinowej. Niższa stawka nie oznacza niższego kosztu, jeśli zespół potrzebuje więcej godzin.
  • „Fixed price z nieograniczonymi poprawkami”. Taka obietnica jest nierealna - wykonawca zabezpieczy się ceną albo jakością.
  • Zmiana modelu w połowie bez rozliczenia. Przejście z kwoty stałej na godziny wymaga odbioru tego, co już zrobiono.

Jeśli nie wiesz, który model wybrać, zacznij od płatnej analizy i dopiero z jej wynikiem wybierz rozliczenie. Jak wygląda to u nas krok po kroku, opisujemy na stronie o procesie współpracy, a ceny znajdziesz w cenniku.

Najczęściej zadawane pytania

Przy trafnym szacunku i stabilnym zakresie tańszy jest time & material, bo nie płacisz bufora na ryzyko, który wykonawca wlicza w kwotę stałą - według naszych szacunków z projektów zwykle 15–30%. Gdy zakres się rozrasta albo szacunek był zbyt optymistyczny, tańszy okazuje się fixed price. O wyniku decyduje więc jakość analizy przed startem, a nie sam model.

Od roli, doświadczenia i technologii. Stawki bywają różne dla programisty, testera, projektanta i kierownika projektu albo uśrednione dla całego zespołu. Porównując oferty, patrz na sumę godzin i skład zespołu, bo niższa stawka z większą liczbą godzin może kosztować więcej. Stawkę dla każdej roli zapisz w umowie, razem z zasadami jej zmiany.

Tak, ale przez procedurę zmian: zgłoszenie, wycenę zmiany, akceptację na piśmie i nowy termin. Każda zmiana to aneks, więc przy wielu zmianach fixed price traci przewagę przewidywalności. Jeśli spodziewasz się częstych korekt, rozlicz tę część projektu godzinowo z limitem albo przenieś zmiany do kolejnego etapu.

Ustal miesięczny limit godzin i próg, po którym wykonawca musi Cię uprzedzić. Wymagaj raportu co tydzień z opisem zadań, a nie tylko sumą godzin. Miej wgląd w tablicę zadań, oglądaj postęp na środowisku testowym, a priorytety ustalaj co dwa tygodnie. Po miesiącu wiesz wtedy, ile kosztuje konkretna funkcja, a nie tylko ile kosztował miesiąc.

Częściowo. Chroni przed niedoszacowaniem pracy, bo przy wynagrodzeniu ryczałtowym w umowie o dzieło wykonawca nie może żądać podwyższenia ceny (art. 632 Kodeksu cywilnego). Nie chroni przed zmianami zakresu zgłaszanymi przez Ciebie ani przed brakami w specyfikacji. Budżet najczęściej przekraczają aneksy, dlatego kluczowa jest analiza przed podpisem.

Domyślnie stałą ceną za etap, ustaloną po warsztacie i projekcie UX, więc wiesz z góry, ile zapłacisz i za co. Rozliczenie godzinowe proponujemy przy projektach o otwartym zakresie, na przykład przy rozwoju produktu po pierwszej wersji. Mówimy o tym wprost już na etapie wyceny, razem z proponowanym limitem godzin.

Źródła