Umowy dla projektów IT w agile a role zespołu

Dobrze napisana umowa, precyzująca m.in. zakres praw i obowiązków oraz odpowiedzialność poszczególnych ról projektowych w ramach Zespołu Scrumowego z pewnością ułatwi ich efektywną współpracę, tym samym zwiększając szanse na sukces projektu. A jak to zrobić? Odpowiedzi na to pytanie chcielibyśmy poświęcić ten artykuł.

Trzecią część naszego cyklu rozpoczynamy cytatem z Kenta Becka, twórcy tzw. Programowania Ekstremalnego oraz współautora Manifestu Agile. W doskonały sposób podkreśla on znaczenie współpracy zespołu, jako czynnika decydującego o sukcesie bądź porażce projektu. Zanim przejdziemy do opisywania postanowień umownych odnoszących się do konkretnych ról Zespołu Scrumowego, przyjrzyjmy się podstawowym zasadom, na których opiera się ich współpraca.

Świadomość tych zasad jest warunkiem koniecznym dla prawidłowego opisania w umowie praw, obowiązków oraz zakresu odpowiedzialności. W wielu umowach „o dzieło”, z którymi się spotykamy nacisk jest położony na odbiór i efekt prac, a nie na procedury ich realizacji – w Agile trzeba zmienić takie myślenie. W tym zakresie umowa agile ma wiele cech umowy zlecenia, gdzie osobiste cechy świadczącego usługę są pierwszoplanowe.

To pierwsza z zasad. Zawarta już w samym Manifeście Agile. Nie ukrywajmy, na pierwszy rzut oka wydaje się być mało odkrywczą konstatacją, możliwą dla każdego w miarę logicznie myślącego osobnika, mającego jakiekolwiek doświadczenie w realizacji projektów, a już w szczególności projektów informatycznych. W praktyce jednak to iście Kopernikańska Rewolucja, wywracająca do góry nogami zastany porządek rzeczy, w którym dotychczas plemię „Biznes” żyło doskonale odseparowane od plemienia „IT” i całego developmentu informatycznego, a ich ewentualna komunikacja była dla nich wzajemnie równie zrozumiała, co język znaków dymnych plemienia Indian Lakota.

Ten tzw. syndrom plemion, opisany m.in. przez Carly Fiorinę w jej pamiętnikach z okresu, kiedy przewodziła koncernowi Hewlett-Packard (“Nie żałuję niczego”; wydawnictwo Difin) niestety zdecydowanie zbyt często widoczny jest w umowach pisanych na potrzeby projektów informatycznych realizowanych w tradycyjnym modelu kaskadowym. Ze świecą szukać w tego typu umowach postanowień odnoszących się do współpracy konkretnych ról projektowych, a spotykana czasami w nich klauzula odnoszącą się do tzw. Personelu Dedykowanego Dostawcy, nie stymuluje stron do wzajemnego współdziałania, ze względu na swój wybitnie jednostronny charakter.

Agile, jak i odpowiadający mu model kontraktowy zrywa z syndromem plemion, stawiając na bliską i intensywną współpracę stron projektu. Czy to jest proste? Nie, przeciwnie. Potwierdza to choćby opinia twórców metody Scrum – Kena Schwabera i Jeffa Sutherlanda – którzy otwarcie przyznają, że Scrum jest lekki, łatwy do zrozumienia, ale … trudny do opanowania („Scrum Guide”). Sęk w tym, że jest skuteczny, inaczej mówiąc działa, pozwalając istotnie, naprawdę istotnie zwiększyć szanse na powodzenie projektu. Czy rzeczywistość to potwierdza? Wystarczy przyjrzeć się wycenie rynkowej Apple, która w opinii ekspertów nawet nie tyle wytwarza produkty w modelu Agile, ale jest Agile sama w sobie.

Małe zespoły projektowe, przykładowo dwóch (!) inżynierów było odpowiedzialnych za przekonwertowanie kodu wyszukiwarki Safari na iPada. Złożyły się na to: genialny Product Owner – o nim więcej za chwilę, praca w krótkich cyklach iteracyjnych oraz legendarny już dla Apple model odpowiedzialności indywidualnych członków zespołu zawierający się w akronimie DIR (Directly Responsible Individual), to tylko niektóre z cech tej organizacji świadczące o rozumieniu i stosowaniu modelu Agile w codziennym cyklu biznesowym.

