Wiemy już, że współpraca z software housem może dotyczyć zarówno nowych projektów IT, tworzonych od podstaw, jak i opieki serwisowej nad istniejącym oprogramowaniem. Obie formy współpracy, oprócz pracy stricte informatycznej, wiążą się również z rozliczeniami. Zdaję sobie sprawę, że nie każdy musi wiedzieć, w jaki sposób są one skonstruowane w takiej relacji. Dlatego dzisiaj postaram się odczarować ten temat i wyjaśnić, na czym polegają dwie główne metody fakturowania pracy software house'u lub freelancera - fixed price oraz time and materials.

W obu podejściach zakładamy, że jednostką pracy jest 1 roboczogodzina, która przekłada się na pewną cenę ustaloną z góry. Jednak podejście do liczenia tych roboczogodzin delikatnie się różni w zależności od metody.

Fixed price (stała cena)

W tym trybie liczba potrzebnych roboczogodzin ustalana jest z góry na podstawie analizy wymagań i dostępnych materiałów przekazanych od klienta. Wyliczenia mogą dotyczyć zarówno całego projektu (a konkretnie zadań wyszczególnionych w ramach danego projektu), a także pojedynczych zleceń czy analiz. Można zatem przyjąć, że na daną pracę przypada stała wycena, która nie ulega zmianie, podobnie jak to ma miejsce w większości branż czy nawet sklepach.

Zaletą tego podejścia jest bez wątpienia to, że zarówno klient wie, ile zapłaci za pracę, jak i firma IT jest świadoma, ile dostanie. W ten sposób łatwiej jest wszystko zaplanować i ocenić konieczną “artylerię” dla całego przedsięwzięcia. Tego typu sposób rozliczenia ułatwia też (a nawet wymusza) przemyślenie harmonogramu prac, co jeszcze bardziej doprecyzowuje ustalenia w kontekście biznesu, a jednocześnie pozwala na wcześniejszym etapie zauważyć nieścisłości czy niebezpieczeństwa.

Nie da się jednak ukryć, że fixed price ma również swoje konsekwencje. Po pierwsze, wymusza dokładną analizę projektu już na samym początku, gdy tak naprawdę poruszamy się w sferze fantazji i koncepcji. Co prawda, analitycy w software house'ach są w stanie wiele rzeczy przewidzieć i wytłumaczyć klientowi różne niuanse, ale mimo to na tym etapie wszystkie wymagania i rozpisywane środowisko biznesowe mogą być mało namacalne. Po drugie, klient musi liczyć się z tym, że wycena obejmuje pewien założony zakres projektu, natomiast proces powstawania oprogramowania ma to do siebie, że już w trakcie można dojrzeć potrzebę wprowadzenia zmian, nowych wymagań itd. Jeśli pojawi się coś, co nie zostało uwzględnione w pierwotnej liczbie roboczogodzin, to będzie musiało zostać wycenione osobno lub jakaś część pierwotnych założeń zostanie uszczuplona.

Podsumujmy zalety i wady dla poszczególnych stron:

Klient:

• z góry wiadomo, ile pieniędzy pochłoną prace i jaki będzie harmonogram rozliczeń,
• gwarancja, że wszystkie założone wymagania zostaną zrealizowane (chyba że strony umówią się na zmiany podczas trwania projektu),
• wiedza o tym, ile orientacyjnie czasu zajmie projekt,
• potrzeba dobrego zdefiniowania wymagań pozafunkcjonalnych (czynników jakościowych), gdyż pewne szczegóły mogą być inaczej rozumiane przez wykonawcę,
• bardziej kłopotliwe, gdy pojawi się dużo zmian podczas trwania projektu - jeśli klient nie ma sprecyzowanej wizji projektu, lepiej przejść na time and materials,
• konieczna jest bardziej szczegółowa dokumentacja, co również należy przewidzieć w budżecie.

Software house:

• z góry znana jest wysokość faktury, co pozwala lepiej planować prace w kontekście całej firmy,
• od początku ustalony jest zakres projektu i dokumentacja - widać tzw. big picture,
• nie ma potrzeby szczegółowego zapisywania czasu spędzonego nad realizacją w celu raportowania tego klientowi,
• jeśli po drodze wystąpią duże problemy z realizacją, projekt może okazać się nierentowny,
• należy sumiennie podejść do tworzenia dokumentacji, zwykle czas analizy (preprodukcji) jest dłuższy,
• trudno realnie przewidzieć harmonogram na kilka miesięcy do przodu.

