Dyrektor IT dostaje dwie oferty na ten sam system. Pierwsza: 2 400 000 zł, cena stała, termin dziewięć miesięcy, zakres zgodny z załączoną specyfikacją. Druga: model time & material, szacunek 1 750 000 zł z zastrzeżeniem, że jest to punkt środkowy przedziału 1 500 000–2 100 000 zł. Komitet inwestycyjny wybiera pierwszą, bo — jak brzmi uzasadnienie w protokole — „przenosi ryzyko na dostawcę i daje przewidywalność budżetu”. Dwadzieścia miesięcy później projekt zamyka się kwotą 3 100 000 zł: cena bazowa plus jedenaście wniosków o zmianę, z których żaden nie był negocjowany w warunkach konkurencji, bo w połowie realizacji nie ma alternatywnego dostawcy.
Ta historia powtarza się w polskim rynku IT na tyle regularnie, że przestała być anegdotą, a stała się wzorcem. Jej sednem nie jest nieuczciwość dostawcy ani niekompetencja klienta. Sednem jest cena ryzyka, której nikt nie rozbił na czynniki przed podpisaniem umowy. Ten artykuł broni tezy, z którą wielu kupujących usługi IT się nie zgodzi: przy tej samej dostawie fixed-price wychodzi drożej niż time & material, bo dostawca wycenia ryzyko z zapasem, a klient płaci ten zapas w stu procentach przypadków, podczas gdy ryzyko materializuje się w mniejszości z nich. Fixed-price nie jest przeniesieniem ryzyka. Jest zakupem polisy — i jak każda polisa, jest droższy niż wartość oczekiwana szkody, bo inaczej jej sprzedawca by nie zarabiał.
Co klient faktycznie kupuje, płacąc cenę stałą?
Warto nazwać precyzyjnie, co przechodzi na drugą stronę wraz z podpisem pod umową o cenie stałej. Nie przechodzi ryzyko, że system nie zadziała. Nie przechodzi ryzyko, że rozwiązanie nie odpowie na potrzebę biznesową. Nie przechodzi ryzyko opóźnienia w sensie biznesowym — kara umowna rekompensuje ułamek strat wynikających z tego, że kampania nie wystartowała na czas. Przechodzi wyłącznie jedno: ryzyko wariancji kosztu wytworzenia.
To jest realna wartość i nie ma sensu jej deprecjonować. Dyrektor finansowy, który musi zamknąć rok bez odchylenia od budżetu inwestycyjnego, kupuje przewidywalność, a przewidywalność jest warta pieniędzy. Problem zaczyna się tam, gdzie ta wartość nie jest zestawiana z ceną. Nikt nie kupuje ubezpieczenia, nie pytając o składkę. W kontraktach IT składka jest wliczona w jedną liczbę na pierwszej stronie oferty i praktycznie nigdy nie jest pokazana osobno.
Druga rzecz, którą klient kupuje niechcący, to zmiana relacji z dostawcy na przeciwnika w sporze o zakres. W modelu czasowo-materiałowym pytanie „czy to mieści się w umowie” nie ma znaczenia ekonomicznego — praca jest rozliczana tak czy inaczej. W cenie stałej to pytanie jest jedynym, które ma znaczenie, bo od odpowiedzi zależy, czyja marża zostanie naruszona. Cały aparat, który powstaje wokół tej odpowiedzi — protokoły odbioru, komisje, opinie, eskalacje — jest kosztem, którego w modelu czasowo-materiałowym po prostu nie ma.
Jak dostawca faktycznie wycenia projekt o stałej cenie?
Wycena fixed-price ma dwie warstwy, z których klient widzi tylko sumę. Pierwsza to koszt oczekiwany — najlepszy szacunek pracochłonności przemnożony przez koszt godziny. Druga to premia za ryzyko — zapas pokrywający scenariusze gorsze od oczekiwanego.
Wysokość premii nie jest kwestią chciwości, tylko rozkładu prawdopodobieństwa. Dostawca, który wycenia projekt na koszt oczekiwany, przy symetrycznym rozkładzie błędu szacunku wychodzi na zero w połowie projektów i traci w drugiej połowie — a rozkład w wytwarzaniu oprogramowania nie jest symetryczny, tylko prawostronnie skośny, bo projekt może zająć dwa razy więcej czasu, niż zakładano, ale nie może zająć dwa razy mniej. Żeby zarabiać, dostawca musi wycenić powyżej wartości oczekiwanej, i to znacząco.
Rzędy wielkości, które można przyjąć jako punkt wyjścia do rozmowy — z zastrzeżeniem, że każdy dostawca liczy je inaczej i rzadko ujawnia:
- zakres dobrze wyspecyfikowany, technologia znana, zespół doświadczony w tej domenie: zapas rzędu 15–25% ponad koszt oczekiwany;
- zakres opisany na poziomie wymagań funkcjonalnych, bez projektu technicznego: 30–50%;
- zakres opisany celami biznesowymi, integracje z systemami klienta o nieznanym stanie: 60–100% i więcej, przy czym powyżej pewnego progu poważny dostawca odmawia wyceny stałej zamiast wystawić ofertę, której nie da się obronić.
Do premii za ryzyko dochodzi jeszcze premia za koszt kapitału i cash flow: przy rozliczeniu kamieniami milowymi dostawca finansuje pracę z własnych środków przez miesiące. W warunkach dodatnich stóp procentowych to kolejne kilka procent, które ktoś musi zapłacić.
Suma tych składników jest ceną polisy. Klient płaci ją zawsze. Ryzyko, przed którym polisa chroni, materializuje się — w zależności od klasy projektu — w może trzydziestu, może czterdziestu procentach przypadków. Ta asymetria jest sednem tezy tego artykułu i jednocześnie powodem, dla którego rynek usług o cenie stałej istnieje: sprzedawanie polis jest opłacalne.
Dlaczego przetarg na cenę stałą wygrywa najgorzej wyceniona oferta?
To zjawisko ma nazwę i literaturę: klątwa zwycięzcy. Gdy kilku oferentów wycenia to samo dobro o niepewnej wartości, a wygrywa najniższa cena, to systematycznie wygrywa ten, który najbardziej pomylił się w dół. Nie ten, który najlepiej rozumie problem — ten, który najbardziej nie docenił jego trudności albo najbardziej potrzebował kontraktu.
W przetargach na oprogramowanie ten mechanizm działa szczególnie mocno, bo rozrzut szacunków między kompetentnymi dostawcami tego samego zakresu potrafi sięgać dwukrotności. Przy takim rozrzucie wybór najniższej oferty jest niemal równoważny wyborowi największego błędu w wycenie.
Konsekwencja nie jest tańszym projektem. Konsekwencją jest dostawca pod presją marży od trzeciego miesiąca realizacji, którego dostępne dźwignie to: obsadzenie projektu tańszymi, mniej doświadczonymi ludźmi; skrócenie tego, co niewidoczne w odbiorze, czyli testów, dokumentacji i jakości kodu; oraz agresywna interpretacja granic zakresu, żeby jak najwięcej przenieść do wniosków o zmianę. Wszystkie trzy są racjonalne z jego perspektywy i wszystkie trzy klient zapłaci — tylko później i w innej walucie. Ta trzecia droga jest zresztą dla klienta najdroższa, a jej ekonomikę warto zrozumieć osobno.
Ile faktycznie kosztuje ekonomia wniosków o zmianę?
Wniosek o zmianę w projekcie o cenie stałej jest transakcją zawieraną w warunkach, w których jedna strona nie ma alternatywy. W chwili podpisania umowy klient miał trzech oferentów i pełną siłę przetargową. W szóstym miesiącu realizacji ma jednego dostawcę, który zna kod, ma zespół z kontekstem i którego zmiana oznaczałaby kilkumiesięczne opóźnienie plus koszt przekazania wiedzy. Siła przetargowa przeszła na drugą stronę stołu w całości.
Efekt jest widoczny w stawkach. Praca wyceniana w ramach wniosku o zmianę bywa rozliczana o kilkadziesiąt procent drożej niż stawka bazowa z pierwotnej oferty — nie dlatego, że kosztuje więcej wytworzyć, ale dlatego, że nie ma z czym jej porównać. Do tego dochodzi koszt samego procesu: przygotowanie wniosku, wycena, negocjacja, akceptacja i aneks to zwykle kilka tygodni kalendarzowych, w których zakres jest zamrożony, a zespół pracuje na pół gwizdka albo nad czymś innym.
Trzeci koszt jest najbardziej podstępny: presja, żeby nie zgłaszać zmian. Skoro każda zmiana jest kosztowna, długa i konfliktowa, organizacja uczy się ich unikać. Efektem jest system wdrożony zgodnie ze specyfikacją sprzed dwudziestu miesięcy — czyli zgodnie z rozumieniem potrzeby, które było najsłabsze w całym cyklu życia projektu, bo powstało przed jakimkolwiek kontaktem z działającym oprogramowaniem. Zgodność ze specyfikacją i przydatność biznesowa to dwie różne rzeczy, a fixed-price optymalizuje pierwszą.
Ile kosztuje specyfikacja wystarczająco dokładna, żeby ją wycenić?
Cena stała wymaga zakresu opisanego na tyle precyzyjnie, żeby dało się go wycenić i żeby dało się rozstrzygnąć spór o odbiór. To nie jest darmowe i ten koszt prawie nigdy nie trafia do porównania modeli.
Przygotowanie specyfikacji na poziomie umożliwiającym wiarygodną wycenę stałą — analiza procesów, wymagania funkcjonalne i niefunkcjonalne, projekt integracji, kryteria akceptacji — to zwykle 8–15% wartości projektu, ponoszone przed rozpoczęciem realizacji. Dla projektu o wartości dwóch milionów złotych mówimy o 160 000–300 000 zł i o dwóch–czterech miesiącach kalendarzowych.
Gorsze od kwoty jest to, kiedy ta praca jest wykonywana. Specyfikacja powstaje w momencie największej niewiedzy w całym cyklu życia projektu: przed zobaczeniem pierwszego działającego ekranu, przed pierwszą konfrontacją z realnym stanem systemów, do których trzeba się podłączyć, przed pierwszą reakcją użytkownika. Kupujemy precyzję opisu tam, gdzie nie mamy jeszcze wiedzy — i płacimy za tę precyzję dwa razy: raz przy jej wytworzeniu, drugi raz przy każdym wniosku o zmianę, który wynika z tego, że opis powstał za wcześnie.
Ten sam mechanizm, tylko na poziomie pojedynczego zadania, opisujemy w tekście o estymacji w story points jako teatrze decyzyjnym — precyzja szacunku wykonanego przed zdobyciem wiedzy nie zamienia się w precyzję wyniku, niezależnie od tego, ile wysiłku w nią włożymy.
Czy time & material rozwiązuje problem, czy tylko przesuwa go na klienta?
Uczciwość wymaga powiedzenia wprost: model czasowo-materiałowy nie jest darmowy i nie jest wolny od patologii. Przenosi ryzyko wariancji kosztu na klienta i wymaga od niego zdolności, której nie każda organizacja ma.
Jego własne wady są realne. Dostawca nie ma bodźca ekonomicznego do skracania pracy — im dłużej trwa, tym więcej zarabia. Bez dyscypliny po stronie klienta zakres puchnie, bo każdy pomysł da się dopisać do backlogu bez negocjacji. Bez wglądu w faktyczny postęp klient płaci za czas, nie za wynik, i dowiaduje się o problemie późno.
Kluczowa różnica polega jednak na koszcie kontroli tych patologii. W modelu czasowo-materiałowym mechanizmy kontrolne są tanie i niekonfliktowe: dwutygodniowy rytm demonstracji działającego oprogramowania, jawny backlog z priorytetami po stronie klienta, prawo wypowiedzenia z krótkim okresem, budżet z twardym limitem miesięcznym. Żaden z nich nie wymaga arbitrażu ani opinii biegłego. W cenie stałej mechanizmem kontrolnym jest protokół odbioru i spór o interpretację zakresu — narzędzie kosztowne, wolne i psujące relację, bo z definicji zakłada, że jedna ze stron ma stracić.
Wniosek nie brzmi więc „time & material jest lepszy”, tylko: oba modele mają niedopasowane bodźce, a różnią się kosztem ich kontrolowania. Klient, który potrafi prowadzić dostawę — ma product ownera z realnym mandatem, umie priorytetyzować i patrzy na działające oprogramowanie co dwa tygodnie — kontroluje model czasowo-materiałowy tanio. Klient, który tej zdolności nie ma, nie skontroluje żadnego modelu i dla niego premia za cenę stałą bywa uczciwą ceną za outsourcing zarządzania.
Kiedy cena stała jest naprawdę właściwym wyborem?
Teza tego artykułu nie brzmi „nigdy nie podpisuj fixed-price”. Brzmi „policz premię, zanim podpiszesz”. Istnieją konfiguracje, w których cena stała jest wyborem poprawnym i to nie z braku alternatywy.
Zakres domknięty, krótki i powtarzalny. Migracja danych o znanej strukturze, wdrożenie standardowego modułu, integracja z udokumentowanym API zewnętrznego dostawcy. Wariancja jest niska, więc premia jest niska, a koszt zarządzania po stronie klienta znika. Przy projektach do kilku tygodni premia bywa niższa niż koszt comiesięcznego nadzoru.
Organizacja bez zdolności prowadzenia dostawy. Jeśli po stronie klienta nie ma nikogo, kto może tygodniowo podejmować decyzje o priorytetach, model czasowo-materiałowy wyprodukuje gorszy wynik niezależnie od ceny. Premia za cenę stałą jest wtedy zakupem zarządzania, a nie tylko zakupem przewidywalności.
Zamówienia publiczne i procedury wewnętrzne wymuszające cenę. Tam decyzja jest podjęta poza tą analizą. Sensownym ruchem nie jest wtedy walka z modelem, tylko zawężenie zakresu jednego postępowania do części naprawdę przewidywalnej i wydzielenie reszty do osobnego trybu.
Silne ograniczenie budżetowe o charakterze twardym. Jeśli przekroczenie budżetu o 15% oznacza nie „trudną rozmowę”, tylko utratę finansowania i zamknięcie inicjatywy, przewidywalność ma wartość opcyjną wykraczającą poza arytmetykę wartości oczekiwanej. Warto ją wtedy nazwać wprost i zapłacić świadomie.
Jakie modele pośrednie działają lepiej niż oba skrajne?
W praktyce najlepsze wyniki dają konstrukcje, które rozdzielają ryzyko zamiast przerzucać je w całości. Cztery z nich sprawdzają się na tyle powtarzalnie, że warto je znać z nazwy.
Cena stała za przyrost, nie za projekt. Zakres dzielony na etapy dwu–trzymiesięczne, każdy wyceniony stałą kwotą po zakończeniu poprzedniego. Wariancja szacunku na krótkim horyzoncie jest wielokrotnie mniejsza, więc premia spada; klient zachowuje przewidywalność w okresie budżetowym i możliwość wyjścia po każdym etapie.
Time & material z twardym limitem i podziałem oszczędności. Rozliczenie za faktyczną pracę, ale z górnym pułapem, którego przekroczenie obciąża dostawcę, oraz z podziałem różnicy, gdy wyjdzie taniej. Ta druga część jest istotna — bez niej limit działa jak cena stała i przyciąga tę samą premię.
Koszt docelowy z podziałem zysku i straty. Strony ustalają koszt docelowy i procentowy podział odchylenia w obie strony, na przykład 50/50. Model przenosi część ryzyka na dostawcę bez zmuszania go do wyceny najgorszego scenariusza i jest jedynym, w którym obie strony zarabiają na tym samym zdarzeniu.
Cena stała za wynik, nie za zakres. Rozliczenie za osiągnięcie mierzalnego rezultatu biznesowego, nie za dostarczenie listy funkcji. Trudne do skonstruowania i wymagające zaufania, ale eliminuje spór o zakres u źródła, bo zakres przestaje być przedmiotem umowy.
Wspólny mianownik wszystkich czterech: skracają horyzont, na którym trzeba przewidywać. Premia za ryzyko rośnie wraz z długością i niepewnością horyzontu, więc jego skrócenie jest najtańszą dostępną dźwignią po stronie kupującego.
Jak porównać dwie oferty w różnych modelach, żeby porównanie miało sens?
Zestawianie ceny stałej z szacunkiem czasowo-materiałowym to porównanie liczby pewnej z liczbą niepewną, i wygrywa je zawsze ta pewna — niezależnie od tego, która jest w rzeczywistości tańsza. Żeby porównanie miało wartość, obie strony trzeba doprowadzić do pełnego kosztu posiadania.
Do oferty fixed-price dolicz: koszt przygotowania specyfikacji na poziomie umożliwiającym wycenę i odbiór; spodziewaną wartość wniosków o zmianę (punkt wyjścia: 15–30% wartości bazowej dla projektów dłuższych niż pół roku, więcej przy niedojrzałym zakresie); koszt procesu odbiorowego i ewentualnych sporów; oraz koszt opóźnień wynikających z zamrożenia zakresu na czas negocjowania aneksów.
Do oferty time & material dolicz: koszt własnego zarządzania dostawą (product owner, przeglądy, priorytetyzacja — realnie 5–12% wartości projektu); ryzyko przekroczenia szacunku wyrażone jako przedział, nie jako pojedyncza liczba; oraz koszt mechanizmów kontrolnych, jeśli trzeba je dopiero zbudować.
Dopiero te dwie sumy są porównywalne. W praktyce, gdy porównanie zostanie przeprowadzone uczciwie, cena stała wypada drożej w większości projektów dłuższych niż sześć miesięcy i z zakresem, który ktokolwiek przy stole nazwałby „w miarę jasnym” — a rzadko okazuje się droższa przy zakresach krótkich i naprawdę domkniętych. To jest dokładnie ten sam kształt rachunku, który stosujemy przy ocenie, kiedy body leasing przestaje się opłacać: model kosztowy trzeba liczyć na całym horyzoncie, nie na fakturze z pierwszego kwartału.
Jak wygląda mapa doboru modelu rozliczenia?
| Charakterystyka projektu | Wariancja szacunku | Zdolność klienta do prowadzenia dostawy | Rekomendowany model | Główne ryzyko przy błędnym wyborze |
|---|---|---|---|---|
| Zakres domknięty, do 3 miesięcy, znana technologia | niska | dowolna | Cena stała za całość | Przepłacenie jest tu małe; ryzykiem jest raczej przeciąganie decyzji niż model |
| Rozwój produktu, horyzont powyżej 12 miesięcy, zakres ewoluujący | wysoka | wysoka | Time & material z limitem miesięcznym | Cena stała: premia 30–50% plus wnioski o zmianę bez konkurencji |
| Wdrożenie systemu, 6–12 miesięcy, wymagania znane, integracje niepewne | średnia | średnia | Cena stała za przyrost, etapy 2–3 miesiące | Jedna cena za całość: premia liczona od najgorszego scenariusza integracji |
| Projekt krytyczny budżetowo, przekroczenie oznacza utratę finansowania | dowolna | dowolna | Cena stała lub T&M z twardym limitem | T&M bez limitu: utrata finansowania jest droższa niż premia |
| Klient bez product ownera z mandatem decyzyjnym | dowolna | niska | Cena stała albo najpierw zbudowanie zdolności | T&M: zakres puchnie, nikt nie priorytetyzuje, koszt rośnie bez kontroli |
| Zamówienie publiczne z wymogiem ceny | dowolna | dowolna | Cena stała na zawężonym, przewidywalnym zakresie | Objęcie jednym postępowaniem części nieprzewidywalnej — premia i spory gwarantowane |
Jak przeprowadzić tę analizę u siebie przed najbliższą decyzją?
Rachunek mieści się w tygodniu i nie wymaga niczego poza dostępem do historii własnych projektów.
Krok 1 — zmierz własną wariancję. Weź pięć ostatnich zamkniętych projektów i porównaj koszt pierwotny z końcowym, licząc aneksy i wnioski o zmianę. Mediana tego odchylenia jest twoją realną wariancją i jednocześnie tym, co dostawca wycenia w premii. Jeśli wychodzi 40%, oferta fixed-price z zapasem 30% jest po twojej stronie stołu tania.
Krok 2 — policz historyczny udział wniosków o zmianę. W projektach o cenie stałej z ostatnich trzech lat: jaki procent wartości końcowej stanowiły aneksy? Ta liczba, dodana do ceny bazowej, jest twoją realną ceną modelu — i to ją należy porównywać z szacunkiem czasowo-materiałowym.
Krok 3 — oceń szczerze własną zdolność prowadzenia dostawy. Czy jest osoba z mandatem do priorytetyzacji? Czy patrzycie na działające oprogramowanie częściej niż raz na kwartał? Czy potraficie powiedzieć „tego nie robimy”? Trzy razy „nie” oznacza, że premia za cenę stałą jest dla was uczciwą ceną, a nie stratą.
Krok 4 — poproś dostawcę o rozbicie wyceny. Poważny dostawca potrafi pokazać koszt oczekiwany i zapas na ryzyko osobno, wraz z listą założeń, na których zapas się opiera. Odmowa rozbicia jest sama w sobie informacją. Rozmowa o konkretnych założeniach potrafi obniżyć premię bardziej niż jakiekolwiek negocjowanie ceny, bo część ryzyk klient może przejąć taniej niż dostawca — na przykład gwarantując dostępność swoich systemów testowych albo decyzję w 48 godzin.
Krok 5 — rozważ skrócenie horyzontu zamiast zmiany modelu. Zanim wybierzesz między dwoma skrajnymi modelami, sprawdź, czy zakres da się podzielić na etapy wyceniane osobno. To zwykle daje większą oszczędność niż wygranie negocjacji o kilka procent od ceny całości.
Jakie są kluczowe wnioski?
Cena stała nie przenosi ryzyka — sprzedaje polisę na jego skutki budżetowe, a jak każda polisa jest droższa niż wartość oczekiwana szkody. Klient płaci premię w stu procentach przypadków, a korzysta z ochrony w mniejszości. To nie czyni modelu złym; czyni go produktem finansowym, który należy wycenić przed zakupem, a nie domyślnym sposobem kontraktowania, wybieranym dlatego, że „daje przewidywalność”.
Trzy mechanizmy sprawiają, że rachunek wypada gorzej, niż wygląda na pierwszej stronie oferty: premia za ryzyko rosnąca wraz z niepewnością zakresu, klątwa zwycięzcy premiująca najgorszą wycenę w przetargu, oraz ekonomia wniosków o zmianę wyceniana w warunkach, w których klient nie ma alternatywy. Do tego dochodzi koszt specyfikacji wytwarzanej w momencie największej niewiedzy.
Praktyczny wniosek nie brzmi „przejdźcie na time & material”. Brzmi: skróćcie horyzont, na którym ktokolwiek musi przewidywać. Cena stała za dwumiesięczny przyrost niesie premię kilkukrotnie niższą niż cena stała za projekt dziewięciomiesięczny, przy zachowaniu przewidywalności w okresie budżetowym. Jeśli chcecie przeprowadzić ten rachunek na własnych danych, zanim podpiszecie kolejną umowę, porozmawiajmy — nasz zespół Software Development prowadzi projekty we wszystkich trzech modelach i potrafi pokazać, gdzie w konkretnym przypadku siedzi premia za ryzyko.