Jak provádět správu změn v systémovém vývoji z právního hlediska

V projektech vývoje systémů se často stává, že obsah, který uživatel předem vysvětlil, se v průběhu práce mění. Proto i jako dodavatel, který přijímá práci, může být někdy nutné přizpůsobit se změnám v obsahu smlouvy, kterou jsme již jednou uzavřeli.

Tento článek vysvětluje, jak bychom měli zacházet s fenoménem “změny”, které se provádějí ex post, z právního hlediska vůči projektům vývoje systémů, které se ne vždy vyvíjejí podle očekávání.

Proč jsou projekty systémového vývoje “změněny” až po skončení?

Systémový vývoj je společná práce dodavatele a uživatele

Systémový vývoj obecně prochází fází plánování a návrhu, definování požadavků na vývoj a uzavření smlouvy. Po uzavření smlouvy následuje řada designových fází, implementace podle designu, a nakonec testování. V celém procesu je samozřejmě dodavatel, který přijímá práci, široce zodpovědný jako odborník na vývoj systémů, ale je také kladen určitý stupeň povinnosti spolupráce na straně uživatele. Zejména v procesech jako definování požadavků (= definování požadavků) na systém, který má být vytvořen, vzhled a ovládání obrazovky (= základní design) a ověřování, zda bylo vytvořeno to, co bylo požadováno (= testování nebo přijetí), je spolupráce uživatele důležitá. Pro obecný přehled o povinnostech, které uživatel nese v systémovém vývoji, se podívejte na následující článek.

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

Ačkoli existuje povinnost spolupráce, uživatelé často požadují změny

Avšak uživatelé, kteří nejsou odborníky na vývoj systémů, nemusí být schopni vždy plánovat a předávat dodavateli všechny informace potřebné pro vývoj systému bez jakýchkoli nedostatků. Ve skutečnosti, protože se jedná o detailní a precizní práci, uživatelé často nemohou předvídat, jaké skutečnosti budou mít rozhodující význam v pozdějších fázích. Ironicky, čím důležitější je skutečnost, tím pravděpodobněji se objeví později. Vzhledem k těmto okolnostem je v reálných projektech, i když je ideálem “průchod od počáteční do konečné fáze”, důležité předpokládat, že po skončení mohou být provedeny různé změny, a řešit otázku, jak provádět “řízení změn”.

Co je to dokument o řízení změn

Kdy se používá dokument o řízení změn

Dokument o řízení změn je dokument, který uživatelé používají, když požadují od dodavatele změnu specifikací nebo přidání funkcí oproti původnímu vysvětlení. Jak bylo uvedeno výše, v fázích jako jsou definice požadavků nebo základní návrh, uživatelé mají povinnost spolupracovat na práci dodavatele, ale je možné, že v pozdějších fázích vzniknou odlišné požadavky.

Příklady situací, kdy je potřeba dokument o řízení změn, mohou být například:

• Pokud byly při definici požadavků nebo základním návrhu přehlédnuty některé aspekty a je potřeba požádat o přidání funkce později
• Pokud je během vývoje nutné změnit specifikace kvůli revizi obchodní politiky atd.

To jsou jen některé příklady.

Co se týče témat jako přidání funkcí nebo změna specifikací, pro stranu přijímající práci je nejdůležitější otázka, zda je změna odhadované částky právně přijatelná. Tento bod je podrobně vysvětlen v jiném článku.

https://monolith.law/corporate/increase-of-estimate[ja]

Dokument o řízení změn je základem pro posouzení spravedlnosti odhadu obsahu při zvyšování odhadu po skončení práce. Při výběru na základě zvýšeného odhadu je důležité vytvořit dokument o řízení změn, aby se předešlo sporům s druhou stranou (a také aby se posílila přesvědčivost vlastního argumentu v případě sporu).

Obsah dokumentu o řízení změn

Jaké položky by měly být z právního hlediska uvedeny v dokumentu o řízení změn? Mechanismus smlouvy, který využívá dokument o řízení změn pro reakci na změny specifikací a přidání funkcí, je již obecně široce uznáván. Proto je možné zjistit, jaké položky by měly být zaznamenány, tím, že se podíváte na vzory smluvních doložek, které poskytují vládní agentury, jako je modelová smlouva Ministerstva hospodářství, obchodu a průmyslu (japonské “Keizai Sangyōshō model keiyaku”).

