Agile na fix price, czyli jak przygotować dobrą umowę na projekty agile? Kontraktowanie prac w metodykach zwinnych

Punkty widzenia

Agile na fix price, czyli jak przygotować dobrą umowę na projekty agile?

Kontraktowanie prac w metodykach zwinnych

Zwinne organizacje | Blog o Agile

Przygotowanie dobrej umowy dla dostawcy zewnętrznego na projekty prowadzone metodami zwinnymi jest dużym wyzwaniem dla organizacji. Niejednokrotnie od dostawców oczekuje się, że będą bardziej elastyczni w zakresie reagowania na zmiany zakresu i tempa prac, jednocześnie zapisy kontraktów oraz zawarte w nich kary umowne znacząco ograniczają pole manewru w tej kwestii. Jak zatem skonstruować dobrą umowę?

W ostatnim czasie wiele razy słyszałem mniej więcej takie opinie: „Ogólnie podejście agile’owe jest fajne ale my dowozimy projekty na fix price więc nie da rady”. Dla mnie takie stawianie sprawy może oznaczać, że różnie jest rozumiane zarządzanie budżetem i zakresem na projektach zwinnych dlatego chciałbym się podzielić moimi przemyśleniami w tym temacie. Aby łatwiej mi było przekazać moje myśli proszę wyobraźmy sobie sytuację w której mamy firmę „Duże Korpo”, która chce zamówić prace deweloperskie od firmy „Śrubokręty”. Chodzi, na przykład, o kontrakt na wdrożenie systemu CRM, w technologii „Niebieska chmurka”, na które firma „Duże Korpo” może poświęcić w danym roku 5 mln PLN (tyle zostało zabudżetowane na ten cel - firma nie zna jeszcze koncepcji Beyond Budgeting). Co więcej firma „Duże Korpo” jest w trakcie transformacji w kierunku zwinnego modelu prac dlatego wdrożenie systemu CRM również chce wykonać w metodyce zwinnej a konkretnie w Scrum.

Subskrybuj "CIO Insights"

Otrzymuj powiadomienia e-mail o nowych wydaniach tego newslettera

Zarejestruj się

Agile a dostawcy zewnętrzni

Pierwsze pytanie jakie się nasuwa, to czy korzystanie z dostawców zewnętrznych nie kłóci się z podejściem zwinnym? Z jednej strony sukces w pracy zwinnej w dużej mierze zależy od zaangażowania poszczególnych osób i ich otwartości. Teoretycznie kontraktorzy mogą mniej się identyfikować z celem projektu[1] niż pracownicy stali, ponieważ mogą traktować środowisko projektowe jako tymczasowe. Dziś są u tego klienta, jutro u innego. Co więcej, może być w ich interesie, aby projekt trwał jak najdłużej i aby zarobić na danym kliencie jak najwięcej. Ciężko również sobie wyobrazić aby kontraktorzy byli członkami zespołów DevOps czyli takich, które w długim okresie zajmują się rozwojem i utrzymanie danego produktu. Jeśli już planujemy budowę zespołu, który będzie przez kilka lat, w stałym składzie, pracował razem, to może lepiej zbudować go z osób pracujących na etacie.

Z drugiej strony, zespoły Scrum złożone w jakimś stopniu z kontraktorów, dalej mogą budować produkty zgodnie z filarami, wartościami oraz procesem opisanym w Scrum Guide. Myślę, że ciężko będzie wykazać, że praca przy wsparciu dostawców zewnętrznych jest niezgodna z tą metodyką. Co do samego podejścia poszczególnych kontraktorów do pracy i teoretycznego konfliktu interesów, to według mnie ciekawy punkt widzenia przedstawia Douglas McGregor w teorii motywacji. Według tej teorii głównym motywatorem ludzi do pracy jest chęć samorealizacji oraz przyjemność z wykorzystywania swojego potencjału, oczywiście jeśli nie jesteśmy krępowani zapisami umowy. Oznaczałoby to, że również dla kontraktorów, jeśli są ludźmi a nie robotami, ważniejsze będzie poradzenie sobie z wyzwaniem projektowym niż wynik finansowy firmy, z której pochodzą, co w sumie jest dość bezpiecznym podejściem.

W tej sytuacji firma „Duże Korpo” postanowiła poszukać dostawcy zewnętrznego, który pomoże jej wdrożyć CRM, tym bardziej, że nie ma obecnie ekspertów, którzy znają się na technologii producenta systemu– „Niebieska chmurka”. Skoro nie ma przeciwskazań metodycznych to decyzja „kupić czy zbudować” jest bardziej decyzją odnoście strategii zakupowej niż kwestią zgodności z metodyką.

