Mik a jogi és szerződéses problémák az agilis fejlesztéssel kapcsolatban?

A rendszerfejlesztés előrehaladásának módszertana létezik. A legklasszikusabb és legáltalánosabb a vízesés modell, és számos rendszerfejlesztéssel foglalkozó jogi könyv is ezt a modellt feltételezi. Ebben a cikkben megvizsgáljuk, milyen jogi problémák merülhetnek fel az agilis fejlesztési modellen alapuló rendszerfejlesztés során, amelyről nehezen szerezhető információ a könyvekből és egyéb forrásokból.

Az agilis fejlesztési modell és a jog

Mi az a fejlesztési modell a rendszerfejlesztésben?

A rendszerfejlesztési projektekben létezik egy fejlesztési modell, amely keretként szolgál az előrehaladás teljes körű megértéséhez. Ennek legismertebb példája a “vízesés modell”. Ez azt jelenti, hogy – akárcsak a víz, ami a folyó “felső” részéről “alsó” részére zuhan – a követelmények meghatározása, a tervezés, a megvalósítás, a tesztelés stb. folyamatait egyszerre, egyetlen lépésben végrehajtjuk. A cél az, hogy minimalizáljuk a visszalépéseket és a dupla munkát, és tervezetten haladjunk előre a feladatokkal.

Ezzel szemben az agilis fejlesztési modellben kis programokat valósítunk meg, majd teszteljük őket, és ezt a folyamatot ismételgetjük. Így, a kis programok megvalósításának és tesztelésének ismétlődő folyamata során fokozatosan építjük fel a nagy rendszert. A rendszerfejlesztési modellek részletesebb leírását, valamint a két fejlesztési modell előnyeinek és hátrányainak összehasonlítását a következő cikkben találhatja meg.

https://monolith.law/corporate/legal-merits-and-demerits-of-development-model[ja]

Az agilis fejlesztési modell jellemzői

Az agilis fejlesztési modell nagy előnye, hogy gyorsan belevághatunk a tényleges munkába. Mivel a követelmények meghatározása és a tervezési dokumentáció készítése, azaz az “upstream” feladatok, és a program megvalósítása nem választottak el egymástól, ezért rugalmasan irányíthatjuk a munkát, beleértve a funkciók hozzáadását, módosítását, a specifikációk változtatását stb. Jogilag nézve, az agilis fejlesztési modell sikerének kulcsa, hogy hogyan kezeljük a dokumentumokat és a változásokat. Az agilis fejlesztési modellben nincsenek olyan világosan meghatározott szerepek és felelősségek, mint a vízesés modellben. Emellett, mivel a “kezelés” helyett a “gyorsaság” a prioritás, ez könnyen vezethet a tervezési dokumentációk, specifikációk, jegyzőkönyvek hiányosságaihoz.

Továbbá, a változáskezelés szempontjából, mivel az agilis fejlesztési modellben a változások kezelése gördülékeny, könnyen előfordulhat, hogy a jóváhagyási folyamatot kihagyva, a helyszíni szinten válaszolunk a specifikációk változtatására irányuló kérésekre, ami a projekt kudarcához vezethet. Ha ez bekövetkezik, az “a változások kezelése gördülékeny” fejlesztési modell előnye maga is a projekt kudarcának kockázatává válhat.

Az agilis fejlesztésben alkalmazott dokumentumkezelés és változáskezelés módszerei

A dokumentumkezelés fontossága

Az agilis fejlesztési modell alapján végzett fejlesztési projektekben a jogi aggályok közé tartozik, hogy a szóbeli kommunikáció felhalmozódik, és hiányosságokat okoz a dokumentációban. Ezzel kapcsolatban, hogy miért fontos a dokumentumkezelés a rendszerfejlesztési projektekben, részletesen tárgyaljuk az alábbi cikkben.

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

A cikkben két szempontból magyarázzuk el a dokumentumkezelés fontosságát a rendszerfejlesztési projektekben: a viták előzetes megelőzése (vagyis a “megelőző jogi munka”) és a bizonyítékok megőrzése vitás helyzetekben (vagyis a “válságkezelés”).

