Jak prawnie poradzić sobie z rozwojem agile bez zbędnych sporów

Typowe problemy prawne w projektach agile

1. Umowa a stale zmieniający się zakres prac (Scope Creep)

Problem: Rozwój agile ma charakter iteracyjny – wymagania dotyczące funkcji i właściwości oprogramowania mogą zmieniać się w trakcie prac. Jeśli mają Państwo klasyczną umowę o dzieło z ściśle określonym zakresem, ceną i terminem, napotkają Państwo trudności. Zamawiający często dopiero w trakcie rozwoju odkrywa, czego naprawdę potrzebuje, a dostawca napotyka nowe przeszkody techniczne. Sztywna umowa zawarta na początku może więc po kilku miesiącach nie odpowiadać rzeczywistości.

Skutkiem są zwykle opóźnienia i przekroczenia budżetu – badania pokazują, że zdecydowana większość projektów informatycznych boryka się z niezadowoleniem klienta, często właśnie z powodu nieodpowiednio skonstruowanej umowy. Być może także Państwo mieli doświadczenie, że nie byli w pełni zadowoleni z przebiegu zewnętrznie rozwijanego oprogramowania, ponieważ „na papierze” wszystko było jasne, ale rzeczywistość wyglądała inaczej.

Przykład z praktyki: Firma zamówiła stworzenie nowej aplikacji o z góry ustalonym zakresie za cenę ryczałtową. W trakcie projektu kierownictwo firmy stwierdziło jednak, że potrzebuje kilku dodatkowych istotnych funkcjonalności. Dostawca je wdrożył, pracy przybyło – i nagle projekt był dwukrotnie droższy, a termin nie był dotrzymywany. Obie strony znalazły się w sporze o to, kto poniesie dodatkowe koszty. Wniosek? Zbyt sztywna umowa nie pozwoliła elastycznie reagować na zmiany.

Rozwiązanie: Umowa agile zamiast klasycznej umowy o dzieło. W umowie dotyczącej rozwoju agile warto zdefiniować proces zmian – na przykład uzgodnić regularne przeglądy założeń po każdym sprincie oraz procedurę zatwierdzania zmian w projekcie. Zamiast szczegółowego, sztywnego opisu dzieła końcowego umowa opisuje wizję produktu, sposób współpracy oraz tzw. „historyjki użytkownika”. Ważne jest uzgodnienie, w jaki sposób będzie doprecyzowywana „Definition of Done” (zestaw kryteriów określających, kiedy zadanie cząstkowe jest ukończone), oraz kryteriów akceptacji przy odbiorze każdej funkcji.

Te mikro-uzgodnione kryteria działają jak małe umowy w ramach projektu – pomagają jasno określić, co ma zostać dostarczone, i tym samym zmniejszają ryzyko sporu o ukończenie prac. Zaleca się również uzgodnienie mechanizmu, w jaki sposób obie strony będą rozwiązywać kwestie zmian zakresu (np. karty zmian, spotkania zatwierdzające). Prawnicy ARROWS chętnie przygotują dla Państwa umowę szytą na miarę projektu agile, w tym z jasnym uregulowaniem procesu zmian, aby Państwa oczekiwania i rzeczywistość rozwoju pozostawały ze sobą w zgodzie.

2. Niejasne prawa własności intelektualnej (IP) i komponenty open source

Problem: Kto będzie właścicielem gotowego oprogramowania i kodu źródłowego? To pytanie jest źródłem zaskakująco częstych sporów. W projekcie agile oprogramowanie powstaje stopniowo i często wykorzystuje się różne biblioteki czy komponenty open source. Jeśli umowa nie reguluje praw własności i praw licencyjnych, może nastąpić nieprzyjemne przebudzenie: dostawca może twierdzić, że zachowuje prawa autorskie do dzieła (i udziela jedynie licencji na korzystanie), albo że niektórych części kodu nie może Państwu przekazać, ponieważ są open source na podstawie specyficznej licencji.