[1] Wymiennie stosuję pojęcia „projekt” i „produkt” ponieważ dla mnie budowa części produkty może być nazwana projektem, z określonym czasem na realizację oraz budżetem.

Wszystko zaczyna się od umowy

W następnym kroku, firma „Duże Korpo” chce przygotować specjalny kontrakt na umowę w modelu zwinnym. Według mnie jest to niezbędne, jeśli mówimy o agile. Niejednokrotnie widziałem próby „wdrażania” agile na projektach, w których brali udział dostawcy zewnętrzni, zakończone fiaskiem z oczywistego powodu - od dostawców oczekiwano, że będą bardziej elastyczni jeśli chodzi o reagowanie na zmiany zakresu i tempa prac, jednak Ci mieli przed oczami podpisane kontrakty oraz kary umowne i ich pole manewru było bardzo ograniczone. No chyba, że mówimy o CRach, czyli dodatkowo płatnych wnioskach o zmianę, wtedy każdy dostawca był chętny do takich modyfikacji. Widziałem również takich dostawców, których model biznesowy opierał się na CRach czyli sprzedawali podstawowe wdrożenie bardzo tanio, po cenach dumpingowych ponieważ i tak wiedzieli, że w pewnym momencie klient poprosi o zmianę zakresu, która to już zostanie wyceniona z „odpowiednim” narzutem.

Jedynie jak można „wdrożyć agile” przy umowach dokładnie określających zakres prac, to wprowadzając poranne pogaduchy („standup’y”) oraz cotygodniowe statusy, na których eskalujemy opóźnienia („planning”), ale wtedy nie ma co liczyć, że to podniesie efektywność prac. Według mnie, jeśli chcemy pracować w modelu zwinnym, musimy o tym pomyśleć już na etapie podpisywania kontraktów z dostawcami. Jak atrament zaschnie na umowach, to będzie za późno.

Różne typy kontraktów

Poniżej opisuję najpopularniejsze typy kontraktów:

Który z tych typów jest powinna wybrać firma „Duże Korpo”?
To zależy przede wszystkim od relacji z dostawcą. Jeśli jest to nowy vendor, z którym nie wiemy jak się pracuje, czy jest rzetelny i zna się na swojej pracy, to rekomendowałbym podejście Fixed Price, ale dla bardzo małego zakresu prac. Można się pokusić o wyznaczenie MVP na 2-3 miesiące i sprawdzenie dostawcy na takim małym wdrożeniu. Jeśli firma „Śrubokręty” to dostawca, z którym „Duże Korpo” już pracowało i jest zadowolone z tej współpracy, to proponowałbym podejście Time&Material. Partnerska relacja z dostawcą to, według mnie, kluczowy czynnik wyboru typu umowy. Jeśli już znajdziemy rzetelnego dostawcę i wypracujemy partnerską relację, to możemy osiągnąć wiele korzyści. Po pierwsze, pracę w modelu Time&Material dostawca może oferować po niższych stawkach ponieważ takie kontrakty są obarczone mniejszym ryzykiem. Ryzyko da się przeliczyć na pieniądze, więc jeśli dostawcy są zmuszani do pracy w Fixed Price wtedy chcą się zabezpieczyć na wypadek gdyby nie doszacowali pracochłonności. Najprostszy na to sposób to wliczenie pewnego buforu w proponowane stawki. Z mojego doświadczenia bufory na ryzyko związane z pracę na Fixed Price wynoszą około 20% - 30% w porównaniu ze stawkami Time&Material. Wynika to również z faktu, że fakturowanie odbiorcy co miesiąc korzystnie wpływa na płynność finansową dostawcy, co pozwala na zaoferowanie lepszych stawek.

Druga korzyść z podejścia Time&Material jest taka, że to jedyne podejście umożliwiające prowadzenie prac zgodnie z metodykami zwinnymi. Odbiorca otrzyma to, czego realnie potrzebuje, a nie to, co zostało opisane w kontrakcie na podstawie rozważań teoretycznych.
W związku z powyższym jeśli firma „Duże Korpo” chce wykonywać pracę w Scrum i ma z góry określony budżet, powinna wybrać typ umowy Capped Time&Material.

7 elementów umowy na pracę zwinną