Oczywiście Apple nie jest jedyną ani tym bardziej pierwszą organizacją, która zrozumiała, że ścisła współpraca „Biznesu” z „IT” jest czynnikiem krytycznym dla powodzenia projektu. Już w latach 40. XX wieku, Richard Feynman, członek zespołu projektu Manhattan, odpowiedzialnego za stworzenie amerykańskiej bomby jądrowej oraz późniejszy laureat Nagrody Nobla w dziedzinie fizyki, zauważył, że odseparowanie poziomu strategicznego (Biznes) od poziomu taktyczno-operacyjnego (IT) w sposób istotny wpływa na efektywność prac realizowanych w ramach projektu. W rezultacie stosowania takiego modelu, zespół taktyczno-operacyjny wie tylko, „co” ma zrobić, natomiast nie wie, „dlaczego”. A to właśnie, jak podkreśla Feynman, wiedza na temat, „dlaczego” coś ma zostać zrobione jest zapalnikiem innowacyjnego podejścia do pracy operacyjnej, który – nomen-omen – pozwala na uwolnienie energii zespołu developerskiego, a tym samym osiągnięcie sukcesu całego projektu.

Jak to się ma do umowy? Umowa dla projektów realizowanych w metodzie Scrum musi w sposób możliwie precyzyjny, a zarazem przejrzysty określać role projektowe, zakres ich praw i obowiązków oraz odpowiedzialności za wybrane obszary projektu. Postanowienia te nie mogą sprowadzać się do nieostrych sformułowań typu „koordynator projektu odpowiedzialny jest za właściwą koordynację działań operacyjnych w ramach projektu, a działania te będzie podejmował ze starannością należytą, odpowiadającą najwyższym międzynarodowym standardom rynkowym”. Postanowienia te muszą precyzyjnie lokalizować zakres czynności poszczególnych ról Zespołu Scrumowego – Product Owner, Scrum Master, Zespół Developerski – wraz z odpowiadającą tym czynnościom decyzyjnością oraz odpowiedzialnością poszczególnych aktorów projektu scrumowego. To właśnie dzięki przejrzystej matrycy decyzyjności i odpowiedzialności poszczególnych ról projektowych, jesteśmy w stanie znacząco zwiększyć efektywność współpracy w ramach projektu, ograniczyć ryzyka związane z obszarem tzw. „ziemi niczyjej”, tym samym podwyższając szanse finalnego sukcesu przedsięwzięcia.

Ot, co, chciałoby się powiedzieć kolejna zdrowo rozsądkowa mądrość. Cały problem w tym, że jej stosowanie w praktyce w 9 na 10 przypadków napotyka na wysoki i gruby mur utkany z korporacyjno-waterfollowskich przyzwyczajeń, gdzie znakomita większość komunikacji przesyłana jest mailem. Zgodnie z badaniami ten sposób komunikacji jest uznawany za najgorszy sposób w ramach zespołu (Alex Sandy Petland; “The New Science of Building Great Teams”; Harvard Business Review 4/2012). I to najczęściej wtedy, kiedy osoba kierująca projektem ze strony zamawiającego ma na to czas, pomiędzy „n” innych rzeczy, jakie ma do zrobienia poza samym projektem.

Cóż innego z tej zasady wynika jak m.in. nie to, że „Biznes” musi być fizycznie obecny na spotkaniach z „IT”. Musi być dla inżynierów realnie dostępny, dyspozycyjny, responsywny, i co gorsza (!) Decyzyjny. I nie chodzi tu o cotygodniowe spotkania statusowe. Chodzi o dostępność codzienną (dzień po dniu), a jeśli już nie zawsze fizyczną (bądźmy realistami) to zdalną, pozwalającą w sposób szybki podejmować decyzje, co do kierunku projektu, produktu, jego pożądanych funkcjonalnościach, parametrach, etc. Tylko taki model działania zapewni odpowiednią dynamikę projektu, kluczową dla szans powodzenia przedsięwzięcia.

