Przedsiębiorcy chcący stworzyć produkt cyfrowy taki jak aplikacja mobilna, serwis internetowy czy system ERP bardzo często nawiązują w tym celu współpracę z wyspecjalizowanym software housem – firmą realizującą projekty programistyczne na zamówienie. Jednym z najważniejszych ustaleń na etapie negocjacji klienta z potencjalnym wykonawcą jest dobór odpowiedniego modelu współpracy. O ile w przypadku startupów technologicznych planujących wprowadzenie nowego produktu cyfrowego na rynek, wykonawcy tego typu projektów z reguły optują za hybrydą rozliczenia gotówkowego oraz objęcia udziałów w nowo utworzonej spółce, o tyle dla klientów będących przedsiębiorstwami o ugruntowanej pozycji na rynku najczęściej stosowane modele współpracy to fixed price oraz time and material.
Model fixed price
Model współpracy fixed price (stała cena) opiera się na odgórnym ustaleniu kosztu wykonania projektu lub jego części przed przystąpieniem do realizacji. W rezultacie, kontrakt fixed price musi zawierać szczegółową specyfikację oraz wycenę realizacji docelowego produktu, która ma charakter wiążący – z otrzymanych wyliczeń w niej zawartych wynikać będzie faktyczna cena zapłacona wykonawcy za zrealizowanie projektu.
Nawiązanie współpracy w modelu fixed price z reguły poprzedzone jest ekstensywnym etapem projektowania oprogramowania i tworzenia dokumentacji projektowej. W skład takiej dokumentacji z reguły wchodzą precyzyjnie sformułowane wymagania funkcjonalne i pozafunkcjonalne, projekty graficzne, schematy architektury oprogramowania oraz zestawy technologii dobranych do realizacji projektu.
Model time and material
Alternatywny model, time and material (roboczogodziny i materiały), zakłada współpracę opartą o bardziej elastyczne warunki. W odróżnieniu od współpracy na zasadach fixed price, w tym modelu podstawę rozliczeń między stronami stanowi czas pracy poświęconej na realizację projektu oraz zużyte przy jego wykonaniu materiały. Każdy członek zespołu projektowego wykonawcy, w skład którego wchodzą programiści o różnych specjalizacjach, testerzy, menedżerowie oraz inżynierowie DevOps, posiada przypisaną stawkę roboczogodziny, w oparciu o którą wyliczana jest należna cena.
Dodatkowe opłaty mogą pojawić po stronie materiałów, jednakże z reguły mają one niewielki udział w całkowitej cenie projektu programistycznego. W przypadku przedsięwzięć związanych z tworzeniem oprogramowania, materiałami mogą być na przykład koszty infrastruktury związane z utrzymaniem środowisk testowych czy kupno licencji na zestawy gotowych komponentów do wykorzystania w produkcie cyfrowym.
Przewagi modelu fixed price
Najważniejszą przewagę modelu fixed price nad modelem time and material stanowi przewidywalność. To nic dziwnego biorąc pod uwagę fakt, iż niemal każdy przedsiębiorca dąży do ograniczenia ponoszonego w swojej działalności ryzyka. Znajomość ceny projektu przed rozpoczęciem jego realizacji pozwala zamawiającemu zaplanować nadchodzące koszty i ewentualnie podzielić zakres projektu na etapy, tak aby rozważane przedsięwzięcie nie wpłynęło negatywnie na przepływy przedsiębiorstwa.
W przypadku niektórych projektów, otrzymanie wyceny w modelu fixed price jest odgórnym, nienegocjowalnym wymaganiem niezależnym od zamawiającego. Dobrym przykładem takiej sytuacji może być działalność startupu, który potrzebuje wyceny w modelu fixed price, aby móc umieścić ją w biznesplanie, który następnie zostanie przedstawiony inwestorom w celu pozyskania finansowania.
Korzyści płynące z zastosowania rozliczeń time and material
Jedną z najważniejszych korzyści płynących z zastosowania modelu time and material jest szansa na znaczące obniżenie kosztu projektu. Warto tutaj zaznaczyć, że szacowanie czasochłonności procesu tworzenia oprogramowania jest dość trudnym problemem. Chociaż istnieją liczne metody estymacji projektów programistycznych, żadna z nich nie daje dostatecznie wiarygodnych wyników. W rezultacie, większość software houseów pozostaje bardzo ostrożna przy przygotowywaniu wycen. Powszechną praktyką jest powiększanie otrzymanej na potrzeby modelu fixed price estymacji o kilkanaście do nawet kilkudziesięciu procent w celu zapewnienia bezpiecznego dla wykonawcy marginesu błędu, w rezultacie czyniąc realizację projektu w tym modelu statystycznie droższą dla zamawiającego.
Dodatkowym czynnikiem przemawiającym na korzyść modelu time and material jest elastyczność, która pozwala na zminimalizowanie wpływu zmieniających się w czasie wymagań na postęp prac. Na pewnym etapie realizacji projektu, zamawiający po przetestowaniu wczesnej wersji produktu cyfrowego może dojść do wniosku, że zaimplementowanie innej funkcjonalności niż pierwotnie zakładano mogłoby być lepszym rozwiązaniem. O ile w przypadku modelu fixed price, jakiekolwiek zmiany w oczekiwanej pierwotnie funkcjonalności produktu cyfrowego wymagają aktualizacji wyceny oraz sporządzenia aneksu do umowy, o tyle model time and material cechuje się dużo większą otwartością na zmiany zakresu projektu. W przedstawionej sytuacji, zespół projektowy po otrzymaniu feedbacku od klienta może zmienić kierunek prac uwzględniając pożądany kształt produktu bez dodatkowych formalności.
Nie bez znaczenia pozostaje również zagadnienie zaufania do wykonawcy. W przypadku współpracy w modelu time and material zamawiający nierzadko decyduje się na przedsięwzięcie dodatkowych kroków w celu zweryfikowania faktycznego czasu pracy poświęcanego przez zespół wykonawcy na realizację projektu. Takie czynności mogą być realizowane przez pracowników zamawiającego posiadających kompetencje IT lub przez zewnętrzną firmę konsultingową świadczącą usługi nadzoru nad projektami informatycznymi.
Który model współpracy wybrać?
To, który model współpracy okaże się być korzystniejszym wyborem zależy od wielu czynników. W przypadku projektów o małym i średnim zakresie oraz ściśle sprecyzowanych wymaganiach, których szansa na zmianę w trakcie produkcji oprogramowania jest niewielka, model fixed price może być lepszym rozwiązaniem.
Istotną kwestią mającą wpływ na wybór modelu rozliczeń jest również etap rozwoju projektu. Znaczna większość przedsiębiorstw zamawiających produkcję oprogramowania w pierwszej kolejności decyduje się na realizację MVP, czyli produktu o okrojonej, aczkolwiek sensownej z punktu widzenia użytkownika końcowego funkcjonalności. Przygotowane MVP zostaje następnie wypuszczone na rynek, po czym jest konsekwentnie rozbudowywane o kolejne funkcjonalności. W takiej sytuacji powszechną praktyką jest realizacja etapu MVP w oparciu o kontrakt fixed price. Następnie, gdy produkt odbył już swój debiut rynkowy i obie strony zdołały zbudować wzajemne zaufanie, bardzo często przechodzi się na model time and material w celu dalszego, iteracyjnego rozwoju projektu.
Materiał został przygotowany przy współpracy z iqcode Software House.