UMOWA AGILE W IT?

4 GŁÓWNE ZAŁOŻENIA

Umowa agile jest odpowiedzią na innowacyjne podejście do projektu.

Innowacje, w tym prawnicze, są siłą napędową rozwoju. Jednak bez zrozumienia, dlaczego ich potrzebujemy, nie będziemy się rozwijać.

Jeśli zaś jedyną stałą jest zmiana, to dlaczego nie mielibyśmy być tymi, którzy ją wprowadzają?

Kontuuję wątek UMOWA AGILE rozpoczęty poprzednim postem.

————————————————————————————————————————————————————————–


Z cyklu NOWOCZESNE KONTRAKTY posted by Renata W.Lewicka

PIASEK MIĘDZY SZPRYCHY, CZYLI JAK TO SIĘ ZACZĘŁO?

Kilkanaście lat temu, w górach Utah zebrała się grupa specjalistów w zakresie różnych metodologii zarządzania projektami IT. Efektem tego spotkania był Manifest Zwinnego Wytwarzania Oprogramowania (Agile Manifesto, Manifesto for Agile Software Development) czyli deklaracja wspólnych zasad dla zwinnych metodyk tworzenia oprogramowania będących alternatywą dla tradycyjnego podejścia opartego na modelu kaskadowym. Do wspomnianych metodyk należą: Scrum, Dynamic Systems Development Method, Adaptive Software Development, Crystal Clear, Feature Driven Development, Pragmatic Programming.

Poniżej treść Manifestu:

Wytwarzając oprogramowanie i pomagając innym w tym zakresie, odkrywa się lepsze sposoby wykonywania tej pracy. W wyniku tych doświadczeń przedkłada się:

LUDZI I INTERAKCJE ponad

Procesy i narzędzia

DZIAŁAJĄCE OPROGRAMOWANIE ponad

Obszerną dokumentację

WSPÓŁPRACA Z KLIENTEM ponad

Negocjacje umów

REAGOWANIE NA ZMIANY ponad

Realizacja założonego planu

Według Manifestu Agile docenia się to, co wymieniono po prawej stronie, jednak bardziej ceni się to, co po lewej.

Uzupełnieniem tez Manifestu jest dwanaście pryncypiów, które należy brać pod uwagę przy wytwarzaniu oprogramowania.

Wśród nich można wymienić min.:

  • satysfakcja klienta może zostać najlepiej osiągnięta poprzez dostarczenie działającego oprogramowania,
  • oprogramowanie powinno być dostarczane w regularnych, niezbyt długich odstępach czasu,
  • należy być otwartym na zmiany wymagań nawet jeśli pojawiają się późno w procesie tworzenia oprogramowania,
  • oczekuje się ścisłej współpracy pomiędzy deweloperami, a biznesem.

Co ciekawsze Agile jest stosowane nie tylko wśród firm zajmujących się tworzeniem oprogramowania, choć korzenie ma wybitnie inżynierskie. Badania wskazują że 48% kierowników projektów używa metod Agile w projektach nie powiązanych z nowymi technologiami. Wróćmy jednak do Agile w obszarze software development.

ZAWRACANIE KIJEM WISŁY? UMOWA AGILE

Dla tradycjonalistów, przyzwyczajonych do realizacji projektów metodą waterfallową, tezy Manifestu Agile są bardzo radykalne.

Bez masowych szkoleń, sesji coachingowych, bombardowania zasadami ani rusz.

Stawianie współpracy z klientem ponad negocjacje umów? Ludzi i interakcji ponad procesy i narzędzia?

Dla biznesu może być trudne. Dla prawnika, który oglądał proces wdrożenia systemu informatycznego z perspektywy ławki na sali rozpraw, z kilkunastoma segregatorami akt przed sobą, a nie tylko perspektywy stołu negocjacyjnego, bardzo trudne do zaakceptowania. A co dopiero do wprowadzenia w życie.