Co zatem wpisujemy do umowy? Nakładamy na poszczególnych aktorów projektu żelazne zobowiązania, co do fizycznej obecności na wybranych kategoriach spotkań Scrumowych, pełnej dyspozycyjności oraz responsywności gwarantujących utrzymanie właściwej dynamiki projektu. Odpierając zarzuty tradycjonalistów, szermujących hasłami, „że nasz Biznes na coś takiego na pewno się nie zgodzi, bo ma 100 innych rzeczy na głowie”, posłusznie acz stanowczo odpowiadamy – jeśli się nie zgodzi, to niech zapomni o zwinnym podejściu do realizacji projektów. Odsyłamy niniejszym już do wyżej przywołanej tezy twórców Scruma, Scrum jest trudny, czasami bardzo trudny do adaptacji. W pewnych obszarach wymaga on wręcz całkowitego zredefiniowania dotychczasowego podejścia do realizacji projektów. Zatem albo umawiamy się na zwinny projekt i piszemy na jego potrzeby odpowiednią umowę, albo pozostajemy przy tradycyjnej metodzie projektowej, akceptując wszelkie wynikające z takiego rozwiązania konsekwencje.

A jak już jesteśmy przy odpieraniu zarzutów, to warto przy tej okazji rozprawić się z mitem braku dyscypliny w projektach zwinnych. Mitem, który rozpływa się nad modelem Agile, powodując powszechne wrażenie, jakoby w modelach zwinnych wszystko jest nieznane, a my po prostu tworzymy – w atmosferze wzajemnej miłości, wolności i zaufania – licząc, że na końcu coś z tego pewnie nam wyjdzie, a jak nie wyjdzie to… trudno. Nic bardziej mylnego.

Agile – w tym metoda Scrum – to jedna z najbardziej ekstremalnie zdyscyplinowanych metod realizacji projektów, gdzie każdy z członków zespołu projektowego ma precyzyjnie określony zakres działań i odpowiedzialności, a wszelkie tzw. zdarzenia – Sprinty, Retrospekcje, Planowania, Dzienny Scrum – są w umowie na sztywno czasowo ograniczone (time-bose), a od tej zasady nie ma żadnych wyjątków. Choć nie da się ukryć, że zaszyta w modelach Agile elastyczność zmiany przedmiotu umowy jest prawnie najtrudniejsza do opisania i kontroli podczas realizacji. Poniżej przedstawiamy role poszczególnych osób w projekcie agile.

Product Owner to jedna z trzech zasadniczych ról w ramach Zespołu Scrumowego. W praktyce to głos zamawiającego lub w istocie sam zamawiający. To on decyduje czy i na jakim etapie produkt zostanie wydany, podejmuje decyzje, co do kontynuacji samego projektu, ma ostateczny głos w kwestii priorytetyzacji poszczególnych elementów zawartych w Rejestrze Wymagań i – last, but not least – jest odpowiedzialny za komunikację na linii Business – IT. Podsumowując Product Owner to rola zamawiającego, którą cechują dwa zasadnicze parametry: decyzyjność i dyspozycyjność.

Zacznijmy od decyzyjności. Umowa powinna zawierać wyraźne umocowanie (pełnomocnictwo) udzielane Product Ownerowi przez zamawiającego do podejmowania decyzji potrzebnych dla efektywnej realizacji projektu. Pisząc umowę zwracać należy szczególną uwagę na zakres pełnomocnictwa udzielanego Product Ownerowi. Niewystarczający lub zdawkowo opisany zakres upoważnienia Product Ownera, uniemożliwiający mu podejmowanie szybkich decyzji w ramach projektu może w łatwy sposób sparaliżować cały projekt i wymusić konieczność każdorazowego zatwierdzania przez zwierzchników Product Ownera podejmowanych przez niego decyzji. To zaś w oczywisty sposób rozbija dynamikę projektu i znacząco utrudnia jego sukces. Zatem na samym początku – prawidłowo, tzn. odpowiednio szeroko – umocujmy w umowie Product Ownera do wykonywania swojej roli.