Po wyborze typu umowy pozostaje ustalić jej treść. Najważniejsze jest, aby umowy była symetryczna, to znaczy tak samo zabezpieczała interesy dostawcy i odbiorcy. Przygotowanie jednostronnej umowy może przynieść korzyści w krótkim okresie ale nie pozwoli na zbudowanie relacji partnerskich.

Kluczowe elementy umowy do ustalenia to:

Nr 

Element umowy

Perspektywa odbiorcy

Perspektywa dostawcy

1

Ramy czasowe, np. zaangażowanie w okresie
1 marca – 30 lipca

Odbiorca gwarantuje sobie, że w tym okresie oddelegowane mu osoby do projektu – będą dostępne.

Dzięki określeniu tych dat, dostawca może lepiej zaplanować alokacje swoich ludzi.

2

Backlog prac, w formie Epik, z wymaganiami Must, Should i Could, przy czym Dostawca zobowiązuje się na dostarczenie wymagań z priorytetem Must. Must’y ważone pracochłonnością powinny stanowić maksymalnie 70% backlogu.

Odbiorca chce wiedzieć na grubych klockach co na pewno zostanie dostarczone w ramach projektu. Odbiorca chce pracować z Dostawcą, który na podstawie swojego doświadczenia jest w stanie zagwarantować efekt biznesowy.  

Dostawca chce wiedzieć na czym ma się skoncentrować, które obszary są najważniejsze, a które mogą zostać pominięte w sytuacji gdy będzie brakować czasu

3

Budżet dostarczenia prac określony w roboczodniach, obliczony per epika i rola np. 700 MD na Must’y, 200 na Could i 100 na Should

Odbiorca widzi jaka jest szacowana pracochłonność prac. Może na tej podstawie kontrolować zużycie budżetu oraz porównać te szacunki z szacunkami dotyczącymi dostarczenia tego samego zakresu prac ale pracownikami własnymi

Dostawca wie ile osób w poszczególnych rolach ma oddelegować do projektu

4

Podejście do rozszerzania zakresu określonego w Backlogu

Odbiorca chce mieć możliwość zmiany zakresu, w szczególności zmian epik o priorytetach Must na wypadek gdyby pierwotne wymagania okazały się nieopłacalne.

Dostawca chce zabezpieczyć się przed sytuacją, gdy do backlogu wpadają nowe Must’y a nie są wyjmowane inne. Poza tym warto ustalić czy wycena nowych Must’ów będzie wykonywana w ramach przyznanego pakietu dniówek czy będzie to traktowane jako dodatkowa praca.

5

Podejście do rozliczenia ewentualnego przekroczenia lub niewykorzystania budżetu.

W przypadku gdy Musty zostaną wdrożone przy przekroczeniu ustalonego budżetu np. 1000 MD to stosowane jest podejście, które zakłada, że nadwyżka obciąży zarówno Dostawcę jak i Odbiorcę. Czyli jeśli Must’y zostaną dostarczone w 1120 MD to za 60 MD zapłaci dodatkowo Odbiorca a 60 MD Dostawca wykona za darmo. Analogiczna sytuacja wystąpi gdy cały backlog zostanie dowieziony poniżej 1000 MD. Wtedy zaoszczędzone dniówki zostaną podzielone równo między Dostawcę i Odbiorcę.

6

Lista osób dedykowanych do projektu

Odbiorca chce mieć pewność, że będzie pracował z tymi samymi osobami przez cały projekt, ponieważ ich wiedza i wartość będzie rosła z każdym dniem.

Dostawca chce mieć pewność, że kompetencje konkretnych osób są zaakceptowane przez Odbiorcę.

7

Podejście do raportowania czasu pracy, postępów i fakturowania

Odbiorca chce mieć aktualną informację na temat zużycia budżetu

Odbiorca może lepiej zarządzać swoją płynnością gdy np. wystawia fakturę co miesiąc. Wtedy odbiory prac też są wykonywane co miesiąc.

W tej sytuacji „Duże Korpo” decyduje się na przygotowanie umowy z 7 elementami umowy zwinnej. W następnym kroku zaprasza firmę „Śrubokręty” na kilku dniowy warsztat na którym zostanie wypracowany backlog, wraz z priorytetyzacją i wstępną wyceną. Ważne jest dobre prowadzenie takich warsztatów, w którym zespół Agile Advisory z Deloitte Digital może pomóc.

Autor:

Maciej Malesa, Menedżer, Lider doradztwa Agile, Deloitte

Czytaj blog Agile
„Zwinne organizacje”

Nie przegap najnowszych wpisów

Czy ta strona była pomocna?