A jogi szempontból mennyire kell megvalósítani azokat a funkciókat, amelyek nem szerepelnek a rendszerfejlesztési specifikációban?

A vállalatok által használt IT rendszereket fejlesztő projektek alapvetően előre meghatározott specifikációk szerint készülnek. Azonban, ha figyelembe vesszük, hogy a szállítókat a rendszerfejlesztés szakértőiként teljes mértékben megbízzák a fejlesztési feladatokkal, akkor a felhasználói elvárások talán nem olyan alacsonyak, hogy csak a specifikációban leírtakat kellene mechanikusan implementálni. Ebben a cikkben megvizsgáljuk, hogy milyen mértékben kellene vállalni a felelősséget azokért a programokért, amelyeket “nem szerepelnek a specifikációban, de a fejlesztés céljának megfelelően implementálni kell”.

A specifikáción kívüli implementációval járó jogi problémák

A szolgáltató munkájától mérlegelés várható

A rendszerfejlesztési projektekkel kapcsolatos szerződések és a hozzájuk kapcsolódó különféle jogi kérdések jellemzője, hogy a munkát vállaló szolgáltatónak nagy mérlegelési jogköre van.

Kapcsolódó cikk: Mi a projektmenedzsment kötelezettsége a rendszerfejlesztésben[ja]

Ugyanakkor, a “mérlegelés” itt nem feltétlenül vonatkozik a rendszerfejlesztési folyamat minden részére. A részletes feladatok kiválasztása után gyakran előfordul, hogy a munka egyszerűbb feladatokra redukálódik. Azonban általánosságban elmondható, hogy minél inkább a folyamat elején vagyunk, annál nagyobb mérlegelési jogkör nélkül a munka végrehajtása nehézkessé válik. Ezért is illik gyakran a szerződési típusokhoz a megbízási szerződés.

Kapcsolódó cikk: A rendszerfejlesztésben alkalmazott szerződés és a megbízási szerződés különbségei és hasonlóságai[ja]

A mérlegelés szigorú fejlesztési folyamatban is meg kell nyilvánulnia

Ugyanakkor, annak ellenére, hogy a rendszert fejlesztő szolgáltatónak nagy mérlegelési jogköre van, a “laza” hozzáállás a kliens kéréseinek elfogadásában későbbi fázisokban jelentős károkat okozhat. Egy IT rendszer apró részekből áll össze, ezért még a legkisebb változtatás is jelentős munkaidő-növekedést eredményezhet a fejlesztő szemszögéből. A rendszerfejlesztés specifikációjának megváltoztatásával kapcsolatban jogi szempontból magyarázatot adó cikkek között található az alábbi. Ez a cikk a változáskezelésről szól, de egyben tárgyalja azt is, hogy a specifikáció változása milyen nagy hatással van a munkára.

Kapcsolódó cikk: A rendszerfejlesztésben a változáskezelés módja jogi szempontból[ja]

Mit kell tenni a specifikáción túl, mint szakértő?

A rendszerfejlesztési projektek zökkenőmentes lebonyolítása érdekében fontos, hogy a fejlesztési követelményeket előre meghatározzuk, és ezeknek megfelelően tervezetten haladjunk. Ugyanakkor, vannak olyan helyzetek, amikor a rendszerfejlesztési szakértőként nem tudjuk teljes mértékben betölteni a szerepünket, ha csak a meghatározott követelményeknek megfelelően, és csak azt tesszük, amit mondanak. Ebben a dilemmában felmerül a kérdés, hogy “mi az, amit a specifikáció nem mutat be, de implementálni kellene?”

A jogi kötelezettségek a specifikációk és szerződések ‘szellemének’ megfelelően határozódnak meg

Az implementálandó tartalom, még ha a szerződésben vagy a specifikációban nincs is leírva, mégis a szerződés és a specifikáció ‘szellemét’, azaz ‘milyen jelentéssel és szándékkal lett ilyen módon megállapodva’ alapján határozódik meg. Tekintsük át az alábbiakban néhány bírósági ítéletet.

Példabírósági ítélet, amelyben a megvalósítási kötelezettséget elutasították, mert nem volt rögzítve