Uczestnicząc tak w negocjacjach umów, jak i procesach sądowych dotyczących wdrożeń systemów informatycznych zdaję sobie sprawę z realiów postępowania dowodowego. Doskonale też rozumiem myślenie kategoriami tego procesu już na etapie negocjacji. Jesteśmy więźniami nie tylko własnych nawyków, ale i doświadczeń. Łatwiej zmienić umowę niż sposób myślenia. Jak sprawić aby bagaż doświadczeń przestał być tylko ciężarem, a stał się źródłem nowych inspiracji i nie zamykał nas na nowe rozwiązania?

Pytanie niebagatelne, a odpowiedź wcale nie taka oczywista.

BĄDŹ PONAD PROSTE PYTANIE –

CZEGO CHCE KLIENT ?

Zacznijmy od pierwszej tezy Manifestu Agile.

Ludzie i interakcje ponad procesy i narzędzia.

Nie wymyślono jak do tej pory lepszej (cywilizowanej) metody komunikacji niż bezpośrednia rozmowa. Rozmowa też jest najlepszym narzędziem wymiany informacji o tym co się w projekcie naprawdę dzieje.

Wymiana informacji pozwala na dzielenie się wiedzą i nie dublowanie pracy.

Tylko który prawnik obsługujący klientów z branży IT uwierzy w bezpośrednie rozmowy w projekcie, szczególnie w przekroju pionowym?

W środowisku IT w kategorii komunikacja najwyżej w rankingach plasuje się mail i ciężko się z tego schematu wyłamać. To pierwszy bloker. Kolejny to typowe prawnicze myślenie traktujące czynnik ludzki jako najsłabsze ogniwo projektu, bo najmniej przewidywalne. Składy zespołów roboczych zmieniają się, w większej grupie zawsze pojawiają się jakieś konflikty czy rywalizacja. Zmieniają się też osoby ze szczebla decyzyjnego i zarządczego, a po zmianach nikt już nie pamięta nic z przyjętych entuzjastycznie i w uściskach ustaleń. Biznes nie ma czasu dla IT na rozmowy, IT zamiast rozmawiać wysyła maile itd. Itp. zatem procesy i narzędzia mogą zyskiwać na atrakcyjności i być bardziej przewidywalne.

Wreszcie nawyki samego prawnika, który często najpierw działa, a dopiero potem zadaje pytania.

Przełamanie tych schematów kooperacji w ramach zespołu projektowego wymaga zatem nie tylko przemodelowania sposobu myślenia prawnika, biznesu i IT zaangażowanych w całe przedsięwzięcie, ale także radykalnej zmiany zachowania wszystkich uczestniczących w procesie.

Zgodnie bowiem z założeniami Agile, biznes i IT muszą ze sobą współpracować ściślej i częściej w trakcie trwania projektu.

Zwinny prawnik potrafi jednak zaadresować te problemy projektując w umowie tak role projektowe (tak sponsora, deweloperów jak i użytkownika) jak i zadania wszystkich graczy oraz rodzaj i zakres ich odpowiedzialności, aby zarządzić tymi tematami i umożliwić efektywną wymianę informacji w trakcie wdrożenia.

SKUP SIĘ, ODKRYJ I ROZKOSZUJ SIĘ EFEKTEM

Działające oprogramowanie ponad obszerną dokumentację to kolejny postulat.

Myślę, że prawnik przyjmie powyższe do wiadomości entuzjastycznie i bez zbędnej zwłoki. Do dokumentacji oprogramowania zaglądamy rzadko albo wcale, tak jak do załączników technicznych umowy (to akurat moim zdaniem błąd, bo zdarzyło mi się tam widywać już wiele ciekawych z prawniczego punktu widzenia zapisów).

Odejście od pomysłu tworzenia setek tomów dokumentacji, z których prawie nikt nie korzysta, prawdopodobnie zostanie entuzjastycznie przyjęte tak przez biznes jak i IT. Wygląda zatem na najmniej problematyczny postulat, który stosunkowo łatwo będzie wdrożyć.