Ponad 70 % sporów w obszarze rozwoju oprogramowania wynika z niejasnych praw IP – typowo wtedy, gdy obie strony różnie zinterpretowały, do kogo należy końcowy kod i czy można go dalej dowolnie modyfikować. Proszę sobie wyobrazić, że inwestują Państwo w rozwój, a ostatecznie okazuje się, że bez zgody dostawcy nie wolno Państwu rozwijać oprogramowania z kimś innym – sytuacja wysoce niepożądana.

Rozwiązanie: Umowa musi jednoznacznie uregulować własność intelektualną do tworzonego oprogramowania. Najbezpieczniejsze dla Państwa jako klienta jest uzgodnienie przeniesienia praw autorskich lub licencji wyłącznej do oprogramowania po jego ukończeniu. W ten sposób uzyskują Państwo pełną kontrolę nad kodem źródłowym. Jeśli nie jest to możliwe, należy przynajmniej nalegać na szeroką licencję na korzystanie oraz przekazanie kodów źródłowych po zapłacie – bez kodów źródłowych oprogramowanie jest trudne do rozbudowy, a Państwo byliby zdani na łaskę dostawcy. Ponadto należy uregulować sposób postępowania z komponentami open source lub komponentami osób trzecich.

Umowa powinna określać, jakie licencje open source są dopuszczalne (np. wykluczyć komponenty, których licencja zmuszałaby do upublicznienia całego Państwa oprogramowania). W przypadku komponentów dostarczonych przez klienta lub bibliotek open source warto z góry uzgodnić, kto ponosi za nie odpowiedzialność i jakie są gwarancje. W przeciwnym razie mogłoby się zdarzyć, że do Państwa produktu zostanie zintegrowany kod obciążony wadą prawną (np. naruszający czyjąś licencję) i spór gotowy. Prawnicy ARROWS pomogą Państwu precyzyjnie ustawić postanowienia licencyjne – od zapewnienia przeniesienia praw lub licencji wyłącznej, przez obowiązek wydania kodów źródłowych, aż po zabezpieczenie ryzyk związanych z open source.

3. Jakość dostawy, wady i odpowiedzialność za nie

Problem: W każdym procesie rozwoju pojawiają się bugi (błędy) lub niedoróbki. Różnica polega na tym, jak podchodzi się do nich umownie. W tradycyjnej umowie o dzieło zwyczajowo udziela się gwarancji na dzieło – przez określony czas po przekazaniu zamawiający ma prawo do bezpłatnego usunięcia ewentualnych wad. W rozwoju agile dostawa jest jednak zwykle podzielona na wiele mniejszych części, a końcowe „przekazanie dzieła” jako takie może w ogóle nie nastąpić (projekt może płynnie przejść do kolejnej fazy rozwoju). Jeśli umowa nie zawiera postanowień o odpowiedzialności za wady, gwarancji i wsparciu serwisowym, grozi podwójne ryzyko: albo nie będą Państwo wiedzieć, do czego są uprawnieni, gdy pojawi się problem, albo każda ze stron będzie zakładać coś innego.

Typowym zarzewiem sporu jest sytuacja, w której klient wykrywa błędy w systemie i żąda ich naprawy w ramach pierwotnej ceny, podczas gdy dostawca podnosi, że wykracza to już poza uzgodniony zakres prac. Bez umownego porozumienia grozi sytuacja patowa – klient czuje się poszkodowany niską jakością świadczenia, a dostawca z kolei nie chce pracować za darmo.

Rozwiązanie: Proszę jasno uzgodnić warunki odpowiedzialności za wady oraz późniejszych usług serwisowych. Już w umowie można zapisać określony serwis gwarancyjny – np. że przez X miesięcy od wdrożenia systemu dostawca będzie bezpłatnie usuwał zgłoszone istotne wady. Ponadto zalecamy uzgodnienie ewentualnego długoterminowego wsparcia i utrzymania (np. w formie umowy serwisowej lub SLA).

