Czym jest agile?

Agile, czyli zwinna umowa, nie jest bynajmniej pojęciem prawnym, ani nawet prawniczym. Przede wszystkim jest to sposób pracy nad projektami, można powiedzieć – framework choć to stwierdzenie też nie odda specyfiki tego określenia w pełni. Zwinność umowy, zakłada przede wszystkim, że w trakcie prowadzenia projektu może dojść do jego licznych zmian, a co więcej, że zostało to przewidziane jeszcze na etapie podpisania umowy.

Warto wiedzieć, że jest więcej niż jeden rodzaj systemów w ramach których można prowadzić zwinną współpracę i w zależności od tego, który z nich zostanie przyjęty, szczegóły takiej współpracy mogą wyglądać nieco inaczej, jednak pewne założenia będą między nimi zbieżne. Jest więc kilka kwestii na które warto zwrócić uwagę podpisując  zwinną umowę. Ze względu na to, że niejednokrotnie praca nad wdrożeniami IT wymaga przyjęcie właśnie agile’owej formuły współpracy stron warto prześledzić co w takich umowach powinno się znaleźć.

Określenie przedmiotu umowy

Choć nie wynika to bynajmniej z przepisów prawa to w mojej ocenie dalekim jest od prawdy twierdzenie, że umowa jest zwinna tylko wówczas, gdy nie określa się w niej nad czym konkretnie będzie pracować zespół deweloperów, a jedyną realnie określoną w umowie kwestią jest stawka za godzinę pracy dewelopera i innych osób wchodzących w skład zespołu IT. Choć oczywiście tego rodzaju umowy także mogą być w IT zawierane, a co więcej – ma to miejsce bardzo często, to jednak niewątpliwie nie na tym polega zwinność.

Zawierając umowę agile’ową dobrym standardem jest określenie czego będzie ona dotyczyć. Nie, bynajmniej nie chodzi o to żeby dokładnie sprecyzować wszystkie niezbędne elementy ostatecznej wersji oprogramowania. Określenie przedmiotu umowy agile może dotyczyć samych tylko kluczowych jego założeń, a wręcz możliwe jest wprowadzenie takich postanowień nawet do umów przedwdrożeniowych. Także wówczas dobrze jest bowiem wiedzieć czego analiza przedwdrożeniowa ma dotyczyć, jaki język programowania ma być przez software house finalnie użyty, czy też może czy to właśnie jest elementem oceny, a ostatecznie co ma być rezultatem etapu przedwdrożeniowego.

Przedmiot umowy agile, a MVP

Kolejną kwestią, która może mieć znaczenie jest ujęcie w zwinnej umowie kwestii dotyczących MVP, czyli Minimum Viabla Produc. Zazwyczaj bowiem jest tak, że w agile wdrażane są innowacyjne rozwiązania, a tych nie przyjęło się wypuszczać na rynek dopiero w wersji finalnej. Idealnym rozwiązaniem jest więc takie skonstruowanie umowy, z którego będzie jednoznacznie wynikać, że jedną z początkowych faz pracy software house jest stworzenie MVP.

Na tym jednak agile nie powinna się zakończyć i zupełnie zasadnym jest uregulowanie w niej kwestii, które następnie nastąpią. Przede wszystkim uregulowania te mogą dotyczyć tego, że po wypuszczeniu na rynek MVP na pewien czas współpraca stron jest wstrzymana i wróci się do niej dopiero w momencie, w którym faza walidacji produktu będzie zakończona. Może być też tak, że na czas od wypuszczenia MVP do podjęcia decyzji o kontynuowaniu produktu software house będzie wyłącznie świadczyć usługę serwisu oprogramowania. Jaką jednak decyzję strony zdecydują się podjąć dobrze jest aby została ona wyrażona w postanowieniach umownych. Warto też rozważyć wprowadzenie po stronie zamawiającego prawa opcji co do kontynuowania projektu, o czym będzie więcej poniżej.

Pracuj iteracyjnie i wyznacz kamienie milowe

Praca w agile nierozłącznie jest związana z bieżącym śledzeniem postępu oraz monitorowaniem jego rezultatu. Temu właśnie służą iteracje. Kwestia do czego konkretnie zostaną one odniesione nie jest w żaden sposób zamknięta, choć swoistym standardem, przeniesionym nomen omen ze scrum, jest ich odniesienie do określonego czasu. Metoda ta z pewnością może być uznana za bardzo dobrą, szczególnie jeśli na etapie podpisywania umowy trudno jednoznacznie stwierdzić jaki będzie finalny przebieg prac nad projektem.

