UMOWA AGILE W IT?

3 KROKI W STRONĘ INNOWACJI

AGILE CONTRACT’S DESIGN – ZWINNE PROJEKTOWANIE WARUNKÓW PRAWNYCH DLA WDROŻEŃ W MODELU AGILE

---

——————————————————————————————————————————————————————

Z cyklu NOWOCZESNE KONTRAKTY by Renata W.Lewicka

 

AGILE? CZYLI JAKI?

„Agile” czyli zwinny.

Agile oznacza zwinne dostosowywanie się do wymagań kontrahenta, które mogą ewoluować w trakcie realizacji projektu, a dochodzenie do celu może odbywać się metodą prób i błędów. Źródło nowatorskiego podejścia do projektów bije w obszarze IT.

Agile software development to grupa metod wytwarzania oprogramowania opartego na programowaniu iteracyjno-przyrostowym, powstałe jako alternatywa do tradycyjnych metod typu waterfall.

UMOWY AGILE

W modelu Agile produkt prawny też ma być z założenia wartościowy i dostosowany do zwinnej metodyki prowadzenia projektu.

W praktyce oznacza to zastąpienie funkcji copy&paste kreatywnością w jego tworzeniu sprzężoną z potrzebami tych, których zadania czy obowiązki ma regulować oraz zrozumieniem całego procesu i sposobu w jaki będzie przebiegał.

Proste? Nie do końca.

Choć w praktyce dostawa wartościowych produktów prawnych nie jest aż tak trudna. Jednak zmiana sposobu myślenia w procesie ich tworzenia już może się taka okazać. Będzie jeszcze trudniej, jeśli prawnicy będą przeciwni innowacjom. Niezależnie bowiem od sposobu myślenia, branża IT już teraz wpływa nie tylko na sposób, w jaki prawnicy przestrzegają prawo, ale także na sposób, w jaki świadczą usługi.

AGILE Z UDZIAŁEM PRAWNIKÓW?

CZY TO JEST W OGÓLE MOŻLIWE?

Wszystkie refleksje zaczęły się od zasłyszanego gdzieś w kuluarach zdania „Jak możemy realizować projekt metodą Agile jeżeli musimy zawrzeć umowę”?

Przypuszczam, że pytającemu chodziło nie tyle o samą umowę, co konieczność zaangażowania w proces prawników. Dla których w większości negocjowanie, dyskutowanie i spieranie się o każdą klauzulę ma większą wagę niż współpraca stron z tym procesem związana.
A sukces samej umowy nie koniecznie jest utożsamiany z sukcesem samego projektu.

SUKCES PROJEKTU? CZYLI CO?

Paradoksalnie bowiem pojęcie „sukces projektu” ma zupełnie inne znaczenie dla prawników, biznesu, a jeszcze inne dla członków zespołów roboczych.

Dla prawnika to „dobra” umowa czyli umowa zabezpieczająca klienta w najwyższym możliwym stopniu, bo prawnik nierzadko postrzega swoją rolę jako ochronę klienta przed ryzykami, o których klient nawet nie ma pojęcia. Udany projekt to taki, który nie skończył się procesem sądowym. Ostatecznie prawnik nie utożsamia sukcesu umowy z wdrożeniem wartościowego produktu, rzadko ma wiedzę na temat tego jak wdrożenie się toczy czy zakończyło, chyba że się nie kończy i pojawiają się problemy.

Dla biznesu sukces projektu najczęściej mierzy się wielkością zysków na projekcie, spięciem się budżetu i dobrymi referencjami, a dla IT sukces projektu to zwykle wartościowy dla klienta produkt.

SILO MENTALITY ≠ AGILE

Jakby się tak głębiej nad tym zastanowić to odmienne podejście jest efektem separowania się wzajemnego uczestników od wiedzy o procesach, prawników o procesach technologicznych i biznesowych, które każe im się zabezpieczać w umowach, a biznesu i IT od głównych obaw prawników (nazywany w terminologii fachowej „silo mentality”).

W praktyce wdrożeń również wymiana doświadczeń i wiedzy pomiędzy biznesem i IT często kuleje. Biznes nie bardzo chętnie angażuje się na poziomie operacyjnym w projekt ograniczając swoją rolę do decyzyjnej w przypadku eskalacji konfliktu albo w sprawach dużej wagi (najczęściej chodzi o dodatkowe pieniądze albo prace).

Sukces projektu jest najczęściej sukcesem kierownika projektu i jego zespołu. Żonglującego umiejętnie czasem biznesu wyższego szczebla, terminami z harmonogramu oraz pojawiającymi się wraz z zaawansowaniem projektu oczekiwaniami klienta. Klienta, który wraz z postępem projektu więcej widzi i rozumie, a którymi trzeba jakoś zarządzić.

WARTOŚCIĄ JEST ZROZUMIENIE

„Podejście do” oraz „zrozumienie” procesów operacyjnych i dostaw oraz sposób ujęcia tego w umowach stanowi kluczową różnicę pomiędzy umowami zwinnymi, a umowami bardziej tradycyjnymi. I od uświadomienia sobie tego należy rozpocząć każdą przygodę z projektem Agile. Nie chodzi tylko o nową strukturę umowy, terminologię czy nową organizację projektu i bycie trendy, bo realizujemy projekt nową metodą.

ZMIANA MYŚLENIA TO KLUCZ

Najważniejszym priorytetem dla wszystkich uczestników projektu wdrożeniowego, w tym prawników jest zmiana myślenia. Rozumienie „sukcesu projektu” jako dostarczenie działającego, satysfakcjonującego użytkownika systemu, a nie tylko zawarcie „dobrego kontraktu” (=szczelnego, zabezpieczającej możliwie największą ilość ryzyk). A w konsekwencji zmiana zachowania wszystkich zaangażowanych, w tym prawników.

Podstawą sukcesu projektu nie jest bowiem umowa, ale dobra relacja pomiędzy uczestnikami projektu. Relacja oparta na współpracy, zaufaniu, transparentności praw i obowiązków. „Dobra” umowa powinna zawierać mechanizmy wspierające funkcjonowanie tych trzech czynników, a nie przyczyniać się do destrukcji drugiej strony już na starcie. Rzucać ją na kolana i zmuszać do dziękowania za możliwości realizacji takiego projektu każdego dnia.

Nie śmiem oczywiście trywializować procesu negocjacji umów Agile, twierdząc iż są mniej kompleksowe czy angażujące niż inne. Wręcz przeciwnie. Zawsze będą skomplikowane jeśli dotyczą czegoś tak niepewnego jak tworzenie i dostawa oprogramowania. Oprogramowania, którego nikt jeszcze nie widział, wszyscy o nim słyszeli, a jego pełna wizja powstanie dopiero na końcu prac.

ZMIANA MYŚLENIA, ZMIANA NAWYKÓW, ZMIANA ZACHOWAŃ

Patrzę jednak na proces negocjowania umowy w kontekście tego czego on dotyczy. A nie jako na rzeczywistość równoległą, nie przecinającą się z operacyjną częścią projektu.

A punktem wyjścia w tym procesie jest zmiana myślenia, zmiana nawyków, a konsekwencji zmiana zachowań.

Więcej o korelacji pomiędzy tezami Manifestu Agile, a realiami świata tradycjonalistów w kolejnej odsłonie.