Dyspozycyjność to już dużo trudniejsza historia z przyczyn przywołanych już powyżej w artykule. Umowa powinna zawierać wyraźne zobowiązanie fizycznej obecności Product Ownera na wybranych kategoriach zdarzeń scrumowych. O jakich zdarzeniach tu mowa? Co najmniej o Planowaniu Sprintu i Przeglądzie Sprintu. Co do reszty zdarzeń pozostawiamy to już do indywidualnej decyzji stron. Jednocześnie nie ukrywając, że im obecność Product Ownera będzie częstsza na spotkaniach z Zespołem Deweloperskim tym lepiej dla powodzenia projektu. Celowym jest również zakreślenie w umowie przestrzeni czasowej, na czas której zamawiający zagwarantuje pełną dyspozycyjność Product Ownera dla projektu, o który się umawiamy.

Dodatkowo zamawiający powinien oświadczyć, że zapewnia priorytet działaniom podejmowanym przez Product Ownera na potrzeby projektu, względem pozostałych, poza projektowych aktywności, do jakich osoba pełniąca rolę Product Ownera jest zobowiązana wobec zamawiającego. Warto również pamiętać o obowiązku należytej responsywności Product Ownera. To cecha kluczowa, szczególnie biorąc pod uwagę dynamikę oraz dyscyplinę czasową, jaka towarzyszy zwinnie realizowanym projektom. W wersji „soft” te postanowienia sprowadzą się do obowiązku responsywności tak szybko, jak to tylko możliwe, w wersji hard zostaną sparametryzowane, poprzez określenie przedziału czasowego, w jakim Product Owner zobowiązany jest do reakcji.

Z punktu widzenia wykonawcy warto wprowadzić do umowy klauzulę gwarantującą odpowiednie kompetencje i doświadczenie Product Ownera, referującą najczęściej do załącznika będącego portfolio projektów zwinnych, jakie nasz Product Owner już zrealizował. Jeśli zatem uzyskamy już pewność, że Product Owner jest wystarczająco kompetentny i doświadczony dla potrzeb naszego projektu, wprowadźmy do umowy postanowienia uniemożliwiające łatwą zmianę Product Ownera, ograniczające taką możliwość tylko do okoliczności od zamawiającego obiektywnie niezależnych jak choroba, śmierć czy złożenie wypowiedzenia.

Poza powyższymi postanowieniami umowa powinna zawierać przejrzysty katalog czynności zarezerwowanych dla niezależnej decyzji Product Ownera. Taki krok pozwoli w dużym stopniu ograniczyć ryzyko niepotrzebnego sporu, co do obszaru tzw. ziemi niczyjej. O jakich tu mowa czynnościach? Jak na prawników przystało odpowiemy – zależy. Między innymi od tego jak szerokie pełnomocnictwa Product Owner posiada. Warto jednak pamiętać o pewnym minimalnym standardzie, poniżej którego pozycja Product Ownera nie powinna być ograniczana, a który sprowadza się m.in. do działań związanych z zarządzaniem Rejestrem Wymagań, jego priorytetyzacją, aktualizacją, jak również decyzjami w przedmiocie kontynuacji projektu.

Nie ma się, co oszukiwać, te postanowienia nie będą wybitnie łatwe do wynegocjowania. W szczególności w polskich realiach rynkowych de facto często dopiero rozpoczynających swoją przygodę z modelem Agile. To oczywiste, że wszystko dzieje się łatwiej, kiedy Product Owner jest postacią formatu Steve’a Jobs’a, Jeff’a Bezos’a czy Elon’a Musk’a osadzonych na najwyższym piętrze firmowej drabiny, w pełni decyzyjnych i w dosłownie obsesyjny sposób oddanych projektowi, gotowi poświęcić każdą minutę na pracę z zespołem deweloperskim, aby możliwie szybko dojść do upragnionego celu. Nie mniej właściwe nastawienie do współdziałania, odpowiednie kompetencje ról projektowych i dobrze napisana umowa są w stanie każdego z nas w sposób istotny przybliżyć do pomyślnej realizacji zwinnego projektu. W osobnym wątku poruszymy zagadnienie konsekwencji, kiedy Product Owner nie współdziała. Niestety mogą one być bardzo bolesne dla zamawiającego i ich opis jest kluczowy dla umowy.

