MONOLITH LAW OFFICE+81-3-6262-3248Všední dny 10:00-18:00 JST [English Only]

MONOLITH LAW MAGAZINE

IT

Jaké jsou právní aspekty spojené s odchodem členů týmu z projektu na vývoj systému?

IT

Jaké jsou právní aspekty spojené s odchodem členů týmu z projektu na vývoj systému?

V projektech vývoje systémů se obvykle klade důraz na důkladné rozdělení jednotlivých fází a úkolů a na co největší plánovitost. Ale bez ohledu na to, jak moc se zaměříme na plánování, existují náhlé problémy, které nelze předvídat, zejména ty, které souvisí s ‘lidmi’. Rizika, jako je náhlé onemocnění nebo odchod členů projektového týmu, jsou často těžko předvídatelná, bez ohledu na to, jak moc se snažíme je řešit. V tomto článku se budeme zabývat tím, jak se právo týká odchodu členů projektového týmu.

Odchod členů týmu jako součást povinností projektového managementu

Nejprve je třeba zdůraznit, že se v rámci projektů systémového vývoje očekává, že dodavatel bude mít komplexní povinnosti směřující k hladkému průběhu projektu. Dodavatel má povinnost odhadnout potřebný personál, dobu trvání, rozpočet a pracovní náklady pro hladký průběh projektu, vyžádat si od uživatele potřebnou spolupráci a řídit průběh projektu. Tyto povinnosti se nazývají “povinnosti projektového managementu” a jejich existence byla opakovaně poukázána v minulých soudních případech.

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

Náhlý odchod členů týmu na straně dodavatele lze považovat za jeden z problémů povinností projektového managementu dodavatele.

  • Fyzické potíže způsobené přepracováním, jako je nadměrný přesčas a práce o víkendech
  • Psychický stres způsobený neshodami ve vztazích mezi lidmi

Existuje mnoho předpokládaných důvodů pro náhlý odchod členů z projektu. Avšak tyto jsou základně otázkou řízení pracovních sil na straně dodavatele. Proto byste měli mít na paměti, že i kdyby tyto okolnosti vedly k zpoždění dodání, pravděpodobnost osvobození od porušení povinnosti je nízká. Jinými slovy, od dodavatelů se očekává, že budou mít proaktivní přístup k řízení průběhu projektu, a to i v případě náhlého vzniku těchto vakancí.

Důležité precedenty týkající se odchodu členů

Příklady situací, které může přinést odchod členů z projektového vývoje.

Případ, kdy odchod člena týmu způsobil zpoždění dodání

Následující případ z judikatury se týká situace, kdy po náhlém odchodu člena týmu projekt nepokračoval podle plánu a došlo k zpoždění dodání. V tomto případě byl na straně dodavatele vyvíjen tlak ze strany zástupce uživatele, což způsobilo psychickou zátěž.

Mezi uživatelem, který chtěl uplatnit odpovědnost za neplnění závazků v důsledku zpoždění plnění, a dodavatelem, který chtěl uplatnit porušení povinnosti spolupráce ze strany uživatele, který se choval agresivně a autoritativně, došlo k prudkému sporu.

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

Soud však rozhodl, že různé okolnosti neosvobozují dodavatele od jeho povinnosti řídit projekt a podpořil názor uživatele (podtržené a tučné části jsou doplněné autorem).

Dodavatel tvrdí, že zástupce uživatele se k dodavateli choval agresivně a autoritativně, což vedlo k tomu, že se dodavatel nemohl vyhnout odchodu z projektu.

Je pravda, že zástupce uživatele na schůzce v listopadu 2003 (Heisei 15) řekl výrazným tónem “Nemáš chuť to dělat?” a “Co to je, tato smlouva je u konce. Jakmile odejdu z této místnosti, je to konec.” Ale to bylo způsobeno zpožděním práce dodavatele a jeho reakcí na to, že navzdory tomu, že bylo dohodnuto, že říjen 2003 (Heisei 15) je období prototypu v základní dohodě, dodatečné funkce cíle vývoje nebyly vůbec zahrnuty do návrhu specifikace a i když byly přidány komentáře k předloženému návrhu specifikace, nebyla žádná odpověď. To nelze považovat za “překročení hranic”.

Co se týče skutečnosti, že C odstoupil od práce na tomto kontraktu kvůli nemoci, příčina není jasná, ale i kdyby stres z této práce byl příčinou, základním problémem by měla být správa práce na straně dodavatele, a to nelze přičítat na vrub uživatele.

Rozhodnutí tokijského okresního soudu ze dne 4. prosince 2007 (Heisei 19)

V uvedeném případu soud zvážil skutečnost, že zástupce uživatele se k dodavateli choval “výrazným tónem”, ale nakonec neosvobodil dodavatele od odpovědnosti. Za tímto rozhodnutím stojí pravděpodobně skutečnost, že by bylo nespravedlivé svalovat vinu na uživatele, který se k dodavateli choval “výrazným tónem”, pokud by se zvážila špatná reakce dodavatele. Soud přijal schéma, podle kterého se projekt vývoje systému uskutečňuje na základě plnění povinnosti řízení projektu dodavatelem a plnění povinnosti spolupráce uživatelem, a rozhodl, že by se nemělo uznat porušení povinnosti spolupráce ze strany uživatele. Tento význam je pravděpodobně vyjádřen výrazem “to nelze považovat za ‘překročení hranic'”.

