W usługach pomiędzy przedsiębiorcami, takimi jak np. IT i software development, body leasing / staff augmentation, utrzymanie i rozwój oprogramowania, cloud computing i DevOps, budownictwo i remonty, inżynieria i przemysł (i wiele innych) często spotykamy się z dwoma modelami współpracy: umową o dzieło oraz rozliczeniem usług w modelu Time & Materials (T&M).
W praktyce różnica pomiędzy nimi ma bardzo duże znaczenie. Wpływa nie tylko na sposób rozliczenia wynagrodzenia, ale przede wszystkim na zakres odpowiedzialności wykonawcy, sposób organizacji pracy, ryzyko projektowe oraz oczekiwania dotyczące rezultatu.
Jest to szczególnie istotne w relacjach pomiędzy wykonawcą a klientem, gdy strony rozważają, czy współpraca ma polegać na dostarczeniu konkretnego rozwiązania, czy raczej na udostępnieniu klientowi kompetencji zespołu.
Na potrzeby niniejszego artykułu będziemy posługiwać się przykładem branży IT.
Umowa o dzieło – najważniejszy jest określony rezultat
Zgodnie z art. 627 Kodeksu cywilnego przez umowę o dzieło przyjmujący zamówienie zobowiązuje się do wykonania oznaczonego dzieła, a zamawiający do zapłaty wynagrodzenia.
Najważniejszym elementem tej konstrukcji jest zatem oznaczone dzieło, czyli określony rezultat, którego osiągnięcia oczekuje zamawiający.
W branży IT może nim być przykładowo:
- wykonanie aplikacji,
- stworzenie określonego modułu oprogramowania,
- przygotowanie konkretnego systemu,
- wykonanie określonej integracji,
- stworzenie strony internetowej według ustalonej specyfikacji,
- wykonanie określonej funkcjonalności.
Oczywiście nie każde świadczenie informatyczne będzie automatycznie dziełem. O kwalifikacji konkretnej umowy decyduje jej rzeczywista treść i charakter zobowiązania, a nie sama nazwa nadana jej przez strony.
Time & Materials – płacimy za czas i wykorzystane zasoby
Time & Materials (T&M) nie jest nazwanym typem umowy uregulowanym w Kodeksie cywilnym.
Jest przede wszystkim modelem organizacji i rozliczania współpracy.
W modelu T&M wynagrodzenie jest najczęściej uzależnione od:
- liczby przepracowanych godzin,
- stawki godzinowej,
- liczby wykorzystanych dni,
- rodzaju zaangażowanych specjalistów,
- ewentualnie innych uzgodnionych kosztów materiałowych lub usług dodatkowych.
Przykładowo strony mogą ustalić, że programista świadczy usługi według stawki 250 zł netto za godzinę, a klient otrzymuje miesięczne rozliczenie odpowiadające rzeczywistej liczbie przepracowanych godzin.
Nie oznacza to jednak, że w T&M wykonawca może wykonywać pracę w sposób całkowicie dowolny. Kluczowa różnica polega na tym, że punktem odniesienia jest przede wszystkim świadczenie pracy/usługi przez określony czas i przy wykorzystaniu określonych zasobów, a nie zagwarantowanie z góry określonego rezultatu całego projektu.
T&M nie oznacza automatycznie „braku odpowiedzialności za rezultat”
Zgodnie z art. 471 Kodeksu cywilnego dłużnik może odpowiadać za szkodę wynikającą z niewykonania lub nienależytego wykonania zobowiązania. Dlatego również w modelu T&M wykonawca powinien należycie wykonywać swoje zobowiązania.
Różnica polega na czym innym – w T&M odpowiedzialność powinna być związana z zakresem rzeczywiście przyjętego zobowiązania, a nie automatycznie z gwarancją osiągnięcia całego rezultatu projektu.
Najważniejsza różnica: kto ponosi ryzyko projektu?
To właśnie kwestia ryzyka najczęściej odróżnia klasyczny model rezultatowy od T&M. W przypadku umowy, której przedmiotem jest wykonanie konkretnego rezultatu, wykonawca może przejmować większą część ryzyka związanego z jego osiągnięciem. Jeżeli klient zamawia: „wykonanie aplikacji posiadającej funkcjonalności X, Y i Z zgodnie ze specyfikacją”, to wykonawca ma jasny cel, do którego powinien doprowadzić.
W modelu T&M sytuacja może wyglądać zupełnie inaczej. Klient może powiedzieć: „Potrzebujemy programisty na 160 godzin miesięcznie. Będzie pracował w naszym zespole, zgodnie z zadaniami ustalanymi przez naszego Product Ownera.” W takim przypadku klient w znacznym stopniu zachowuje kontrolę nad:
- zakresem bieżących prac,
- priorytetami,
- wymaganiami,
- kolejnością wykonywania zadań,
- decyzjami produktowymi,
- organizacją projektu.
Trudno więc automatycznie przenosić całe ryzyko rezultatu na podmiot, który jedynie udostępnia specjalistę.
T&M a body leasing
Szczególnie wyraźnie widać tę różnicę w przypadku body leasingu lub team augmentation.* W takim modelu software house może zobowiązać się do udostępnienia klientowi konkretnego programisty albo zespołu.
Przykładowo: Software house zapewnia programistę Java na okres sześciu miesięcy, w wymiarze do 160 godzin miesięcznie.
Klient natomiast:
- przydziela zadania,
- określa priorytety,
- przekazuje wymagania,
- organizuje pracę zespołu,
- nadzoruje realizację projektu,
- dokonuje bieżącej weryfikacji efektów.
W takiej sytuacji świadczenie software house’u może być bliższe udostępnieniu określonych kompetencji i zasobu osobowego niż zobowiązaniu do wykonania konkretnego dzieła.
To ma istotne konsekwencje dla odpowiedzialności.
Odpowiedzialność za programistę a odpowiedzialność za projekt
W modelu body leasingowym warto odróżnić dwie kwestie: odpowiedzialność za należyte wykonanie zobowiązania przez software house od odpowiedzialności za końcowy rezultat całego projektu klienta.
Software house może odpowiadać przykładowo za:
- zapewnienie osoby o uzgodnionych kwalifikacjach,
- dostępność specjalisty,
- przestrzeganie uzgodnionych zasad współpracy,
- poufność,
- bezpieczeństwo,
- należyte wykonywanie powierzonych zadań,
- zawinione działania lub zaniechania po swojej stronie.
Nie oznacza to jednak automatycznie odpowiedzialności za każdy element projektu, którego organizacją i nadzorem zajmuje się klient.
Wynagrodzenie – Fixed Price a T&M
Kolejną istotną różnicą jest sposób kalkulowania wynagrodzenia. W modelu Fixed Price strony często ustalają: „Za wykonanie całego projektu klient zapłaci 200 000 zł.” Wykonawca musi więc skalkulować, ile będzie kosztować realizacja projektu. Jeżeli projekt okaże się bardziej pracochłonny niż zakładano, ryzyko tego wzrostu kosztów może w dużej mierze obciążać wykonawcę – zależnie oczywiście od treści umowy i mechanizmów zmiany zakresu.
W modelu T&M strony mogą ustalić: „Wynagrodzenie wynosi 250 zł netto za godzinę pracy programisty.” Jeżeli programista przepracuje 100 godzin, wynagrodzenie wynosi 25 000 zł. Jeżeli przepracuje 150 godzin, wynagrodzenie wynosi 37 500 zł. Ryzyko związane z liczbą godzin potrzebnych do wykonania określonych zadań jest zatem rozłożone inaczej niż w modelu Fixed Price.
A co, jeżeli projekt trwa dłużej niż zakładano?
To właśnie jedna z sytuacji, w których różnica między modelami staje się najbardziej widoczna.
Załóżmy, że klient chce stworzyć nową aplikację. W modelu Fixed Price wykonawca może zobowiązać się do dostarczenia określonego rozwiązania za 300 000 zł. Jeżeli wykonanie projektu zajmie więcej czasu, niż zakładano, wykonawca może ponieść dodatkowy koszt – chyba że wystąpią podstawy do zmiany wynagrodzenia lub zakresu.
W modelu T&M klient płaci natomiast za rzeczywisty czas pracy. Jeżeli wykonanie zadania wymaga większej liczby godzin, wynagrodzenie może odpowiednio wzrosnąć. Nie oznacza to oczywiście, że klient powinien płacić za nieefektywną lub wadliwą pracę. Dlatego umowa powinna określać zasady raportowania, akceptacji i odpowiedzialności za nienależyte wykonanie zobowiązań.
Zakres prac w T&M może się zmieniać
To kolejna istotna cecha T&M. W praktyce projekty IT rzadko pozostają niezmienne od dnia podpisania umowy do dnia zakończenia projektu.
Zmieniają się:
- wymagania biznesowe,
- priorytety,
- funkcjonalności,
- architektura,
- harmonogram,
- zakres integracji,
- oczekiwania użytkowników.
Model T&M dobrze odpowiada na takie warunki, ponieważ strony mogą na bieżąco kierować pracę zespołu na kolejne zadania. W modelu opartym na z góry określonym rezultacie każda istotna zmiana zakresu może natomiast wymagać zmiany specyfikacji, harmonogramu i wynagrodzenia.
Co z błędami programisty?
To jeden z najczęstszych punktów spornych.
Klient może argumentować: „Programista popełnił błąd, więc software house powinien bezpłatnie go poprawić.” Odpowiedź zależy od konstrukcji konkretnej umowy.
Jeżeli software house zobowiązał się do wykonania konkretnego rezultatu zgodnego ze specyfikacją, odpowiedzialność za niezgodność rezultatu z uzgodnionymi wymaganiami może być istotnym elementem zobowiązania.
Jeżeli natomiast mamy do czynienia z body leasingiem, a programista:
- pracuje pod kierownictwem klienta,
- realizuje zadania przekazywane przez klienta,
- korzysta z architektury i środowiska klienta,
- otrzymuje zmieniające się wymagania,
- jest częścią zespołu klienta,
to odpowiedzialność powinna być analizowana przez pryzmat rzeczywistego podziału obowiązków.
Nie każdy problem techniczny w projekcie jest automatycznie „błędem software house’u”.
Co jest bardziej korzystne dla zamawiającego?
Nie ma jednej odpowiedzi.
Umowa o dzieło / model rezultatowy może być korzystniejszy, gdy:
- klient dokładnie wie, czego potrzebuje,
- zakres projektu jest dobrze określony,
- wymagania są stabilne,
- klient chce przenieść większą część ryzyka wykonania na wykonawcę,
- istotne jest osiągnięcie konkretnego rezultatu.
T&M może być korzystniejsze, gdy:
- wymagania będą się zmieniać,
- projekt jest innowacyjny lub trudny do precyzyjnego oszacowania,
- klient chce samodzielnie zarządzać pracą zespołu,
- potrzebna jest elastyczność,
- zakres prac nie jest jeszcze dokładnie znany,
- klient chce mieć możliwość zmiany priorytetów bez każdorazowej renegocjacji całej umowy.
Co jest bardziej korzystne dla software house’u?
Z perspektywy software house’u T&M może ograniczać ryzyko związane z niemożnością dokładnego oszacowania projektu. Nie oznacza to jednak, że T&M zawsze jest bezpieczniejszy. Jeżeli umowa zawiera jednocześnie postanowienie: „Wykonawca rozliczany jest godzinowo, ale zobowiązuje się do bezpłatnego usunięcia wszelkich błędów aż do momentu uzyskania satysfakcjonującego rezultatu”, software house może w praktyce przejąć ryzyko charakterystyczne dla modelu rezultatowego, mimo że wynagrodzenie ustalono jako T&M.
Dlatego model rozliczenia i zakres odpowiedzialności powinny być ze sobą spójne.
Nie sama nazwa umowy decyduje o jej charakterze
W praktyce nie wystarczy zatytułować dokument: „Umowa o świadczenie usług T&M” albo „Umowa o dzieło”. O charakterze prawnym konkretnego zobowiązania decyduje przede wszystkim jego rzeczywista treść i sposób wykonywania. Jeżeli dokument nazwany „umową T&M” w rzeczywistości zobowiązuje wykonawcę do osiągnięcia ściśle określonego rezultatu, sama nazwa umowy nie rozwiązuje problemu. Podobnie umowa nazwana „umową o dzieło” nie będzie automatycznie umową o dzieło tylko dlatego, że strony użyły takiego tytułu.
Podsumowanie
Umowa o dzieło i model Time & Materials odpowiadają na różne potrzeby biznesowe. W przypadku umowy o dzieło kluczowe znaczenie ma oznaczony rezultat, który wykonawca zobowiązuje się osiągnąć. W przypadku T&M kluczowe znaczenie ma natomiast czas pracy i zasoby wykorzystywane do realizacji zadań, przy większej elastyczności co do zakresu i sposobu organizacji projektu. Nie oznacza to, że T&M wyłącza odpowiedzialność wykonawcy za nienależyte wykonanie zobowiązania. Oznacza natomiast, że odpowiedzialność ta powinna być dostosowana do rzeczywistego zakresu zobowiązania oraz podziału odpowiedzialności pomiędzy stronami. Szczególnego znaczenia nabiera to w przypadku body leasingu. Jeżeli Zamawiający samodzielnie zarządza pracą programisty, określa wymagania i priorytety oraz podejmuje decyzje dotyczące projektu, nie powinien automatycznie przenosić na software house całego ryzyka związanego z rezultatem projektu.
Warto zatem, jeszcze przed podpisaniem umowy, skonsultować jej treść z prawnikiem, który doradzi jaki model współpracy będzie dla nas korzystniejszy.
*team augmentation – to model współpracy, w którym zewnętrzny dostawca uzupełnia istniejący zespół klienta o dodatkowych specjalistów, np. programistów, testerów, DevOps czy UX designerów.