Scrum Master to kolejna z ról projektowych Zespołu Scrumowego. W zespole scrumowym rolę Scrum Mastera chyba najlepiej oddaje określenie coach lub mentor. Scrum Master prowadzi permanentny coaching Zespołu Deweloperskiego, dbając jednocześnie o jego dobrą atmosferę i o to, aby cały proces projektowy prowadzony był zgodnie z zasadami modelu Scrum, dodatkowo motywując i stymulując Zespół Deweloperski do lepszej, efektywnej i bardziej wydajnej pracy.

Nie powtarzając się niepotrzebnie, chcemy tylko zasygnalizować, że umowne postanowienia, jakie komentowaliśmy powyżej w odniesieniu do roli Product Ownera, znajdują w pewnym zakresie swoje odpowiednie zastosowanie do funkcji Scrum Mastera. Mamy tu na myśli w szczególności wymóg fizycznej obecności na określonych kategoriach zdarzeń scrumowych, responsywności, czy dyspozycyjności dla pozostałych członków Zespołu Scrumowego. To samo dotyczy klauzul umownych regulujących zakaz zmiany Scrum Mastera bez ważnych powodów oraz oświadczeń, w których strona projektu zapewniająca Scrum Mastera gwarantuje jego należyte kompetencje i doświadczenie, potwierdzone odpowiednio grubym portfolio zrealizowanych już zwinnych przedsięwzięć.

Z punktu widzenia zamawiającego chcemy zwrócić szczególną uwagę na ten ostatni aspekt, a mianowicie wpisanie do umowy wyraźnego uprawnienia zamawiającego umożliwiającego mu weryfikację deklarowanych kompetencji i doświadczenia Scrum Mastera. Innym modelem pozwalającym ograniczyć ryzyko związane z nietrafionym Scrum Masterem jest wpisanie w umowie krótkiej procedury pozwalającej na dokonanie przez strony wspólnego wyboru kandydata na pozycję Scrum Mastera. Strony, w oparciu o ustalone kryteria, będące z punktu widzenia charakteru projektu cechami szczególnie pożądanymi, razem dokonują wyboru kandydata do roli Scrum Mastera. Pamiętajmy, że Scrum Master to rola mająca m.in. czuwać nad tym, że projekt jest realizowany zgodnie z właściwymi zasadami metody Scrum. To rola szczególnie odpowiedzialna, zwłaszcza wtedy, kiedy tak zamawiający, jak i dostawca nie posiadają jeszcze doświadczenia pozwalającego w porę zauważyć i zapobiec takiej sytuacji. Proponowane powyżej mechanizmy umowy umożliwiające uprzednią weryfikację kompetencji i doświadczeń Scrum Mastera lub pozwalające na jego świadomy i przemyślany wybór w dużej mierze pozwalają ograniczyć ryzyko związane z nietrafionym wyborem kandydata do tej roli.

Na zakończenie tej części warto podkreślić, że zdarzają się projekty, a w konsekwencji pisane na ich potrzeby kontrakty, które w ogóle nie przewidują roli Scrum Mastera. Nie mniej winni jesteśmy wyjaśnienie, że takie projekty realizowane są najczęściej przez organizacje posiadające już duże doświadczenie w modelach zwinnych.

W ten sposób Steve Jobs – z właściwym sobie urokiem – podkreślił znaczenie, jakie dla powodzenia projektu mają kompetencje biorących w nim udział programistów. Nie sposób się z tym nie zgodzić! Właśnie, dlatego, w Scrumie to zespół deweloperski odgrywa jedną z kluczowych ról projektowych, która powinna znaleźć potwierdzenie w postanowieniach umowy.

