Fixed price czy godziny? Jak rozliczyć projekt IT bez niespodzianek

Zlecasz projekt software'owy i dostajesz dwie wyceny: jedna to konkretna kwota „za całość”, druga to stawka za godzinę plus szacowany czas. Która jest dla Ciebie lepsza? To nie jest pytanie o to, który model jest „uczciwszy”, oba bywają uczciwe i oba bywają pułapką. Pytanie brzmi: który pasuje do Twojego projektu, budżetu i tolerancji na ryzyko. Poniżej rozkładam fixed price i rozliczenie godzinowe (time & material) na czynniki pierwsze, z plusami i minusami obu, bez udawania, że istnieje jeden słuszny wybór.

Dwa modele w pigułce

Fixed price (stała cena) to umowa na z góry ustalony zakres za z góry ustaloną kwotę. Wykonawca bierze na siebie ryzyko, że robota zajmie więcej, niż zakładał.

Time & material (godziny) to rozliczenie za faktycznie przepracowany czas według stawki godzinowej lub dziennej. Ryzyko niedoszacowania leży po Twojej stronie, płacisz za tyle pracy, ile realnie wejdzie.

Cała reszta to warianty i hybrydy tych dwóch. Najkrótsze porównanie wygląda tak:

Fixed price: plusy i minusy

Po stronie plusów:

• Przewidywalność budżetu. Znasz końcową kwotę przed startem. Łatwo zaplanować cash flow i przypisać konkretne złotówki do konkretnej pozycji.
• Ryzyko po stronie wykonawcy. Jeśli zadanie zajmie dwa razy dłużej, to jego problem, nie Twój, o ile zakres się nie zmienił.
• Prostsze rozliczenie. Jedna kwota, jasne kamienie milowe, brak comiesięcznego liczenia godzin i tłumaczenia się z każdej pozycji.

Po stronie minusów, i to trzeba powiedzieć wprost:

• Ryzyko niedoszacowania = bufor w cenie. Wykonawca, który bierze ryzyko na siebie, wlicza je w wycenę. Za przewidywalność płacisz narzutem, nawet jeśli projekt pójdzie gładko.
• Sztywność. Każda zmiana zakresu to renegocjacja. Model premiuje trzymanie się ustaleń, nie reagowanie na nowe pomysły z rynku.
• Pokusa cięcia jakości. Jeśli wykonawca źle wycenił, presja na „domknięcie” potrafi zejść na testy, edge case'y albo dokumentację. Dobra umowa i jasne kryteria odbioru to ograniczają, ale ryzyko istnieje.

Time & material: plusy i minusy

Plusy:

• Elastyczność. Zmieniasz priorytety w trakcie, dokładasz pomysł z researchu użytkowników, rezygnujesz z funkcji, bez aneksów do umowy za każdym razem.
• Płacisz za realną pracę. Brak bufora „na wszelki wypadek”. Jeśli projekt pójdzie sprawnie, zapłacisz mniej, niż wyniosłaby stała cena.
• Transparentność. Widzisz, na co schodzi czas. Przy uczciwym raportowaniu to świetne narzędzie do zarządzania, a nie tylko faktura.

Minusy, równie szczere:

• Ryzyko budżetowe po Twojej stronie. Niedoszacowanie to Twój problem. Faktura potrafi rosnąć szybciej niż sam produkt.
• Wymaga Twojego zaangażowania. Bez właściciela produktu, który pilnuje priorytetów, godziny rozpływają się w „drobnych poprawkach”.
• Trudniej porównać oferty. Niższa stawka godzinowa nie znaczy taniej, wolniejszy zespół po niższej stawce wyjdzie drożej. Stawka bez estymacji to połowa informacji.

Kiedy fixed price wygrywa

Stała cena ma sens, gdy:

• Zakres jest znany i stabilny. Wiesz, co budujesz, masz makiety, user stories, jasną definicję „gotowe”. Im lepiej opisany zakres, tym mniejszy bufor ryzyka w cenie.
• Budżet jest ograniczony i sztywny. Masz do wydania konkretną kwotę i nie możesz pozwolić sobie na niespodziankę na fakturze.
• Chcesz przewidywalności. Raportujesz do zarządu, inwestora albo wspólnika i potrzebujesz jednej liczby, a nie widełek „mniej więcej”.
• Projekt jest zamknięty. Wdrożenie, migracja, MVP z jasną listą funkcji, coś, co ma początek i koniec.

Kiedy godziny mają sens

