Obecnie na rynku IT dostępne są dwa najbardziej popularne modele rozliczeń za projekt:
Aby doszło do współpracy zarówno dostawca jak i zamawiający muszą ustalić idealny consensus, który będzie dobrym rozwiązaniem dla obydwu stron. Zazwyczaj klient obawia się umowy na time& material, ponieważ od czasów starożytnych nauczeni jesteśmy płacić z góry określoną cenę za wykonaną pracę, więc dlaczego klient miałby płacić za przepracowany faktycznie czas? Programista przecież może do raportu godzinowego wpisać dowolną liczbę godzin. Z punktu widzenia software house sprawa nie jest taka oczywista- oprogramowanie dedykowane najczęściej nie jest zamkniętym produktem- to nie samochód czy komputer, a system, który w każdej chwili może się zmieniać, być aktualizowany czy rozwijany. W trakcie trwania współpracy klientom często zdarza się zmieniać wstępne założenia, a czasami nawet główne funkcjonalności rozwijanej aplikacji.
Poszukujesz partnera do wykonania aplikacji: zadzwoń do nas i porozmawiajmy o możliwych rozwiązaniach.
W dzisiejszym artykule pokażemy Wam plus i minusy każdego typu rozliczenia, a także postaramy się doradzić w jakich sytuacjach korzystniej będzie wybrać określony model współpracy.
Dobrze, znamy więc już plusy oraz minusy proponowanych rozwiązań, natomiast klient często sam nie posiada wiedzy, które podejście będzie bardziej efektywne w przypadku jego projektu. Co jest istotne, każdy projekt należy rozpatrywać indywidualnie.
Jest to typ umowy, który jest wyjątkowo elastyczny przy pracy z softwarehouse-em, ponieważ dopuszcza wdrażanie zmian podczas trwania umowy. Jest to typ umowy, który określa wysokości zapłaty za wykonane prace w stosunku do czasu jej trwania oraz wartości wykorzystanych narzędzi. Zleceniobiorca w tym modelu jest na bieżąco ( najczęściej w 2 tygodniowych iteracjach) informowany o postępach- otrzymuje szczegółowy raport mówiący o wykonanych pracach. Dzięki temu ma możliwość weryfikacji stanu projektu i wprowadzania ewentualnych zmian. Niepodważalnym atutem tego modelu jest oszczędność, ponieważ klient płaci zawsze za faktyczną pracę- kierownika projektu, analityka oraz programisty, bez doliczanych kosztów ryzyka.
Wybór tego typu rozliczenia jest rekomendowany dla klientów, którzy mają ogólną wizję produktu końcowego, jednak trudno jest im sprecyzować pełen zakres prac oraz harmonogram. Klient w tym modelu współpracy określa podstawowe funkcjonalności projektu, natomiast szczegóły funkcjonalności są dopracowywane podczas kolejnych iteracji prac programistycznych. Time & material wykorzystywany jest również w projektach dla których trudno sprecyzować ich całkowitą wielkość, a także w tych gdzie zleceniodawca ma świadomość, że wymagania mogą zmieniać się w czasie cyklu wytwarzania projektu- np. jest wielu interesariuszy., którzy mają wpływ na projekt.
Jest to opcja dla wszystkich projektów, których wartość da się oszacować jeszcze przed rozpoczęciem prac- musi to być dobrze przemyślany projekt, który posiada gruntownie przygotowaną specyfikację, która uwzględnia jej realny czas wykonania, dokładny harmonogram oraz zakres prac. Klient nie musi również w tym modelu stale monitorować projektu- jest on rozliczony po przedstawieniu całości projektu. Rozliczenie fixed price najlepiej stosować do małych projektów, gdzie ryzyko niezgodności z oczekiwaniami klienta jest małe. W przypadu większych projektów należy pamiętać, że wybierając fixed price przygotowanie specyfikacji początkowej może na początku stanowić duży koszt wejściowy na starcie- scenariusze użycia, makiety funkcjonalne czy struktura bazy danych- to komponenty, które są konieczne aby bezpiecznie określić całość zakresu projektu.
Każdy software house bez względy jak transparentny będzie projekt musi w kosztach umowy fixed price uwzględnić pewien zapas w kosztach na wypadek nieprzewidywanych komplikacji, które mogą wystąpić podczas realizacji projektu. Sumarycznie ustalona kwota będzie asekuracyjnie powiększona, niż wycena w modelu time & material. Trudność wprowadzenia modyfikacji do projektu rozliczanego fixed price polega na tym, że aby zmienić zakres prac w trakcie trwania umowy należy zmodyfikować specyfikację wymagań, a tym samym ponownie oszacować nanoszone zmiany. Wydaje się zatem, że fixed price to model nie opłacalny, jednak takie określenie będzie trafne jedynie w przypadku klientów, którzy nieprzemyślanie wybiorą takie rozliczenie, bez pewności, że mają jasno sprecyzowane i udokumentowane wymagania jak ma wyglądać finalny produkt.
Podsumowując:
Częsty rozwiązaniem jest zastosowanie obu opcji rozliczenia aby dać klientowi możliwość sprawdzenia jakości współpracy, jeżeli dopiero zaczyna współpracę z firmą programistyczną, a kolejno po etapie MVP przejść na model Time& material. Decydując się na współpracę ze software house w celu wytworzeniu dedykowanego oprogramowania należy przeanalizować wielkość projektu, jego oczekiwany kształt oraz nakład pracy wymagany do jego osiągnięcia. Dobrze podjęta decyzja uchroni klienta od przepłacenia za otrzymaną usługę bez rezygnacji z wysokiej jakości.
Poszukujesz wykonawcy do aplikacji mobilnej lub aplikacji internetowej? Skontaktuj się z nami już dzisiaj- oszacujemy wielkość Twojego projektu i doradzimy najlepszy typ podejścia oraz rozliczenia.
Bezpłatna konsultacja
Powiedz nam czego potrzebujesz, a nasi eksperci Powiedzą Ci jak to zrobić, ile to kosztuje i na kiedy będzie gotowe.