Czym jest prawo dotyczące odejścia członka zespołu projektowego od rozwoju systemu?

W projektach rozwoju systemów zwykle kładzie się nacisk na szczegółowe podział na etapy i zadania, aby jak najbardziej planowo prowadzić pracę. Jednakże, bez względu na to, jak bardzo skupiamy się na planowaniu, nie da się uniknąć niespodziewanych problemów związanych z “ludźmi”. Szczególnie ryzyko niespodziewanej choroby lub odejścia członka zespołu projektowego jest trudne do całkowitego zabezpieczenia, bez względu na to, jak bardzo staramy się to zrobić. W tym artykule omówimy, jak prawo wpływa na kwestię odejścia członków zespołu projektowego.

Wycofanie członka zespołu jako aspekt obowiązków zarządzania projektem

Na wstępie należy zauważyć, że w projektach rozwoju systemów, dostawca jest zobowiązany do zapewnienia sprawnego przebiegu projektu. Dostawca ma obowiązek szacować potrzebne zasoby, czas, budżet i nakład pracy, a także prosić o odpowiednią współpracę od użytkownika, aby zarządzać postępem projektu. Te obowiązki są nazywane “obowiązkami zarządzania projektem” i ich istnienie zostało wielokrotnie podkreślone w poprzednich wyrokach sądowych.

https://monolith.law/corporate/project-management-duties[ja]

Nagłe odejście członka zespołu z dostawcy można uznać za jeden z problemów związanych z obowiązkami zarządzania projektem po stronie dostawcy.

• Nadmierna praca w nadgodzinach, praca w dni wolne od pracy itp., co prowadzi do problemów zdrowotnych
• Stres psychiczny spowodowany konfliktami interpersonalnymi

Można przewidzieć różne przyczyny nagłego odejścia członka zespołu z projektu. Jednak są to zasadniczo problemy z zarządzaniem pracą po stronie dostawcy. Dlatego nawet jeśli te okoliczności prowadzą do opóźnień w dostawie, prawdopodobieństwo zwolnienia z naruszenia obowiązków jest niskie. Innymi słowy, od dostawcy oczekuje się postawy zarządzania postępem projektu z uwzględnieniem możliwości nagłego pojawienia się takich braków.

Ważne wyroki dotyczące odejścia członka zespołu

Przypadek opóźnienia terminu dostawy spowodowanego odejściem członka zespołu

W cytowanym poniżej przykładzie z orzecznictwa, po nagłym odejściu członka zespołu, postęp projektu nie przebiegał zgodnie z planem, co spowodowało opóźnienie w dostawie. W tym przypadku, osoba odpowiedzialna po stronie użytkownika przyjmowała agresywną postawę wobec osoby odpowiedzialnej po stronie dostawcy, co powodowało dodatkowe obciążenie psychiczne.

Użytkownik, który chciał dochodzić odpowiedzialności za niewykonanie zobowiązań związanych z opóźnieniem w wykonaniu, i dostawca, który chciał dochodzić naruszenia obowiązku współpracy ze strony użytkownika, który przyjmował agresywną i dominującą postawę, znaleźli się w skomplikowanym sporze.

https://monolith.law/corporate/user-obligatory-cooporation[ja]

Jednakże sąd uznał, że różne okoliczności nie zwalniają dostawcy z obowiązku zarządzania projektem i poparł stanowisko użytkownika (podkreślenia i pogrubienia dodane przez autora).

Dostawca twierdzi, że reprezentant użytkownika, poprzez agresywne i dominujące zachowanie, obrażał pracownika dostawcy, co zmusiło go do odejścia od projektu.

Na pewno, reprezentant użytkownika, podczas spotkania w listopadzie 2003 roku (Heisei 15), powiedział w ostrym tonie: “Czy nie masz ochoty pracować“, “To koniec umowy. Gdy opuszczę ten pokój, to koniec.“, ale to wynikało z faktu, że pomimo ustalenia w podstawowej umowie, że okres do października 2003 roku (Heisei 15) był okresem prototypu, dodatkowe funkcje, które były celem tego rozwoju, nie były w ogóle uwzględnione w projekcie definicji wymagań, a nawet gdy odpowiedź na projekt definicji wymagań została zwrócona z komentarzami, nie było odpowiedzi na to, co wynikało z opóźnienia w pracy dostawcy i jego reakcji, i nie można powiedzieć, że to było zachowanie przekraczające granice.

Co więcej, choć przyczyna odejścia C z powodu choroby od pracy związanej z tym kontraktem nie jest pewna, nawet jeśli stres związany z pracą kontraktową był przyczyną, to jest to problem zarządzania pracą po stronie dostawcy, i nie można tego przypisać do użytkownika.

Wyrok Sądu Okręgowego w Tokio z 4 grudnia 2007 roku (Heisei 19)

W powyższym wyroku, po uwzględnieniu faktu, że użytkownik naciskał na dostawcę “w ostrym tonie”, sąd ostatecznie nie zwolnił dostawcy z odpowiedzialności. W tle takiego orzeczenia leży prawdopodobnie przemyślenie, że obarczanie użytkownika, który naciskał “w ostrym tonie”, byłoby niesprawiedliwe, biorąc pod uwagę niewłaściwe zachowanie dostawcy. Sąd przyjął schemat, według którego cały projekt rozwoju systemu jest realizowany dzięki spełnieniu obowiązku zarządzania projektem przez dostawcę i spełnieniu obowiązku współpracy przez użytkownika, i stwierdził, że nie powinno się uznawać naruszenia obowiązku współpracy przez użytkownika. Można przypuszczać, że taka interpretacja jest zawarta w sformułowaniu “nie można powiedzieć, że to było zachowanie przekraczające granice”.

