Je možné zvýšení odhadované ceny systémového vývoje po faktu?

Práce spojená se systémovým vývojem zahrnuje velké množství lidí jak na straně objednavatele, tak na straně dodavatele. Synchronizovat všechny účastníky projektu a zajistit jeho hladký průběh není snadné. Je samozřejmé, že plánování je nesmírně důležité, ale zároveň není vždy možné, aby objednavatel poskytl dodavateli všechny potřebné informace včas a stručně. Pokud dojde k určitému pokroku ve vývojovém procesu a objednavatel požaduje změnu specifikací nebo přidání funkcí, může se dodavatel ptát, zda je možné účtovat více než původní odhadovanou cenu.

Jak jsou tato práva uznávána podle zákona? A jak se stanovuje odměna za dodatečný vývoj a úpravy funkcí? V tomto článku se pokusíme odpovědět na tyto a další otázky.

Kdy můžeme mluvit o dodatečném vývoji a úpravě funkcí?

V projektech vývoje systémů jsou typy smluv, které obvykle přijímáme, obvykle smlouvy o dílo nebo smlouvy o zastoupení. V obou těchto typech smluv jsou povinnosti, které by měla strana přijímající práci splnit (= povinnosti), a odměna, která s tím souvisí (= práva), uvedeny v smlouvě jako pár. Proto, pokud se později přidají úkoly, které nejsou zahrnuty v práci, která je základem pro tuto odměnu, může se jednat o dodatečný vývoj nebo úpravu funkcí. Naopak, pokud jsou zahrnuty, budou považovány za věci podle původních specifikací (= v rámci původní smlouvy).

Podrobnější vysvětlení rozdílů mezi smlouvou o dílo a smlouvou o zastoupení najdete v samostatném článku.

https://monolith.law/corporate/contract-and-timeandmaterialcontract[ja]

Avšak, pokud bychom měli říci, že vše, včetně jemného ladění fontů zobrazených na obrazovce, je dodatečný vývoj, pokud to není předem stanoveno ve specifikacích, mohlo by to výrazně bránit hladkým obchodním transakcím. Proto, pokud zahrneme diskuse o těchto detailních specifikacích, není jednoduché stanovit jednotnou hranici. Nicméně, pokud bychom měli uvést obecné směrnice,

• Pokud jsou po potvrzení specifikací nařízeny další funkce
• Pokud je po dokončení implementace programu nařízena jeho úprava

je možné říci, že v těchto případech je pravděpodobné, že tvrzení bude mít určitou právní platnost.

Případ soudního sporu, kde bylo předmětem diskuse, zda se jedná o dodatečný vývoj nebo opravu funkce

Příklad potvrzení: Případ změny specifikací základního návrhu po faktu

Následující příklad se týká změny specifikací po faktu.

Vývoj softwaru probíhá prostřednictvím fází vývoje, které zahrnují ① definici požadavků, ② externí návrh, ③ interní návrh, ④ vytváření zdrojového programu (návrh programu, kódování), ⑤ různé testy (jednotkové testy, kombinované testy, systémové testy) (vynecháno)… Původní specifikace (vynecháno) jsou realizovány prostřednictvím práce po interním návrhu, a to je rozsah práce, který je vztahem mezi nárokem na odměnu a protihodnotou na základě této smlouvy o vývoji. Žádost o změnu specifikací je právně považována za novou žádost o smlouvu o zadání práce, která překračuje rozsah práce na základě původní smlouvy ze strany zadavatele, a pokud dodavatel neuvádí dodatečnou částku za práci a dokončí práci týkající se dodatečného zadání bez dohody o dodatečné částce, je to považováno za novou smlouvu o provedení práce, ve které nebyla stanovena částka, a je rozumné chápat, že vzniká povinnost zaplatit přiměřené dodatečné náklady na vývoj.

Osaka District Court, 29. srpna 2002 (Heisei 14)

Klíčová slova jako “vztah protihodnoty” a “nová smlouva” mohou být klíčem k hlubšímu pochopení tohoto rozhodnutí.

Mimochodem, v tomto rozhodnutí byl uveden ještě jeden velmi zajímavý bod. To je, že drobné úpravy, jako je umístění tlačítek nebo styl písma, nepatří do změny specifikací, jak je zde uvedeno. Relevantní část je následující:

Však vývoj softwaru, vzhledem k jeho povaze, obvykle nezahrnuje rozhodnutí o takových detailech jako je styl písma pro zobrazení textu na obrazovce nebo umístění tlačítek v fázi externího návrhu, a detaily jsou obvykle upravovány do určité míry po potvrzení specifikací prostřednictvím konzultací mezi stranami. Vzhledem k tomu, by mělo být řečeno, že není přiměřené považovat požadavky na detailizaci specifikací za změnu specifikací.

Osaka District Court, 29. srpna 2002 (Heisei 14)

V rozhodnutí bylo použito zajímavé slovo “detailizace specifikací”.

• Případ, kdy bylo něco, co mělo být již rozhodnuto, později zrušeno
• Případ, kdy bylo něco, co mělo být rozhodnuto během procesu, úmyslně nebylo rozhodnuto a bylo pokračováno

