Pierwszym rodzajem kontraktu, modelu rozliczeniowego jest fixed price. Mówiąc najprościej jest to taki układ, w którym dogadujemy się z klientem konkretnie na to, co ma zostać w ramach współpracy dowiezione. Rozliczamy się po outpucie. I tego typu kontrakt, model ma zastosowanie raczej w małych biznesach lub w małych projektach. Tam, gdzie na samym początku mamy bardzo dużą pewność co do pożądanego efektu tej współpracy. Czyli mamy bardzo jasno sprecyzowane wymagania biznesowe i dość dużą pewność tego, że w trakcie procesu powstawania tego rozwiązania czy produktu cyfrowego, wymagania biznesowe się nie zmienią. I uwaga, w dużym biznesie, w dużych organizacjach, przy dużych projektach jest to w zasadzie normą, że te wymagania się zmieniają. Dlaczego? Dlatego że mamy różnych interesariuszy, Stake Holderów. Te procesy często są tak długie, że w trakcie tworzenia rozwiązania np. pojawiają się nowe elementy, które mogą jeszcze bardziej usprawnić to co produkujemy, co wdrażamy. Które mogą jeszcze łatwiej rozwiązać problem biznesowy. Pojawiają się nowi interesariusze. Po prostu organizacja się zmienia wraz z rozwojem projektu. Oczywiście takich powodów wprowadzania zmian na bieżąco może być znacznie więcej. Natomiast w przypadku fixed price, kiedy umówiliśmy się na output, na efekt, zmiana tego co chcieliśmy osiągnąć bywa bardzo problematyczna. Mamy jasno sprecyzowane co chcieliśmy dostać i po jakiej cenie. Więc w tym modelu, a za tym idzie cały model operacyjny dostarczania usługi, jest zwyczajnie trudniej wprowadzać zmiany na bieżąco. A produkt cyfrowy może być naprawdę złożony. O tym z czego się składa i jak powstaje przeczytasz w artykule “Jak zbudowany jest produkt cyfrowy? UI/UX, Front End, Back End…”.
Time & Materials
Dlatego że nawet przy mniejszych projektach, jeżeli porównamy oba modele, taką typową praktyką rynkową jest to żeby przyjąć, że klient na pewno będzie chciał coś zmienić po drodze. I generalnie dostawca przygotowując wycenę na fixed price, po prostu będzie musiał wziąć pod uwagę potencjalne zmiany, czyli większy nakład pracy. Będzie musiał założyć dodatkową marżę na ryzyko. Dlatego generalnie model time and materials będzie zwykle dla klienta tańszy. Mimo że może się wydawać że “no przecież nie dostałem konkretnej ceny”, więc ten dostawca może na przykład przedłużać prace w nieskończoność. Takie rzeczy już dzisiaj raczej nie występują. Proces dostarczania oprogramowania jest jasny, jest przejrzysty. Metodyka wytwarzania oprogramowania, metodyki zwinne czy framework SCRUMowy (czy jakikolwiek inny zostanie przyjęty) jest transparentny. Czyli obie strony mają non stop wgląd w operacje, monitorują to co się dzieje. Więc takie ryzyko, że dostawca coś specjalnie przeciąga, bo rozlicza się po inpucie jest generalnie bardzo niskie, a korzyść płynąca z takiego rozwiązania potencjalnie wysoka.
Czy Time And Materials jest zawsze lepsze od Fixed Price?
Podsumowanie
Obejrzyj film:
