Rozliczanie godzinowe czy projektowe – co się bardziej opłaca?
Z wpisu dowiesz się kiedy wybrać rozliczenie projektowe, a kiedy godzinowe. Wyjaśnię, którym (według mnie) sposobem rozliczeń można zrealizować projekt szybciej. Poruszam temat z dwóch perspektyw – wykonawcy i klienta.
Na początku zacznę od dokładniejszego wyjaśnienia sposobów rozliczeń, które będę ze sobą porównywał.
- time and material (t&m, rozliczanie godzinowe) – płacimy za czas poświęcony nad wykonaniem zadania. Osoba realizująca nie musi gwarantować efektu prac – myślę, że głównie dlatego wielu ludzi jest sceptycznie nastawiona do tego typu rozliczeń. Bardzo często ustala się stawkę godzinową, programiści realizują zadania i finalnie mamy do zapłaty kwotę: stawka * liczba godzin przepracowanych nad zadaniami.
- fixed price (rozliczanie projektowe) – płacimy za efekt prac, bez względu na to ile czasu zajmie wykonawcy ich realizacja. Bardzo często ustala się termin oddania prac, jednak jest mniej ważne czy wykonawca poświęci na zadania 10h czy 100h – ważne jest aby były zrobione w sposób, który wcześniej uzgodniliśmy.
Oczywiście można się spotkać z hybrydami rozliczeń łączącymi na różne sposoby rozliczanie fixed price i t&m. W opisach podałem jaskrawe przykłady, żeby podkreślić różnicę między nimi.
W Fresh Apps głównie rozliczamy się godzinowo. Jedną z najczęstszych wątpliwości jaką muszę rozwiewać podczas rozmowy z klientami jest obawa, że w tym typie rozliczeń nie gwarantuje się efektu prac. Trzeba więc wykazać się sporym zaufaniem do wykonawcy. Z moich obserwacji i statystyk bardzo często projekty realizowane w rozliczeniu godzinowym są realizowane szybciej i taniej – wyjaśnię dlaczego.
Generalizując, są dwa główne typy projektów:
- projekty o zmiennym lub niezdefiniowanym zakresie – nikt nie wie, nawet odbiorca biznesowy jak finalnie będzie wyglądał realizowany produkt. Często istnieją ogólne założenia i koncepcja projektu. Detale (mniejsze i większe 😉 ) będą ustalane na etapie realizacji.
- projekty o stałym i zdefiniowanym zakresie – są poparte analizą przedwykonawczą. Istnieje niewielkie ryzyko, że zakres ulegnie zmianie. Projekt jest zaplanowany w ogóle i szczególe.
Mówiąc ogólnie – najczęściej spotykamy się z powyższymi typami projektów. Istnieją oczywiście hybrydy. Warto zaznaczyć, że bardzo często tylko wydaje nam się, że projekt ma stały i zdefiniowany zakres. Spisanie założeń w mailu, to nie analiza przedwykonawcza. Bardzo często (głównie freelancerzy) podchodzą do takich szczątkowych i lakonicznych dokumentacji jakby projekt miał zdefiniowany zakres i rozliczają się projektowo kiedy tak naprawdę nie wiadomo jak w szczegółach (które wpływają na pracochłonność) projekt ma wyglądać. Opisałem to złudzenie w kolejnych akapitach.
Zacznę od opisywania sytuacji dla projektu o zakresie zmiennym, niezdefiniowanym. Przed przystąpieniem do prac często wykonawca proszony jest o niewiążącą wycenę zadań w postaci liczby rbh (roboczogodzin). Służy to temu, żeby klient mógł ocenić czy stać go na realizację projektu oraz poznać szacowaną datę ukończenia prac. Dla uproszczenia przyjmijmy, że nasz projekt składa się z trzech zadań: task #1, task#2, task#3. Podczas estymowania zadań przez programistów w projekcie, który ma jedynie zarys zakresu trzeba wielokrotnie domyślać się, zakładać jak ma system wyglądać w detalach – jest to niezbędne do oszacowania czasu realizacji. Musimy zgadywać bo nigdzie nie zostało sprecyzowane jak ma wyglądać finalny efekt. Bardzo często robiąc te założenia mylimy się, więc rzeczą całkowicie normalną jest to, że przy wycenie projektu o niezdefiniowanym zakresie wycena szacunkowa odbiega od faktycznego czasu realizacji. Czasami jest wyższa, czasami niższa – ale w większości przypadków jest różna. Poniżej możesz zobaczyć diagram, który nakreśli to, co mam na myśli.
Długość prostokąta z zadaniem określa czas jego wykonania. Czyli czym dłuższy prostokąt, tym dłuższy czas realizacji. Linią przerywaną zaznaczyłem założenia programistów.
- Task #1 – programista założył, że skończy go wcześniej. Zadanie się opóźniło względem szacunkowej wyceny.
- Task #2 – programista wykonał zadanie szybciej niż zakładał.
- Task #3 – programista założył, że skończy zadanie wcześniej. Prawie udało mu prawidłowo oszacować czas realizacji.
Przy rozliczaniu godzinowym mimo tego, że programista opóźnił realizację dwóch zadań względem szacunkowej wyceny – klient płaci za godziny poświęcone nad zadaniami. W tym miejscu trzeba powiedzieć, że bardzo często programista nie jest winien tej sytuacji. W trakcie realizacji klientowi mógł wpaść do głowy dodatkowy zakres, lub musiało być zastosowane rozwiązanie bardziej pracochłonne, którego nie był w stanie przewidzieć.
Zdarza się, że w takich przypadkach (jak pisałem wcześniej) następują rozliczenia projektowe – wykonawca godzi się na wykonanie projektu za ustaloną z góry kwotę, kiedy tak naprawdę nie zna szczegółów projektu. Czasami te szczegóły mogą przedłużyć czas realizacji o kilkaset procent. W przypadku kiedy wykonawca realizuje projekt o niezdefiniowanym zakresie metodą fixed price bierze na siebie sporą odpowiedzialność. Odpowiedzialność kosztuje, więc wykonawca narzuca bufor na wykonywane zadania, żeby z niego skorzystać w momencie, gdy będzie trzeba użyć bardziej pracochłonnych rozwiązań do zrealizowania projektu. Czasami bufor wystarcza, czasami się go przekracza (wtedy na projekcie nie zarabiamy tylko tracimy (w ogólnieniu)). Wycena takiej sytuacji wyglądałaby mniej/więcej tak:
Zaznaczyłem na diagramie w każdym zadaniu 2 sekcje – zakładany czas realizacji i bufor na nieprzewidziane trudności.
FYI: rozliczenie projektowe jest tak naprawdę zbliżone do rozliczania godzinowego. W jednym i drugim przypadku zakładamy ile poświęcimy roboczogodzin na realizację. Różnicą jest to, że w przypadku rozliczania godzinowego odpowiedzialność ponosi klient (płaci za opóźnienia), a w przypadku rozliczenia projektowego odpowiedzialność ponosi wykonawca (klienta nie obchodzi to, że nie doszacowaliśmy czasu realizacji lub założyliśmy zbyt mały bufor). Bufory mają różną długość – przy bardziej ryzykownych zadaniach bufor może wynosić nawet 100% (lub więcej) czasu realizacji. W naszym przykładzie bufory są mają „standardową długość” 20-40%.
W powyższym przykładzie rozliczania projektowego klient więc płaci za bufor, który być może wykorzystamy, a być może nie będziemy zmuszeni go użyć i „zarobimy więcej”. Dodanie dużych buforów zwiększa szanse rentowności projektu po stronie wykonawcy. Z drugiej strony są to dodatkowe koszta po stronie klienta.
W tym przypadku (podobnie jak w poprzednim) zakładamy, że długość prostokąta wyraża jego pracochłonność. Na poniższym diagramie zaprezentuję jak wygląda porównanie kosztu realizacji tego samego projektu w dwóch sposobach rozliczeń – godzinowym i projektowym.
Jak widać podsumowując czas za który płaci klient w rozliczeniu godzinowym jest krótszy niż w rozliczeniu projektowym. Dotyczy to tych samych zadań w tym samym projekcie. W przypadku rozliczenia godzinowego zsumowałem czas realizacji (2 zadania opóźnione, jedno wykonane przed czasem), natomiast w przypadku rozliczenia projektowego jest to suma czasu realizacji (zakładanego) wraz z buforem (bo klient też za niego płaci). Prezentuję ten wykres „oczami klienta”, który w tym przypadku zapłaciłby około ~25% mniej rozliczając się z wykonawcą godzinowo. Nie musiałby płacić za niejawne bufory. Niestety większość klientów wychodzi z założenia, że „czego nie widać tego sercu nie żal” i wolą rozliczać się projektowo bo nie mają świadomości buforów.
Oczywiście mówimy tu o „zdrowych projektach”. Kiedy klientowi również zależy na ukończeniu projektu. Niestety, ale spotykałem się kilkukrotnie z sytuacją, gdy po ustaleniu ceny na projekcie z niezdefiniowanym zakresie rozpoczynał się „koncert życzeń” klienta. Czyli padały założenia, o których nie było mowy przed realizacją projektu i wstępnej wyceny. Jest to oczywiście sytuacja patologiczna. W takim przypadku powyższy wykres prawdopodobnie wyglądałby odwrotnie. Po ustaleniu ceny, często klientom przestaje zależeć na „skutecznym” przekazaniu wymagań – nie płacą za stracony czas wykonawcy, który poświęcił na zgadywaniu co autor miał na myśli. Smutne, ale życiowe.
Złudzenie zdefiniowanego zakresu
Złudzenie zdefiniowanego zakresu to częsty wróg mniej doświadczonych wykonawców. Wspominałem już o tym wcześniej – często słyszę od znajomych freelancerów, że mają projekt o zdefiniowanym i stałym zakresie opisany w mailu ~1000 znaków (to mniej niż ten wpis). Przy projekcie trwającym kilka tygodni, w tej ilości znaków da się opisać jedynie koncepcję, zarys.
Innym zgubnym elementem często bywa zrobiona analiza, dokumentacja (która potrafi być obszerna), przez osobę, która nie potrafi tego robić. W takim przypadku mimo napisanego tekstu – zakres ciężko uznać za stały i zdefiniowany. Pisanie dokumentu, wymagań to nie tylko „klepanie” akapitów – to bardzo trudna czynność, która na początku pracy analitycznej potrafi wychodzić z różnym skutkiem. Tym częściej wychodzi „średnio” jeśli ktoś na codzień nie pracuje jako analityk i stara się opisać projekt. Należy brać poprawkę na to w jaki sposób pisany jest dokument i przez kogo (ile autor ma doświadczenia). Czasami jedno źle dobrane zdanie może zwielokrotnić pracochłonność. Największym wrogiem analiz przedwykonawczych jest niejednoznaczność – kiedy coś jest opisane w sposób, który możemy zinterpretować to na więcej niż jedną możliwość. Zawsze istnieje ryzyko, że zrealizujemy według tego niewłaściwego sposobu rozwiązania.
Często spotykam się z sytuacją, w której analizę/wymagania lub kryterium akceptacji sporządza klient – bo w jego mniemaniu przecież on zna to najlepiej (finalną wizję projektu). Natomiast (z całym szacunkiem) nie zawsze jest to najlepsza osoba do tworzenia wymagań. W większości przypadków klient jest osobą nietechniczną, co dodatkowo potęguje ryzyko wystąpienia błędów w analizie przez nieznajomość specyfiki pracy programistów. Klient ma również często spaczony stosunek do projektu bo patrzy na niego „jak na swoje dziecko”, czasami brakuje chłodnego myślenia analitycznego. Możemy taką sytuację zauważyć wśród startupowców, którzy z wielkim uporem pomimo przesłanej społeczności i liczb realizują swoje aplikacje. Trudno powiedzieć sobie stop.
Warto zaznaczyć, że spisanie samych wymagań (co często robi klient w różnego rodzaju brief’ach) to nie analiza. Pisałem o tym m.in. poruszając temat analizy i syntezy. Najczęściej wymagania możemy zobaczyć w postaci kryterium akceptacji zadania. Wbrew pozorom trudno je napisać „z głową, dobrze”. Jeśli robi to osoba niedoświadczona to kryteria bywają napisane w taki sposób, że można je często spełnić robiąc tzw „fuszerkę”, a właśnie po to je się tworzy żeby wyeliminować taki styl pracy.
Pisałem już o tym, że nie jesteśmy w stanie pominąć etapu tworzenia analizy przedwykonawczej. Nie będę się więc powtarzał. W tym miejscu jedynie zachęcam cię do obejrzenia podlinkowanego przeze mnie filmiku żeby uświadomić sobie, że jeśli nie zrobimy analizy przed pracami programistycznymi – to zrobią ją programiści podczas realizacji projektu. Oczywiście płaci za to klient – niezależnie od sposobu rozliczeń. W fixed price jest to dodawane w postaci np. buforu, w t&m występuje to bardziej jawnie. Z mojego doświadczenia wynika, że taniej jest gdy analizę zrobi analityk przed wykonaniem prac programistycznych, niż gdy robią to programiści „w trakcie pracy” ;).
Podsumowanie
Wbrew pozorom rozliczanie projektowe nie różni się bardzo od rozliczania godzinowego. Największą różnicą jest to, że w przypadku rozliczenia projektowego odpowiedzialność za zmianę zakresu ponosi wykonawca, w przypadku godzinowego – klient. Z mojego doświadczenia wynika, że częściej szybciej i taniej jest realizować projekt w rozliczeniu godzinowym. Nie jest to oczywiście regułą – są różne rodzaje projektów, niektóre z nich wymagają specjalnego podejścia.
Musimy uświadomić sobie, że nikt nie pracuje za darmo. Jeśli rozliczamy się z kimś projektowo to musimy być świadomi, że wykonawca w kwotę wliczył czas, który poświęci na analizę i nieprzewidziane trudności (bufor). Często te rzeczy nie są jasno wydzielane w wycenie – stąd mylne wrażenie, że wykonawca nie poświęci na nie czasu, a klient za nie nie zapłaci. W rozliczeniu godzinowym etapy realizacji są bardziej jawne – klient nie płaci za bufory bo ich nie ma. Nie ma ich dlatego, że wykonawca nie ponosi odpowiedzialność za zmianę zakresu.
Rozliczenie projektowe będzie tańsze od godzinowego w przypadku gdy nasz wykonawca jest niekompetentny – wtedy można powiedzieć, że płacimy za rezultat jaki uzyska, nie płacąc za błądzenia w drodze do uzyskania rozwiązania. W innych przypadkach (moim zdaniem) tańsze okaże się rozliczenie godzinowe. W rozliczeniu projektowym płacimy za dodatkowe (niejawne) elementy realizacji, które być może są nadmiarowo wycenione. Klient w takim przypadku „przepłaca”. W przypadku rozliczenia godzinowego ten problem nie występuje, klient nie płaci za czas, którego programista nie wykorzystał. Ogromną barierą, którą zauważam jest mentalne przełamanie się i zaufanie wykonawcy. Klient boi się stwierdzenia, że płaci za poświęcony czas, nie za efekt. Natomiast gdy te liczby wpiszemy w Excel, często wychodzi, że to się bardziej opłaca.
Sprawdź jak mogę Ci pomóc osiągnąć Twoje cele 🎯
Dziękuję, że przeczytałeś ❤️
Pssst... przygotowałem dla Ciebie kilka prezentów - wybierz co Ci się przyda! 👍