Je možné říci, že to naznačuje myšlenku, že právní zacházení by mělo být také odlišné v závislosti na situaci.

Další příklady potvrzení

Kromě toho, mezi případy, které byly uznány jako další vývoj a úpravy funkcí, patří:

• Případ, kdy počet programů dodaných oproti původnímu plánu vzrostl zhruba dvojnásobně (Rozsudek Tokijského okresního soudu ze dne 22. dubna 2005 (2005))
• Případ, kdy se pracovní doba prodloužila zhruba třikrát (Rozsudek Tokijského okresního soudu ze dne 22. ledna 2010 (2010))

Jak vidíme z těchto příkladů, je zřejmé, že prodloužení pracovní doby je také považováno za široce pojatý další vývoj a je přijímán přístup, který umožňuje určitou právní ochranu.

“Dohoda o dalším vývoji a zvýšení odměny” a “uzavření původní smlouvy” jsou odlišné problémy

Důležitým bodem týkajícím se těchto problémů je, že

1. “Zda byla mezi dvěma společnostmi formálně uzavřena smlouva o vývoji systému (původní smlouva)”
2. “Zda byla po formálním uzavření smlouvy o vývoji systému uzavřena také dodatečná smlouva o dalším vývoji”

jsou kritéria soudu odlišná. Stručně řečeno, soud má tendenci

• být přísný v případě 1 (v případě absence smlouvy je uzavření smlouvy těžko uznáno)
• být relativně benevolentní v případě 2 (i bez smlouvy o dalším vývoji je ochoten uznat zvýšení odměny a podobně)

lze říci. Podrobnější vysvětlení k bodu 1 naleznete v samostatném článku.

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

Případ, kdy bylo zamítnuto: Případ, kdy bylo považováno za součást podobného obsahu smlouvy v právním smyslu

Na druhou stranu, existují také soudní případy, kdy nebylo přiznáno zvýšení odměny. V případě uvedeném v následujícím citátu z rozsudku bylo diskutováno o tom, zda je možné zvýšit odměnu v důsledku změny obsahu práce po uzavření smlouvy o zadání práce pro vývoj systému.

Hlavní body sporu v tomto případě jsou: (1) Jaký byl obsah práce, kterou žalobce převzal v rámci této smlouvy? (2) Byla mezi žalobcem a žalovaným dohodnuta dohoda o rozšíření rozsahu a zvýšení ceny za převzatou práci? (…)

Především, tato smlouva je smlouva o zadání práce, ve které bylo dohodnuto, že cena bude pevnou odměnou za práci, kterou žalobce převzal (zadání), a počet kroků a jednotková cena jsou pouze interními dokumenty používanými žalobcem pro výpočet ceny za zadání práce, a jakékoliv změny v počtu kroků atd. jsou zcela nesouvisející s cenou za zadání práce. (…)

Jak bylo uvedeno výše, práce, kterou žalobce převzal, byla změněna 25. února 1987 (Showa 62), a byla omezena pouze na správu systému, výpočet nákladů na zadání práce a část utility, zatímco zbytek byl převeden na žalovaného. Práce žalobce po změně je stále v rámci původní smlouvy a odměna za tuto práci je pokryta celou částkou, která byla dohodnuta jako pevná cena při uzavření smlouvy.

Rozsudek Okresního soudu v Tokiu ze dne 12. června 1995 (Heisei 7)

V tomto rozsudku bylo rozhodnuto, že i když se obsah práce svěřené dodavateli změnil, pokud se tento vývojový obsah vejde do původního rozsahu smlouvy, měl by být pokryt původně dohodnutou odměnou.

Nakonec se zdá, že postoj je takový, že po zvážení toho, jaké práce byly předpokládány při stanovení odměny, by měly být přiznány další nároky na odměnu pro práce, které nejsou zahrnuty.

A jaká práce byla považována za odměnu, není nutně určena pouze smlouvou, ale může být rozhodnuta také na základě důkazů, jako jsou zápisnice. Podrobnosti o důležitosti zápisnic jsou vysvětleny v následujícím článku.

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

Jak se stanovuje odměna za dodatečný vývoj a úpravy funkcí?

V oblasti vývoje systémů není neobvyklé, že se specifikace, které se zdály být jednou potvrzené, později změní. Při každém takovém výskytu není praktické připravovat novou písemnou smlouvu a pokračovat v smluvních jednáních. Pokud je možné znovu potvrdit obsah specifikací pro položky, které je třeba přidat nebo upravit, a uzavřít souhrnnou dohodu, jako je memorandum, je to jedna věc, ale jak by měla být stanovena částka odměny, pokud projekt selže, aniž by byly provedeny tyto postupy?

Článek, který by měl být v takových případech vzat jako referenční, je následující článek 512 obchodního zákoníku (podtržené části jsou ty, které jsem podtrhl).

Článek 512 obchodního zákoníku: Když obchodník jedná pro jiného v rámci svého obchodního rozsahu, může požadovat přiměřenou odměnu.