Proszę pomyśleć o tym, co będzie po wdrożeniu: czy dostawca będzie dostępny w celu wprowadzania poprawek i aktualizacji? Na jakich warunkach? Wszystko to powinno znaleźć się w umowie. Dobrze sformułowane postanowienie o gwarancji i serwisie pomoże Państwu uniknąć nieporozumień i sporów w przyszłości. Innymi słowy, gdy obie strony wiedzą, na czym stoją – że na przykład błędy krytyczne zostaną usunięte w ciągu 14 dni, a mniej poważne w kolejnej wersji itp. – zapobiegają Państwo konfliktom wynikającym z niespełnionych oczekiwań. Prawnicy ARROWS na co dzień pomagają klientom ustalać w umowach realistyczne warunki gwarancyjne i procedurę reklamacji wad, tak aby jakość dostaw była egzekwowalna, a jednocześnie dostawca wiedział, gdzie kończy się jego odpowiedzialność.

4. Ochrona danych i zgodność z regulacjami (RODO)

Problem: Nowoczesne oprogramowanie często przetwarza dane osobowe klientów lub inne wrażliwe dane. W rozwoju agile – z naciskiem na działające oprogramowanie ponad szczegółową dokumentację – istnieje ryzyko, że aspekty bezpieczeństwa i ochrony danych nie zostaną dostatecznie udokumentowane ani rozwiązane. Może się na przykład zdarzyć, że zespół deweloperski użyje rzeczywistych danych do testów bez zgody albo że nie zostanie jasno określone, kto odpowiada za środki bezpieczeństwa.

Wyciek danych lub naruszenie RODO prowadzi wówczas nie tylko do utraty reputacji, ale także do sankcji prawnych. Czy wiedzą Państwo, że za naruszenie obowiązków wynikających z RODO grozi kara do 20 milionów EUR lub 4 % rocznego obrotu firmy – w zależności od tego, która kwota jest wyższa? Taka sankcja może być dla średniej firmy zabójcza. Znaczna część incydentów wynika przy tym z bagatelizowania bezpieczeństwa w trakcie rozwoju – aż 63 % wycieków danych jest spowodowanych niewystarczającymi środkami bezpieczeństwa po stronie ludzi i procesów. Zespoły agile czasem nie chcą „tracić czasu na papierologię”, ale brak jasnych zasad i dokumentacji dotyczącej postępowania z danymi może mieć konsekwencje prawne.

Rozwiązanie: Proszę zadbać o włączenie zasad ochrony danych już do umowy i do procesu rozwoju. Umowa powinna zawierać klauzule poufności, jasno określać, kto jest administratorem, a kto podmiotem przetwarzającym dane osobowe, oraz nakładać na dostawcę obowiązki w zakresie bezpieczeństwa (szyfrowanie, kopie zapasowe, dostępy itp.). Zalecamy również uzgodnienie, że dostawca przestrzega RODO i ponosi odpowiedzialność za ewentualne wycieki spowodowane naruszeniem zabezpieczeń z jego strony. Poza umową warto także w praktyce, w trakcie rozwoju, pamiętać o zasadzie „Privacy by Design” – na przykład włączyć kryteria bezpieczeństwa i compliance do Definition of Done poszczególnych zadań. Agile nie oznacza całkowitego ignorowania dokumentacji – kwestie wrażliwe (takie jak właśnie przetwarzanie danych osobowych) powinny być należycie odnotowane i zatwierdzone przez obie strony. Można również uzgodnić np. regularne audyty bezpieczeństwa po określonych fazach. Prawnicy ARROWS specjalizują się także w IT compliance – pomogą Państwu ustawić umowę i procesy wewnętrzne tak, aby rozwój przebiegał zgodnie z RODO i innymi przepisami, minimalizując w ten sposób ryzyko sankcji.

5. Model cenowy i niepewność finansowa projektu

Problem: Ile będzie kosztował rozwój? – Pytanie, na które kierownictwo firmy chce mieć jasną odpowiedź, ale w projekcie agile nie jest ona jednoznaczna. Kontrakty agile zazwyczaj nie mają formy ryczałtu ze stałą ceną za całe dzieło, ponieważ na początku nie jest znany dokładny zakres wszystkich wymagań. Może to prowadzić do napięć: klient (zamawiający) oczekuje określonego poziomu cen, podczas gdy dostawca zwraca uwagę, że z powodu zmian prace mogą podrożeć.