(Proces řízení změn)
Článek 37: Strana A nebo B, pokud obdrží návrh na změnu na základě článku 34 (Změna systémových specifikací atd.), článku 35 (Schválení uživatelem středních materiálů) nebo článku 36 (Zacházení s nejasnými záležitostmi), musí do ○ dnů od data přijetí předat druhé straně dokument (dále jen “dokument o řízení změn”), který obsahuje následující položky. Strana A a B pak budou diskutovat o přijatelnosti této změny na komunikační konferenci stanovené v článku 12.
① Název změny
② Vedoucí osoba návrhu
③ Datum
④ Důvod změny
⑤ Podrobnosti změny včetně specifikací souvisejících se změnou
⑥ Pokud je pro změnu potřeba náklady, jejich výše
⑦ Plán práce na změně včetně doby pro zvážení
⑧ Další dopady změny na podmínky této smlouvy a individuální smlouvy (doba trvání práce nebo termín dodání, poplatky za zakázku, smluvní podmínky atd.)

Přímé čtení textu a ověření doporučených položek k zapsání by mělo být dostatečné a další vysvětlení by nemělo být nutné. Aby se předešlo problémům typu “řekl jsem / neřekl jsem”, je třeba zaznamenat podrobný a konkrétní průběh změny.

Po jasném uvedení těchto položek a jejich spojení s podpisy nebo pečetěmi odpovědných osob a rozhodovatelů obou stran, dodavatele a uživatele, bude mít tento dokument, pokud dojde k soudnímu sporu, stejný význam jako smlouva.

Co byste měli vědět o správě změn

Správa změn by měla být prováděna společně s řízením úkolů

Důvodem pro vytvoření dokumentu o správě změn je, že správou historie změn můžeme vést projekt k úspěchu (nebo v případě neúspěchu se vyhnout neoprávněnému přenesení odpovědnosti). V praxi se často vytváření a aktualizace dokumentu o správě změn provádí společně s vytvářením přehledu úkolů. Jinými slovy, jakmile spravujeme historii změn v tabulce správy změn, dohodnuté změny se začlení do přehledu úkolů jako úkoly, které je třeba v budoucnu řešit.

Je lepší také stanovit pravidla pro jednání o změnách

Nejen způsob řízení změn, ale také způsob jednání o změnách by měl být stanoven, což může usnadnit řešení změn. Toto je zvláště důležité v případě, že používáte vývojové metody, jako je agilní vývoj, kde se předpokládají různé změny po skončení. V praxi je často stanoveno, kdy by měla druhá strana reagovat na požadavek na jednání o změnách.

Jednání o změnách a povinnost upřímnosti

Když obě strany souhlasí se změnou smlouvy, kterou již jednou uzavřely, je to v podstatě uzavření nové smlouvy. Z principu, že smlouva je založena na svobodné vůli stran, by dodavatel neměl být povinen souhlasit se změnou smlouvy. Nicméně, pokud se příliš zdůrazňují práva, může se obávat, že projekt vývoje systému nebude hladce pokračovat.

Proto se v praxi často uvádí v smlouvách, že existuje “povinnost upřímně jednat o změnách”, a pokud dodavatel nejedná upřímně o změnách, může být možné požadovat odškodnění. Například, následující je příklad takového ustanovení (citováno z “Návrhu základní smlouvy pro základní / individuální smlouvy” vytvořeného oficiálně nezávislou správní institucí, Japonským institutem pro podporu zpracování informací).

Článek 4, odstavec 3: Při jednání o změnách obě strany upřímně diskutují o tom, zda provést změnu, po zvážení cíle změny, možnosti změny a dopadu změny na cenu a termín dodání.

Ustanovení o způsobu změny

Jak již bylo uvedeno, při provádění změn je z právního hlediska “bezpečnější” konat jednání o každé změně. Nicméně, v případě menších projektů nemusí být nutné stanovit způsob jednání o změnách. V takovém případě můžete místo stanovení pravidel pro jednání provést změnu tím, že necháte odpovědné osoby uživatele a dodavatele podepsat a razítkovat dokument o správě změn, aniž by bylo nutné jednat. Pokud umožníte snadné změny pouze na základě ústní dohody, může být nejasné, zda byla provedena změna, což může později vést k velkým problémům. V tomto smyslu by měla být dokumentace pečlivě spravována.

Na druhou stranu, příprava samostatných dokumentů pro každou změnu může být náročná a můžete chtít dát přednost flexibilnímu přístupu. V takovém případě může být jednou z možností dokumentovat změny v zápisech z jednání. Podrobnosti o tom, jak vést zápisy z jednání při vývoji systémů, jsou vysvětleny v následujícím článku.

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

Shrnutí

V prostředí, kde se často mění specifikace, je jistě často spojeno s rizikem problémů a sporů. Nicméně, v takovém prostředí, kde je vyžadována pružnost, je často obtížné uplatnit praktická opatření, i když zdůrazňujeme “důležitost řízení” striktně a přímo.

Problém, jak skloubit rychlost vyžadovanou v obchodě a přípravu na nejhorší možný scénář, se zdá být často odlišný v závislosti na situaci společnosti a obsahu projektu. I při zohlednění obsahu tohoto článku je důležité, aby každá společnost a každý projekt hledaly vhodný způsob, jak postupovat.