🟠 Dlaczego Manifest Agile może niepokoić prawników?

Manifest Agile przedkłada ludzi i interakcje, działające oprogramowanie oraz współpracę z klientem ponad procesy i narzędzia, szczegółową dokumentację, negocjacje umów a także reagowanie na zmiany ponad realizację założonego planu.

Oczywiście docenia się te elementy wymienione na drugim miejscu jednak bardziej ceni się pierwsze.

Mówi się, że podejście agile samo w sobie stanowi skuteczne narzędzie zarządzania ryzykiem, jednakże przypisywanie mniejszej wagi procesom dokumentacji czy negocjacjom umów może niepokoić prawników, ponieważ są to podstawowe elementy zarządzania ryzykiem prawnym.

 Niniejszy tekst jest o tym jak skutecznie „doceniać” formalną stronę

🟠 Definicja i zarządzanie ryzykiem prawnym

Zarządzanie ryzykiem prawnym to kierowanie i nadzór nad organizacją w kontekście ryzyka prawnego. Według wg ISO 31022 ryzyko prawne to wpływ niepewności na cele w kontekście regulacyjnym, umownym oraz w zakresie pozaumownych praw i obowiązków. Ryzyko prawne być ono konsekwencją zarówno zdarzeń o charakterze prawnym (np. zawarcie umowy) jak i pozaprawnym (np. czyn nieuczciwej konkurencja). Wyróżnia się następujące obszary ryzyka prawnego.

‼️ Ryzyko regulacyjne ma swoje źródło w niezgodności działania z obowiązującymi przepisami, orzeczeniami władz, praktyką czy i wytycznymi organów, a w szczególności:

👉 Ryzyko niezgodnego z prawem celu/przedmiotu umowy bądź poszczególnych jego elementów. Nie jest wykluczone, że zamówiony produkt będzie służył np. obchodzeniu zakazów prawnych bądź wprost je naruszał, w szczególności w branżach regulowanych (np. usług finansowych, monopolu państwa itd.)

👉 Ryzyko niespełnienia przez produkt specyficznych wymagań regulacji prawnych i praktyki rynku np. RODO, ochrona konsumenta, wymagania regulatora rynku, podatki, dobre praktyki branżowe itd.

‼️ Ryzyko umowne odnosi się do sytuacji, w których organizacja nie wywiązuje się ze swoich zobowiązań umownych lub nie egzekwuje swoich praw umownych, lub zawiera umowy na warunkach, które są uciążliwe, nieodpowiednie, nieuczciwe i/lub niemożliwe do wyegzekwowania. Dotyczy to wszystkich umów, ale przede wszystkim samego kontraktu na wykonanie produktu. Kompleksowy opis ryzyk związanych z „umowami agile” wymagałby odrębnego omówienia, więc tutaj zasygnalizowane zostaną tylko niektóre z nich:

👉prawny charakter samej umowy (zlecenie, dzieło, umowa mieszana?)

👉 trudności z precyzyjnym zdefiniowaniem przedmiotu umowy

👉 metody wynagradzania (kosztorysowy, ryczałtowy, mieszany)

👉 terminy wykonania projektu, ocena jego zaawansowania,

👉 sposób i moment zakończenie projektu,

👉 komunikacja i prawidłowe rozumienie wzajemnych oczekiwań,

👉 stałość i dobór właściwego personelu że strony klienta i wykonawcy.

‼️ Ryzyko pozaumowne polega na tym, że organizacja nie zdoła dochodzić swoich praw pozaumownych (np. z tytułu praw własności intelektualnej) lub wynikające z zachowań i decyzji organizacji, które mogą skutkować zachowaniem niezgodnym z prawem lub niedopełnieniem pozaprawnego obowiązku należytej staranności (lub obowiązku cywilnego) wobec osób trzecich, przykładowo:

👉 niespełnienie wymaganych standardów staranności wobec klientów,

👉 czyny nieuczciwej konkurencji (np. kradzież know-how),

👉 naruszenia własności intelektualnej (np. wykorzystanie cudzego prawa)

👉 zmiany personalne w trakcie projektu (np. choroby, konflikty w zespole, odejścia z pracy),