Jeśli nie zostanie to uzgodnione z góry, grozi budżet wymykający się spod kontroli i spór o to, kto poniesie dodatkowe koszty. Zamawiający może mieć poczucie, że „płaci więcej, niż się spodziewał”, a dostawca przeciwnie – że „pracuje dodatkowo za darmo”. Projekty agile czasem zaczynają się od optymistycznej obietnicy szybkiej i taniej wersji podstawowej, ale stopniowe dodawanie funkcji może wielokrotnie podnieść końcowy rachunek, jeśli brakuje ram.

Rozwiązanie: Proszę ustalić właściwy model cenowy i przejrzyste zasady finansowe. Istnieje kilka modeli, które można stosować w umowach agile, np.:

• Time & Materials (czas i materiały): Płacą Państwo na bieżąco według przepracowanych godzin i rzeczywistych kosztów. Ten model jest bardzo elastyczny – płacą Państwo za to, co faktycznie zostanie wykonane. Wada: niepewność ceny końcowej, wymaga zaufania i kontroli przebiegu prac.
  
• Cena stała z zarządzaniem zakresem: Łączy zalety stałej ceny i zwinności. Uzgadniają Państwo maksymalną cenę za określony zestaw funkcjonalności, ale zakres może być modyfikowany – jeśli coś zostanie dodane, coś innego musi zostać usunięte, aby utrzymać budżet.
  
• Cena docelowa (Target Cost): Z góry uzgadniają Państwo budżet docelowy i ewentualnie mechanizm podziału ryzyka – np. jeśli uda się ukończyć projekt taniej, różnicą się Państwo dzielą, a jeśli drożej, dostawca pokrywa część przekroczenia. Obie strony mają wtedy motywację do efektywnej współpracy.
  
• Dostawy etapowe z bieżącym finansowaniem: Projekt dzieli się na etapy (kamienie milowe, sprinty), a za każdą ukończoną część płacą Państwo z góry uzgodnioną kwotę. Zamawiający inwestuje więc stopniowo i może w każdej chwili wstrzymać projekt, jeśli nie jest zadowolony – straty są ograniczone. Dostawca z kolei ma pewność płatności częściowych i możliwość kontynuowania prac tylko wtedy, gdy dostarcza wysoką jakość.
  

Nie istnieje uniwersalnie najlepszy model – wszystko zależy od charakteru projektu i preferencji. Czasem wybiera się także kombinację, na przykład limit budżetu (cap) w kontrakcie Time & Materials, który uspokaja klienta, że projekt nie przekroczy określonej kwoty, chyba że zostanie dodatkowo zatwierdzone jej podwyższenie. Ważne jest, aby Państwo jako zamawiający mieli wgląd w wydatkowanie środków i możliwość reagowania w porę, jeśli rozwój drożeje. Umowa powinna zawierać mechanizmy raportowania wykonanej pracy i bieżącej kontroli budżetu (np. miesięczny raport godzin, prawo do audytu postępów, spotkania budżetowe przy kamieniach milowych).

Prawnicy ARROWS pomogą Państwu wybrać odpowiedni model cenowy i jasno opisać go w umowie, łącznie z elementami ochronnymi, takimi jak limity cenowe czy kwoty zatrzymane. Dzięki temu unikną Państwo późniejszej nieprzyjemnej niespodzianki na fakturze.

Gdy dojdzie do sporu: postępowanie sądowe i alternatywne metody rozwiązywania konfliktów

Mimo wszelkich działań prewencyjnych czasem może dojść do sporu między Państwem a dostawcą. Środowisko agile jest złożone i mogą pojawiać się odmienne interpretacje umowy czy oczekiwań. Jeśli nieporozumienia przerodzą się w otwarty konflikt, istnieje kilka sposobów ich rozwiązania – nie zawsze trzeba od razu biec do sądu. W rzeczywistości droga sądowa jest raczej ostatecznością. Najpierw warto spróbować porozumienia; jeśli to nie jest możliwe, proszę rozważyć poniższe warianty. Prawnicy ARROWS zawsze zalecają klientom ocenę, która metoda rozwiązania sporu jest w danej sytuacji najszybsza i najskuteczniejsza.

