Agilis fejlesztéshez agilis szerződést!

Agilis fejlesztéshez agilis szerződést!

A cikksorozat 1. része, 2. része és 3. része után itt a folytatás, ahol rendhagyó módon nem egy éles, hanem egy szerződés sablon kerül terítékre. A sablon az Agilis Szoftverfejlesztők Szövetsége web oldalán érhető el itt: http://www.agilealliance.hu/ProfessonalMaterials/107

A dokumentum megtekintéséhez ingyenes regisztráció szükséges. Nem adok közvetlen elérést, mert nem szeretném senkinek a szerzői jogait megsérteni.

A szerződés egy feltételezett nagyvállalat és informatikai kkv közötti megállapodást körvonalazza. Az agilis fejlesztés sok szempontból eltérő a hagyományos fejlesztési folyamattól, ezért szükséges a módszertanhoz jobban illeszkedő megállapodással előállni.

Nagyon örülök, hogy valaki végre kézbe vette ezt a témát és önzetlenül segítséget nyújt a magyar kkv-knak. Ez úton is köszönöm szépen Zsuffa Zsoltnak, hogy felhívta rá a figyelmet.

És most jöjjön maga a szerződés!

Mi a szerződés tárgya?
A legeslegelső kérdés amit az ügyvéd feltesz, hogy mit nyújt a Vállalkozó a Megrendelő részére. Ez tipikusan egy termék (például a kész szoftver) vagy szolgáltatás (például szoftver fejlesztés vagy tanácsadás).
A szoftver fejlesztési projektek tipikusan a termékről, az átadandókról szólnak, vagyis minden az elkészítendő szoftver körül forog. Az agilis fejlesztés tipikusan nem a scope-ról, hanem az együttműködésről szól, ezért úgy érzem, ezt szolgáltatásként kellene definiálni.
Éppen ezért célszerű lenne elkerülni az ezzel ellentétes kijelentéseket. Például „üzleti folyamat szoftveres támogatásának megvalósítása” helyett „támogatást nyújt az üzleti folyamat szoftveres megvalósításához”. A különbség az, hogy az első esetben a hangsúly a megvalósításon van, és az ember azt hiszi, hogy előáll valamilyen késztermék a munka eredményeként (leszállítandó). A második esetben a hangsúly a támogatáson van, ami értelemszerűen szolgáltatás.
Hasonló okok miatt nem tetszik a megvalósítási időszak. Azt sugallja, hogy van határidő. A nyújtandó szolgáltatásnak van időszaka, de jó lenne ezt tisztességesen meghatározni. Például mi történik, ha az iteráció túlnyúlik a megadott végdátumon? Azonnal abbahagyjuk a munkát?

Az együttműködés módja
Nagyon helyes, hogy a szerződés kitér az együttműködés részleteire. A szerződés szintjén le kell fektetni az agilis munka kereteit, későbbi félreértések elkerülése végett.
Célszerű lenne nyomatékosabban hivatkozni a módszertanra. A módszertan standard, tehát objektívan és konkrétan leírja a szolgáltatás minőségi mutatóit illetve az elvégzendő feladatokat. Fontos, hogy a módszertan pontosan meg legyen hivatkozva, azaz például ha valaki SCRUM szerint fejleszt, akkor ezt írja bele. (Találós kérdés: megszegi-e a megállapodást a Vállalkozó, ha teljesíti az iterációt de eltér a módszertantól?)
Jelen pillanatban olyan kitételek is szerepelnek is, amik feleslegesek, vagy legalábbis nem így kellene ezeket leírni. Például 1.2.7
Habár az iteráció leírását szerintem frappánsabban is meg lehet fogalmazni, de ez így ebben formában is jó és használható.

Mit nyújt a Vállalkozó?
Ami viszont nagyon hiányzik, az a Vállalkozó által nyújtandó feladatok/szerepkörök (vagyis hogy a Vállalkozó konkrétan milyen tevékenységeket végez). Hiszen nem mindent a Vállalkozó csinál. Értelemszerűen ennek összhangban kell lennie a hivatkozott módszertannal. Például jelenleg sehol sincs leírva, hogy a Vállalkozónak szoftvert kell fejlesztenie, hogy azt tesztelnie kell, hogy műszaki tanácsadást kell nyújtania, hogy elő kell állítania a szükséges dokumentációt, stand-up-meeting-eket tartani, SCRUM Master-t delegálni, stb stb.
A Vállalkozó kötelezettségei leírják, hogy x fő fejlesztőt delegál a projektbe, de nincs megadva, hogy ezek a fejlesztők mit csinálnak.

Szakmai halandzsa
Problémának érzem, hogy időnként rejtélyes szakszavak bukkannak fel. A szerződést elsősorban üzleti döntéshozók, cégvezetők, ügyvédek és beszerzők olvassák. Kizártnak tartom, hogy egy ügyvéd tudja, mit jelent a tesztlefedettség. Azt még kevésbé, hogy ebben a formában átengedi a dokumentumot.
A helyzetet tovább rontja, hogy a szolgáltatás minőségi mutatója nem közérthető módon (hanem tesztlefedettséggel) lett meghatározva. Az sincs meghatározva, hogy ennek a – csak szakmailag érthető – mutatónak a mérését és ellenőrzését ki és hogyan fogja végezni (az nem válasz, hogy a Vállalkozó saját bemondásra).
Ez így ebben a formában egyértelműen a Vállalkozónak kedvez.

