Do jaké míry by měla být funkce, která není uvedena ve specifikacích vývoje systému, implementována z právního hlediska?

Projekty na vývoj IT systémů používaných v podnicích jsou v zásadě vytvářeny v souladu s předem definovanými specifikacemi. Nicméně, pokud zvážíme význam toho, že dodavatel je jako odborník na vývoj systémů pověřen celým vývojem, očekávání uživatelů nemusí být tak nízká, že by stačilo pouze mechanicky implementovat to, co je napsáno ve specifikacích. V tomto článku se budeme zabývat otázkou, do jaké míry by měli nést povinnost implementovat programy, které nejsou uvedeny ve specifikacích, ale jsou potřebné vzhledem k cílům vývoje.

Právní problémy spojené s implementací nezahrnutých v specifikacích

Od dodavatelů se vyžaduje diskrece

Jednou z hlavních charakteristik smluv a různých právních problémů spojených s projekty systémového vývoje je, že dodavatel, který přijímá práci, má velkou diskreci.

Související článek: Co je povinností projektového managementu v systémovém vývoji[ja]

Avšak “diskrece”, o které zde hovoříme, neplatí nutně pro všechny fáze vývoje systému. Po identifikaci jednotlivých fází a pokročilém rozdělení na detailní úkoly se může práce často stát blízkou jednoduchým operacím. Nicméně, obecně platí, že čím více se stáváme součástí procesů výše, tedy v rámci upstream procesů, tím více se stává obtížným provádění práce bez velké diskrece. Toto je také důvod, proč se smluvní typy často lépe hodí pro quasi-mandáty, zejména v případě upstream procesů.

Související článek: Rozdíl a rozlišení mezi smlouvou o dílo a quasi-mandátní smlouvou v systémovém vývoji[ja]

Diskrece by měla být uplatňována i v rámci přísných vývojových procesů

Avšak, i když dodavatel vývoje systému má velkou diskreci, přijímání požadavků klienta “na poslední chvíli” může způsobit značné škody v pozdějších fázích. Jeden IT systém se skládá z mnoha malých komponent, a proto i malé změny na povrchu mohou vyžadovat značné změny v pracovní době z pohledu vývojářů. K tématu změn specifikací vývoje systémů existuje následující článek, který vysvětluje, jak spravovat změny z právního hlediska. Tento článek vysvětluje, jak spravovat změny, ale také diskutuje o tom, jak velký dopad mohou mít změny specifikací na práci z pohledu techniků.

Související článek: Jak spravovat změny v systémovém vývoji z právního hlediska[ja]

Co by měli odborníci dělat, aniž by byli omezeni specifikacemi?

Pro hladký průběh projektu vývoje systému je důležité předem definovat požadavky na vývoj a plánovat podle nich. Na druhou stranu, existují situace, kdy nemůžete plně vykonávat svou roli jako odborník na vývoj systémů, pokud jen děláte to, co vám bylo řečeno podle předem definovaných požadavků. V tomto dilematu se objevuje otázka “Co by mělo být implementováno, i když to není uvedeno ve specifikacích?”.

Právní povinnosti jsou stanoveny v souladu s “účelem” specifikací a smluv

Obsah toho, co je třeba implementovat, je určen podle “účelu”, tedy “jaký význam nebo záměr byl při uzavírání dohody”, i kdyby nebyl uveden v smlouvě nebo specifikacích. Podívejme se na několik příkladů soudních rozhodnutí.

Případ, kde povinnost implementace byla popřena kvůli absenci záznamu

Následující citovaný případ se týká systému, který vyvinul dodavatel a který se dostal až do fáze testování, kdy došlo k sporu o zrušení smlouvy kvůli nedostatečným funkcím. Uživatel tvrdil, že chybí “funkce automatické aktualizace dat”, což byl údajně hlavní prodejní bod tohoto systému, ale soud tuto povinnost implementace neuznal.

Jak bylo uznáno výše, v smlouvě o tomto případu, základním návrhu a detailním návrhu nejsou žádné záznamy, které by ukazovaly, že funkce ③ je cílem vývoje tohoto systému.

Žalobce tvrdí, že funkce ③ byla hlavním prodejním bodem systému pro žalobce ze strany žalovaného a zdůrazňuje potřebu této funkce, ale pokud by to bylo tak, jak tvrdí, mělo by to být jasně uvedeno v smlouvě atd., a je těžké si představit, že by byl dohodnut vývoj této funkce bez toho.

Tokijský okresní soud, 18. února 2009 (Heisei 21)

Toto rozhodnutí jistě může být jednoduše shrnuto jako “Pokud to není uvedeno v návrhu, nemusíte to vytvořit”. Avšak přesněji řečeno, rozhodnutí bylo učiněno na základě “účelu” záznamů v návrhu a smlouvě, nikoli na základě formálních skutečností, zda je záznam v návrhu nebo ne. Jinými slovy, “Pokud zvážíme důvody, proč nebylo v návrhu a smlouvě nic uvedeno, je rozumné se domnívat, že nebyla dohodnuta žádná dohoda odpovídající tomuto záznamu”.

Případ, kde byla potvrzena povinnost implementace i bez zápisu

