Jeśli kiedyś miałeś do czynienia z usługą prawną, najczęściej usłyszysz – „Nasza godzina pracy kosztuje 100-1000 złotych za godzinę. Zobaczymy ile nam to zajmie, zależy to od postępowania i charakteru sprawy.” Jednakże jeśli pójdziesz do notariusza, to najczęściej przestawi Ci górną stawkę danej usługi i raczej trudno będzie z nią negocjować.
To artykuł z cyklu Współpraca z dostawcą zewnętrznym. W ramach cyklu ukazały się artykuły:
1. Jak wybrać zewnętrznego dostawcę do rozwoju produktu?
2. Jaki model współpracy z dostawcą wybrać? Fixed price vs Time and material
Nie inaczej jest w świecie zamawiania usług informatycznych. Przy współpracy z dostawcą zewnętrznym, tworzącym produkt od strony technicznej, stosowane są dwa rodzaje rozliczeń – po stałej stawce za realizację projektu lub na podstawie przepracowanych godzin.
Pierwsza z nich to tzw. fixed price. Umawiamy się na konkretny zakres, podpisujemy umowę zawierającą dokładną dokumentację projektu, płacimy po zrealizowaniu tego zakresu (w całości lub etapami). Drugą metodę przyjęło się określać jako time and materials. Czas i materiały. Czas to liczba przepracowanych godzin. A tajemnicze materiały?
Co to są te słynne „materials”?
To koszty licencji, serwerów, podróży służbowych. Weźmy za przykład koszty licencji zewnętrznych. Przypuśćmy, że Twój dostawca korzysta z oprogramowania JIRA do wykonywania zadań programistycznych.Jego zespół jest 10-osobowy i pracuje nad rozwiązaniem. Na platformę dodajemy 5 nowych użytkowników. Cena dla 13 użytkowników to 7*15=105$ miesięcznie. I ta kwota powinna będzie doliczana do comiesięcznej faktury za usługę w modelu time and materials.
Zalety i wady obu modeli
Jakie są zalety i wady obu modeli? W czym najlepiej się sprawdzają, a gdzie trzeba uważać? Zebrałem je na poniższej liście.
Fixed price
- Łatwość zarządzania w trakcie projektu – wystarczy odebrać skończone dzieło
- Budżet jest przewidywalny i z góry określony
- Transparentność i łatwość raportowania dla sponsora projektu
- Trudność w określeniu założeń na początku projektu
- Nie sposób przewidzieć wszystkich funkcjonalności produktu
- Często pojawia się konieczność zmian w specyfikacji w trakcie projektu
Time and material
- Elastyczność w rozwijaniu funkcjonalności produktu
- Dynamiczne planowanie budżetu względem planów
- Możliwość pracy na sprintach, gdzie powstają mini-produkty
- Wymaga ciągłego planowania i rozliczania pracy dostawcy
- Wskazane jest wsparcie “osoby technicznej” w trakcie rozwoju produktu
- Wymaga stałego nadzoru nad budżetem i czasem realizacji
Mity na temat pracy w modelu Time and materials
Wiele firm boi się współpracy w modelu Time and materials. Wynika to z wielu steretotypów i mitów, które narosły wokół tego sposobu współpracy. Przyjrzyjmy się tym najbardziej popularnym.
Mit 1: „Firma napisze mi, że pracowała nad prostym zadaniem tysiąc godzin”
Po pierwsze, w większości przypadków, zadania powinny być najpierw estymowane (to znaczy wstępnie wycenione). Umawiając się na każdą pracę wykonawca można zapisać ile maksymalnie może zająć to zadanie. Jeśli znacznie przekroczy czas bez uzasadnienia może obniżyć stawkę godzinową lub nawet zerwać kontrakt
Mit 2: „Kupując czas programistów, nie wiem jaki jest produkt finalny”
Dobrze zorganizowana praca time and materials powinna być podzielona na etapy (sprinty). Efektem każdego sprintu powinien być kawałek oprogramowania. Nawet jeśli jest to baza danych, lub skonfigurowany serwer, dostawca powinien móc w czasie odbioru tego sprintu pokazać co zostało wykonane.
Mit 3: „Praca time and materials jest droższa niż fixed price”
Jeśli praca jest dobrze zorganizowana, jest wręcz przeciwnie. Dostawca, jeśli wycenia cały projekt z góry, musi wziąć duży zapas na ewentualne poprawki, dodatkowe funkcjonalności, lub zmiany w specyfikacji. Jeśli coś się zmieni lub zostanie dodane, wykonawca powinien domagać się wtedy zmiany specyfikacji, tzw. Change request. Dlatego paradoksalnie, praca w oparciu o czas, może być tańsza niż w przypadku z góry ustalonej stawki.
W swojej karierze w IT nie spotkałem się by firmy zawyżały swoje godziny względem tego co deklarują klientom. Warto jednak mieć po stronie odbiorcy zamówienia osoby, która także jest w stanie estymować czas zadań. Jeśli jako product manager nie masz takich kompetencji, poszukaj ich u kolegów z firmy lub zatrudnij zewnętrznego konsultanta. Kilkakrotnie firmy zamawiając produkty powyżej 1 miliona złotych zatrudniała mnie w roli product managera, głównie po to, bym oceniał i akceptował zadania realizowane przez dostawcę usług IT. Oceniałem m.in. czy estymacje etapów są realistyczne i czy realizowane zgodnie z wytycznymi.
Który model wybrać?
Fixed price
Wybierz model Fixed price, gdy:
- Dysponujesz ustalonym budżetem, którego nie można przekroczyć, np. w projekcie ze środków publicznych czy unijnych. Taka sytuacja jednak zdarza się bardzo rzadko, gdyż można często pewne prace opłacić z innego budżetu.
- Specyfikacja jest bardzo dokładna i jasno sprecyzowana.
- Możesz zgodzić się na kompromisy jeśli chodzi o jakość produktu.
- W projekcie będzie brało udział kilka podmiotów, np. Podwykonawcy.
- Nie masz jeszcze pełnego zaufania do dostawcy?
Time and materials
Wybierz model Time and materials, gdy:
- Twój produkt będzie powstawał w kolejnych iteracjach.
- Nie wiesz jeszcze co będzie produktem finalnym.
- Dostawca jest zaufany.
- Jesteś w stanie skontrolować jakość pracy dostawcy.
- Zakładasz działanie w kilku iteracjach.
Jaka jest praktyka? Model mieszany
Z doświadczenia pracy w usługach informatycznych najczęściej pierwszy kontrakt zawierany jest na określoną kwotę za określone prace (fixed price). Zazwyczaj już przy drugim, a najdalej przy trzecim kontrakcie, bazą do wyceny są godziny.
Innymi słowy, firma podaje co ma być wykonane i dostawca określa maksymalną liczbę godzin. Po akceptacji przystępuje do pracy. Ważne jest też dokładne cotygodniowe raportowanie nie tylko godzin ale też efektów pracy. Model mieszany jest bardzo często stosowany, natomiast konieczne jest zbudowanie zaufania stron.
To drugi artykuł z cyklu Współpraca z dostawcą zewnętrznym.
W następnych artykułach dowiesz się m.in. Jak efektywnie współpracować z dostawcami oprogramowania, nie będąc „osobą techniczną”? Jak przygotować umowę dla dostawcy?
Co za herezje… Trochę odnosisz się w artykule do scruma, zwłaszcza w części dotyczącej mitów, a zwłaszcza mit 3 mnie zabolał najbardziej. Piszesz tam o swoich doświadczeniach jako Product Manager. I to tym bardziej boli, że piszesz tam, że product manager estymuje, że on może podważyć estymację. NIGDY!!! Tylko zespół estymuje, tylko on ma wiedzę, która pozwala mu na to żeby prawidłowo oszacować złożoność zadania, czy nawet czas, jeśli w taki sposób chce estymować. Nigdy nie powinien robić tego nikt inny, tylko człowiek, który fizycznie wykona tę pracę. Proszę, usuń ten artykuł, bo jest w nim o wiele więcej herezji, których nie chce mi się przytaczać. Szanujmy swoją pracę i nie rozsiewajmy takich głupot w internecie…
Z tego co rozumiem Krzyśka, to nie chodzi o to by po stronie klienta był ktoś kto będzie estymował i narzucał zespołowi szacunki, tylko „Oceniał m.in. czy estymacje etapów są realistyczne i czy realizowane zgodnie z wytycznymi.” Według Ciebie, Klient ma „łykać” każdą wycenę którą przedstawi dostawca, bo po prostu tak powiedział? To jest normalna praktyka, że po stronie klienta jest też ktoś kto rozumie technologię i widzi, czy przedstawiane wyceny są realistyczne, czy nie. Jeśli nie to jest to normalny temat do dyskusji. Klient też musi się jakoś zabezpieczać, bo relacja klient-dostawca nie jest symetryczna.
Jasna sprawa, zgadzam się z tym, że klient nie jest na tyle nieodpowiedzialny żeby wierzyć bezgranicznie dostawcy (chociaż z drugiej strony jak w takim razie zbudować zaufanie) i może problemem jest nazywanie osoby, która weryfikuje estymacje „Product Manager”, dla mnie taka rola ma kompletnie inne obowiązki i odnosząc się do Scruma, to estymacja powinna się odbywać w obecności Product Ownera, który w mojej praktyce zawsze jest osobą „od klienta” albo samym klientem, ewentualnie możemy mieć pomost w postaci proxy PO. Wtedy w trakcie planowania klient (PO) może wyrazić swoją opinie na temat estymacji, która de facto nie powinna wpływać na ostateczną estymację zrobioną przez zespół dev – no, ale to przytaczam teorię Scruma. W przypadku TM można też estymować maksymalny koszt sprintu, czy etapu, czyli np. zaangażowanie wszystkich członków zespołu na 100% będzie kosztowało X, wtedy klient ma świadomość ile maksymalnie może zapłacić za projekt, a my ile maksymalnie czasu możemy na niego poświęcić.
Zresztą, nie zamierzam pisać artykułu na ten temat 😀 Trochę mnie razi mieszanie praktyki, z elementami Scruma w tym artykule. Ale tak się niestety często pracuje w Polsce. Zamiast robić Scruma, używa się tylko jego elementów, co nie przynosi spodziewanego efektu, a firma chwali się, że jest Agile, pracuje w Scumie itd.
Co do ostatniego akapitu – pełna zgoda 😀 A jak byś chciał jakiś artykuł jednak napisać – to zapraszamy do publikacji na PV 😀
Artykuł nie jest opisem tego jak powinien wyglądać SCRUM, tylko moich doświadczeń – pamiętajmy, że nie wszyscy pracują w SCRUMie 🙂 Akurat tutaj gdzie pracowałem jako Product Owner, było z BCG i oni mają swoją metodykę. Nie piszę jak to powinno wyglądać, tylko raczej, jak wygląda w praktyce, jedno z ujęć, z którym się zetknąłem. Na pewno nie pretenduję do autorytetu w roli PO, bo na codzień zajmuję się stykiem współpracy C-level z D-level (zarząd z IT), przede wszystkim strategią IT. Upraszczam trochę pewne elementy, bo artykuł musi być też czytelny 🙂
Metodyka dla ludzi jest a nie ludzie dla metodyki. Jednocześnie zgadzam się w 100%, że wiele firm się chwali, że stostuje Agile/Scrum a stosuje tylko elementy.
Wreszcie, warto pamiętać, że estymowanie jest niezwykle trudne i czasem zajmuje się tym zespół developerski zgodnie ze Scrumem, ale często robi to techniczny PM/architekt/lead dev etc. Osobiście nie widzę w takiej praktyce nic złego, bo oszczędza czas zespołu. Szczególnie, gdy zależy nam jedynie na podaniu wstępnego zakresu prac i wyjaśnieniu niejasności.