Problémem je, kolik bude “přiměřená odměna” uvedená v tomto článku v konkrétní situaci. Podle minulých soudních rozhodnutí se zdá, že byla přijata myšlenka, že náklady by měly být neseny v poměru k pracovní době, množství práce nebo době trvání. To je pravděpodobně způsobeno tím, že vývoj systémů je svou povahou druhem služby a základními náklady jsou mzdové náklady.

Proto, navzdory abstraktnosti fráze “přiměřená odměna” v obchodním zákoníku, odhadování tržní ceny dodatečné odměny v tomto kontextu nevyžaduje příliš složité výpočty. Podívejme se na několik příkladů soudních rozhodnutí.

Případ 1: Příklad, kdy byla uznána dodatečná odměna v poměru k nárůstu pracovních hodin

V tomto případě je rozumné považovat vývojové pracovní hodiny na základě změny specifikací za celkový počet těchto hodin, tj. 257,5 člověk/den, a pokud to převedeme na vývojové náklady na osobu/den ve stejných 32 500 jenech (v případě A3 je jednotková cena 650 000 jenů [na osobu/měsíc] a pokud počítáme s 20 pracovními dny v měsíci, vývojové náklady na osobu/den činí 32 500 jenů.) jako v tomto případě vývojové smlouvy, je rozumné považovat dodatečné vývojové náklady na základě požadavku na změnu specifikací za 8 367 500 jenů.

Rozsudek Okresního soudu v Ósace ze dne 29. srpna 2002 (rok 14 éry Heisei)

“Na osobu/den” je klíčové slovo. Ukazuje, že jako základ pro výpočet dodatečné odměny se používají pracovní hodiny.

Případ č. 2: Příklad uznání dodatečné odměny v poměru k počtu programů

Při zkoumání odpovídající částky odměny včetně dodatečné částky v tomto případě, většina nákladů na vývoj počítačového systému spočívá v mzdových nákladech techniků a tyto mzdové náklady jsou obecně proporcionální k množství programů, které se vytvářejí. Pokud vezmeme v úvahu počáteční smluvní částku 23,250,000 jenů a podělíme ji počtem programů (206), které byly dokončeny do druhé kontroly, a poté vynásobíme tuto jednotkovou cenu za program počtem programů (414), které prošly třetí kontrolou, dostaneme částku 46,725,728 jenů (23,250,000 ÷ 206 × 414 = 46,725,728), kterou považujeme za odpovídající.

Rozsudek tokijského okresního soudu ze dne 22. dubna 2005 (Heisei 17)

Čísla se zde objevují v hojném množství, ale pokud si to přečtete s klidem, zjistíte, že se nejedná o žádné složité výpočty. Na základě původní smlouvy se jednoduše provádí kontrola “jakou jednotkovou cenu za program jsme odhadovali” a poté se provádí jednoduchá násobení “jednotková cena × množství”.

Případ č. 3: Příklad uznání dodatečné odměny v poměru k délce trvání

V smlouvě “A3” bylo stanoveno, že odměna za práci vykonanou jako kvazimandát v období od ledna do března roku 2005 (Heisei 17) bude 60 milionů jenů. Na druhou stranu, práce vykonaná bezplatně po dubnu téhož roku zahrnuje práci, která byla provedena bezplatně, stejně jako v předchozím roce. Očekává se, že množství práce se zvýší po dubnu téhož roku, kdy začne nový semestr a systém pro registraci kurzů a podobně bude v provozu. Na základě těchto skutečností je rozumné stanovit odměnu za práci vykonanou v období od dubna do září roku 2005 (Heisei 17) na základě 60 milionů jenů, které byly stanoveny jako odměna za práci v průběhu tří měsíců, na 120 milionů jenů.

Rozsudek Okresního soudu v Tokiu ze dne 22. ledna 2010 (Heisei 22)

Výše uvedený rozsudek naznačuje, že dodatečná odměna za prodloužené období by měla být vypočítána pomocí jednoduchého proporcionálního výpočtu.

Shrnutí

Jak je vidět z výše uvedených soudních příkladů, zdá se, že se objevují určité zákony a společné rysy týkající se právního zacházení s dodatečnou odměnou pro programátory a inženýry. Jinými slovy, z principu se zdá, že se snažíme vypočítat co nejjednodušeji na základě poměrně objektivních ukazatelů, jako je počet hodin strávených na práci, formální množství práce (například dodané programy) a doba strávená prací.

Při pohledu na to, že dodatečný vývoj a opravy funkcí vznikají právě kvůli selhání přesného postupu nebo dokonalého odhadu pracovních hodin, může se zdát, že vzniká dodatečná odměna za tolik práce, kolik bylo vynaloženo, nebo za formální množství provedené práce, nebo za strávený čas, jako by to bylo bez chuti a bez zájmu. Avšak, pokud se na to díváme z pohledu dodavatele, i když se snažíme prioritizovat zájmy zákazníků při provádění naší práce, skutečnost, že taková práva jsou pravděpodobně uznána zákony, by mohla mít význam v kontextu určitého krizového řízení.