Krótka historia zwinnej umowy. Lektura do kawy, wzór do pobrania.

Piękny poranek, XI piętro w Warszawskim Centrum Finansowym przy ul. Emilii Plater. Wchodzę do biura, kiedy odzywa się mój telefon.
– Panie Krzysztofie – zwraca się do mnie szef IT naprawdę dużej firmy – mamy pozytywną decyzję, chcemy wdrożyć Wasze rozwiązanie. Potrzebujemy odpowiedniej umowy. Chodzi o umowę agile’ową.

– Mamy sprawdzoną umowę. Za chwilę ją wyślę. Jeżeli pan pozwoli, chciałbym spotkać się i omówić jej zapisy – odpowiedziałem.

Poznaliśmy się kilka miesięcy wcześniej. Zaintrygowała mnie jego wypowiedź w jednym z magazynów IT dotycząca Agile. Napisałem maila. Spotkaliśmy się. Okazało się, że firma szuka możliwości usprawnienia procesów związanych z przepływem dokumentów oraz ich archiwizacją. Podjęto decyzję o wyborze rozwiązania z rynku. Po blisko 3 miesiącach zbierania wymagań, krótkiego testu, kilku wizytach, zostaliśmy wybrani. Jak się później dowiedziałem, jednym z istotnych argumentów przemawiających za nami był właśnie Agile.

Przesyłając nasz wzór umowy wdrożeniowej, obawiałem się reakcji. Wprawdzie obie strony pracowały zgodnie z postulatami Agile, ale oto nastąpił moment, w którym istotę działania trzeba było przelać na papier i – co trudniejsze – skonfrontować z korporacyjnymi standardami. Pewny byłem tylko partnerskiego podejścia, wzajemnego zaufania i… doskonałej kawy.

Na spotkaniu partner, jak zawsze, zwrócił się do mnie bardzo konkretnie:
– W Preambule powinniśmy zawrzeć cel, jaki chcemy osiągnąć oraz wizję produktu, który powstanie w wyniku wdrożenia.
– Zgadzam się – odpowiedziałem – poza punktami, w których określamy sprawy formalne, gotowość do wykonania usług oraz intencje realizacji dodatkowych usług w przyszłości powinniśmy zawrzeć te dwa zapisy, o których pan mówi. Sugeruję jednak, aby wizja produktu, który powstanie przy okazji wdrożenia została opisana w załączniku do umowy.

1. Zadbaj o włączenie do umowy opisu głównego celu wdrożenia oraz wizji produktu, który ma powstać w jego efekcie.

– Widzę, że w umowie rozbudował pan szeroko definicje. Czy to na pewno potrzebne?
– Zarówno państwo, jak i my mamy kilkuletnie doświadczenie w prowadzeniu i realizacji projektów Agile. Zagadnienia oraz typowe dla Agile zwroty są dla nas zrozumiałe. Obawiam się jednak, że nie dla wszystkich. Jestem zdania, że te stosunkowo „młode” definicje oraz ich znaczenie warto krótko opisać. Unikniemy nieporozumień, a umowa będzie stanowiła prawdziwą pomoc przy realizacji wdrożenia.

2. Opisz krótko terminologię Agile, aby uniknąć nieporozumień na poziomie definicji. Zadbaj, by założenia umowy były zrozumiałe także dla osób niezaangażowanych w proces wdrożenia.

– Brakuje definicji Product Ownera i Scrum Mastera. Dlaczego nie zawarł ich pan w umowie?
– Trudno sobie wyobrazić, aby prezes czy członek zarządu uczestniczył we wdrożeniu i za każdym razem akceptował zmiany, które są przecież istotą takiego projektu. Wystarczające jest odpowiednie umocowanie decyzyjne personelu dostawcy i odbiorcy. W dalszej części umowy znajdują się zapisy dotyczące powołania i uprawnień Komitetu Sterującego. W takim przypadku nie musimy więc definiować i opisywać tych funkcji.

3. Wpisz członków zespołu ze strony Dostawcy i Odbiorcy do załącznika umowy.

Powołaj Komitet Sterujący. Dla najważniejszych ról czyli Project Managera, Product Ownera i Scrum Mastera zdefiniuj: zakres odpowiedzialności i uprawnień, kompetencje, doświadczenie, dyspozycyjność, możliwe okoliczności i procedurę zmiany.
– Ostatnią sprawą w definicjach jest harmonogram. Jestem zaskoczony, że wprowadził go pan do umowy. Przecież umowa miała być agile’owa?!
– Spodziewałem się takiej reakcji. Słowo „harmonogram” może kojarzyć się z umowami „starego” typu, tutaj ma ono jednak inne znaczenie. Po pierwsze – rozumiemy państwa cel. Określiliśmy również wizję produktu, który powstanie w efekcie wdrożenia. Po drugie wypracowaliśmy wspólnie inicjalny Zakres Prac (Back Log) i określiliśmy do tych zadań (User Stories) ich stopień trudności (Story Points). Z doświadczenia wiemy ile Story Pointów w Sprincie może zrealizować nasz zespół. Dzięki temu z dużym prawdopodobieństwem określamy przewidywany czas realizacji zadań z Back Logu. Oznacza to , że jesteśmy w stanie wpisać do umowy przewidywany harmonogram realizacji inicjalnego Back Logu. Informacja ta pozwoli obu stronom przygotować się na rozruch projektu i jego początkową fazę. Dodatkowe zapisy „przypilnują nas”, aby w żadnym przypadku nie stracić we wdrożeniu ducha Agile, zagwarantować elastyczność we wprowadzaniu zmian i priorytetyzacji zadań.

