Prawny wymiar metody Agile

Manifest for Agile przesunął akcent z praktykowanego dotychczas kurczowego trzymania się procesów, dokumentacji i planu na dynamiczną współpracę ludzi i zdolność adaptacji do nowych wymagań. W miarę upływu czasu wykształciło się sporo metodyk, które podążają za duchem agile’a, ale różnią się od siebie szczegółami.

Metodyki agile

Wśród popularnych metodyk wyróżnia się DSDM (AgilePM), PRINCE2 Agile, scrum, Kanban, Lean, XP. Ogromną zaletą wszystkich metodyk zwinnych jest ich elastyczność. Inaczej niż do tej pory nie określa się precyzyjnie z góry rezultatu prac i ścisłego harmonogramu poszczególnych etapów projektu (tzw. postępowanie kaskadowe – waterfall), ale ustala się priorytety i pracuje nad projektem „przyrostowo”, systematycznie weryfikując rezultaty i doprecyzowując produkt końcowy. Dzięki temu minimalizuje się ryzyko, że produkt końcowy nie będzie odpowiadał aktualnym oczekiwaniom, ponieważ te albo zmieniły się w trakcie projektu, albo na początku nie zostały właściwie sformułowane ze względu na nowatorski charakter projektu lub brak doświadczenia w tego rodzaju projektach. Mimo a może raczej ze względu na dużą dynamikę agile’owych projektów, agile wymaga dyscypliny, wyrażającej się m.in. w odpowiedzialności wszystkich członków zespołu projektowego za rezultaty projektu oraz systematycznej i dobrej komunikacji.

Równowaga stron umowy w projektach agile

W przypadku projektów agile’owych, których efektem ma być wypracowanie rozwiązania IT, niezwykle istotne jest przygotowanie przez prawnika umowy oddającej ducha agile, przy jednoczesnym zapewnieniu równowagi stron umowy. W praktyce wciąż obserwuje się dość często odstępstwa od zasad agile na korzyść dostawcy. Być może wynika to z faktu, iż to międzynarodowi dostawcy rozwiązań IT byli pionierami w stosowaniu metodyk agile i to prawnicy pracujący dla nich dokonywali adaptacji zasad do polskich realiów prawnych.

Wpływ wykonawców na przyjęte standardy rynkowe widać np. w przypadku wynagrodzenia, które w ocenie wykonawcy z samego tytułu zwinnego prowadzenia projektu powinno zawsze i bez wyjątku być oparte na zasadzie „time and material”, czyli stawkach godzinowych. Natomiast zgodnie z zasadami metodyki AgilePM zarówno czas, jak i koszty są ustalone na początku projektu i powinny pozostać niezmienione przez cały okres realizacji projektu – zmianie może podlegać zakres projektu, np. przez wprowadzenie mniej rozbudowanych, niż pierwotnie planowano, funkcjonalności systemu IT. Oparcie rozliczeń na zasadzie „time and material” bez włączenia postanowień umownych wprowadzających dodatkowe wynagrodzenie za wcześniejsze ukończenie części lub całości projektu może skutkować tym, iż wykonawca nie będzie wystarczająco zmotywowany do utrzymania czasu realizacji projektu i budżetu.

Podział ról i kompetencji

W zależności od wybranej metodyki w projekcie uczestniczą osoby pełniące różne role, np. kierownika projektu, sponsora, wizjonera, koordynatora i analityka (AgilePM) lub właściciela produktu, Scrum Mastera i członka zespołu deweloperskiego (scrum). Istotne, by w umowie dokładnie określić zakres zadań i kompetencji poszczególnych członków zespołu. W kontekście ułożenia współpracy stron na poziomie prawnym, należy określić, kto i w jakim zakresie ma kompetencje do wprowadzenia zmian w przedmiocie projektu w mniej formalny sposób (np. w drodze wymiany korespondencji mailowej).

W projektach agile prace są często prowadzone w mieszanych zespołach obejmujących przedstawicieli dostawcy rozwiązania i klienta. W takiej sytuacji efektem wspólnej pracy będą utwory stanowiące przedmiot wspólnych praw autorskich. Ta współwłasność powstaje z mocy prawa i nie może zostać wykluczona lub zmodyfikowana w wyniku uzgodnień umownych. Aby autorskie prawa majątkowe przysługiwały jednej stronie umowy, należy dokonać ich umownego przeniesienia. 

Przeniesienie autorskich praw majątkowych

W umowie należy przewidzieć cykliczne przenoszenie autorskich praw majątkowych do produktów powstałych w ramach kolejnych etapów prac. Niezależenie od postanowień umownych przewidujących przeniesienie praw na polach eksploatacji odnoszących się do programów komputerowych, postanowienia umowne powinny przewidywać też obowiązek przeniesienia praw do innych utworów powstałych w ramach współpracy (np. grafik interfejsu, dokumentacji) oraz obowiązek przekazania kodu źródłowego.

Przeniesienie kodu źródłowego wydaje się naturalnym następstwem przeniesienia autorskich praw majątkowych do oprogramowania, które nie wymaga ujęcia w zapisach umowy. Jednak ten – jakby się wydawało niezwykle logiczny – pogląd nie zawsze jest podzielany. Istnieje bardzo kontrowersyjne orzeczenie Sądu Apelacyjnego w Warszawie, w którym sąd stanął na stanowisku, iż umowne przeniesienie autorskich praw majątkowych, wraz z wyrażoną w umowie zgodą na dokonywanie opracowań, modyfikacji i rozbudowy programu komputerowego, nie jest równoznaczne z obowiązkiem wydania kodów źródłowych (Sąd Apelacyjny w Warszawie, orzeczenie z dnia 18 września 2014 r., I ACa 315/14).

Scenariusz wyjścia

Istotnym elementem umowy są postanowienia odnoszące się do warunków zakończenia współpracy między stronami – w formie wypowiedzenia umowy lub odstąpienia od niej. Prawo przypisuje im różne skutki prawne. W przypadku wypowiedzenia umowy przyjmuje się, iż umowa przestaje obowiązywać od dnia jej rozwiązania. Umowa, od której odstąpiono, uznawana jest za niezawartą, a skutki odstąpienia sięgają aż do dnia zawarcia umowy. Oznacza to, iż strony umowy zwracają to, co sobie nawzajem świadczyły w ramach umowy. Takie postanowienie umowne mogą mieć formę swego rodzaju scenariusza zawierającego opis działań, ze wskazaniem, która strona umowy jest za nie odpowiedzialna. Scenariusz ten powinien regulować takie kwestie, jak wspomniane przeniesienie autorskich praw majątkowych, kodów źródłowych i dokumentacji, migrację danych, zapewnienie dostępu do oprogramowania przez wydanie haseł oraz usunięcie przez wykonawcę kopii danych i informacji, w szczególności tych stanowiących tajemnicę przedsiębiorstwa.

Przemyślane zapisy umowne dobrze zabezpieczą interesy odbiorcy rozwiązania IT, a przede wszystkim pozwolą uniknąć rozczarowań związanych z przebiegiem prac i ich rezultatem. Dotyczy to w szczególności organizacji, które nie mają zbyt dużego doświadczenia w zakresie wdrożeń nowych rozwiązań IT oraz stawiających pierwsze kroki w agile’u.

Noerr Biedecki sp.k.

source: Automatyka 11/2019