A rendszerváltozások kezelésének módja a rendszerfejlesztésben, jogi szempontból nézve

A rendszerfejlesztési projektekben gyakran előfordul, hogy a felhasználók által előzetesen ismertetett tartalmak a munka előrehaladtával megváltoznak. Emiatt a munkát vállaló szolgáltatók számára is előfordulhat, hogy a már megkötött szerződéseket is módosítaniuk kell a szerződéses tartalom későbbi változásaihoz igazodva.

Ebben a cikkben jogi szempontból megvizsgáljuk, hogyan kell kezelni a “változás” jelenségét a nem a tervek szerint haladó rendszerfejlesztési projektekben.

Miért “változnak” a rendszerfejlesztési projektek utólag?

A rendszerfejlesztés a szolgáltató és a felhasználó közös munkája

A rendszerfejlesztés általában a tervezési és javaslati szakasz után kezdődik, amikor a fejlesztési követelmények meghatározásra kerülnek, és a szerződés megkötésre kerül. A szerződés megkötése után általában a különböző tervek elkészítése, majd a tervek szerinti megvalósítás következik, végül a tesztelés lezárja a folyamatot. Az egész folyamat során a szolgáltató, mint a rendszerfejlesztés szakértője, természetesen széles körű kötelezettségeket vállal, de a felhasználói oldalon is bizonyos együttműködési kötelezettségek vannak. Különösen fontos a felhasználói együttműködés a rendszer által betöltendő funkciók meghatározása (azaz a követelmények meghatározása), a képernyő megjelenése és kezelhetősége (azaz az alapvető tervezés), valamint a követelményeknek megfelelően elkészült-e a rendszer (azaz a tesztelés vagy az átvétel) során. A felhasználók által a rendszerfejlesztés során vállalt kötelezettségekről általános magyarázatot találhat az alábbi cikkben.

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

Az együttműködési kötelezettség ellenére a felhasználók gyakran kérnek változtatásokat

Az a felhasználó, aki nem rendszerfejlesztési szakértő, nem mindig képes tervezetten és átfogóan közölni a szolgáltatóval a rendszerfejlesztéshez szükséges információkat. A valóságban, mivel ez egy aprólékos és precíz munka, a felhasználók gyakran nem tudják előre jelezni, mely tények lesznek döntő jelentőségűek a későbbi fázisokban. Ezért ironikus módon, a legfontosabb tények gyakran csak később, apránként kerülnek elő. Ebből adódóan, a valós projektekben, bár az ideális az lenne, ha a “felső fázistól az alsó fázisig egyetlen lépésben” haladnánk, gyakran előfordul, hogy utólag különböző változtatásokat kell végrehajtani. Ezért fontos, hogy hogyan kezeljük a “változáskezelést”.

Mi az a változáskezelési dokumentum?

Mikor használják a változáskezelési dokumentumot?

A változáskezelési dokumentum olyan irat, amelyet a felhasználók használnak, amikor a szolgáltatótól specifikációk módosítását vagy új funkciók hozzáadását kérik az előzetesen adott magyarázatoktól eltérően. Ahogy korábban említettük, a követelmények meghatározása és az alapvető tervezési fázisban a felhasználóknak is kötelességük együttműködni a szolgáltató munkájával, de a későbbi folyamatokban előfordulhat, hogy különböző igényeket fogalmaznak meg.

Például a változáskezelési dokumentum szükségessé válhat a következő esetekben:

• Ha a követelmények meghatározása és az alapvető tervezés során valami elmaradt, és utólag kérnek új funkciókat
• Ha a fejlesztés közben a vállalkozás irányvonalát felül kell vizsgálni, és szükség van a specifikációk módosítására

Ezek csak néhány példa a lehetséges esetekre.

Megjegyzendő, hogy a funkciók hozzáadása vagy a specifikációk módosítása kapcsán a szolgáltató számára a legfontosabb kérdés az, hogy a becsült költség módosítása jogilag elfogadható-e. Ezt a kérdést részletesen tárgyaljuk egy másik cikkben.

https://monolith.law/corporate/increase-of-estimate[ja]

A változáskezelési dokumentum szolgál alapként a becsült költség utólagos növelésének tartalmának ésszerűségének megítéléséhez. A növelt becsült költség alapján történő számlázás során fontos a változáskezelési dokumentum elkészítése, hogy elkerüljük a vitákat a másik féllel (és hogy meggyőző érveket tudjunk felhozni, ha vita alakul ki).

A változáskezelési dokumentum tartalmi elemei

De milyen elemeket kell tartalmaznia a változáskezelési dokumentumnak jogi szempontból? A változáskezelési dokumentum használata, amely szerződési mechanizmusként szolgál a specifikációk módosítására és a funkciók hozzáadására, már általánosan elismert és széles körben elfogadott. Ennek megfelelően, ha megnézzük a Japán Gazdasági, Kereskedelmi és Ipari Minisztérium (METI) által javasolt szerződési záradékok sablonját, nagyjából megérthetjük, milyen elemeket kell dokumentálni.

(Változáskezelési eljárás)
37. cikk Ha az A vagy B fél megkapja a másik fél változtatási javaslatát a 34. cikk (Rendszerspecifikációk és egyéb változások), a 35. cikk (Köztes dokumentumok felhasználói jóváhagyása) vagy a 36. cikk (Nem meghatározott kérdések kezelése) alapján, akkor a megkapott napotól számított ○ napon belül, a következő elemeket tartalmazó írásos dokumentumot (a továbbiakban “változáskezelési dokumentum“) kell átadnia a másik félnek, és az A és B félnek a 12. cikkben meghatározott kapcsolattartó tanácskozáson meg kell vitatnia a változás elfogadhatóságát.
① A változás neve
② A javaslat felelőse
③ Dátum
④ A változás indoka
⑤ A változás részletes adatai, beleértve a specifikációkat
⑥ Ha a változás költségeket igényel, annak összege
⑦ A változás munkájának ütemterve, beleértve a vizsgálati időszakot
⑧ A változás hatása a szerződés és az egyedi szerződés feltételeire (munkaidő vagy határidő, megbízási díj, szerződési záradékok stb.)