Warto też zwrócić uwagę na to, że jeśli nawet w miarę ogólnie da się określić przedmiot umowy agile’owej, gdy jest ona podpisywana świadomie, a jest to praktycznie zawsze możliwe, to należy wyznaczyć kamienie milowe. Innymi słowy, należy określić przełomowe momenty pracy nad produktem i odnieść do nich kwestię weryfikacji całego projektu. Pozwala to uzyskać jeszcze lepszą płynność pracy i jest w projektach IT pożądanym rozwiązaniem.

Wyznacz osoby odpowiedzialne i zakres ich kompetencji

Zwinne umowy mają przenosić maksymalnie dużo kompetencji na osoby będące jak najbliżej procesu pracy nad produktem. Oznacza to nie mniej nie więcej, że maksimum uprawnień powinno być przeniesione z zarządów software house i zamawiającego na zespoły pracujące po każdej ze stron. Powyższe wymusza jednak stworzenie jasnych zasad pracy tych zespołów, a przede wszystkim wskazanie osób decyzyjnych oraz kwestii, w których mogą one samodzielnie podejmować decyzję. Niekiedy, dla najdalej idącej jasności, warto także wprost wskazać które decyzje pozostają w rękach zarządów.

W tym kontekście warto też podkreślić, że niezależnie od przyjętego modelu pracy zwinnej dobrze jest wyznaczyć osobę, która będzie w imieniu zamawiającego decydować na temat rozwoju projektu. Chodzi tu o osobę, która w scrum określana jest jako product owner, ale rzecz jasna nie o nazwy tu chodzi. Krótko mówiąc, jeśli zamawiający przez cały czas aktywnie uczestniczy w procesie tworzenia oprogramowania istnieje znacznie mniejsze ryzyko, że finalnie będzie on nieusatysfakcjonowany z osiągniętego rezultatu.

Procedury odbiorowe

Rzecz jasna jeśli współpraca przebiega bez problemu to kwestie odbiorów nie musiałyby nawet zostać uregulowane w umowie. Problem polega jednak na tym, że w agile najczęściej pracuje się nad kwestiami innowacyjnymi, nowymi, nad którymi praca nie koniecznie musi przebiegać zgodnie z założeniami stron. Innymi słowy, agile to idealny sposób pracy nad takimi projektami, które mają sporą szansę niepowodzenia.

Z tego też powodu najlepiej już na samym wstępie ustalić kwestie dotyczące tego co konkretnie będzie weryfikowane podczas odbiorów tak częściowego, jak i końcowego. Kiedy software house będzie miał prawo do pełnego wynagrodzenia mimo wystąpienia błędów w tej części oprogramowania, która została wykonana, a kiedy będzie jednak musiał dokonać stosownych poprawek, aby mieć prawo do wyfakturowania kolejnego etapu pracy? Wbrew pozorom kwestie te nie są takie oczywiste więc tym bardziej lepiej dla późniejszej prawidłowej współpracy jest ustalić je przed rozpoczęciem prac nad projektem, a nie już po wykryciu błędów.

Warto także podkreślić, że w żadnej mierze nie stoi poczynieniu takich ustaleń na przeszkodzie fakt, że na etapie podpisywania umowy może nie być jeszcze nawet przesądzone jakie cechy będzie miała aplikacja, która finalnie zostanie wykonana. Kwestię tę można zawsze rozwiązać w ten sposób, że akceptowalne i nieakceptowalne błędy będą ustalane przez strony przed przystąpieniem do kolejnej iteracji bo jest to i tak lepsze rozwiązanie niż rozstrzyganie charakteru błędu już po jego wykryciu na etapie odbioru częściowego, czy końcowego, gdzie wcześniej strony nie poczyniły jakichkolwiek ustaleń co do tego jak błędy te będą przez nie oceniane.

Procedury zmiany a agile

Praca w agile niejako defultowo przewiduje możliwość zmian w projekcie. Niemniej jednak, najrzadziej jest tak że wprowadzanie takich zmian nie wpływa na realizację projektu. Dlatego też, już w samej umowie najlepiej przewidzieć w jaki sposób wprowadzać się będzie zmiany w projekcie, które z nich są dokonywane przez zespół software house i zespół zamawiającego bez udziału ich prawnych przedstawicieli, a do których koniecznym jest udział osób uprawnionych do reprezentacji stron.

Warto też zwrócić uwagę na to, aby w umowie wskazać dla przykładu, że jeśli umowa przewidywała określony termin jej zakończenia, a strony w trakcie jej wykonywania dokonają zmiany zakresu umowy to defultowo będzie mieć to wpływ na termin zakończenia prac nad projektem nawet jeśli określona zmiana nie będzie wymagać zmiany umowy.