Z perspektywy zamawiającego u mowie należy zawrzeć postanowienia gwarantujące odpowiednio wysokie kompetencje i doświadczenie poszczególnych członków zespołu deweloperskiego. Zespół Developerski powinien spełniać dwa kluczowe parametry: interdyscyplinarność, samowystarczalność – tj. zespół posiada kompletny zestaw kompetencji pozwalający na realizację projektu, bez konieczności korzystania z zasobów zewnętrznych oraz międzyfunkcjonalność – członkowie zespołu developerskiego posiadają kompetencje pozwalające im się wzajemnie zastępować. Kontrola nad zespołem pojawia się prawie w każdej umowie, ale klauzule w umowach agile są o wiele bardziej rozbudowane. Np. jedna z nich może wymagać od dostawcy zespołu, który razem pracuje od dłuższego czasu – weryfikacja CV konsultantów jest o wiele bardziej staranna, niż w większości typowych umów o dzieło.

Dodatkowo umowa powinna nakładać ograniczenia, co do liczebności zespołu deweloperskiego oraz jego lokalizacji. W przypadku tej ostatniej, umowa powinna jasno określać miejsce, w którym członkowie zespołu deweloperskiego będą wykonywali prace na potrzeby projektu. Przez miejsce należy rozumieć jedną, fizycznie istniejąca lokalizację gwarantującą wszystkim członkom zespołu optymalne warunki realizacji pracy projektowej, w tym komunikacji z pozostałymi rolami scrumowymi. Jeśli ma ją zapewnić zamawiający, to także dokładnie to opiszmy, także z parametrami zapewnianej łączności.

Podobnie, jak miało to już miejsce w przypadku Product Ownera i Scrum Mastera umowa powinna przewidywać określone mechanizmy uniemożliwiające wykonawcy dowolną zmianę członków zespołu deweloperskiego. Zmiany te powinny zachodzić wyłącznie w wyjątkowych okolicznościach. Tutaj może się sprawdzić autorski mechanizm kar umownych.

Kolejny ważny element, to zapewnienie w umowie pełnej niezależności zespołu scrumowego w czasie realizacji prac projektowych podczas Sprintu. Nikt, nawet Scrum Master nie ma prawa mówić Zespołowi Developerskiemu, co należy zrobić w celu osiągnięcia zakładanego celu Sprintu. Zespół Developerski jest w tym zakresie całkowicie niezależny i tylko on ponosi z tego tytułu odpowiedzialność.

Na zakończenie warto dodać, że w zaawansowanych projektach zwinnych zdarza się, że zespół developerski złożony jest tak z personelu zamawiającego jak i wykonawcy. To oczywiście świat idealny Scruma, pozwalający najpełniej wykorzystać jego potencjał. Z prawnego punktu widzenia – w przypadku sporu – może jednak wystąpić trudność, co do właściwego ustalenia odpowiedzialności tj. ustalenia konkretnie, kto i za co jest odpowiedzialny. Dlatego też, o ile strony nie posiadają sporego doświadczenia w realizacji projektów zwinnych, nie rekomendujemy takiego rozwiązania.

Podsumowując, w niniejszym artykule staraliśmy się zwrócić uwagę na szczególnie istotny obszar projektów zwinnych dotyczący występujących w nich ról projektowych. Przedstawione przez nas rozwiązania mają charakter modelowy i mogą być poddawane odpowiednim modyfikacjom w zależności od potrzeb konkretnego projektu. Nie mniej to, na czym zależało nam szczególnie to zwrócenie uwagi na precyzyjne i przejrzyste ujęcie w umowie praw, obowiązków oraz odpowiedzialności poszczególnych ról projektowych charakterystycznych dla modeli zwinnych.

Jak ująć w umowie poszczególne zdarzenia takich modeli? Postaramy się opowiedzieć już w następnym artykule.

Autorami tekstu są: Marcin Maruta – specjalista w zakresie projektów IT. Doradzał największym krajowym i międzynarodowym dostawcom usług IT oraz odbiorcom tych usług. Koordynuje obsługę prawną międzynarodowych sporów sądowych i arbitrażowych oraz Łukasz Węgrzyn – prawnik w Kancelarii Radców Prawnych Maruta i Wspólnicy. Specjalista z zakresu prawa nowych technologii, własności intelektualnej i mediów. Wcześniej pracował między innymi, jako prawnik wewnętrzny dla Agora, MTV Networks oraz członek zespołu TMT kancelarii prawnej „Bird & Bird”.