Fixed price / zakres projektu
Dlaczego fixed price nie oznacza nieograniczonych zmian?
Stała cena chroni obie strony tylko przy stałym zakresie. Wyjaśniamy, jak obsługiwać nowe pomysły, poprawki i zmiany bez konfliktu oraz scope creep.
KRÓTKA ODPOWIEDŹ
Fixed price oznacza stałą cenę za uzgodniony rezultat i zakres, a nie abonament na dowolną liczbę pomysłów. Każda zmiana wpływa na analizę, kod, testy, dokumentację i termin. Uczciwy model pozwala poprawiać błędy względem specyfikacji, a nowe funkcje przenosi do kolejnego sprintu albo wycenia jako zmianę zakresu.
- Stała cena wymaga listy elementów w zakresie i poza zakresem.
- Błąd to nie to samo co nowy pomysł lub zmiana reguły biznesowej.
- Backlog chroni dobre pomysły bez rozbijania bieżącego etapu.
- Cotygodniowe prezentacje wykrywają nieporozumienia wcześniej niż odbiór końcowy.
Z PRAKTYKI TWOJSOFTWARE
Po wdrożeniu systemu ewidencji tras pojawiły się wartościowe potrzeby: wyszukiwarka operacyjna, nowe polityki edycji i moduł dokumentów. Zamiast wciskać je do zamkniętego MVP, realizowaliśmy je w osobnych sprintach rozwojowych.
01
Wewnętrzna myśl: „Skoro płacę stałą cenę, efekt ma być idealny”
Klient chce uniknąć rosnącego rachunku, a wykonawca chce znać odpowiedzialność i termin. Fixed price odpowiada na oba cele, ale tylko wtedy, gdy strony rozumieją, co dokładnie kupują. „Aplikacja do obsługi firmy” nie jest zakresem. Zakresem są konkretne role, przepływy, integracje i kryteria odbioru.
02
Stanowisko: stała cena jest możliwa przy stałym zakresie
Nieograniczone zmiany przenoszą całe ryzyko na wykonawcę. Ten musi wtedy podnieść cenę, dodać duży bufor albo obniżyć jakość, aby zmieścić się w budżecie. Żadna z tych opcji nie jest dobra dla klienta. Lepiej zawęzić pierwszy etap, pokazywać postęp i oddzielić błędy od nowych decyzji.
03
Dowód: realne użycie tworzy nowy backlog po MVP
W pierwszej wersji systemu ewidencji tras najważniejsze były karty pracowników, historia, role, eksport PDF i panel administratora. Dopiero praca operacyjna pokazała wartość wyszukiwarki odpowiadającej na pytanie: kto zna wymagane odcinki na konkretny dzień.
Ta funkcja była cenna, ale nie była błędem pierwszego zakresu. Była nowym modułem odkrytym dzięki wdrożeniu. Osobny sprint pozwolił ją zaprojektować na prawdziwych danych bez destabilizowania odbioru MVP za około 12 000 zł.
- 01
Zakres
Lista przepływów, założeń i kryteriów odbioru.
- 02
Budowa
Regularne prezentacje i szybkie wyjaśnianie nieporozumień.
- 03
Nowy pomysł
Zapis do backlogu wraz z problemem i priorytetem.
- 04
Kolejny sprint
Osobna decyzja o cenie, terminie i wpływie na produkt.
04
Usunięcie obawy: jak odróżnić błąd od zmiany zakresu
Jeśli system miał według zaakceptowanego zakresu blokować zapis niepoprawnej daty, a tego nie robi, jest to błąd do poprawy. Jeśli po testach klient decyduje, że data ma być zatwierdzana przez dodatkową rolę, jest to zmiana reguły i zakresu. Pomaga prosta dokumentacja decyzji, makiety oraz przykładowe scenariusze odbioru.
| Poprawka w zakresie | Zmiana zakresu |
|---|---|
| funkcja nie działa zgodnie z ustalonym scenariuszem | nowa rola, krok lub reguła |
| błąd walidacji opisanej przed startem | obsługa nowego wyjątku |
| niezgodność z zaakceptowaną makietą | zmiana zaakceptowanego przepływu |
| problem techniczny po wdrożeniu | integracja z kolejnym systemem |
05
Kwalifikacja: kiedy fixed price będzie dobrym modelem
Fixed price pasuje, gdy wynik pierwszego etapu jest jasny, jedna osoba podejmuje decyzje, a zespół klienta regularnie testuje produkt. Nie pasuje, gdy wizja zmienia się codziennie, interesariusze nie uzgadniają priorytetów albo prace mają polegać na stałym eksperymentowaniu bez zamkniętego celu.
Dla badań i niepewnych eksperymentów lepszy bywa płatny warsztat, krótki PoC albo sprint rozliczany za ustalony czas zespołu.
06
Zaproszenie: zamknijmy mały zakres zamiast negocjować duży bufor
Opisz pierwszy wynik, który chcesz osiągnąć. Na tej podstawie łatwiej przygotować mały zakres w stałej cenie, listę elementów poza zakresem i jasną zasadę obsługi nowych pomysłów.
FAQ
Pytania, które pojawiają się najczęściej.
Czy poprawki błędów są dodatkowo płatne przy fixed price?
Błędy względem zaakceptowanego zakresu powinny zostać poprawione w ramach projektu lub uzgodnionego okresu wsparcia. Nowe funkcje i zmiany reguł wymagają osobnej decyzji.
Co dzieje się z dobrym pomysłem zgłoszonym w trakcie projektu?
Trafia do backlogu wraz z opisem problemu i priorytetem. Może wejść do kolejnego sprintu bez rozbijania ceny oraz terminu bieżącego etapu.
Czy fixed price jest droższy od rozliczenia godzinowego?
Może zawierać bufor na jasno określone ryzyka, ale daje przewidywalny budżet. Największy wpływ na cenę ma nadal zakres, liczba wyjątków i integracji.
NASTĘPNY KROK
Chcesz dostać stałą cenę bez dopłacania za niejasność?
Odpowiedz na sześć pytań. Zaproponujemy możliwie mały, zamknięty zakres pierwszego etapu i wskażemy ryzyka wymagające doprecyzowania.