Jogdíj, szerzői jog
A jogdíjról szóló rész szándékosan nincs kidolgozva. A lehetséges verziókkal nagyon furcsák, de nyilván nem ez jelenti a sablon lényegi részét.

Teljesítés
Már említettem, hogy nem célszerű szakmai halandzsát keverni a szerződésbe, ezért az 1.6.1-es pontot ki lehetne szedni. Esetleg a átrakni a Vállalkozó kötelezettségei közé.
Az 1.6.2-es pont koncepcionálisan jó, de pontosításra szorul. A felek az iteráció elején megállapodnak a feladatokban, azokat a Vállalkozó végrehatja, az iteráció végén az ügyfél nyilatkozik, hogy megfelelően lettek-e végrehajtva a feladatok.
A Megrendelő nem a teljesítés igazolásra fizet, hanem a Vállalkozó által benyújtott számlára. A számla alapját a Megrendelő által igazolt teljesítés jelenti. Mintha az 1.6.2 ellentmondásban lenne az 1.8.1-gyel.

Díjazás
Nagyon nem egyértelmű, hogy mi történik nézeteltérésnél. Tegyük fel, hogy egy feladatot előzetesen 1 hétre becsülnek. Aztán valami történik, és lesz belőle 2 hét. Ki fizeti ki a különbözetet? Mi van akkor, ha az 1 hétre becsült munka 1 hétig tart, de az ügyfél hibát talál benne, és plusz 1 hétig tart kijavítani?
Gondolom a válasz egyértelmű, hasonlóan egyértelműen kellene megjelennie a szerződésben is.
Az 1.8.3-as pont felesleges.

Titoktartás
Az 1.9.2 és 1.9.3 pontok feleslegesek. Az 1.9.4 ponttal kapcsolatban az a kérdésem, hogy pontosan ki is az a „közreműködő”? Ugyanis adva van a Megrendelő, és az ő munkatársai. Adva vannak a Vállalkozó oldalán a fejlesztők, illetve a Vállalkozó alvállalkozói. Rajtuk kívül senkinek semmi köze a projekthez, ugyebár?
Hiányzik az a pont, hogy az együttműködés bármilyen megszűnése esetén a Vállalkozó mit tegyen a részére átadott dokumentumokkal (megsemmisíti?).

Felmondás
Feltennék pár segítő kérdést, amit nem sikerült a felmondással kapcsolatban tisztázni:
Hogyan lehet egy határidővel nem rendelkező, határozatlan időre szóló szerződésnél értelmezni a projekt hossz 50%-át?
Határozatlan időre szóló szerződésnél – ahol szigorúan véve leszállítandók sincsenek - miért nem lehet rendes felmondást alkalmazni?
Mi a teendő, ha iteráció közepén elszámolási kötelezettségbe bonyolódnak a felek, és az egyik oldal rendes felmondással kiszállna a történetből?
Bármilyen felmondás esetén a Vállalkozó mit ad át a Megrendelőnek? Forráskód, dokumentáció, adatbázis, oktatás?

Kötbér, pénzügyi felelősség, jótállás, szavatosság, mulasztás
Szokás mondani, hogy a papír mindent elbír, bármit le lehet írni. Azért szoktunk kötbért, garanciát és pénzügyi felelősséget tenni a szerződésbe, hogy a teljesítésnek tétje legyen, és a szerződés betűje ne csak pusztába kiáltott szó legyen. Ha nincs tét, akkor csakis a Vállalkozó jóindulatán múlik minden.
Úgy is fogalmazhatnék, hogy az igazi szerződés és a haverokkal kötött megállapodás között a kötbér a különbség.
A dokumentumból hiányoznak ezek a biztosítékok. Célszerű lenne későbbi viták elkerülése végett minőségi mutatókat és garanciákat meghatározni.
Formális módszertannál kötbérezzük a csúszást, a nem-teljesítést, előírjuk a jótállási időszakot, a garanciális szolgáltatást, illetve a gondatlanságból eredő hibákból fakadó kár kezelését. Nyilván ezek agilis fejlesztésnél kevésbé értelmezhetőek, de akkor helyettük találni kellene valami mást. Az nem megoldás, hogy nincs semmi.

Hol van a bikkfanyelv?
A dokumentum nyelvezete, a szóhasználat és a felépítése egyértelműen arra utal, hogy informatikus írta. Hiányoznak a tipikus ügyvédi szófordulatok és meghatározások, pl. definíciók, default-ok, garanciák. Feltenném a kérdést: töltött-e elég időt ezzel a szerződéssel egy igazi ügyvéd?

Összegzésképpen: nagyon örülök, hogy a sablon létezik. A használhatóságával kapcsolatban kétségeim vannak – egyoldalúan a Vállalkozónak kedvez, a Megrendelőnek biztosan nem lesz jó így ebben a formában, bele fog javítani, és innentől kezdve borulhat a szépen felépített struktúra. (Rosszabb esetben teljes egészében elveti a sablont, és hozza a sajátját…)

Ezeket a dolgokat – úgy érzem – könnyen lehet javítani, és el lehet jutni egy mindenkinek megfelelő dokumentumig.