Az alábbi idézett bírósági ítéletben a szolgáltató által fejlesztett rendszer esetében a próbaüzemig jutottak, de a szükséges funkciók hiányában a szerződést felbontották és vita alakult ki. A felhasználók szerint hiányzott az “adatok automatikus frissítése” funkció, amelyet a rendszer fő értékesítési pontjaként hirdettek, de a bíróság nem ismerte el ezt a megvalósítási kötelezettséget.

A fentiekben megerősítettük, hogy a jelen szerződésben, valamint az alapvető és részletes tervezési dokumentációban nincs olyan megjegyzés, amely azt mutatná, hogy a ③ funkció a jelen rendszer fejlesztésének tárgya.

A felperes azt állítja, hogy a ③ funkció a vádlott fő értékesítési pontja volt a felperes számára, és hangsúlyozza ennek a funkció szükségességét, de ha ez az állítás igaz, akkor ezt a tényt a szerződésben és más dokumentumokban is rögzíteni kellett volna, és nehéz elképzelni, hogy a funkció fejlesztéséről megállapodtak volna, ha ez nem történt meg.

Tokiói Kerületi Bíróság, 2009. február 18. (Heisei 21)

Az említett ítélet valóban egyszerűen összefoglalva azt mondja, hogy “ha nincs rögzítve a tervezési dokumentációban, akkor nem kell megvalósítani”. Azonban pontosabban fogalmazva, nem a formai tények, mint például a tervezési dokumentációban való rögzítés, hanem a tervezési és szerződési dokumentáció “szándékának” figyelembevétele alapján hozták meg a döntést. Vagyis, “ha figyelembe vesszük, miért nem került rögzítésre a tervezési és szerződési dokumentációban, akkor ésszerűnek tekinthető, hogy nem volt megállapodás a rögzítésre”.

Ítélkezési példák, amelyek megerősítik a megvalósítási kötelezettséget, még ha ez nincs is kifejezetten leírva

Másrészről, vannak olyan ítélkezési példák is, amelyek szerint a megvalósítási kötelezettséget el kell ismerni, még ha ez nincs is kifejezetten leírva a szerződésben vagy a műszaki leírásban. Az alábbiakban idézett ítélkezési példa egy olyan esetről szól, ahol a felhasználók nem tudták átvinni az adatokat a meglévő rendszerből az új rendszerbe, amelyet a gyógyszeradagolási előzmények kezelésére fejlesztettek ki, és ezért nem tudták kihasználni az új rendszert, így felbontották a szerződést. Azonban a szolgáltató vitatkozott azzal, hogy az adatátvitel nem tartozik a munkakörébe.

Az új rendszerek fejlesztése gyakran jár a meglévő rendszerek megszüntetésével és az adatok átvitelével. A ilyen feladatok fontosságáról és a hozzájuk kapcsolódó jogi kérdésekről részletesen tárgyalunk az alábbi cikkben.

Kapcsolódó cikk: Jogi kérdések az új rendszerbe történő átállással kapcsolatban a rendszerfejlesztés során[ja]

A meglévő rendszerben már több mint 50 000 beteg adatait tárolták, és a felperes ezen adatokat használta az adminisztráció hatékonyságának növelésére. Ha a betegadatokat nem lehet átvinni a meglévő rendszerből az új rendszerbe, nyilvánvaló, hogy ez zavarokat okoz a gyógyszertárban végzett receptúra munkában, és a felperes képviselője természetesen felismerte ezt. És még a szerződéskötés előtt a felperes képviselője megkérdezte az alperes képviselőjét az adatátvitel lehetőségéről, amit az alperes képviselője is elismert (közbeiktatás), a felperes képviselője felismerte, hogy nagy valószínűséggel kézzel kell beírnia a több mint 50 000 beteg adatait, aligha gondolható, hogy mégis eldöntötte az új rendszer bevezetését. Emellett, ahogy a fent említett (1) pontban is szerepel, az alperes nem tudta átvinni a meglévő rendszer gyógyszeradagolási adatait az új rendszerbe, ezért kinyomtatta az adatokat papírra, és PDF-fájlként importálta őket, bár az adatátvitel nem volt feltételezve a szerződésben, aligha gondolható, hogy az alperes ezt a munkát végezte el szolgáltatásként.