A kapcsolattartó tanácskozások hatékonyak a dokumentumkezelésben

Ha az agilis fejlesztési modellt alkalmazzuk, ellentétben a vízesés modell esetével, nincs előre elkészített világos tervünk. Emiatt nem elég csak a terv és a tényleges eredmények közötti eltérést kezelni, mert ha a helyszínen hagyjuk, a költségek időben és pénzben is megnőhetnek.

Ezért hatékony intézkedés, ha a felelős személy rendszeresen tart kapcsolattartó tanácskozásokat a projekt zökkenőmentes előrehaladása érdekében. Ha a fejlesztési méret kicsi, valóban, inkább előnyös, ha a felelősök találkoznak, amikor össze tudnak gyűlni, mint rendszeresen tartani kapcsolattartó tanácskozásokat. Azonban az agilis fejlesztési modell esetében különösen nagy a veszélye annak, hogy a tanácskozásokon időben nem kezelik a felmerülő problémákat. Ezért biztonságos, ha a rendszeres kapcsolattartó tanácskozásokat beépítjük a szerződésbe is. A szabályozás módja a Japán Gazdasági, Kereskedelmi és Ipari Minisztérium (METI) modellszerződésében a következőképpen van meghatározva:

(A kapcsolattartó tanácskozás létrehozása)

12. cikk A és B, a projekt végéig, a projekt előrehaladásának, a kockázatkezelésnek és jelentésnek, az A és B közös munkájának és egyéni feladatainak végrehajtásának, a rendszer specifikációkban szereplő tartalom megerősítésének, a problémák megvitatásának és megoldásának, és más szükséges kérdések megvitatására, kapcsolattartó tanácskozást tartanak. Azonban, (köztes elhagyás).

2. A kapcsolattartó tanácskozást alapvetően rendszeresen tartják az egyedi szerződésben meghatározott gyakorisággal, és ezen felül, ha A vagy B szükségesnek tartja, bármikor megtartják.

3. A kapcsolattartó tanácskozáson A és B felelősei, a fő felelősök és azok, akiket a felelősök megfelelőnek tartanak, részt vesznek. Ezenkívül A és B képes kérni a másik fél részvételét a kapcsolattartó tanácskozáson szükséges megbeszélésekben, és a másik félnek, kivéve ha van ésszerű ok, válaszolnia kell erre.

4. B, a kapcsolattartó tanácskozáson, elkészíti és benyújtja a haladási jelentést az A és B között külön megállapodott formátumban, és megerősíti a haladási állapotot a haladási jelentés alapján, valamint megvitatja és meghatározza a késések jelenlétét, a késések okait és megoldásait, a fejezetben meghatározott előrehaladási struktúra változásait (személyzet cseréje, növekedése, csökkenése, alvállalkozók cseréje stb.), a biztonsági intézkedések végrehajtásának állapotát, az egyedi szerződés módosításának szükségességét, és ha van olyan ok, ami miatt módosítani kell az egyedi szerződést, annak tartalmát, és megerősíti a meghatározott kérdéseket, a folyamatosan vizsgálandó kérdéseket és a folyamatosan vizsgálandó kérdések esetén a vizsgálati ütemtervet és a vizsgálatot végző feleket.

(A továbbiakban a 5., 6. és 7. pontokat kihagyjuk.)

A kapcsolattartó tanácskozás létezése a szerződési záradékokban is bizonyos jogosságot biztosít, és eltérő jelentést ad a helyszíni találkozóktól. Ez a legfontosabb pont.

Az egyeztetőbizottság alkalmazása a változáskezelésben

Az agilis fejlesztésben előfordul, hogy a felek által eredetileg megállapodott kérdések utólag megváltoznak, ez alapvető feltétel. Ezért rendkívül fontos, hogy hogyan kezeljük az utólagos specifikációváltozásokat.

Ha rendszeresen tartanak egyeztetőbizottsági üléseket, a változáskezelés is nagyon gördülékenyen megy. Például, a változásokat az egyeztetőbizottságban tárgyalják meg, és ha az egyik fél változtatási javaslatot tesz, a másik fél köteles ezt a megbeszélést a szerződésbe foglalni. (Az alábbiakban kivonatokat közlünk a Japán Gazdasági, Kereskedelmi és Ipari Minisztérium (METI) modellszerződéséből.)