Ha közvetlenül olvassuk a szöveget és megnézzük az ajánlott elemeket, nincs szükség további magyarázatra. A “mondta-nem mondta” problémák elkerülése érdekében részletesen és konkrétan kell dokumentálni a változásokat.

Ha ezeket az elemeket világosan rögzítjük, és hozzáadjuk a szállító és a felhasználó felelősének vagy döntéshozójának aláírását vagy pecsétjét, akkor még akkor is, ha pereskedésre kerül sor, a dokumentum bizonyítékként szolgál, és ugyanolyan jelentőséggel bír, mint a szerződés.

Amit érdemes tudni a változáskezelésről

A változáskezelést általában feladatkezeléssel együtt kell végrehajtani

A változáskezelési dokumentum elkészítésének oka abban rejlik, hogy a változások nyomon követésével a projektet a megvalósítás felé vezetjük (vagy ha nem sikerült elérni a céljainkat, elkerüljük a jogosulatlan felelősségvállalást). A gyakorlatban a változáskezelési dokumentum elkészítése gyakran együtt jár a feladatkezelési lista elkészítésével és frissítésével. Vagyis, ha a változásokat a változáskezelési táblázatban kezeljük, az elfogadott változásokat a jövőbeni feladatokként beépítjük a feladatkezelési listába.

A változások megvitatásának módját is érdemes szabályozni

Nem csak a változáskezelés módját, hanem a változások megvitatásának módját is érdemes szabályozni, hogy a változások kezelése zökkenőmentesen menjen. Ez különösen fontos az agilis fejlesztésnél, ahol a változások utólagos bevezetése alapvető. A gyakorlatban is gyakran előfordul, hogy ha változáskezelési megbeszélésre van szükség, meghatározzák, hogy a másik félnek mennyi idő alatt kell válaszolnia.

Változáskezelési megbeszélések és a jóhiszeműség kötelezettsége

Ha a felek megállapodtak egy szerződésben, és utólag megváltoztatják azt, ez gyakorlatilag új szerződéskötést jelent. Mivel a szerződés az érintett felek szabad akaratán alapul, elvileg a szolgáltatót nem kötelezi a változások elfogadása. Azonban, ha túlságosan hangsúlyozzuk ezt a jogot, előfordulhat, hogy a rendszerfejlesztési projekt nem halad zökkenőmentesen.

Ezért a gyakorlatban gyakran előfordul, hogy a szerződésben kifejezetten megjelölik a “jóhiszemű egyeztetési kötelezettséget”, és ha a szolgáltató nem jár el jóhiszeműen a változásokkal kapcsolatban, akkor kártérítési igényt is benyújthatnak.

Például a következő szöveg szerepelhet a szerződésben (az alábbiakban a szerződési cikk példáját közöljük, amelyet az Independent Administrative Institution Information Processing Promotion Agency hivatalosan készített “ff Basic / Individual Contract Model Basic Contract Proposal” című dokumentumból idéztünk):

4. cikk 3. bekezdés: A változások megvitatásakor meg kell vizsgálni a változás tárgyát, a változás lehetőségét, a változás ár- és határidőre gyakorolt hatását, és mindkét félnek jóhiszeműen meg kell vitatnia, hogy végrehajtja-e a változást.

A változások végrehajtásának szabályozása

Ahogy korábban említettük, a változások végrehajtásakor jogilag “biztonságosabb”, ha minden egyes változás esetén megbeszélést tartunk. Azonban egy kisebb projekt esetén előfordulhat, hogy nem szükséges meghatározni a változások megvitatásának módját. Ebben az esetben nem a megbeszélés szabályozását kell beállítani, hanem a változáskezelési dokumentumot a felhasználó és a szolgáltató felelősének aláírásával és pecsétjével hitelesíteni, és csak ekkor hajtják végre a változásokat. Ha a változásokat csak szóban egyeztetik, akkor gyakran homályos, hogy ténylegesen történt-e változás, és ez később nagy problémákat okozhat, ezért a dokumentumkezelést alaposan végre kell hajtani.

Természetesen előfordulhat, hogy a változáskezelési dokumentumok elkészítése minden alkalommal terhes, és inkább a rugalmas reagálást részesítik előnyben. Ilyen esetekben érdemes lehet a változásokat a megbeszélések jegyzőkönyvében dokumentálni. A rendszerfejlesztési megbeszélések jegyzőkönyvének megőrzéséről az alábbi cikkben talál részletes magyarázatot.

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

Összefoglalás

A gyakori specifikációváltoztatásokkal működő helyeken valóban hajlamosak lehetünk a problémákra és vitákra. Azonban, ezekben a helyzetekben, ahol rugalmasság szükséges, a “menedzsment fontosságának” merev hangsúlyozása nem mindig vezet valós, megvalósítható intézkedésekhez.

Az üzleti sebesség és a váratlan eseményekre való felkészülés közötti egyensúly megtalálása gyakran változik a cég helyzetétől és a projekt tartalmától függően. Úgy gondoljuk, hogy fontos a hozzáállás, hogy minden cég és projekt esetében keresse a megfelelő megoldást, figyelembe véve a cikkben tárgyalt tartalmat.