Tokiói Kerületi Bíróság, 2010. november 18. (Heisei 22)

Itt is fontos szempont a szerződés célja és a szerződésben leírtak “szándéka”. Ha mindkét fél úgy értelmezte a szerződést, hogy az adatátvitel nem tartozik a munkakörbe, akkor a bíróság rámutatott arra, hogy mind a felhasználó, mind a szolgáltató természetellenes szándékkal kötött szerződést. Vagyis a felhasználó hatalmas mennyiségű kézi munkát vállalt, míg a szolgáltató tudta, hogy a projekt megvalósítása zavarokat okoz a felhasználó munkájában, ami rendkívül ésszerűtlen.

Mit tanulhatunk a két ítéletből?

Az adatmigrációval kapcsolatban, még ha a szerződésben vagy a műszaki leírásban nincs is róla említés, a megvalósítás kötelezettségét megerősítette, hogy a “data” olyan téma, amely nem jelenik meg a képernyőn. Az előző “hiányzó alapvető funkció” alapvetően a rendszer képernyőjén vagy megjelenésén jelenik meg. Ezért még a rendszerfejlesztési amatőrök számára sem nehéz felfedezni a műszaki leírás hiányosságait. Ezzel szemben az adatmigráció kérdése olyan jellemzővel bír, hogy a rendszerfejlesztési amatőrök számára nehezen érzékelhető a folyamat fontossága, a munka nehézsége és a munkaidő. Ezért feltételezhető, hogy a szolgáltató oldalnak szakértőként kellett volna zökkenőmentesen kezelnie ezt a kérdést.

Ha így gondolkozunk, a műszaki leírás vagy a szerződés hiányosságai szorosan kapcsolódnak a felhasználó “együttműködési kötelezettségéhez”. Vagyis az a kérdés, hogy a felhasználó valóban teljesítette-e az “együttműködési kötelezettséget” a szerződéskötés és a műszaki leírás elkészítése során. A rendszerfejlesztési projektekben a felhasználó által teljesítendő jogi kötelezettségekről általános magyarázatot találhat az alábbi cikkben.

Kapcsolódó cikk: Milyen együttműködési kötelezettségek terhelik a rendszerfejlesztés megrendelőjét, a felhasználót?[ja]

Ha megnézi a fenti cikket is, meggyőződhet arról, hogy a felhasználói együttműködés, mint például a képernyő és az alapvető funkciók azonosítása, nagy területet igényel, míg az adatmigráció elmulasztása esetén a helyzet jelentősen eltér.

Hogyan kell gondolkodni a specifikáción kívüli fejlesztési díjakról?

Az is érdekes lehet ezzel kapcsolatban, hogy ha valamit készítünk, ami nincs a specifikációban, akkor jogilag elfogadható-e a felár kérése. A felár lehetőségéről és a becsült összeg számítási módszeréről részletesen tárgyalunk az alábbi cikkben.

Kapcsolódó cikk: Lehetséges-e a rendszerfejlesztési becslés utólagos növelése[ja]

A fenti cikkben elmagyarázzuk, hogy fontos, hogy voltak-e olyan feladatok, amelyek meghaladták a díjazás és a ellenérték viszonyában meghatározott munkakört. Vagyis, ha a szolgáltató vállalja a specifikáción kívüli fejlesztést (ezt a cikket tekintve, a tagadó példát), akkor ott további díjat kérhet.

Összefoglalás

A rendszerfejlesztés során a szolgáltató szerepe egyrészről a szerződés és a specifikációk tartalmától függ. Azonban, ha figyelembe vesszük, hogy szakértőként nagyfokú bizalommal bízták meg őket a feladattal, akkor világossá válik, hogy a valóság nem csak a formai követelményekből adódik. Ugyanakkor, annak megértéséhez, hogy mi a valós helyzet, fontos megérteni, hogy a jog milyen nagy szerepet játszik ebben.