Jaké jsou povinnosti spolupráce, které musí uživatelé jako objednavatelé systémového vývoje nést

Práce na vývoji systémů vyžaduje, čím větší je systém, který se má vyvíjet, tím více lidí a času je potřeba. Proto nejen na straně dodavatele, který přijímá vývoj, ale také na straně uživatele, který zadává vývoj systému, existuje určitá povinnost spolupracovat.

Toto se liší od běžných vztahů mezi zadavatelem a dodavatelem. Například, pokud si u švadleny objednáte šití na míru, zadavatel, tedy zákazník (uživatel), nemá žádné “povinnosti”. “Povinnosti” má především dodavatel, tedy švadlena (dodavatel). Právě kvůli potřebě mnoha lidí a času pro IT systémy, je nutné, aby i uživatel “spolupracoval” s dodavatelem.

V tomto článku vysvětlíme, jaké právní povinnosti má zadavatel v případě vývoje systémů, který nelze ponechat jen na dodavateli.

Vlastní systém není možné jednoduše “přenechat”

I v případě jednoho projektu vývoje systému se často zapojuje mnoho lidí a organizací. Samozřejmě, inženýři a programátoři se silnými dovednostmi v kódování jsou důležití, ale pro sjednocení jejich výstupů do jednoho výsledku je také důležitá role projektového manažera.

Avšak, bez ohledu na to, jak vysokou technickou a organizační schopnost má dodavatel, vývoj systému nemůže být dokončen pouze silou dodavatele. Například, dodavatel nemá možnost získat informace o interních termínech používaných pouze v dané společnosti nebo o obchodních znalostech specifických pro danou společnost pouze svým jednostranným úsilím. Obecně platí, že čím větší je vývoj systému, tím častěji je společnost, která tento systém využívá, velkou společností s mnoha lidmi a operacemi. Pro úspěch projektu vývoje systému je často důležité především uspořádání těchto obchodních logik, a to i před práci na počítači.

Proto by uživatelé neměli být pasivní s tím, že “nejsou odborníci na IT technologie”, ale naopak by měli aktivně poskytovat informace, což může přispět k hladkému průběhu projektu. V tomto smyslu je role, kterou uživatelé hrají v projektu vývoje systému, ve skutečnosti velmi důležitá.

Co je povinností uživatele vycházející z precedensu

Takže konkrétně, jaké povinnosti má uživatel v rámci projektu vývoje systému? Na tuto otázku existuje mnoho nápověd v předchozích soudních rozhodnutích.

V soudních případech, kdy dodavatel (žalovaný) zpozdil termín dodání, bylo zpoždění rozhodnutí uživatele (žalobce) jedním z bodů sporu ohledně povinnosti uživatele spolupracovat na vývoji. Soud v tomto případě uznal porušení povinnosti spolupráce ze strany uživatele a zamítl odpovědnost dodavatele za nesplnění závazku. (Bylo uznáno zrušení smlouvy, ale bylo také uznáno šedesátiprocentní snížení škody.)

V případě tohoto kontraktu na vývoj počítačového systému, který je takzvaným kontraktem na vývoj systému na míru, dodavatel sám nemůže dokončit systém, a proto je nutné, aby zadavatel (uživatel) během vývoje koordinoval interní názory, sjednotil své názory, jasně sdělil dodavateli, jaké funkce požaduje, společně s dodavatelem prozkoumal požadované funkce, nakonec rozhodl o funkcích, dále rozhodl o obrazovce a formulářích, a převzal výsledky.

Rozhodnutí Tokijského okresního soudu ze dne 10. března 2004 (Heisei 16)

Toto rozhodnutí nejen ukazuje, že vývoj systému je společnou prací s uživatelem, ale také velmi názorně uvádí, “v jakých konkrétních bodech by měla probíhat spolupráce”.

Zkusme přeložit výše uvedený text rozhodnutí do IT terminologie vývoje systémů.

Takto lze informace uspořádat. Všechny tyto body vyžadují spolupráci uživatele, bez ohledu na to, jak vysoká je odbornost na IT systémy. Funkce a rozvržení obrazovky, které uživatel požaduje, by měl základně specifikovat uživatel, a také jen uživatel může ověřit, zda je výsledek podle požadavků.

Navíc, stejně jako je dodavateli uložena povinnost řízení projektu, uživateli je uložena povinnost spolupráce. Pokud by uživatel porušil povinnost spolupráce v procesu, jak je uvedeno výše, mohl by být naopak požadován od dodavatele náhrada škody za nesplnění závazku nebo protiprávní jednání.

Jak jsou interpretovány požadavky na změnu specifikací po dokončení

Pokud předpokládáme, že projekt vývoje systému je společnou prací uživatele a dodavatele, diskuse se dále rozvíjí. Jde o otázku, kdo nese odpovědnost, pokud uživatel požádá o přidání nebo úpravu funkce a tím se stane obtížným dodržet termín.

