Czy multidyscyplinarne zespoły to przyszłość legislacji?

Czy multidyscyplinarne zespoły to przyszłość legislacji?

Autor: Patryk Ciurak

Trudno wskazać branżę, z którą prawo „zacieśniło” swoje relacje bardziej niż w przypadku IT. Kolejne akty normatywne wpływają istotnie na funkcjonowanie systemów informatycznych; wystarczy wspomnieć wymogi privacy by design i privacy by default zawarte w GDPR, czy projektowane rozporządzenie dotyczące funkcjonowania AI. Jednak relacja ta jest dwustronna; współczesna kancelaria nie obejdzie się bez wachlarza rozwiązań informatycznych, a prawodawca stara się nadążyć za zmianami, które zachodzą dzięki informatyzacji. Również metody pracy nad skomplikowanymi zespołami reguł (jak w drastycznym uproszczeniu można określić oprogramowanie) inspirują prawników do poszukiwania nowych sposobów tworzenia prawa. Rezultat działań ma lepiej odpowiadać potrzebom cyfrowej rzeczywistości XXI w., nadawać się do łatwego zaimplementowania w postaci kodu komputerowego i uwzględniać zróżnicowane punkty widzenia prezentowane także przez nie-prawników. Stąd też wzrost zainteresowania wykorzystaniem metodyk zwinnych w legislacji i pracy w multidyscyplinarnych zespołach.

 

Do najważniejszych cech metodyk zwinnych stosowanych przy wytwarzaniu oprogramowania (np. Scrum, Kanban czy XP)[1] można zaliczyć m.in. działanie iteracyjne (oparte na cyklach czy też pętlach i zakładające stopniowe udoskonalanie produktu aż do osiągnięcia zamierzonego celu) oraz inkrementacyjne (polegające na stopniowym oddawaniu kolejnych, działających części produktu).[2] Co istotne, działania w metodykach zwinnych podejmowane są nie przez pojedynczych specjalistów, ale przez zespół osób, który w założeniu jest międzyfunkcjonalny (ang. cross-functional)[3] czy wręcz multidyscyplinarny. Biorąc pod uwagę różnorodność zagadnień, które należy wziąć pod uwagę projektując współczesne prawo, jego stałe przenikanie się z informatyką a także wskazanie, by skoncentrowane było na użytkowniku końcowym (tzw. user-centric design) oraz nadawało się do łatwego zaimplementowania w systemach informatycznych, czerpanie pełnymi garściami z metodyk zwinnych w celu usprawnienia legislacji jest w pełni uzasadnione. Podejście takie reprezentowały m.in. zespoły uczestniczące w eksperymentach przeprowadzonych w Nowej Zelandii. Ich celem było zapisanie fragmentów istniejącego aktów normatywnych w postaci kodu komputerowego (co określane jest najczęściej jako machine-consumable legislation lub też Rules-as-Code).[4] Korzyści z wykorzystania metodyk zwinnych oraz pracy multidyscyplinarnych zespołów nad projektowaniem prawa nadającego się do odwzorowania w postaci kodu komputerowego (digital-ready) badane są również w ramach Programu ISA2 prowadzonego pod egidą Komisji Europejskiej.[5]

Opierając się na metodyce Scrum,[6] można zaproponować, by „rdzeń” zespołu projektującego prawo digital-ready czy wręcz machine-consumable powinni stanowić:

  • prawnik posiadający praktykę w obszarze prawa, do którego zaliczają się tworzone regulacje,
  • developer (lub developerzy) oprogramowania odpowiedzialny za powstanie kodu,
  • osoba formułująca zadania dla zespołu na podstawie informacji otrzymanych od podmiotów zewnętrznych oraz koordynująca prace zespołu (więcej o tej roli niżej)

Wskazane jest, by w prace zespołu zaangażowane byli również:

  • prawnik, najlepiej legislator, który będzie wspierał działania od strony zastosowania zasad techniki legislacyjnej,
  • osoba odpowiedzialnej za kształtowanie i badanie doświadczenia (tzw. user experience) adresata norm (użytkownika końcowego),
  • przedstawiciel grupy społecznej będącej adresatem regulacji,
  • przedstawiciel organu publicznego, który będzie stosował projektowane prawo,
  • osoba odpowiedzialna za przygotowanie i koordynację testów powstałego kodu.