• Mediacja: Pozasądowe rozwiązanie z pomocą neutralnego mediatora. Strony siadają do stołu negocjacyjnego i przy wsparciu mediatora poszukują polubownego rozwiązania. Zaletą mediacji jest szybkość, niższe koszty i poufność – nic nie odbywa się publicznie. Ponadto można zachować relacje biznesowe; często po udanej mediacji firmy kontynuują współpracę.

Mediacja sprawdza się zwłaszcza w przypadku nieporozumień dotyczących umowy, jakości dostawy lub obowiązków płatniczych. Prawnicy ARROWS mogą występować jako Państwa pełnomocnicy w mediacji – doradzą strategię i dopilnują, aby proponowane porozumienie chroniło Państwa interesy.

• Arbitraż (postępowanie arbitrażowe): Bardziej sformalizowana procedura, w której sporu nie rozstrzyga sąd, lecz arbiter (lub zespół orzekający) na podstawie zapisu na sąd polubowny zawartego w umowie. Arbitraż jest szybszy niż postępowanie sądowe, niejawny, a Państwo mogą wybrać arbitra, który rozumie problematykę IT. Orzeczenie arbitra jest przy tym prawnie wiążące i wykonalne podobnie jak wyrok.

Arbitraż wybiera się często w bardziej złożonych sporach technologicznych, w których atutem jest fachowość arbitra. Prawnicy ARROWS pomogą Państwu już przy zawieraniu umowy wynegocjować uczciwy zapis na sąd polubowny, a w razie sporu profesjonalnie będą Państwa reprezentować przed arbitrem.

• Postępowanie sądowe: Klasyczna droga powództwa przed sądem to ostatnia instancja, jeśli zawiodą porozumienia i szybsze metody. Wadą są dłuższe terminy (postępowania sądowe mogą ciągnąć się latami), wyższe koszty oraz jawność postępowania (spór może przedostać się do opinii publicznej, co nie jest idealne dla wizerunku firmy). Z drugiej strony tylko sąd może wydać prawomocny wyrok, którym np. zmusi drugą stronę do wykonania obowiązków, jeśli wszystkie inne możliwości zawiodły.

Czasem już sama groźba skierowania sprawy do sądu skłania niepłacącego kontrahenta lub nieuczciwego dostawcę do działania. Prawnicy ARROWS mają bogate doświadczenie także w sporach sądowych z obszaru IT – jeśli proces okaże się konieczny, zapewnią Państwu kompleksową reprezentację i ochronę Państwa praw przed sądem.

Prewencja to podstawa: praktyczne wskazówki dla zamawiających rozwój agile

Najlepszym sposobem rozwiązania sporu jest niedopuszczenie do niego. Oto kilka praktycznych zaleceń, jak zminimalizować ryzyka, zanim problem się pojawi. Zalecenia te wynikają z doświadczeń prawników ARROWS, którzy od dawna śledzą obszar rozwoju agile:

• Proszę zaangażować prawnika od początku projektu: Nie należy traktować nadzoru prawnego jako czegoś, czym zajmuje się „dopiero, gdy będzie źle”. Prewencja jest zawsze tańsza niż rozwiązywanie sporu. Ekspert w dziedzinie prawa IT pomoże Państwu ustawić umowę w duchu agile – uwzględni specyficzne pojęcia (sprint, backlog, user story itp.), ureguluje procedurę zmian i zapewni możliwość zakończenia współpracy w razie niezadowolenia.

Na przykład do umowy można wprowadzić klauzulę o wypowiedzeniu „for convenience” po zakończeniu każdej fazy, co daje Państwu możliwość wycofania się z projektu, jeśli rozwijałby się źle. Prawnicy ARROWS znają sprawdzone wzory umów agile i dopilnują, aby kontrakt spełniał wszystkie wymogi prawne.

• Nacisk na komunikację i współpracę: Rozwój agile opiera się na ścisłej komunikacji między Państwem (zamawiającym) a dostawcą. Proszę korzystać z regularnych spotkań (stand-upy, sprint review itp.) i nalegać, aby kluczowe decyzje były potwierdzane na piśmie (np. podsumowaniem w e-mailu lub protokołem). To nie jest dodatkowa biurokracja, lecz zapewnienie dowodów – gdy później dojdzie do sporu, jasna komunikacja i protokoły zapobiegną przepychankom typu „kto co powiedział, a czego nie obiecał”.