Vývoj systému obecně začíná definicí požadavků, následuje základní návrh, detailní návrh, výroba (implementace programu), testování atd., s cílem minimalizovat opakování práce (obecně známé jako vodopádový model). Avšak v praxi se často stává, že se objeví nedostatky v předchozích fázích a dochází k opakování práce.

Jak bychom měli přemýšlet, pokud se nesplní termín v takových případech? Při čtení minulých rozhodnutí se zdá, že závěr se liší v závislosti na okamžiku, kdy došlo k dodatečné práci.

Pokud došlo k dodatečné práci před zpřesněním specifikací, jako je vnější návrh

Výše uvedený případ ukazuje, že není porušením povinnosti spolupráce, pokud uživatel požaduje dodatečný vývoj během základního návrhu (před implementací programu).

Je samozřejmé, že uživatel požaduje různé požadavky na systém, který se má vytvořit během základního návrhu, a navíc, u uživatele bez odborných znalostí, je obtížné správně posoudit, zda tyto požadavky vyžadují dodatečné poplatky nebo odklad dodání, zda způsobují problémy v pracovním procesu, atd. Proto nelze říci, že uživatel by měl omezit požadavky, které vyžadují dodatečné poplatky nebo odklad dodání. Naopak, pokud uživatel požaduje požadavky, které vyžadují dodatečné poplatky nebo odklad dodání, dodavatel, který má povinnost řízení projektu, by měl informovat uživatele o tomto faktu, požadovat diskusi o stáhnutí požadavku nebo o odkladu dodání, atd., aby nedošlo k problémům v vývoji.

Rozhodnutí Tokijského okresního soudu ze dne 10. března 2004 (2004)

Toto rozhodnutí potvrdilo, že i na straně uživatele existuje určitá povinnost spolupráce, a zároveň poukázalo na to, že uživatel není odborníkem na vývoj systémů. Jinými slovy, pokud uživatel, který objednává, není odborníkem na vývoj systémů, není neobvyklé, že během období, kdy se obsah systému stává jasným, předkládá objednávky po kouscích (někdy dokonce není zvyklý objednávat) a je nespravedlivé očekávat, že si “uvědomí sám”, pokud jeho objednávka vyžaduje přehodnocení termínů dodání atd.

Avšak povinnost dodavatele zde znamená především úsilí o komunikaci, jako je požadavek na odklad termínu dodání (nebo pokud nelze termín dodání posunout, navrhnout stáhnutí dodatečného požadavku), atd. Proto je třeba poznamenat, že to neznamená, že zahrnuje všechny povinnosti, včetně dodání v původním termínu po přijetí všech požadavků uživatele.

Pokud došlo k dodatečné práci po potvrzení specifikací výrobního nebo testovacího procesu

Pokud obrátíme obsah výše uvedeného rozhodnutí, můžeme do určité míry předpovědět, jaký by byl závěr, pokud by šlo o dodatečný vývoj po potvrzení specifikací. V tomto případě by bylo obtížné splnit takové požadavky. Je pravda, že rozdíl v porozumění vývojovým pracím mezi uživatelem a dodavatelem se nemění, ať už je to před nebo po potvrzení specifikací.

Avšak změna nebo přidání objednávky po potvrzení specifikací často vyžaduje opakování práce. V mnoha případech je obtížné obhajovat zpoždění dodání způsobené tím, že “je samozřejmé, že zákazník má různé požadavky”. Navíc, pokud dojde k mnoha změnám specifikací nebo přidání funkcí po dokončení, může to vyvolat otázky, zda nebylo porušení povinnosti spolupráce na straně uživatele již v předchozích fázích, jako je základní návrh, který měl být již dokončen.

Z těchto důvodů se zdá nepravděpodobné, že by dodavatel nesl odpovědnost za zpoždění dodání způsobené změnou specifikací provedenou po potvrzení specifikací. Z výše uvedeného rozhodnutí lze spravedlivě vyčíst také tento význam.

Navíc, takové rozhodnutí se často provádí na základě důkazů, jako jsou zápisy ze schůzí, které odpovídají pokroku vývoje systému, nejen na základě smlouvy. Podrobnosti o zápisech ze schůzí jsou vysvětleny v následujícím článku.

Související článek: Jak správně vést zápisy ze schůzí při vývoji systémů z právního hlediska[ja]

Shrnutí: Je důležité nezapomenout, že definice požadavků je procesem na straně uživatele

Definice požadavků je místem, kde dodavatelé ukazují své dovednosti, ale především bychom měli být vědomi toho, že je to proces na straně uživatele. Pokud jde o systém, který vaše společnost používá, i když ho vytváříte s pomocí externích odborníků, z právního hlediska by mělo být předpokládáno, že je to oblast, která by měla být pod kontrolou vaší společnosti.

Pokud uživatelé nejsou v procesu vývoje spolupracující, soudy mohou mít přísný názor na uživatele, i když projekt selže. Tento bod byste měli nejprve pochopit.