Dodatkowo, w zależności od bieżących zadań, w prace zespołu powinni włączać się inni eksperci dziedzinowi, przez co rozumieć należy np. księgowych czy doradców podatkowych.

Współcześnie w polskim procesie legislacyjnym również prowadzone są konsultacje i uzgodnienia z różnymi grupami społecznymi; najczęściej jednak przyjmują postać zgłaszania w formie pisemnej opinii i stanowisk. Cały proces ma też więcej wspólnego z podejściem kaskadowym (gdzie prace odbywają się liniowo, rozpoczynając od fazy analizy problemu a na fazie wdrożenia kończąc) niż zwinnym. W przytoczonym wyżej modelu ściśle współpracują adresaci projektowanych norm, przedstawiciele organów stosujących prawo i osoby odpowiedzialne za wytwarzanie oprogramowania. Prowadzi to do lepszego zrozumienia potrzeb, celów, definicji, przebiegu procesu i możliwych zagrożeń. Podobne wnioski płyną z prac prowadzonych w Nowej Zelandii. W skład zespołów wchodzili m.in. urzędnicy, legislatorzy, osoby odpowiedzialne za projektowanie usług dla obywateli, analitycy, developerzy oprogramowania oraz doradcy biznesowi.[7] Szczególnie dużo korzyści przynosi włączenie w prace całego zespołu developerów oprogramowania, którzy – poza stworzeniem kodu – analizują logikę i jakość projektowanych regulacji. Dzięki temu możliwe jest szybkie zidentyfikowanie rozbieżności między przepisami, kodem oraz procesami (np. usługami dla obywateli).[8] Wskazano również, że najsprawniej działają niewielkie zespoły,[9] co skutkuje oszczędnością czasu zużywanego na komunikację.[10] Należy jednak założyć istnienie krótkiego okresu na początku prac w celu dopracowania komunikacji między członkami zespołu i ujednolicenie rozumienia wykorzystywanych definicji. Dlatego też kluczowym krokiem było rozpoczęcie działań od stworzenia modeli pojęciowych, a dopiero potem praca nad brzmieniem konkretnych przepisów.[11]

Szczególną uwagę należy poświęcić osobie, której zadaniem będzie koordynacja prac zespołu. W literaturze problem z komunikacją między prawnikami a programistami uchodzi za jeden z najbardziej znaczących.[12] W celu przezwyciężenia tej niedogodności S. Scherbak sygnalizuje potrzebę nowego rodzaju specjalisty: legal programming expert, który będzie biegle posługiwał się wiedzą i umiejętnościami zarówno z dziedziny prawa jak i tworzenia oprogramowania. Dzięki temu będzie w stanie (samodzielnie lub przy wsparciu prawnika lub programisty) tworzyć przepisy, interpretować je i wreszcie zapisywać je w postaci kodu komputerowego.[13]

Przedstawiona wizja rodzi pewne wątpliwości. Trudno wyobrazić sobie sytuację, w której jedna osoba osiągnie taki poziom wiedzy i doświadczenia z zakresu prawa i programowania, by bez problemu zastąpić czynnego zawodowo prawnika lub programistę.[14] Konsekwencją powyższego będzie też wyeliminowanie z procesu tworzenia prawa dyskusji nad planowanymi rozwiązaniami. Niemniej problemy w komunikacji mogą stanowić istotne utrudnienie przy tworzeniu prawa nadającego się do bezpośredniego zaimplementowania w postaci kodu. Możliwym środkiem zaradczym jest wprowadzenie osoby stanowiącej „pomost” między światem IT i prawa.

W tym miejscu ponownie można odwołać się do metodyki Scrum, w ramach której funkcjonuje rola „mistrza młyna” (ang. scrum master). Osoby pełniące tę rolę odpowiedzialne są przede wszystkim za usprawnianie komunikacji w zespole (np. poprzez uwspólnienie rozumienia celów, pojęć i definicji), doradzanie (ale nie kierowanie) w zakresie organizacji pracy, sugerowanie możliwych rozwiązań w przypadku napotkania przez zespół przeszkód we współpracy oraz przygotowanie i prowadzenie spotkań.[15] Jak łatwo zauważyć, przedstawiony zakres obowiązków odpowiada wprost na problem, który sygnalizuje S. Shcherbak.