Time and materials

W tym przypadku język polski nie oferuje "oficjalnego" tłumaczenia tej metodyki, choć można powiedzieć “czas oraz materiały”. A, w odróżnieniu od fixed price, polega ona na tym, iż klient płaci za rzeczywisty czas pracy zespołu IT. Oczywiście, nadal pewne oszacowanie z góry jest wykonywane i dyskutowane, jednak jest ono bardziej drogowskazem, a nie kontraktem. Końcowe rozliczenie nie jest zatem stałe, ale odpowiada faktycznie przepracowanym godzinom.

W tym przypadku zaleta wiąże się z rdzeniem metodyk zwinnych - takie podejście ułatwia stopniowy rozwój projektu, zaczynając od jego podstawowych, najmniejszych części i umożliwia stopniowe dokładanie wymagań. Klient płaci za to, co rzeczywiście jest realizowane już teraz i może przerwać rozwój w momencie, kiedy jest zadowolony z efektu lub chce poczekać na powiększenie swojego budżetu. Można więc powiedzieć, że ten sposób działania wspomaga skalowanie oprogramowania na wielu płaszczyznach. Dodatkowo, time and materials nie wymaga dogłębnej analizy i planu całości już na początku - owszem, te kroki nadal się bardzo przydają i pewne założenia są niezbędne, aby zespół IT nie zabrnął w ślepą uliczkę ze swoimi decyzjami technologicznymi, jednak nie muszą to być rozważania dotyczące najdrobniejszych szczegółów aplikacji, które będą realizowane za kilkanaście miesięcy. Zamiast tego analizowane są poszczególne partie oprogramowania, które właśnie mają być implementowane - dzięki temu wszyscy są zawsze na bieżąco i rzadziej występuje problem przypominania sobie, co zostało ustalone rok wcześniej.

Decydując się na time and materials trzeba wziąć pod uwagę to, że rozliczamy się za faktycznie poświęcony czas, więc trudno przewidzieć rachunek. Oczywiście, po to robi się wstępną estymację, aby wiedzieć, czego mniej więcej obie strony mogą się spodziewać, jednak końcowa kwota może minimalnie różnić się od założonej zarówno w dół, jak i w górę. Spokojnie - w przypadku, kiedy już widać, że praca bardzo odbiega od początkowego oszacowania, software house powiadomi klienta i zapyta, co dalej. Inną konsekwencją, tym razem dla zespołu IT, jest konieczność uważniejszego notowania swojego czasu pracy (oczywiście, w pewnym przybliżeniu) - zwykle programiści i tak to robią, choćby dla wewnętrznych analiz, ale tutaj jest to szczególnie ważne z uwagi na wpływ tych wartości na późniejsze rozliczenia.

Także tutaj podsumujmy korzyści i niebezpieczeństwa dla obu stron:

Klient:

• dostępna wiedza, ile realnie kosztuje praca przy projekcie, po każdej transzy można zobaczyć postęp oprogramowania; łatwiej też przerwać współpracę,
• można sprawniej reagować i wprowadzać zmiany, skupiając się na rzeczach rzeczywiście istotnych z biznesowego punktu widzenia,
• szybciej widać postępy, co przynosi wszystkim większą motywację i ochotę do działania,
• trudniej zaplanować budżet, gdyż nieznane są realne koszty,
• brak sztywnych terminów w dłuższej perspektywie z uwagi na większą swobodę zmian,
• nie ma gwarancji ukończenia “całego” projektu, współpraca w długim okresie czasu jest mniej przewidywalna.

Software house:

• rozliczenia są za realną pracę, przez co łatwiej uniknąć nierentowności projektu,
• nowe funkcje i zmiany są ustalane i dyskutowane na bieżąco, przez co łatwiej zarządzać doprecyzowaniem szczegółów,
• prace odbywają się małymi partiami, które łatwiej planować,
• decyzje klienta o zmianach mogą naruszać architekturę oprogramowania - tutaj szczególnie rekomendowane jest elastyczne podejście do budowy kodu, co wymaga doświadczenia,
• brak pewności współpracy z klientem w dłuższym okresie,
• konieczność uważnego monitorowania i zapisywania czasu pracy, co bywa trudne przy pracy nad wieloma projektami naraz.

