Fixed price opłaca się, gdy zakres jest jasny, a ty masz gotowe komponenty, które skracają pracę. Time and material opłaca się, gdy zakres będzie się zmieniał albo klient sam nie wie, czego chce.
| Fixed price | T&M | |
|---|---|---|
| Kto bierze ryzyko przekroczenia budżetu | Software house | Klient |
| Na czym zarabiasz | Każda zaoszczędzona godzina jest twoją marżą | Stawka razy godziny, bez górki i bez straty |
Na czym zarabiasz w każdym modelu?
Fixed price. Zarabiasz na różnicy między ceną a kosztem wykonania. Ten koszt obniżają trzy rzeczy:
- dobra wycena,
- kontrola zakresu,
- kod, którego nie piszesz od zera.
Ta trzecia rzecz robi największą różnicę i najrzadziej trafia do arkusza wyceny.
T&M. Zarabiasz na różnicy między stawką dla klienta a kosztem godziny programisty. Marża jest stała i przewidywalna. Nie rośnie, gdy pracujesz szybciej.
Przykład z rachunkiem
Przykładowe liczby, żeby pokazać mechanizm. Projekt wyceniony na 100 MD. Koszt MD w zespole wynosi umownie 1 jednostkę, cena dla klienta 1,4 jednostki.
| T&M | Fixed price bez własnych komponentów | Fixed price z własnym modułem | |
|---|---|---|---|
| Przepracowane MD | 100 | 100 | 70 |
| Przychód | 140 | 140 | 140 |
| Koszt | 100 | 100 | 70 |
| Marża | 40 | 40 | 70 |
Przy T&M ten sam moduł obniżyłby przychód do 98 przy koszcie 70, czyli marża spadłaby do 28. Przy fixed price własny kod podnosi marżę. Przy T&M ją obniża.
Dlatego software house z dużą biblioteką własnych komponentów powinien sprzedawać więcej projektów fixed price. Ten sam rachunek działa w drugą stronę. Jeśli przy fixed price przekroczysz zakres o 30 MD, marża spada z 40 do 10.
Kiedy wybrać fixed price?
- zakres opisany w specyfikacji, którą klient akceptuje jako załącznik do umowy,
- projekt podobny do tych, które już robiłeś,
- masz gotowe moduły albo starter kit, które pokrywają część pracy,
- klient ma stały budżet i potrzebuje przewidywalnej kwoty.
Kiedy wybrać T&M?
- produkt w fazie odkrywania, z backlogiem, który zmienia się co sprint,
- klient chce sam ustalać priorytety,
- nowa technologia albo domena, w której twoja wycena byłaby zgadywaniem,
- długa współpraca z dedykowanym zespołem.
Jak chronić się na fixed price?
- Specyfikacja jako załącznik. Wszystko, czego w niej nie ma, jest change requestem.
- Procedura change requestów. Każda zmiana wyceniona i zaakceptowana na piśmie przed realizacją.
- Etapy i odbiory. Płatność po każdym etapie. Bez odbioru nie zaczynasz kolejnego.
- Bufor w wycenie. Jawny albo wliczony w stawkę.
- Prawa do kodu. Przy fixed price przejście praw na klienta warto powiązać z zapłatą za dany etap. Twoje biblioteki zostają w firmie, a klient dostaje do nich licencję.
Co z kodem, który zostaje po projekcie?
Przy obu modelach decyduje umowa.
| Co przenosisz na klienta | Skutek |
|---|---|
| Wszystko, łącznie ze swoimi bibliotekami | Każdy kolejny projekt zaczynasz od zera |
| Kod projektu, a do swoich komponentów dajesz licencję | Z każdym projektem masz więcej gotowego kodu |
Taki kod podnosi marżę na kolejnych projektach fixed price i można go licencjonować innym firmom. Zobacz licencja na oprogramowanie i przeniesienie autorskich praw majątkowych.
Ile jest wart kod, który już zebrałeś, sprawdzisz na stronie ile jest wart kod źródłowy.