Analogicznie można więc założyć funkcjonowanie w zespole pracującym nad nowymi regulacjami legal scrum master, czyli osoby posiadającej wiedzę z zakresu prawa oraz programowania, która jest łącznikiem pomiędzy wszystkimi członkami zespołu i wspomaga (a niekiedy umożliwia) komunikację między nimi. Czyni to poprzez gromadzenie i udostępnianie informacji na temat celu, jaki mają osiągnąć projektowane regulacje oraz dba o jednakowe rozumienie definicji, zakresu działań oraz procesów wśród wszystkich członków zespołu. Oprócz tego dokonuje wszystkich innych czynności, które podejmuje „typowy” scrum master, a ponadto formułuje zadania do realizacji przez członków zespołu i odpowiada za komunikację z zewnętrznymi interesariuszami.[16] Legal scrum master nie powinien jednak wyręczać w pracy prawnika ani programisty. Skoro w skład zespołu mają wchodzić eksperci w swoich dziedzinach, należy im umożliwić niezakłóconą pracę oraz efektywną wymianę informacji (a niekiedy wręcz ją prowokować). Stąd zaliczenie tej roli do „rdzenia” zespołu pracującego nad nowymi regulacjami.

Te same korzyści, które metodyki zwinne wniosły do tworzenia oprogramowania, są potrzebne w procesie stanowienia prawa. Poprawa komunikacji w całym procesie, obejmująca potrzeby, problemy, wspólne rozumienie pojęć i planowanie rozwiązań mogą doprowadzić do stworzenia prawa lepiej dostosowanego do „cyfrowej” rzeczywistości, neutralnego technologicznie i wymagającego mniejszej liczby nowelizacji. Rezultatem może być większe poczucie bezpieczeństwa adresatów norm, ale także ograniczenie ilości potrzebnych prac legislacyjnych, a co za tym idzie – redukcja kosztów po stronie administracji publicznej. Wprowadzenie opisanych zmian wiąże się jednak ze znaczącą przebudową istniejącego procesu legislacyjnego. Z tego powodu powinny być one poprzedzone pogłębionymi analizami tak pod względem funkcjonalnym jak i zgodności z obowiązującym prawem.

Autor: Patryk Ciurak

 

 

Artykuł został napisany przez współautora książki Legal tech. Czyli jak bezpiecznie korzystać z narzędzi informatycznych w organizacji, w tym w kancelarii oraz dziale prawnym i jest rozszerzeniem treści w niej zawartych.

Kup książkę i zapoznaj się z pełną treścią publikacji >>

 

 

 

 

 

 


[1] Zasady zwinnego tworzenia oprogramowania określa Manifest programowania zwinnego dostępny pod adresem https://agilemanifesto.org/iso/pl/manifesto.html (dostęp: 4.02.2021 r.). Istnieją również inne metodyki tworzenia oprogramowania, jednak popularnością zdecydowanie ustępują metodykom zwinnym.

