Jaké jsou právní aspekty 'hoření' projektů na vývoj systémů?

Projekt vývoje systému není něco, co lze dosáhnout přes noc, ale vyžaduje mnoho zdrojů, jako je velké množství lidí a organizací, obrovské množství peněz a dlouhé období vývoje. V tomto článku vysvětlíme, jak lze fenomén “hoření” projektu při vývoji systému uspořádat v rámci právního rámce, a shrneme také směrnice pro řešení.

Proč projekty “hoří”

Jednotlivý IT systém, i když není zvlášť velkým projektem, správně funguje až po hromadění velkého množství vytvořených programových souborů a zdrojových kódů. Často je mnohem detailnější a preciznější, než by si kdokoli mohl představit z pohledu ovládání na obrazovce (nebo spíše, čím jednodušší a stručnější je ovládání IT systému z pohledu obrazovky).

• Termín dodání je stanoven předem, zatímco specifikace a požadavky zůstávají nejasné, jak čas plyne
• Členové týmu jsou příliš zaměstnáni otázkami interní politiky a mnoho z nich vypadne kvůli stresu z mezilidských vztahů
• Chybí vyjednávací schopnosti na úrovni managementu, včetně projektového manažera, a členům týmu nejsou požadovány adekvátní zprávy, komunikace a konzultace

Důvody pro “hoření” projektů se mohou lišit od projektu k projektu. Avšak z právního hlediska lze důvody pro “hoření” projektů relativně jednoduše uspořádat do několika typů.

Typ ohně 1: Případ, kdy projekt selže uprostřed

V průběhu vývoje systému je typickým důvodem pro jeho selhání uprostřed nedostatečná komunikace mezi uživateli a dodavateli. Samotný projekt vývoje systému vyžaduje nejen odborné technické a organizační schopnosti dodavatele, ale také spolupráci uživatelů, kteří budou systém nakonec používat.

Pokud je tedy v jednom projektu nejasné, jakou roli každý z účastníků hraje, a projekt pokračuje v této nejistotě, může dojít k vzniku jakéhosi “přehazování povinností” a tím k narušení hladkého průběhu projektu. Pro právní úvahy o povinnostech uživatelů a dodavatelů se prosím podívejte na následující články.

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

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

Podrobnosti o povinnostech každé strany naleznete v uvedených článcích, ale klíčovým bodem zde je, že v rámci jednoho projektu vývoje systému mají uživatelé i dodavatelé určité povinnosti. Hrubě řečeno, uživatelé mají povinnost spolupracovat na definování požadavků, návrhu vzhledu obrazovky atd. (tj. základní návrh) a přijetí systému, což je potvrzeno v minulých rozhodnutích a soudních případech.

Na druhé straně, dodavatelé mají také povinnost, po získání spolupráce uživatelů v uvedených oblastech (a zároveň po vynaložení úsilí na komunikaci o takové spolupráci), zajistit hladký průběh projektu a odstranit překážky jeho průběhu.

Na základě tohoto přístupu, soudy ukazují postoj, který se snaží spravedlivě řešit všechny konflikty, ukazují povinnost uživatelů řídit interní systémy a povinnost dodavatelů prokázat svou odbornost a technické dovednosti jako externí odborníci.

Typickou situací, kdy je pravděpodobné, že dojde k “selhání”, je přijetí systému. Podrobnosti o přijetí jsou vysvětleny v následujícím článku.

https://monolith.law/corporate/estimated-inspection-of-system-development[ja]

V takových případech, jakmile dojde ke konfliktu, důležitou roli hrají objektivně ověřitelné důkazy, jako je vývoj minulých projektů a obsah jednání. Proto zde často hraje velkou roli dokumentace, která byla předem zaznamenána. Pro zachování vaší pozice je důležité důkladné vedení dokumentace. Podrobný výklad z hlediska důležitosti správy dokumentů v rámci vývoje systému naleznete v následujícím článku.

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

Typ ohně 2: Případ zrušení z důvodu uživatele

Je také možné, že projekt bude uprostřed zastaven na žádost uživatele. Například, pokud jste začali vytvářet IT systém pro řízení lidských zdrojů včetně zahraničních poboček a strategie expanze do zahraničí byla stáhnuta, vývoj tohoto systému se může stát zbytečným i pro uživatele.

Problém, jak by měl být IT systém používaný v podniku postaven, je nerozlučně spojen s otázkou, jaké obchodní operace existují v dané společnosti. Proto je možné, že se požadavky na systém, který se stane potřebným (nebo nepotřebným) v důsledku zásadních změn v organizační struktuře nebo revize strategie, změní po skutečnosti.

V důsledku těchto okolností mohou vzniknout různé právní problémy, pokud je projekt přerušen uprostřed. V takovém případě, obvykle, vzhledem k tomu, že je to z důvodu uživatele, je dodavateli uznáno určité právní právo, jako je například požadavek na odměnu v závislosti na stupni dokončení. Obsah těchto práv se liší v závislosti na typu smlouvy, ale může být shrnut následovně:

・V případě smlouvy o dílo: Občanský zákoník (Japonský Občanský zákoník) článek 641
Občanský zákoník článek 641
→ Dokud dodavatel nedokončí práci, může objednatel kdykoli odstoupit od smlouvy s náhradou škody.
・V případě smlouvy o zastoupení: Občanský zákoník článek 648 odstavec 3 (v závislosti na okolnostech, také náhrada škody podle Občanského zákoníku článek 651)
Občanský zákoník článek 648
→ Pokud zastoupení skončí uprostřed plnění z důvodu, který nelze přičíst zástupci, může zástupce požadovat odměnu v závislosti na stupni již provedeného plnění.
Občanský zákoník článek 651
→ 1. Zastoupení může kdykoli zrušit každá strana.
→ 2. Pokud jedna strana zruší zastoupení v nepříznivém okamžiku pro druhou stranu, musí tato strana nahradit škodu druhé straně. Toto však neplatí, pokud existuje neodkladný důvod.

Shrnutí

Jednotlivé projekty vývoje systémů se mohou vyvíjet různými a mnohdy komplikovanými způsoby. Nicméně, pokud se dostaneme k tématu “hořících” projektů z právního hlediska, rámec, který jsme představili v tomto článku, se může stát jedním z možných východisek. Právní problémy související s vývojem systémů skutečně zahrnují velmi širokou škálu témat.

Stejně jako práce na vývoji systémů vyžaduje konstruktivní myšlení, tak i s tím související řízení rizik může být prováděno konstruktivněji, pokud neztratíme z dohledu celkový obraz daného oboru. Není tomu tak?