Problémy práva a smluv spojené s agilním vývojem

V postupu vývoje systému existují metodologie. Nejklasičtější a nejobecnější je model Waterfall, a mnoho právních knih zabývajících se vývojem systémů také diskutuje s tímto modelem jako předpokladem. V tomto článku vysvětlíme, jaké právní problémy existují v souvislosti s vývojem systémů založených na modelu agilního vývoje, o kterém je těžké získat informace z knih a podobných zdrojů.

Agilní vývojový model a právní aspekty

Co je vývojový model v systémovém vývoji

V projektech systémového vývoje existuje vývojový model jako rámec pro celkové pochopení pokroku. Tím nejznámějším je takzvaný “vodopádový model”. To znamená, že stejně jako voda padající z “horního toku” do “dolního toku” řeky, projdete všemi fázemi jako jsou definice požadavků, návrh, implementace, testování atd. v jednom průchodu. Cílem je minimalizovat opakování a zbytečnou práci a postupovat plánovaně.

Na druhou stranu, v agilním vývojovém modelu se malé programy implementují a testují opakovaně. Tímto opakovaným procesem implementace a testování malých programů se postupně vytváří velký systém. Podrobnější vysvětlení tohoto modelu vývoje systémů a srovnání výhod a nevýhod obou vývojových modelů najdete v následujícím článku.

https://monolith.law/corporate/legal-merits-and-demerits-of-development-model[ja]

Charakteristiky agilního vývojového modelu

Velkou výhodou vývoje pomocí agilního modelu je, že se můžete rychle pustit do skutečné práce. Protože “horní tok” práce, jako je definice požadavků a tvorba návrhů, není oddělen od implementace programu, je tento model vhodný pro flexibilní řízení, včetně reakce na přidání a úpravy funkcí a změny specifikací. Z právního hlediska jsou klíčové body pro úspěch agilního vývojového modelu správa dokumentů a řízení změn. V agilním vývojovém modelu nejsou role a odpovědnosti tak jasně rozděleny jako ve vodopádovém modelu. Navíc, protože se klade důraz na “rychlost” místo na “správu”, je snadné nedostatečně zpracovat různé návrhy, specifikace a zápis z jednání.

Co se týče řízení změn, agilní vývojový model je hladký v reakci na změny, což může vést k riziku, že projekt se “vznítí”, pokud se na úrovni pracoviště vyhoví požadavkům na změnu specifikací bez schválení rozhodujícími osobami. Pokud se to stane, výhoda vývojového modelu, který je “hladký v reakci na změny”, se může sama stát rizikem pro “vznícení” projektu.

Jak spravovat dokumenty a změny v agilním vývoji

Důležitost správy dokumentů

V rámci vývojových projektů založených na agilním vývojovém modelu je právně problematické, že se hromadí ústní komunikace, což vede k nedostatku dokumentů. K tomuto bodu, proč je správa dokumentů důležitá v projektech vývoje systémů, podrobně vysvětlujeme v následujícím článku.

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

V daném článku vysvětlujeme důležitost správy dokumentů v projektech vývoje systémů z dvou hledisek: předcházení sporům (tj. “preventivní právní péče”) a ochrany důkazů v případě sporu (tj. “krizového řízení”).

Zřízení koordinačních schůzek je účinné pro správu dokumentů

Při použití agilního vývojového modelu, na rozdíl od vodopádového modelu, není předem připraven žádný jasný plán. Proto není dostatečné pouze spravovat odchylky mezi plánem a skutečností, existuje obava, že ponechání věcí na místě by mohlo vést k finančním a časovým nákladům.

Proto je účinné, pokud vedoucí pracovník uspořádá pravidelné koordinační schůzky pro hladký průběh projektu. Pokud je rozsah vývoje malý, je skutečně preferováno, že se vedoucí pracovníci scházejí, kdykoli se mohou sejít, místo pravidelného konání koordinačních schůzek. Avšak v případě agilního vývojového modelu je riziko, že se na schůzce přehlédnou aktuální problémy. Proto je bezpečné zahrnout pravidelné konání koordinačních schůzek i do smluv a podobných dokumentů. Způsob stanovení je uveden v modelové smlouvě Ministerstva hospodářství, obchodu a průmyslu (METI) následovně:

(Zřízení koordinačních schůzek)

Článek 12: Strany A a B budou konat koordinační schůzky pro diskusi o potřebných záležitostech pro hladké provádění této práce, včetně pokroku, řízení a hlášení rizik, společné práce obou stran a stavu provádění jejich vlastních úkolů, potvrzení obsahu, který by měl být zahrnut do specifikací systému, diskuse a řešení problémů, atd., až do ukončení této práce. Avšak, (vynecháno).

2. Koordinační schůzky se budou konat pravidelně v frekvenci stanovené v individuální smlouvě a kromě toho se budou konat kdykoli, když to strana A nebo B považuje za nutné.

3. Na koordinačních schůzkách budou přítomni vedoucí pracovníci a hlavní zodpovědné osoby obou stran, stejně jako osoby, které vedoucí pracovníci považují za vhodné. Navíc, strana A a B mohou požadovat, aby druhá strana přivedla osoby, které jsou potřebné pro diskusi na koordinační schůzce, a druhá strana musí na toto požadavku reagovat, pokud neexistuje důvodný důvod.