[2] Różnice pomiędzy podejściem iteracyjnym a inkrementacyjnym bardzo dobrze opisał Jacek Wieczorek w artykule „Podejście iteracyjne oraz przyrostowe” (https://agile247.pl/podejscie-iteracyjne-oraz-przyrostowe/, dostęp: 9.05.2021 r.)

[3] Por. (Schwaber i Sutherland, 2020)

[4] Efekty prac omówiono w publikacjach: (The Service Innovation Lab (LabPlus), 2018) oraz (Accident Compensation Better Rules Discovery Team, 2019).

[5] Por. Takeaways from the workshop on Key enablers of digital-ready policymaking: multidisciplinary teams & tools, https://joinup.ec.europa.eu/sites/default/files/news/2021-04/Key%20enablers%20of%20digital-ready%20policymaking_Key%20takeaways_VF.pdf, dostęp: 9.05.2021 r.)

[6] Prace toczące się w Nowej Zelandii także zorganizowano zgodnie z metodyką Scrum (Accident Compensation Better Rules Discovery Team, 2019, str. 14).

[7] (The Service Innovation Lab (LabPlus), 2018, str. 9), (Accident Compensation Better Rules Discovery Team, 2019, str. 28)

[8] (Accident Compensation Better Rules Discovery Team, 2019, str. 6)

[9] (Accident Compensation Better Rules Discovery Team, 2019, strony 6, 28)

[10] (Accident Compensation Better Rules Discovery Team, 2019, str. 7)

[11] (Accident Compensation Better Rules Discovery Team, 2019, str. 6)

[12] S. Shcherbak określa go jako The Babel Problem nawiązując do biblijnej historii pomieszania języków. (Shcherbak, 2014, str. 9)

[13] (Shcherbak, 2014, str. 12)

[14] Podobnie jak oprogramowania dla np. księgowych, doradców podatkowych czy choćby lekarzy nie tworzą programiści specjalizujący się w tych dziedzinach.

[15] Powyższe zestawienie jest skrótowe i uproszczone. Osoby zainteresowane poszerzeniem swojej wiedzy znajdą szereg publikacji w Internecie poświęconych roli Scrum Mastera. Jednym z bogatszych zasobów jest strona https://www.scrum.org/pathway/scrum-master/.

[16] Działania te w metodyce Scrum charakterystyczne są dla roli właściciela produktu (ang. product owner), a powierzenie ich „mistrzowi młyna” może być uznane za patologię organizacyjną. W omawianej sytuacji nie ma jednak jednego, konkretnego produktu, który miałby być rozwijany na przestrzeni kilku czy kilkunastu lat i nad którym opiekę sprawowałby konkretny właściciel produktu. Stąd pomysł na przekazanie tych kompetencji w ręce „mistrza młyna”.

Bibliografia

  • Accident Compensation Better Rules Discovery Team. (2019, 1 lipca). Exploring Machine Consumable Accident Compensation Legislation. Lessons for a structural rewrite of the AC Act and opportunities to make it machine consumable. Pobrano 30.01.2021 r. z lokalizacji The Service Innovation Lab: https://serviceinnovationlab.github.io/assets/Exploring_Machine_Consumable_Code_With_ACC.pdf
  • Schwaber, K. i Sutherland, J. (2020). The 2020 Scrum Guide(TM). Pobrano 5.02.2021 r. z lokalizacji Scrum Guides: https://www.scrumguides.org/scrum-guide.html
  • Shcherbak, S. (2014, 14 września). Integrating Computer Science into Legal Discipline: The Rise of Legal Programming. doi:http://dx.doi.org/10.2139/ssrn.2496094
  • The Service Innovation Lab (LabPlus). (2018, Marzec). Better Rules for Goverment Discovery Report. Pobrano 31.01.2021 r. z lokalizacji NZ Digital Goverment: https://www.digital.govt.nz/dmsdocument/95-better-rules-for-government-discovery-report/html#summary,

 

Długość okresu testowego dostosowana do potrzeb Twojej kancelarii

W polu numeru telefonu należy stosować wyłącznie cyfry (min. 9).

W polu numeru NIP należy stosować wyłącznie cyfry (min. 10).

Wyślij
Okres testowy jest bezpłatny. Oferta kierowana jest do kancelarii prawnych, firm, instytucji i nie jest dostępna dla osób fizycznych.

Administratorem danych osobowych jest Wydawnictwo C.H.Beck sp. z o.o., Warszawa, ul. Bonifraterska 17, kontakt: daneosobowe[at]beck.pl. Dane przetwarzamy w celu marketingu własnych produktów i usług, w celach wskazanych w treści zgód, jeśli były wyrażane, w celu realizacji obowiązków prawnych, oraz w celach statystycznych. W sytuacjach przewidzianych prawem, przysługują Ci prawa do: dostępu do swoich danych, otrzymania ich kopii, sprostowania, usunięcia, ograniczenia przetwarzania, przenoszenia, cofnięcia zgody oraz wniesienia sprzeciwu wobec przetwarzania danych. Pełne informacje w Polityce prywatności.