Proszę budować z dostawcą relację partnerską, ale zachować też zdrowe mechanizmy kontrolne. Prawnicy ARROWS często radzą klientom, aby w większych projektach powołali tzw. komitet sterujący lub organizowali regularne spotkania statusowe kierownictwa – także takie postanowienia można zawrzeć w umowie, aby druga strona była zobowiązana do spotkań i bieżącego rozwiązywania ewentualnych problemów.

• Procesy wewnętrzne i dokumentacja: Choć Manifest Agile głosi „działające oprogramowanie ponad obszerną dokumentację”, z punktu widzenia prawa pewnej dokumentacji Państwo potrzebują. Proszę upewnić się, że mają Państwo wewnętrznie ustawione wersjonowanie wymagań, archiwizację kodu źródłowego oraz kopie zapasowe komunikacji z dostawcą. Każdą zmianę założeń należy potwierdzić. Proszę stworzyć ścieżkę audytu – w przyszłości może okazać się przydatne wykazanie, na co się Państwo umówili.

W obszarach wrażliwych (bezpieczeństwo, architektura) można śmiało żądać formalnego zatwierdzenia dokumentu także w trybie agile. Nowoczesne narzędzia, takie jak Jira czy Confluence, mogą służyć jako żywa dokumentacja – przy właściwym użytkowaniu wszystko, co istotne, jest odnotowane. Prawnicy ARROWS mogą pomóc Państwu ustalić wewnętrzne standardy dokumentacji tak, aby nie były nadmiernie biurokratyczne, a jednocześnie zapewniały wystarczające dowody i przejrzystość na wypadek ewentualnego sporu.

Podsumowanie: z innowacjami agile ostrożnie, ale bez obaw

Rozwój oprogramowania w modelu agile może przynieść Państwa firmie ogromne korzyści – szybsze wprowadzenie produktu na rynek, wyższą wartość dla klienta i zdolność elastycznego reagowania na zmiany. Jednocześnie jednak nie wolno lekceważyć strony prawnej. Jak pokazaliśmy, niejasne umowy, nieuregulowane prawa lub obowiązki oraz bagatelizowanie ryzyk prawnych mogą prowadzić do wzrostu kosztów projektu, utraty inwestycji i długotrwałych sporów. Prewencja i właściwe ustalenie zasad są w środowisku agile absolutnie kluczowe.

Główna myśl brzmi: zwinność i pewność prawna wzajemnie się nie wykluczają. Dzięki odpowiednio skonstruowanej umowie i przestrzeganiu powyższych zasad mogą Państwo czerpać korzyści z rozwoju agile bez obaw, że zaskoczy Państwa wezwanie do sądu czy nieprzyjemny spór. Prawnicy ARROWS mają bogate doświadczenie w rozwiązywaniu sporów wynikających z projektów agile, a także w zapobieganiu im. Chętnie zapewnią Państwu wsparcie – czy to przy przygotowaniu umowy, konsultacjach w trakcie projektu, czy reprezentacji w sporze.

Nie pozwólcie, aby niepewność prawna zagroziła Państwa innowacjom. Jeśli rozwijają Państwo oprogramowanie w modelu agile (lub to planują) i nie są pewni, czy wszystko jest należycie zabezpieczone, prosimy o kontakt z ARROWS. Omówimy Państwa sytuację, zweryfikujemy umowy lub przygotujemy nowe i zadbamy o to, aby rozwój nie przysparzał Państwu problemów od strony prawnej. Dzięki współpracy z nami mogą Państwo spokojnie korzystać z podejścia agile, minimalizować ryzyka i w pełni skoncentrować się na rozwoju swojego biznesu. Troski związane z pułapkami prawnymi proszę zostawić nam – zespół kancelarii adwokackiej ARROWS jest po to, aby Państwa projekty przebiegały sprawnie i bez sądowych przepychanek.

Ponad 2000 klientów już nam zaufało, a my zostaliśmy wyróżnieni tytułem Kancelarii Prawnej Roku 2024. Prosimy do nich dołączyć – jesteśmy gotowi pomóc także Państwu na drodze do sukcesu w modelu agile!