4. Harmonogram wdrożenia zawarty w umowie Agile nie przeczy fundamentalnym założeniom metodyki. Zdefiniowanie Zakresu Prac (Back Log), zadań (User Stories), ich stopnia trudności (Story Points) pozwala określić czas realizacji zadań oraz nadać wdrożeniu ramy, które jednak w żaden sposób nie blokują zwinnego zarządzania zmianami.

– Przejdźmy wobec tego do Przedmiotu Umowy. Jaka to umowa?
– Umowa, którą ma pan w ręku ma charakter umowy zlecenia. Jej przedmiotem jest świadczenie usług związanych z wdrożeniem naszego rozwiązania.
– A jednak w wyniku wdrożenia powstanie również produkt. Czy w związku z tym umowa nie powinna mieć charakteru umowy o dzieło?
– Aby osiągnąć państwa cel, 90% prac będzie miało charakter usług. Na produkt, który powstanie w wyniku realizacji części zapisów tej umowy udzielimy państwu licencji oraz wsparcia. Odbędzie się to na podstawie protokołu przekazania produktu ora Umowy Licencyjnej – rozszerzającej licencję o powstały produkt. Podpiszemy także Umowę Konserwacyjną – gwarantującą świadczenie wsparcia dla tego produktu.

5. Aby nie stracić z oczu głównego celu wdrożenia (w omawianym przypadku to: usprawnienie przepływu dokumentów i ich archiwizacja), warto uporządkować wzajemne zobowiązania stron, przygotowując osobną umowę licencyjną oraz świadczenie wsparcia dla produktu – Umowa Konserwacyjna.

– Widzę, że wypił pan kawę (2). Zamówić następną?
– Tak, jest doskonała.
– Wróćmy do umowy. Chcemy, aby projekt zakończył się sukcesem, ale jego realizacja może zająć kilka miesięcy. W tym czasie warunki i otoczenie biznesowe mogą się zmienić. Być może staniemy przed koniecznością przerwania projektu. Chcielibyśmy zawrzeć w umowie opis „procedury wyjścia” z umowy. Nie widzę takich zapisów w przedstawionej przez pana propozycji.
– Nie spotkałem się wcześniej z takimi wymaganiami. Proponuję jednak, aby opis „procedury wyjścia” z umowy zawrzeć w paragrafie 10 (okres obowiązywania i wypowiedzenia umowy), a jej szczegóły wprowadzić do załącznika.

6. Realizując projekty trwające kilka miesięcy, uwzględnij ryzyko przerwania współpracy , np. ze względu na zmieniające się warunki rynkowe. Zawrzyj w umowie zapisy określające „procedurę wyjścia” z wzajemnych zobowiązań.

– Zostały do omówienia dwie sprawy: rozliczenia i obowiązywanie umowy. Czytałem pana artykuł Jak skonstruować umowę Agile?, w którym poruszył pan te kwestie. Muszę powiedzieć, że nie zgadzam się z pana argumentami!
– Nie wiem co powiedzieć. Zapisy, o których pan mówi sprawdzają się bardzo dobrze…
– Panie Krzysztofie, żartowałem. O, jest nasza kawa!

Umowa została podpisana. W oparciu o jej zapisy został zrealizowany projekt wdrożenia systemu zarządzania dokumentami. W trakcie wdrożenia powstało również kilka produktów (modułów) oraz wykonane zostały integracje z innymi systemami. Projekt trwał niecały rok. Budżet wyniósł blisko 200 000 zł. Duża część zapisów umowy wdrożeniowej została później przeniesiona do umowy o współpracy i funkcjonuje do dzisiaj.

DO POBRANIA: Umowa wdrożeniowa Agile.
Wyrażamy zgodę na jej pobranie, kopiowanie, modyfikację oraz wykorzystanie. Zamieszczony wzór umowy wdrożeniową wypracowaliśmy na przestrzeni ostatnich kilku lat. W tym czasie w myśl jej zapisów zrealizowaliśmy kilkanaście dużych i dziesiątki mniejszych projektów. Z każdym kolejnym projektem jesteśmy bogatsi w nowe doświadczenia i wprowadzamy w niej modyfikacje.

Krzysztof Wiśniewski CEO

STRESZCZENIE:
W przypadku wdrożenia agile’owego, zanim strony zgodzą się na zapisy umowy musi zostać spełnionych kilka warunków. Jest to przede wszystkim pełna akceptacja zasad Agile i postępowanie według nich. Nie bez znaczenia są również: partnerstwo, zaufanie, doświadczenie i kompetencje obu stron. Spełnienie tych warunków jest tym ważniejsze, im mniej znają się partnerzy.

Uwagi: (1) w przypadku zespołów współdzielonych między Dostawcą i Odbiorcą, sugeruję wprowadzenie definicji Product Ownera i Scrum Mastera oraz umocowania tego pierwszego w umowie. (2) niezamierzony product placement:)

Niniejsze opracowanie przygotowaliśmy z najwyższą starannością, jednak niektóre informacje zostały podane w formie skróconej. W związku z tym artykuły zawarte w #contmanway mają charakter poglądowy, a zawarte w nich informacje nie powinny zastąpić szczegółowej analizy zagadnienia. Wobec powyższego CONTMAN nie ponosi odpowiedzialności za jakiekolwiek straty powstałe w wyniku czynności podjętych lub zaniechanych na podstawie niniejszej publikacji. Jeżeli są Państwo zainteresowani dokładniejszym omówieniem niektórych kwestii poruszonych w #contmanway, zachęcamy do kontaktu i nawiązania współpracy.

Informacje powiązane:
Jak skonstruować umowę Agile?
Wzór Umowy wdrożeniowej Agile (.docx)