Rozliczenie godzinowe wygrywa, gdy:

• Zakres jest zmienny z natury. Research, eksperymenty, produkt, który dopiero szuka product-market fit. Nie da się rzetelnie wycenić czegoś, czego kształt jeszcze nie istnieje.
• To długi, ciągły rozwój. Produkt rozwijany latami, z roadmapą, która żyje. Wymuszanie fixed price na każdym sprincie to więcej narzutu niż wartości.
• Priorytety zmieniają się szybko. Startup po launchu, w którym dane z rynku co tydzień przestawiają plany.
• Masz zespół i własność produktu. Potrafisz zarządzać backlogiem i realnie pilnować, na co schodzi czas.

Jak rozliczamy projekty w SEVENEDGE

Najczęstszy ból, jaki słyszymy od founderów, to nie „model X jest zły”, tylko „dostałem fakturę większą, niż się umawialiśmy”. Dlatego ułożyliśmy to tak, żeby tej sytuacji po prostu nie było:

• Transparentne widełki przed scoping callem. Zanim cokolwiek ustalimy, znasz rząd wielkości. Żadnego „to zależy” w nieskończoność, orientacyjny przedział dostajesz od razu, żeby było jasne, czy w ogóle gramy w tej samej lidze budżetowej. Aktualne widełki trzymamy na stronie cennik.
• Fixed price po ustaleniu zakresu. Na scoping callu domykamy, co dokładnie powstaje. Wychodzisz z niego ze stałą ceną i terminem, nie z włączonym licznikiem godzin.
• Nowy zakres = nowa propozycja, nie pęczniejąca faktura. Jeśli w trakcie pojawi się pomysł spoza ustaleń, dostajesz osobną, jasną wycenę tej zmiany. Decydujesz, czy wchodzisz. Faktura za pierwotny zakres się nie rusza.

To nie jest magiczny trzeci model, to fixed price poprzedzony uczciwym scopingiem, poukładany tak, żeby nie było niespodzianek. Dla projektów badawczych albo długiego rozwoju proponujemy rozliczenie godzinowe, ale mówimy o tym wprost, zamiast udawać, że wszystko da się zamknąć w jednej kwocie. Jak wygląda droga od zapytania do wdrożenia, rozpisaliśmy krok po kroku w naszym procesie.

Czego pilnować w umowie, niezależnie od modelu

Model rozliczeń to jedno. Umowa to drugie, i tu founderzy najczęściej się przejeżdżają. Niezależnie od tego, czy płacisz fixed, czy za godziny, sprawdź trzy rzeczy:

• Definicja zakresu. Co dokładnie wchodzi, a co nie. W fixed price to fundament ceny; w godzinach, punkt odniesienia, od którego liczysz odchylenia. „Zrobimy aplikację” to nie zakres. „Logowanie, panel z trzema rolami, integracja z systemem płatności”, to zakres.
• Kamienie milowe i kryteria odbioru. Kiedy płacisz, za co i jak poznajesz, że etap jest „gotowy”. Płatności powiązane z odbiorem działającego fragmentu chronią obie strony przed sporem o to, czy coś jest skończone.
• Własność kodu. Upewnij się, że kod i prawa autorskie przechodzą na Ciebie, najlepiej od pierwszego dnia, w Twoim repozytorium. Bez tego płacisz za coś, czego formalnie nie posiadasz, i ryzykujesz vendor lock-in.

Który model wybrać?

Skrót decyzji: znany zakres i sztywny budżet → fixed price. Zmienny zakres i długi rozwój → godziny. A jeśli nie jesteś pewien, po której jesteś stronie, to sam ten brak pewności jest sygnałem, warto najpierw usiąść do scopingu i zamienić mgłę w konkretną listę, zanim zdecydujesz o modelu.

Najgorszy wybór to model dopasowany do wygody wykonawcy, a nie do Twojego projektu. Drugi najgorszy to brak umowy, która jasno opisuje zakres, kamienie milowe i własność kodu, bo wtedy nawet najlepszy model rozliczenia Cię nie ochroni.

Najłatwiej zobaczyć to na projekcie o zamkniętym zakresie, choćby przy budowie MVP, gdzie stała cena po scopingu naprawdę gra na Twoją korzyść. Wyceny nie zrobi się w próżni, ale dobry scoping zwykle szybko pokazuje, który model pasuje do Twojego projektu, więc jeśli chcesz przejść przez to na konkretach, opisz nam swój projekt.