Co lze vyčíst z výše uvedeného soudního případu

Mimo jiné můžeme získat následující důležité ponaučení:

  • Při odchodu člena projektu kvůli nemoci, pokud se uvažuje o přičítání viny na stranu uživatele, je požadováno, aby strana dodavatele prokázala kauzální vztah k tomu, že odchod byl způsoben uživatelem → Avšak prokázání existence kauzálního vztahu obvykle není snadné.
  • Dokonce i kdyby se prokázalo, že kvůli vině uživatele došlo k velké pracovní zátěži a člen týmu onemocněl, obvykle se to nakonec považuje za problém řízení pracovních sil na straně dodavatele → Pokud se zaměříme na silnou formulaci “přehnané chování”, která je použita v rozsudku, měli bychom předpokládat, že situace, které by osvobodily dodavatele od odpovědnosti za řízení pracovních sil, jsou velmi omezené.

Jak se připravit na riziko odchodu členů týmu

Jaké opatření lze přijmout k předcházení problémům s odchodem členů projektového týmu?

Jak již bylo uvedeno, i když dojde k náhlému vzniku pracovních míst, je velmi obtížné přičítat to na stranu uživatele. Může se stát, že budete nuceni provést obrovský dodatečný vývoj nebo budete nuceni provést násilné změny specifikací, ale není snadné prokázat příčinnou souvislost mezi fyzickými a psychickými změnami a různými pracovními zátěžemi. S ohledem na tyto okolnosti je důležité pokračovat v přípravě personálního systému na základě předpokladu, že dojde k problémům, jako je nemoc členů projektového týmu nebo špatný zdravotní stav.

Pokud by se tato otázka měla řešit u soudu, je zřejmé, že by se strana dodavatele ocitla v velmi nepříznivé situaci. Proto je důležité spíše přijmout opatření k předcházení takovým sporům. Možná opatření zahrnují následující:

Zajistěte systém, který neizoluje zodpovědné osoby

Je důležité se vyhnout situacím, kdy se zodpovědná osoba účastní schůzky sama, a vytvořit systém, který umožňuje účast na schůzce více osobám, což by mohlo předcházet psychické izolaci.

Snažte se o dostatečné personální nasazení

Je důležité mít dostatek personálu. Je pravda, že zajištění dostatečného personálu může vést ke zvýšení nákladů. Avšak pokud zvážíme náklady na odškodnění za zpoždění dodávky a obavy z dalších odchodů v důsledku řešení takových problémů, může být v některých případech racionálnější zajišťovat personál s určitou rezervou od samého začátku.

Přehodnoťte nasazení před zhoršením zdravotního stavu

Pokud dojde k odchodu jedné osoby, zvýší se pracovní zátěž ostatních členů týmu, což může vést k dalším odchodům a vytvoření negativního cyklu. Aby se tomuto negativnímu cyklu zabránilo, je důležité přehodnotit nasazení před vážným zhoršením zdravotního stavu.

Důkladně provádějte správu změn a dokumentaci projektu

Není snadné prokázat příčinnou souvislost mezi odchodem členů týmu a porušením povinnosti spolupráce na straně uživatele, ale je důležité důkladně provádět správu změn a dokumentaci. To proto, že i když nelze prokázat příčinu odchodu členů týmu, pokud existuje situace s nadměrnou pracovní zátěží, která vede k nemoci zodpovědné osoby, může to obsahovat prvky, které podporují porušení povinnosti spolupráce na straně uživatele. Tyto okolnosti mohou být důkazem pro oprávněnost, jako je kompenzace za nedbalost, i když dojde k situaci, kdy je dodavatel stíhán za nesplnění závazků nebo záruky za vady.

V následujícím článku se zabýváme důležitostí správy dokumentů v projektech vývoje systémů.

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

Pro podrobnější diskusi o změnách specifikací se podívejte na následující článek.

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

Shrnutí

Výše jsme provedli vysvětlení právní teorie spojené s jevem “odchod členů týmu”. Pro dodavatele je obtížné uplatňovat odpovědnost uživatele za odchod členů, a to je nepochybně velmi obtížné z právního hlediska.

Ale i přes takové okolnosti je důležité nespatřovat v problému “odchod členů týmu” nedorozumění, že “právní diskuse je k ničemu”. Samotný proces myšlení uvedených případů se zabývá otázkou, jak stanovit hranice mezi “projektovými manažerskými povinnostmi dodavatele” a “povinností spolupráce uživatele”, natož že opatření pro prevenci sporů jsou často odvozována zpětným výpočtem z předpokládaných scénářů sporů.

Je důležité chápat, že místo toho, aby se “nevýhodné soudní spory” považovaly za “právo je k ničemu”, je naopak důležité “důležitost preventivního právního hlediska”.

Managing Attorney: Toki Kawase

The Editor in Chief: Managing Attorney: Toki Kawase

An expert in IT-related legal affairs in Japan who established MONOLITH LAW OFFICE and serves as its managing attorney. Formerly an IT engineer, he has been involved in the management of IT companies. Served as legal counsel to more than 100 companies, ranging from top-tier organizations to seed-stage Startups.

Category: IT

Tag:

Zpět na začátek