A 'kigyulladás' jogi vonatkozásai a rendszerfejlesztési projektekben

A rendszerszoftver-fejlesztési projektek nem valósíthatók meg egyik napról a másikra, hanem számos ember, szervezet, jelentős pénzügyi források és hosszú fejlesztési időszakok bevonásával valósulhatnak meg. Ebben a cikkben bemutatjuk, hogy a rendszerszoftver-fejlesztési projektek “kiégésének” jelensége hogyan rendezhető a jogi keretrendszer alapján, és összefoglaljuk a megoldások irányelveit.

Miért „égnek le” a projektek?

Egy IT rendszer, még ha nem is különösen nagy méretű projekt, csak akkor működik megfelelően, ha rengeteg programfájl és forráskód van összehordva. Az interfészről nézve a működés sokkal bonyolultabb, mint amit elképzelhetnénk (vagy éppen ellenkezőleg, minél egyszerűbb és tömörebb az interfészről nézve az IT rendszer), gyakran nagyon aprólékos és precíz a kialakítása.

• A határidő már megvan, de a specifikációk és követelmények még mindig homályosak, és az idő csak telik
• A csapattagokat csak a cég belső politikai problémái foglalkoztatják, és sokan közülük a személyes kapcsolatokból adódó stressz miatt idő előtt kiszállnak
• A projektmenedzser és a menedzsment réteg is hiányos a tárgyalási készségekben, és nem kérik meg a csapattagokat a megfelelő jelentések, kommunikáció és konzultációk elkészítésére

A projektek konkrét „leégésének” okai projekt-specifikusak lehetnek. Azonban jogi szempontból a projektek „leégésének” okait viszonylag egyszerűen lehet csoportosítani néhány típusba.

Tűzvész típus 1: Amikor a projekt félúton meghiúsul

A rendszerfejlesztés során gyakran előfordul, hogy a projekt félúton meghiúsul, és ennek tipikus oka a felhasználók és a szolgáltatók közötti kommunikációs zavar. A rendszerfejlesztési projektekben a szolgáltatók szakmai technikai és szervezeti képességei nélkülözhetetlenek, de a végső felhasználók együttműködése is elengedhetetlen a projekt sikeréhez.

Ha egy projektben nem tisztázott, hogy milyen szerepet vállalnak a felek, és a projekt halad előre anélkül, hogy ezt tisztáznák, akkor előfordulhat, hogy a munka “odacsapódik” egymásnak, ami akadályozza a projekt zökkenőmentes előrehaladását. A felhasználók és a szolgáltatók kötelezettségeiről, valamint a jogi megfontolásokról az alábbi cikkekben olvashat bővebben.

https://monolith.law/corporate/project-management-duties[ja]

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

A felek által vállalt felelősségek részleteit az előző cikkekben találja, de a lényeg, hogy egy rendszerfejlesztési projektben mind a felhasználóknak, mind a szolgáltatóknak vannak bizonyos felelősségeik. Nagy vonalakban a követelmények meghatározása, a felület tervezése (azaz az alapvető tervezés), az átvétel és más, a felhasználók együttműködése nélkül nem teljesíthető feladatok esetében a bíróságok elismerik a felhasználók együttműködési kötelezettségét.

Másrészről a szolgáltatóknak is vannak kötelezettségeik, például a projekt zökkenőmentes előrehaladásának biztosítása, a problémák azonosítása és megoldása, valamint a felhasználók támogatása (és ugyanakkor a kommunikációs erőfeszítések megtétele).

Ezen gondolkodásmód alapján a bíróságok azt várják el, hogy a felhasználók belső rendszereiként gyakorolják a kormányzást, míg a szolgáltatók külső szakértőkként mutassák be szakmai és technikai képességeiket, és mindkét fél hozzáállása legyen a konfliktusok igazságos kezelése.

A “meghiúsulás” gyakran az átvétel során következik be. Az átvételről részletesen olvashat az alábbi cikkben.

https://monolith.law/corporate/estimated-inspection-of-system-development[ja]

Ilyen esetekben, ha konfliktus alakul ki, a bíróságok nagy hangsúlyt fektetnek a korábbi projektek alakulására, a megbeszélések tartalmára és más objektíven ellenőrizhető bizonyítékokra. Ezért a korábban rögzített dokumentumok nagy jelentőséggel bírnak. A dokumentumkezelés alapvető fontosságú a saját pozíciójának védelme érdekében. A rendszerfejlesztés során a dokumentumkezelés fontosságáról az alábbi cikkben olvashat bővebben.

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

Tűzvész típus 2: Felhasználói oldali lemondás saját érdekből

Előfordulhat, hogy a projekt közepén a felhasználói oldal kérésére a projektet leállítják. Például, ha egy vállalat elkezd egy IT rendszert építeni, amely egységesen kezeli a személyzeti adminisztrációt, beleértve a külföldi irodákat is, és a vállalat visszavonja a külföldi terjeszkedési stratégiáját, akkor a rendszer fejlesztése már nem szükséges a felhasználó számára.

Alapvetően az, hogy milyen IT rendszert kell építeni egy vállalatban, nem választható el attól a kérdéstől, hogy milyen munkafolyamatok vannak a vállalatban. Ezért, ha jelentős változások történnek a szervezeti struktúrában vagy az üzleti egységekben, vagy ha a stratégiát alapvetően felülvizsgálják, akkor a szükséges (vagy már nem szükséges) rendszer követelményei is megváltozhatnak.

Ilyen körülmények között, ha a projektet közben felfüggesztik, számos jogi kérdés merülhet fel. Ilyen esetekben általában a felhasználó saját érdeke miatt történik a felfüggesztés, így a szolgáltató oldalnak is bizonyos jogi jogai vannak, például a munka befejezési arányának megfelelő díjazás. A konkrét jogalap a szerződés típusától függ, de általánosságban az alábbiak szerint rendezhető:

・Megbízási szerződés esetén: Polgári Törvénykönyv 641. cikk
Polgári Törvénykönyv 641. cikk
→ A megbízott munkájának befejezése előtt a megbízó bármikor felmondhatja a szerződést, kártérítés fizetése mellett.
・Közvetett megbízási szerződés esetén: Polgári Törvénykönyv 648. cikk 3. bekezdés (a helyzettől függően a Polgári Törvénykönyv 651. cikk alapján kártérítési igény is felmerülhet)
Polgári Törvénykönyv 648. cikk
→ Ha a megbízás a megbízott hibájából nem teljesíthető és a teljesítés közben megszakad, a megbízott a már teljesített munka arányában díjat igényelhet.
Polgári Törvénykönyv 651. cikk
→ 1. A megbízást mindkét fél bármikor felmondhatja.
→ 2. Ha az egyik fél a másik fél számára hátrányos időpontban mondja fel a megbízást, akkor a felmondó félnek kártérítést kell fizetnie a másik félnek. Ha azonban elkerülhetetlen okból történt a felmondás, akkor ez nem érvényes.

Összefoglalás

Az egyes rendszerfejlesztési projektek változatos és sokszínű kihívásokon mennek keresztül. Azonban, ha a jogi projektek “kigyulladásáról” beszélünk, a cikkben bemutatott keretrendszer szolgálhat egyfajta áttekintő térképként. A rendszerfejlesztéssel kapcsolatos jogi kérdések valóban számos különböző témát foglalnak magukban.

Ugyanakkor, ahogyan a rendszerfejlesztési munka konstruktív gondolkodást igényel, úgy a hozzá kapcsolódó kockázatkezelés is hatékonyabban végezhető el, ha nem veszítjük szem elől a teljes képet. Nem gondolják?