Czy warto stosować umowy Agile?

W mojej ocenie warto opierać na umowach Agile przy wdrożeniach, zarówno tych dużych, jak i małych. Chyba nawet przy takich mniejszych i średnich jest szersze pole do skorzystania z dobrodziejstw umów Agile, ponieważ jest większa swoboda przy ustalaniu treści kontraktu. Na większe wdrożenia najczęściej ma wpływy szereg czynników zewnętrznych, co znacznie ogranicza zakres swobody kontraktowej pomiędzy stronami.

Krótko mówiąc, w dużych wdrożeniach, zazwyczaj jedna ze stron umowy ma narzucone, przynajmniej częściowo, wymagania lub warunki. W efekcie przy takich wdrożeniach umowa Agile musi posiadać niektóre elementy tradycyjnych umów wdrożeniowych. Inaczej na to patrząc, można również powiedzieć, że przy małych wdrożeniach umowy Agile są niepotrzebne, ponieważ posłużenie się tradycyjną umową jest wystarczające, nawet jeśli projekt prowadzi się w myśl filozofii Agile, gdyż w mniejszych projektach jest więcej możliwości dokonywania częstych zmian w kontrakcie. Może tak być. Ale jeśli można również wtedy posłużyć się lepszym typem umowy, to dlaczego tego nie zrobić od razu?

W tym miejscu drobne wtrącenie odnośnie samego rozumienia Agile. Moje uwagi dotyczą tzw. umowy Agile. Patrzę zatem na Agile przede wszystkim w kontekście prawa. Ale to wciąż chodzi o Agile. Nie chcę w tym wpisie zachęcać do metodologii Agile (choć uważam, że jest najlepsza, w każdym razie ja w pewnym sensie tak mam zorganizowaną swoją pracę zawodową), lecz zwrócić uwagę na konieczność specjalnego potraktowania obsługi prawnej, jeśli już zdecydowano się na taką filozofię wdrożenia. Innymi słowy, może się rodzić wątpliwość czy jest sens angażowania w środków w tworzenia specjalnej umowy Agile, skoro może wystarczyć zwykła umowa wdrożeniowa, pomimo że wdrożenia realizowana jest w myśl metodologii Agile.

Według mnie przede wszystkim trzy argumenty przemawiają za umowami Agile:

  1. Pozwalają zrealizować wdrożenie w sposób w najwyższym stopniu satysfakcjonujący obie strony. Umowa zawsze jest kompromisem, ale przy tradycyjnych umowach stronie silniejszej łatwiej narzucić swoje rozwiązanie, co jest konsekwencją okoliczności, że ta zazwyczaj taka strona przedstawia draft umowy, w którym niezbyt jest co zmieniać. W umowach Agile przygotowanie draftu wyłącznie przez jedną ze stron jest z zasady utrudnione i w pewnym sensie niemożliwe, ponieważ jeśli strony nie są w stanie na wstępie współpracy wypracować w drodze kompromisu kontraktu, to niezbyt dobrze wróżyłoby to prowadzeniu projektu w myśl filozofii Agile.
  2. Zapisy w tradycyjnycm umowach to często pustosłowie, a jak rodzi się konflikt, to okazuje się, że jednak jedna ze stron w sposób wcześniej „niewyobrażalny” wykorzystuje zapisy na swoją korzyść. W umowach Agile wprawdzie również musi być sporo treści, ale trzeba się w nich kierować konkretami. Czasami spotykam się również z sytuacjami, że dla stron umowy jakieś postanowienie wydaje się jasne, tymczasem dla mnie jest to, jak wspomniałem, pustosłowie, gdyż po głębszym zastanowieniu mógłbym je interpretować na wiele sposobów.
  3. Skutkiem ewentualnego niezrealizowania umowy Agile niekoniecznie musi być wieloletni spor sądowy (połączony z położeniem całego projektu), lecz wymiana kontrahenta na lepszego, połączona z wzajemnych, ale realnym. rozliczeniem się dotychczasowych stron.

Osobiście podoba mi się również w filozofii Agile rola prawnika, która nie jest marginalizowana do minimalizacji ryzyk prawnych na wypadek sporów, ale koncentruje się na doradztwie, czasami bardzo aktywnym, co do ułożenia zasad współpracy pomiędzy stronami. Tym samym jest to prewencja.

Z mojego doświadczenia wynika, że najczęściej główni aktorzy projektu (podmiot biznesowy i podmiot developerski) nie rozumieją się wzajemnie i w pewnym sensie uważają, że ich udział jest kluczowy. Takie wzajemne niezrozumienie prowadzi zazwyczaj do powstania tzw. „obszarów niczyich”. Podmiot biznesowy uważa, że jako inicjator i sprzedawca zleca pracę podmiotowi developerskiemu (dosłownie „zleca”, co jest równoznaczne, że sam w tym zakresie niewiele robi i po prostu chciałby gotowy produkt), a z kolei podmiot developerski uważa, że wie lepiej co można, a czego nie i robi jak uważa, samemu „urealniając” potrzeby podmiotu biznesowego. W efekcie zatraca się sens projektu. Mówiąc dobitnie – sens projektu przestaje odgrywać wiodącą rolę, a zaczyna liczyć się jedynie minimalizowanie tych niedoróbek, do których można „doczepić się” z punktu widzenia zapisów umownych.

Czy dobrym pomysłem jest wypełniać umowę Agile obowiązkami w zakresie organizowania regularnych spotkań. Wydaje się, że nie. Pisanie o tych spotkaniach może często tworzyć złudzenie działania w ramach metodologii Agile, pomimo że wdrożenie faktycznie realizowane jest według tradycyjnych metod.

Na zakończenie w kilku słowach chciałem zwrócić uwagę na błędne posługiwanie się pojęciem odpowiedzialności, co dotyczy w szczególności tradycyjnych kontraktów, w mniejszym stopniu umów Agile. Nie-prawnicy posługują się nim jako synanimem słowa „kompetencja” lub „uprawnienie”. Zapisując w umowie, że ktoś jest odpowiedzialny za coś, znaczy dla nich tyle, że to jest jego działka (tym czymś ten ktoś się właśnie zajmuje). Idąc takim tokiem rozumowania, można dodać, że inne osoby nie powinny w ten obszar wkraczać, skoro ten ktoś jest za niego odpowiedzialny. Tak pojmowane pojęcie odpwiedzialności jest w świetle prawa „puste”, ponieważ nie wiąże się z nim sankcji. Dla prawnika powiedzenie, że ktoś jest odpowiedzialny np. za interfejs (ogólnie mówiąc) znaczy tyle, że jak w tym zakresie coś będzie nie tak, to osoba odowiedzialna ponosi konsekwencje niepowodzenia całego projektu, a nie tylko interfejsu.