Co dodatkowo warto ustalić?

Niezależnie od przyjętej formy współpracy, istnieje kilka punktów, które powinny zostać przemyślane i przedyskutowane pomiędzy klientem a software housem.

W powyższych rozważaniach kilka razy została podniesiona kwestia dokumentacji, która jest szczególnie ważna przy podejściu fixed price, ale w mniej sztywnej formie występuje także w time and materials. Warto się zastanowić, w jaki sposób będą spisywane ustalenia - można to robić na różne sposoby, a sami polecamy opracowaną przez Piotra Miklosika metodę HANSA. Korzystając z okazji, dziękuję Piotrowi za pomoc w merytorycznym przygotowaniu tego artykułu.

Kwestią dyskusji jest też okres rozliczeniowy lub zakres prac, po którym następuje wystawienie faktury. Zwykle wynosi on dwa tygodnie lub miesiąc, jednak projekty i potrzeby udziałowców są tak różne, że warto przedyskutować to wcześniej, aby uniknąć nieporozumień.

Kolejną kwestią jest ustalenie czasu gwarancji na zrealizowane prace oraz umiejętne zarządzanie informacją, co podlega gwarancji w danym momencie. Dotyczy to szczególnie dłuższej współpracy, w której pojawiają się zgłoszenia dotyczące kwestii opracowywanych wiele miesięcy wcześniej.

Idąc dalej, warto wcześniej przedyskutować sposób odbierania prac. Idealne jest każdorazowe spotkanie połączone z prezentacją nowych zmian, jednak wszyscy dobrze wiemy, że nie zawsze jest to możliwe z uwagi na brak czasu po obu stronach. Stąd należy pomyśleć, w jaki sposób to zrobić, mając na uwadze fakt, że im wcześniej klient oceni i zgłosi uwagi dotyczące bieżących kwestii, tym szybciej i sprawniej uda się wprowadzić zalecenia w życie. Dodatkowo, prace powinny być odbierane także formalnie, zabezpieczając tym samym obie strony.

Wreszcie, po etapie realizacji, następuje etap utrzymania, w którym zazwyczaj pojawiają się zgłoszenia zmian i zauważonych nieścisłości. Być może warto od razu podpisać umowę serwisową, o której więcej możecie przeczytać tutaj.

Jak widać, istnieje kilka kwestii, które mogą wydawać się “nudne” i niepotrzebne na wczesnym etapie współpracy, jednak ustalenie jasnych zasad pozwoli ograniczyć nieporozumienia w przyszłości na tym najgorszym poziomie, a więc formalnym. Dodatkowo, gotowość do przemyślenia tych spraw pokazuje profesjonalizm obu stron i to, że kooperacja rzeczywiście wygląda poważnie i działa jak partnerstwo.

Którą formę najlepiej wybrać?

Jak zwykle - to zależy. W przypadku projektów, w których klient od początku wie, czego chce i do czego dąży, a także choćby zgrubny harmonogram jest znany od początku, bardziej właściwe może okazać się podejście fixed price. Nie da się też ukryć, że od strony software house'u ta metoda jest wygodniejsza w "liczeniu", ale też bardziej ryzykowna ze względu na konieczność uważnego szacowania i przewidzenia wielu kwestii. Natomiast dla projektów lub zadań, które są w szczątkowej fazie planowania, nie są "pewne" pod kątem rozmiaru czy końcowych funkcji, warto wybrać podejście time and materials, dające większą elastyczność i niejako krok po kroku pokazujące, jak może wyglądać dalszy rozwój projektu.

Czy można łączyć oba podejścia? Po części tak - w ramach jednego projektu mogą zdarzyć się zadania "sztywno" wyceniane, jak i takie, w których wycena nie jest stała. A jeśli klient ma wątpliwości, które podejście jest najlepsze w jego przypadku i jak to wygląda w praktyce - zawsze może zapytać sam software house, który z pewnością wyjaśni, jak to u nich wygląda i jaki jest kształt rozliczeń. Jeśli chcesz o tym porozmawiać z nami (także niezobowiązująco - my naprawdę lubimy rozmawiać), zapraszamy do kontaktu. A nuż uda się zbudować razem coś ciekawego :)

Pozdrawiam i dziękuję - Jakub Rojek.