(Változáskezelési eljárás)

37. cikk: Ha az A vagy B fél változtatási javaslatot kap a másik féltől (…), akkor a kézhezvétel napjától számított ○ napon belül írásban (a továbbiakban “változáskezelési dokumentum”) adja át a másik félnek, és az A és B fél megvitatja a változás elfogadhatóságát az 12. cikkben meghatározott egyeztetőbizottságban. (A továbbiakban a részleteket mellőzzük)

A fenti rendelkezés fő pontjai a következők:

• A változások bejelentésének módját egységesítették a “változásjavaslati dokumentum” formátumban.
• A javaslat kézhezvételétől a megbeszélésig terjedő időszakra határidőt állapítottak meg → Nem szükséges a “◯ napon belül” kifejezést használni, helyette gondolhatunk olyan szavakra, mint “haladéktalanul”.
• A változások elfogadhatóságának megvitatásának helyét egységesítették az “egyeztetőbizottság” megnevezésű testületben.

Tehát, hogy elkerüljék a félreértéseket, mint például “bejelentettem a változást, nem jelentettem be”, “válaszoltam a változás elfogadhatóságára, nem válaszoltam”, az eljárás módját tisztázták.

Az őszinteség kötelezettsége és a jóhiszeműség megértése kerül kérdésre

Eddig bemutattuk a “Kapcsolattartó Tanácskozás” és a “Módosítási Megbeszélés” szerződési záradékok modelljeit. Azonban ezek alapvető megértéséhez fontos a “őszinteség kötelezettsége” és a “jóhiszeműség” kérdésköre. Az agilis fejlesztési modell alapvetően nehézkes lehet a megrendelő és a szolgáltató közötti bizalmi viszony nélkül. Ennek oka, hogy a tényleges munkába való bekapcsolódás sebességét hangsúlyozza, és a bekapcsolódásig tartó eljárásokat minimálisra csökkenti. Ezért gyakori a gyakorlatban, hogy a másik félre “őszinteség kötelezettségét” rója.

4. cikk 3. bekezdés: A módosítási megbeszélés során meg kell vizsgálni a módosítás tárgyát, a módosítás lehetőségét, a módosítás által okozott költség- és határidőbeli hatásokat, és mindkét félnek őszintén meg kell vitatnia, hogy módosítást hajtson-e végre.

Ez megakadályozza, hogy a kezdeti bizalmi viszonyon alapuló tárgyalások során hirtelen “a szerződés módosításának elfogadása vagy elutasítása kizárólag az ajánlatot elfogadó fél szabadon dönthet, és nincs kötelezettsége a kényszernek engedni” stb., formális jogi érveléssel megtévesztse a másik felet. Ez tükrözi a magánjogi ügyletekkel kapcsolatos jogi alapelveket, nem csak a rendszerfejlesztésre vonatkozik.

Polgári Törvénykönyv 1. cikk 2. bekezdés

A jog gyakorlása és a kötelezettségek teljesítése jóhiszeműen és őszintén kell, hogy történjen.

A jog nem feltétlenül csak a “szerződési dokumentumok tartalmát” vagy a “cikkelyek szövegét” tiszteli. Különösen, ha a másik fél részt vesz az ügyletben, rugalmasan kell alkalmazni a “jóhiszeműséget” és az “őszinteséget”. Egyébként a jog által előírt “kötelezettség” nem feltétlenül alapul a “szerződés” eljárásán, erről részletesen tárgyalunk az alábbi cikkben.

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

Összefoglalás

Az agilis fejlesztési modell alapján működő rendszerfejlesztési projektekben természetesen fontos megérteni a kockázatot, hogy az adminisztratív eljárások és a menedzsment struktúra fokozatosan hanyagolhatóvá válik. Azonban nem csak ez a lényeg, hanem az is, hogy megértsük a jogi rendszer, például a “jóhiszeműség elve” által meghatározott rugalmas jellemzőit, és ezt a gyakorlatban is alkalmazzuk. Ez is fontosnak tekinthető.