Na druhou stranu, existují případy, kdy byla potvrzena povinnost implementace, i když nebyla uvedena v smlouvě nebo specifikacích. Následující citovaný případ se týká vývoje systému pro správu historie užívání léků, kde se nepodařilo přenést data z existujícího systému do nového systému, což znemožnilo využití nového systému a uživatelé tak ukončili smlouvu. Nicméně, dodavatel se bránil tím, že přenos dat je mimo rozsah jeho práce, což vedlo k sporu.

Vývoj nového systému často zahrnuje odstranění existujícího systému a přenos dat. Důležitost těchto úkolů a s nimi související právní problémy jsou podrobně vysvětleny v následujícím článku.

Související článek: Právní problémy spojené s přechodem ze starého systému při vývoji systému[ja]

V existujícím systému byla již uložena data více než 50 000 pacientů a žalobce se snažil zefektivnit administrativu využitím těchto dat. Pokud by nebylo možné přenést data pacientů z existujícího systému do nového systému, je zřejmé, že by to způsobilo problémy v lékárně. Je tedy možné předpokládat, že i zástupce žalobce si toho byl jistě vědom. A před uzavřením smlouvy se zástupce žalobce zeptal zástupce žalovaného na možnost přenosu dat, což zástupce žalovaného také uznal (vynecháno). U zástupce žalobce je vysoká pravděpodobnost, že si uvědomil, že bude muset ručně zadat data více než 50 000 pacientů, a je těžké si představit, že by se rozhodl zavést nový systém. Navíc, jak je uvedeno výše v bodě (1) I, žalovaný nemohl přenést data o lékárně z existujícího systému do nového systému, takže tiskl tato data na papír a zpracovával je do PDF souborů, i když přenos dat nebyl předpokládán v smlouvě, je těžké si představit, že by žalovaný prováděl takovou náročnou práci jako službu.

Verdikt Tokijského soudu ze dne 18. listopadu 2010 (Heisei 22)

Co je zde důležité, je “účel” smlouvy a “záměr” uvedený v smlouvě. Pokud by obě strany uzavřely smlouvu s vědomím, že přenos dat je mimo rozsah práce, soud poukázal na to, že by to znamenalo, že obě strany – uživatel i dodavatel – uzavřely smlouvu s neobvyklým úmyslem. Jinými slovy, uživatel by přijal obrovské množství ruční práce a dodavatel by se připravil na projekt, vědom si, že to bude způsobovat problémy v práci uživatele, což je velmi nesmyslné.

Co lze vyčíst z obou rozsudků

I když v smlouvě nebo specifikaci nebylo nic uvedeno o přenosu dat, povinnost implementace byla potvrzena. Jedním z důvodů může být skutečnost, že se jednalo o “data”, což je otázka, která se neprojevuje na vzhledu obrazovky. Předchozí “chybějící nezbytná funkce” je něco, co se přímo projevuje na obrazovce nebo vzhledu systému. Proto, i když jste laik v oblasti vývoje systémů, není tak těžké objevit chybějící informace ve specifikaci. Na druhé straně, problém přenosu dat má charakteristiku, že laici v oblasti vývoje systémů mají obtíže s pochopením důležitosti procesu, složitosti práce a pracovní doby. Proto se také předpokládá, že byl situace, kdy bylo snadné ošetřovat otázky, které by měl dodavatel řídit hladce s odborností.

Pokud o tom takto přemýšlíme, vynechání informací ve specifikaci nebo smlouvě je také problém úzce spojený s “povinností spolupráce” uživatele. Jinými slovy, je otázkou, zda uživatel skutečně splnil svou “povinnost spolupráce” při uzavírání smlouvy a vytváření specifikace. Celkový výklad právních povinností, které by měl uživatel splnit v rámci projektu vývoje systému, je podrobně popsán v následujícím článku.

Související článek: Jaké jsou povinnosti spolupráce na straně uživatele, který objednává vývoj systému[ja]

Pokud si přečtete také výše uvedený článek, měli byste být schopni pochopit, že v oblastech, kde je velká poptávka po spolupráci uživatele, jako je identifikace obrazovky a nezbytných funkcí, a v případě vynechání přemýšlení o přenosu dat, je příběh značně odlišný.

Jak bychom měli uvažovat o odměně za vývoj, který není uveden v specifikacích?

Další otázkou, která souvisí s tématem tohoto článku a která vás možná zajímá, je, zda je možné z hlediska práva požadovat vyšší odměnu, pokud vytvoříte něco, co není uvedeno ve specifikacích. O možnosti zvýšení odměny a o způsobu výpočtu odhadované částky v případě, že je to možné, se dozvíte více v následujícím článku.

Související článek: Je možné zvýšit odhadovanou částku pro vývoj systému?[ja]

V článku výše je vysvětleno, že důležité je, zda existovala práce přesahující rámec úkolu, který byl v poměru k odměně. Jinými slovy, pokud se vztahuje na tento článek, pokud dodavatel reaguje na vývoj něčeho, co nebylo zahrnuto v původních specifikacích (v tomto článku, negativní příklad), je možné uznat požadavek na dodatečnou odměnu.

Shrnutí

V oblasti vývoje systémů je role, kterou by měl dodavatel hrát, určena podle obsahu smlouvy a specifikací na jedné straně. Nicméně, s ohledem na skutečnost, že jsou jako odborníci svěřeni s prací na základě vysoké důvěry, je také zřejmé, že jejich skutečná podstata není určena pouze formálně. Přesto bychom měli pochopit, že právo hraje velkou roli při pochopení jejich skutečné podstaty.