Wersja polska | English version | Deutsche version
X Zamknij
Ta witryna używa plików cookies, aby ułatwić użytkownikom korzystanie z tego serwisu oraz do celów statystycznych. Brak zmiany ustawień przeglądarki w zakresie użycia plików cookie, oznacza zgodę na ich użycie oraz zapisanie w pamięci urządzenia. Każdy ma możliwość samodzielnego zarządzania cookies, poprzez zmianę ustawień przeglądarki.
  • Zaufaj przewodnikom

  • Wytyczamy nowe szlaki

  • Podejmujemy wyzwania

  • Wspólnymi siłami

  • Zaufaj przewodnikom

  • Wytyczamy nowe szlaki

  • Podejmujemy wyzwania

  • Wspólnymi siłami

Agile - Zwinne umowy w projektach Agile cz II

Odsłona druga – GET THE JOB DONE czyli „Manifest kontra Nawyki”

W 2001 r. opublikowano Manifest Zwinnego Wytwarzania Oprogramowania (Agile Manifesto, Manifesto for Agile Software Development) czyli deklarację 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ółpracę z klientem ponad Negocjacje umów
Reagowanie na zmiany ponad Realizację 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, ale to temat na osobną odsłonę. Wróćmy do Agile w obszarze software development.

Dla tradycjonalistów, przyzwyczajonych do realizacji projektów metodą waterfallową, tezy Manifestu Agile są bardzo radykalne. Bez masowych szkoleń, bombardowania zasadami, zawracania Wisły kijem, a być może przeszczepu mózgu 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, ale dla prawnika, który oglądał proces wdrożenia systemu informatycznego z perspektywy ławki na sali rozpraw z kilkunastoma segregatorami akt przed sobą oraz składem sędziowskim, a nie tylko perspektywy stołu negocjacyjnego, bardzo trudne do zaakceptowania, a co dopiero 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 i doskonale 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. Jako prawnicy wszystko co nowe i nieznane zwykle traktujemy z dużym sceptycyzmem i ograniczonym zaufaniem. 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.

Zacznijmy od pierwszej tezy Manifestu. Ludzie i interakcje ponad procesy i narzędzia. Jako kobieta i jako prawnik podpisuję się pod tym obiema rękami. 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. I nie chodzi tu bynajmniej o modne i powszechne w użyciu „jesteśmy w kontakcie”, ale efektywne komunikowanie się, wyrażanie i słuchanie opinii innych, nawet jeśli się z nimi nie zgadzamy. 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.

Działające oprogramowanie ponad obszerną dokumentację to kolejny postulat Manifestu. 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.

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: „Brzmi nieźle, ale ja jestem tutaj od zabezpieczenia interesów mojego klienta, któremu może się wydawać co tylko chce, ale założę się że nie stwierdzi, że priorytetem powinna być współpraca jak wszystko pójdzie źle i zostanie złożony pozew.” Bo 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 (wordingu w corpo mowie) 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 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.

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.

 

Kraków


Autorem artykułu jest:

Radca prawny - Renata Warchoł - Lewicka

EMAIL:renata.lewicka@gsw.com.pl




Podobne Artykuły



Konsultacje on-line

Jeżeli powyższa porada nie wyczerpała interesującego Państwa tematu proszę zadać pytanie prawnikowi specjalizującemu się w danej dziedzinie




Komentarze

Dodaj komentarz:

Imię/email:

Komentarz:


 



Strona główna  |   Aktualności  |   Kancelaria  |   Oferta  |   Zespół  |   Klienci  |   Publikacje  |   Kariera  |   Pro Bono  |   Blogi  |   Kontakt

Siedziba: Plac Szczepański 8 | 31-011 Kraków | tel. +48 12 422 44 59 | fax. +48 12 422 49 39
Biuro: Ul. Pługa 1/2 | 02-047 Warszawa | tel. +48 22 114 33 62 | tel./fax. +48 22 251 89 45