Co istotne, niejednokrotnie w umowach IT korzysta się też z tak zwanego prawa opcji, o którym wspominałem już powyżej. Mianowicie chodzi tu o sytuacje, gdy określony zakres umowy będzie wykonywany tylko o tyle o ile taką decyzję (skorzystanie z prawa opcji) podejmie jedna ze stron umowy, najczęściej zamawiający. Warto na to zwrócić uwagę, gdyż może mieć to znaczenie w kontekście opłacalności podpisania określonej umowy.

Dobrym rozwiązaniem jest też wprowadzenie postanowień umownych zgodnie z którymi wraz ze skorzystaniem z prawa opcji co do danego zakresu prac wchodzić będą także inne postanowienia umowne dotyczące innych istotnych dla stron kwestii.

Odpowiedzialność stron a agile

Podpisując umowę agile’ową warto też poświęcić czas na ustalenia czego realnie oczekujemy i wymagamy od software house. Mianowicie, chodzi o to, że tego rodzaju umowa może być podpisana zarówno jako umowa starannego działania, jak i umowa rezultatu. Od tego, jak finalnie zostanie ona skonstruowana zależeć będzie zakres odpowiedzialności software house, co z pewnością ma duże znaczenie dla przebiegu współpracy.

Warto też pamiętać, że odpowiedzialność stron może być także uregulowana poprzez wprowadzenie kar umownych. Trzeba jednak wyraźnie podkreślić, że w przypadku umów agile’owych wydaje się niejednokrotnie wątpliwym ich odnoszenie do powodzenia danego wdrożenia i zdecydowanie lepiej odnosić je do konkretnych uchybień i błędów.

Prawa autorskie a agile

Kwestia tego komu przysługiwać będą prawa autorskie do efektu prac software house nie jest być może najistotniejsza dla stron, gdy rozpoczynają współpracę, ale gdy produkt jest już stworzony często potrafi stać się kością niezgody. Dlatego też, dobrze dokładnie przeanalizować treść umowy, którą podpisujemy i ustalić, czy zgodnie z jej treścią mamy otrzymać licencję wyłączną, licencje niewyłączną, a może nabyć majątkowe prawa autorskie do programu komputerowego, który będzie efektem współpracy.

Przede wszystkim, dobrze jest jednak rozróżniać zakres uprawnień, który daje każde z tych rozwiązań. Co więcej, nie można w tym zakresie zapominać, że jako zamawiający powinniśmy zadbać o to, żeby zastosowanie określonego rozwiązania nie ograniczało się do tej części prac, która w świetle przepisów jest programem komputerowym. Nie można bowiem zapominać choćby o takich kwestiach jak to, że graficzny interfejs użytkownika nie stanowi programu komputerowego i co najwyżej mogą do niego przysługiwać prawa autorskie jak do innych utworów.

Exit plan

W przypadku innowacyjnych rozwiązań niekiedy bywa i tak, że już na pewnym etapie ich realizacji da się jednoznacznie stwierdzić, że kontynuowanie pracy nad nimi nie ma ekonomicznego, czy biznesowego sensu. Powyższe będzie szczególnie widoczne właśnie w przypadku IT, gdzie już sam rozwój technologii jest tak szybki, że  nawet jeden, czy dwa kwartały mogą okazać się na tyle przełomowe, że zmieni się zupełnie technologia programowania.

Dlatego też warto wprowadzić do umowy tak zwany plan wyjścia, który pozwoli zakończyć współprace nad danym projektem z poszanowaniem praw obu stron. Z jednej strony trzeba bowiem ważyć interesy zamawiającego, które dotyczą nieopłacalności kontynuowania danego projektu. Z drugiej natomiast, istotne są interesy software house, który do jego realizacji z pewnością delegował swoich pracowników jednocześnie nie poszukując dla nich innych projektów, nad którymi mogliby pracować w tym czasie.

Podsumowanie

Choć niejednokrotnie słyszy się tezy, że zwinna umowa powinna określać jak najmniej kwestii dotyczących ram współpracy stron to w rzeczywistości jest zupełnie odmiennie. Przemyślana agile’na umowa będzie posiadać prawdopodobnie wiele więcej postanowień niż umowa waterfall’owa. Ma to jednak na celu takie ułożenie praw i obowiązków stron, aby współpraca przebywała w sposób sprawny, niezakłócony i bez uszczerbku dla stron takiej umowy.