👉 realia rynkowe (np. wzrost wynagrodzeń).

Zarządzanie ryzykiem prawnym w agile wymaga, aby w projekt odpowiednio wpleść w mechanizmy tej metody. Jako podstawę rozważań proponuję przyjąć SCRUM i na jego tle rozważyć możliwość użycia reguł zarządzania ryzykiem prawnym opisanych w ISO 31022. Proces zarządzania ryzykiem ilustruje poniższy rysunek.

Jak widać można podzielić go na dwie główne części: etap identyfikacji ryzyk oraz etap oceny i postępowania z ryzykiem.

‼️ Identyfikacja ryzyk powinna być wpleciona w codzienność SCRUM i mieć odzwierciedlenie we wszystkich jego elementach. Zarządzanie ryzykiem, podobnie jak metodyka agile, ma charakter iteracyjny, więc w tym kontekście stałe poszukiwanie niebezpieczeństw wydaje się całkowicie naturalne. Jak powiedziano wcześniej ryzyko prawne wiąże się ze zdarzeniami zarówno o charakterze prawnym jak i pozaprawnym. Z tego względu poszukiwanie zagrożeń o charakterze prawnym odbywa się równolegle z analizą wszystkich niebezpieczeństw.

Identyfikacja ryzyk powinna uwzględniać kontekst wewnętrzny (np. kapitał ludzki, sprawy organizacyjne, sytuację finansową jednostki, oczekiwania właściciela) oraz zewnętrzny (np. działania konkurencji, zmiany prawa, sytuację rynkową) w jakim działa organizacja i realizowany jest projekt.

Cel produktu opisany w Backlogu ma kluczowe znaczenie dla organizacji prac. Jest on również punktem odniesienia przy identyfikacji ryzyk. Główną rolę w tym obszarze powinien pełnić Product Owner, który w porozumieniu z doradcą prawnym oraz przy udziale Klienta, Scrum Mastera, zespołu deweloperskiego i interesariuszy ma obowiązek poszukiwać zagrożeń. Nie oznacza to jednak, że w ramach projektu nie mogą równolegle być realizowane inne cele, niesprzeczne z głównym zamierzeniem np. dotyczące ograniczenia kosztów, utrzymania niezmiennego składu zespołu, rozwoju kompetencji itd. Jeśli tak jest, to należy również poszukiwać okoliczności zagrażających ich realizacji.

Również elementy składające się na Zobowiązanie (Commitment) takie jak Cel Sprintu oraz Definition of Done dają dobrą okazję do poszukiwania potencjalnych ryzyk. Zwłaszcza ten drugi element powinien być szczegółowo analizowany i konfrontowany z zapisami umowy. Inną sposobnością do wspólnego poszukiwania niebezpieczeństw jest Sprint Review, na które zapraszani są interesariusze, w tym doradca prawny. Zidentyfikowane ryzyka powinny być umieszczane Backlogu Produktu (Product Backlog).

🟠 Ocena i postępowania z ryzykiem.

Ocena ryzyk następuje za pomocą oszacowanego prawdopodobieństwa jego wystąpienia oraz możliwych konsekwencji dla realizacji Celu Produktu. Wybór postępowania z ryzykiem to wachlarz możliwości – od zaakceptowania, przez zmianę prawdopodobieństwa, likwidację przyczyny, transfer na inny podmiot aż do zaniechania projektu (jeśli nie da się osiągnąć jego celu). Powyższe jest rolą Product Ownera we współpracy z doradcą prawnym, interesariuszami i zarządem spółki (jeśli PO nie w nim nie zasiada). Niebezpieczeństwa powinny być odzwierciedlone w Backlogu Produktu, uszeregowane wedle ich prawdopodobieństwa i wpływu na realizację Celu Produktu i aktualizowane w ramach Doskonalenia Backlogu Produktu (Product Backlog Refinement).

🟠 Podsumowując – wprowadzenie systemu zarządzania ryzykiem, w szczególności ryzykiem prawnym opartego na ISO 31000 i 31022 w agile wydaje się działaniem stosunkowo prostym a jednocześnie pożytecznym.