Co można wywnioskować z powyższego wyroku

Ponadto, można wyciągnąć następujące ważne wnioski:

• W przypadku odejścia członka projektu z powodu choroby, jeśli dostawca chce obarczyć użytkownika odpowiedzialnością, dostawca musi udowodnić związek przyczynowy między odejściem a działaniami użytkownika → jednak udowodnienie takiego związku przyczynowego jest zazwyczaj trudne.
• Nawet jeśli dostawca może udowodnić, że obciążenie pracą zwiększyło się z powodu użytkownika i członek zespołu zachorował, zazwyczaj jest to uważane za problem zarządzania pracą po stronie dostawcy → jeśli zwrócimy uwagę na użycie silnego sformułowania “zachowanie przekraczające granice” w wyroku, powinniśmy przypuszczać, że sytuacje, które zwalniają dostawcę z odpowiedzialności za zarządzanie pracą, są dość ograniczone.

Jak przygotować się na ryzyko odejścia członka zespołu

Jak już wspomniano, nawet jeśli nagle pojawi się wakat w zespole, bardzo trudno jest obarczyć tym użytkownika. Może dojść do sytuacji, w której zostaniesz zmuszony do ogromnej ilości dodatkowego rozwoju lub do brutalnych zmian specyfikacji w późniejszym czasie. Jednak dowodzenie związku przyczynowo-skutkowego między problemami zdrowotnymi a obciążeniem pracą nie jest łatwe. Biorąc pod uwagę te okoliczności, ważne jest raczej przygotowanie się na problemy, takie jak chorobowe czy złe samopoczucie członków projektu, i rozwijanie struktury zespołu.

Jeśli sprawa trafi do sądu, jasne jest, że strona dostawcy będzie w bardzo niekorzystnej sytuacji. Dlatego ważne jest raczej podjęcie działań mających na celu zapobieganie takim konfliktom. Możliwe środki mogą obejmować:

Utworzenie struktury, która nie izoluje osoby odpowiedzialnej

Uważa się, że tworzenie struktury, w której wiele osób uczestniczy w spotkaniach, zamiast sytuacji, w której jedna osoba uczestniczy w spotkaniach, może zapobiec sytuacji izolacji psychicznej.

Stosowanie luźnej alokacji personelu

Ważne jest również, aby mieć pewien margines w alokacji personelu. Z pewnością zabezpieczenie personelu z pewnym marginesem prowadzi do wzrostu kosztów. Jednak jeśli weźmiemy pod uwagę koszty odszkodowań za opóźnienia w dostawie i obawy o dalsze odejścia w sytuacji radzenia sobie z takimi problemami, nie jest rzadkością, że bardziej racjonalne jest zabezpieczenie personelu z pewnym marginesem od samego początku.

Przeglądanie alokacji przed pogorszeniem stanu zdrowia

Jeśli jedna osoba odejdzie, obciążenie pracy innych członków zespołu wzrośnie, co może prowadzić do błędnego cyklu generowania kolejnych osób odchodzących. Aby uniknąć takiego błędnego cyklu, ważne jest również przeglądanie alokacji przed poważnym pogorszeniem stanu zdrowia.

Dokładne zarządzanie zmianami i dokumentacją projektu

Choć nie jest łatwe udowodnienie związku przyczynowo-skutkowego między odejściem członka zespołu a naruszeniem obowiązku współpracy ze strony użytkownika, nadal ważne jest dokładne zarządzanie zmianami i dokumentacją. Dlatego, że nawet jeśli nie można udowodnić przyczyny odejścia członka zespołu, jeśli faktycznie istnieje sytuacja nadmiernego obciążenia pracą, która prowadzi do chorobowego, może to zawierać elementy potwierdzające naruszenie obowiązku współpracy ze strony użytkownika. Takie okoliczności mogą stanowić element potwierdzający słuszność takich działań jak kompensata za zaniedbanie, nawet jeśli strona dostawcy zostanie pociągnięta do odpowiedzialności za niewykonanie zobowiązań lub odpowiedzialność za wady w przypadku “zapalenia” projektu.

W poniższym artykule omówiono znaczenie zarządzania dokumentacją w projektach rozwoju systemów.

https://monolith.law/corporate/the-minutes-in-system-development[ja]

Jeśli chodzi o szczegółowe omówienie zmian specyfikacji, poniższy artykuł również omawia to szczegółowo.

https://monolith.law/corporate/howto-manage-change-in-system-development[ja]

Podsumowanie

Powyżej przedstawiliśmy wyjaśnienie prawne zjawiska, jakim jest “odejście członka zespołu”. Dla dostawcy, pociągnięcie użytkownika do odpowiedzialności za odejście członka zespołu jest niewątpliwie bardzo trudne z prawnego punktu widzenia.

Jednakże, nawet mimo takich okoliczności, ważne jest, aby nie mylić się, myśląc, że “w kwestii odejścia członka zespołu, prawo jest bezużyteczne”. Proces myślowy prezentowanego wyroku sądowego sam w sobie kwestionuje, jak określić granicę między “obowiązkiem zarządzania projektem przez dostawcę” a “obowiązkiem współpracy użytkownika”, nie mówiąc już o tym, że środki zapobiegawcze konfliktom są często wynikiem odwróconego procesu myślowego, zaczynając od przewidywanych scenariuszy konfliktów.

Ważne jest, aby nie interpretować “bycia w niekorzystnej pozycji w sądzie” jako “prawo jest bezużyteczne”, ale raczej zrozumieć, że “perspektywa prewencyjna prawa jest ważna”.