4. Strana B vytvoří a předloží zprávu o řízení pokroku podle formátu dohodnutého mezi stranou A a B na koordinační schůzce, potvrdí pokrok na základě této zprávy o řízení pokroku, diskutuje a rozhodne o případných zpožděních, důvodech a opatřeních pro zpoždění, potřebě změny struktury podle této kapitoly (změna personálu, zvýšení nebo snížení, změna subdodavatelů atd.), stavu plnění bezpečnostních opatření, případné potřebě změny individuální smlouvy, obsahu, pokud je potřeba změnit individuální smlouvu, atd., podle potřeby, a potvrdí rozhodnuté záležitosti, záležitosti, které budou nadále zkoumány, a pokud existují záležitosti, které budou nadále zkoumány, potvrdí plán zkoumání a strany, které budou zkoumání provádět. 

(Následující články 5, 6 a 7 jsou vynechány.)

Nejdůležitějším bodem je, že existence koordinačních schůzek je legitimizována smluvními ustanoveními a má jiný význam než ad hoc schůzky.

Využití komunikačního výboru pro řízení změn

V agilním vývoji je předpokládáno, že obě strany budou měnit prvotně dohodnuté záležitosti. Proto je velmi důležité, jak spravovat situace, kdy dojde k dodatečným změnám specifikací.

Pokud se pravidelně konají schůzky komunikačního výboru, řízení změn probíhá velmi hladce. Například, diskuse o změnách se mohou konat na schůzce komunikačního výboru a pokud jedna strana požaduje diskusi o změně, druhá strana je povinna se této diskusi zúčastnit. Toto je zakotveno v smlouvě. (Níže je uveden výňatek z modelové smlouvy Ministerstva průmyslu a obchodu.)

(Proces řízení změn)

Podle článku 37, pokud strana A nebo B obdrží návrh na změnu od druhé strany, musí do ○ dnů od data přijetí předat druhé straně dokument (dále jen “Dokument řízení změn”) s následujícími informacemi a strany A a B musí diskutovat o schválení změny na komunikačním výboru podle článku 12. (Podrobnosti jsou vynechány.)

Klíčové body výše uvedeného ustanovení lze shrnout následovně:

• Jednotný formát “Návrh na změnu” pro přijímání návrhů na změny
  
• Stanovení lhůty mezi přijetím návrhu a diskusí o něm → Místo formulace “do ◯ dnů” lze zvážit použití výrazů jako “co nejdříve”.
  
• Jednotný rámec “komunikační výbor” pro diskuse o schválení změn
  

Jinými slovy, aby se předešlo nedorozuměním, jako je “Nabídl jsem změnu, nebo ne”, “Odpověděl jsem na schválení změny, nebo ne”, je proces jasně definován.

Rozumění povinnosti upřímnosti a zásadě dobré víry je klíčové

Dosud jsme představili modely smluvních doložek týkajících se “Kontaktního konzultačního výboru” a “Změnových konzultací”. Nicméně, pro podstatné pochopení těchto věcí je důležité se zaměřit na otázky jako “povinnost upřímnosti” a “zásada dobré víry”. Agile vývojový model je obecně obtížný k provádění bez důvěry mezi objednatelem a dodavatelem. To je proto, že klade důraz na rychlost zahájení skutečné práce a procesy vedoucí k zahájení jsou obvykle minimalizovány. Proto se v praxi často stává, že do smlouvy je začleněna doložka ukládající “povinnost upřímnosti” druhé straně.

Článek 4 odstavec 3: V rámci konzultací o změnách se obě strany upřímně dohadují o předmětu změny, možnosti změny, dopadech změny na cenu a termín dodání atd.

Toto je zaměřeno na zabránění situacím, kdy by jedna strana náhle zradila druhou stranu tím, že by tvrdila, že “rozhodnutí o přijetí změny smlouvy je výhradně na straně příjemce a není povinností reagovat na nátlak”, což by bylo v rozporu s právními argumenty založenými na formálních aspektech. To odráží zásady práva, které se týkají obchodních transakcí mezi soukromými subjekty, a to nejen v oblasti vývoje systémů.

Občanský zákoník článek 1 odstavec 2

Výkon práv a plnění povinností musí být prováděny upřímně a v souladu s dobrou vírou.

Zákon neklade důraz pouze na “obsah smlouvy” nebo “slovní znění článků” založené na formálních aspektech. Zejména v obchodních transakcích s druhou stranou by mělo být právo používáno flexibilně, zatímco se zohledňuje podstatná “dobrá víra” a “upřímnost”. Kromě toho, podrobně vysvětlujeme, že “povinnost” ukládaná zákonem není nutně založena na “smlouvě”, v následujícím článku.

https://monolith.law/corporate/system-development-unlawful-responsibility[ja]

Shrnutí

Je samozřejmě důležité pochopit riziko, že v projektu vývoje systému založeném na agilním vývojovém modelu se administrativní postupy a řídící struktury mohou postupně stát nedbalými. Nicméně, není to jen o tom. Je také důležité pochopit flexibilní charakteristiku, kterou má zákon v základě, jako je “pravidlo dobré víry”, a mít postoj, který to využívá v praxi.