Na fali uniesienia należy tylko pamiętać, o tym że postulat ten nie oznacza odrzucenia dokumentacji w ogóle, ale skoncentrowanie się na oprogramowaniu którego ona dotyczy.

UMOWA AGILE MA WSPIERAĆ PROJEKT, A NIE ODWROTNIE

Współpraca z klientem ponad Negocjacje umów

to prawdopodobnie będzie największe wyzwanie dla większości prawników.

Prawnik przeczyta ten postulat, zrobi notatki i pomyśli: „Współpraca, współpracą. Ale ja jestem tutaj od zabezpieczenia interesów mojego klienta, na wypadek gdy coś pójdzie nie tak.”

Bo przecież obowiązkiem prawnika jest zarządzanie problemami, które pojawią się gdy współpraca stron pogorszy się i dojdzie do utraty zaufania po jednej lub obu stronach.

Zgoda.

Jednakże prawnik nie powinien rozumieć tego postulatu w ten sposób, że kontrakt ma zostać zastąpiony współpracą stron w czystej postaci, ale że owa współpraca ma znaczenie dominujące w procesie i powinna znaleźć odzwierciedlenie w języku umowy i strukturze samej umowy. A nade wszystko w zachowaniu osób w nim uczestniczących, w tym prawników. I dotyczy to zarówno samych negocjacji kontraktu jak i tańca poprzedzającego zawarcie umowy (ofertowania i RFP).

Istotne jest również aby nie tracić z oczu funkcji umowy, bo prawdziwym testem dla umowy jest etap wykonawczy projektu, w którym zespoły robocze zaczynają ze sobą pracować, a to co opisane w umowie ma tej współpracy służyć i pomagać.

Umowa Agile ma bowiem wspierać projekt, a nie być pachnącym drukiem pomnikiem zespołu negocjacyjnego.

Uczestnicząc w negocjacjach dotyczących wdrożeń realizowanych w modelu kaskadowym nie raz zdarzało mi się doświadczać poruszania się w rzeczywistości równoległej do samego projektu. Projekt żył swoim życiem, najczęściej długo przed zawarciem umowy. Nikt z zespołów roboczych nie znał treści zapisów umowy tychże zespołów dotyczących, ani żadnych innych istotnych dla wykonywania projektu. Zmiany koncepcji i specyfikacji (która była załącznikiem do umowy) czy składów zespołów roboczych dokonywały się w mailach (mimo że umowa przewidywała rygor formy pisemnej) itd. itp.

Idea Agile wspiera i łączy obydwa nurty, wymagając od umów życia w projekcie i osadzenia ich mocno w projekcie.

ELASTYCZNOŚĆ I ZWINNOŚĆ TO PODSTAWA

Reagowanie na zmiany ponad Realizację założonego planu?

Planowanie, ale uświadamianie sobie ograniczeń związanych z planowaniem w zmieniającym się środowisku to klucz do elastyczności w projekcie. Tak jak i otwartość na zmiany, nawet na zaawansowanym etapie.

Organizacja projektu w krótkich interwałach czasowych wspiera ten postulat i umożliwia na szybkie reagowanie na potrzeby klienta, bez dramatów typowych dla modelu kaskadowego. Ten postulat w mniejszym stopniu dotyka prawników i dotyczy głównie etapu wykonawczego. Prawnik musi tylko wykazać się zwinnym myśleniem na etapie projektowania i negocjowania klauzul tych aktywności dotyczących i elastycznym reagowaniem na ewentualne zmiany tych procesów.

Tym bardziej, że istota projektów realizowanych w modelu Agile polega na otwartości na zmiany i zmieniające się potrzeby klienta. W przeciwieństwie do modeli kaskadowych, gdzie procedury zmian pojawiały się w umowach, ale ich wcielanie w życie szło bardzo opornie i najczęściej nie nadążało za tempem projektu.

Jeden komentarz

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

This site uses Akismet to reduce spam. Learn how your comment data is processed.