ITÉlet

Milyen az, amikor az alapos ügyvéd és az inkompetens informatikai tanácsadó szerződést ír? Szakmai zanzákban való elmerülés helyett jogok és kötelezettségek hálójaként definiáljuk a szoftverfejlesztést. Egyszerre tragédia és komédia! A titokzatos Harmadik Fél felbukkanásával pedig szerelmi háromszög!

Milyen az, amikor az alapos ügyvéd és az inkompetens informatikai tanácsadó szerződést ír? Szakmai zanzákban való elmerülés helyett jogok és kötelezettségek hálójaként definiáljuk a szoftverfejlesztést. Egyszerre tragédia és komédia! A titokzatos Harmadik Fél felbukkanásával pedig szerelmi háromszög!

A cikksorozat 1. része, 2. része, 3. része, 4. része és 5. része után – hogy klasszikusoknál maradjunk – következzék valami egészen más!

A mai példát „M” küldte el – köszönet érte!
A szerződés közbeszerzésen keresztül megnyert rendszerfejlesztésről szól a Közbeszerzések Tanácsa és az Albacomp között 2009-ből. Tárgya „Közbeszerzések Tanácsa tevékenységét támogató informatikai alkalmazások fejlesztésének megvalósítása”.

A szerződés itt tekinthető meg: http://www.kozbeszerzes.hu/static/uploaded/document/IT%20fejleszt%C3%A9s%20-%20szerz_.pdf

A szerződés első felén kimondottan érezni a jogászok stílusjegyeit: pontos, határozott, tárgyra térő. Nincs mellébeszélés vagy ködösítés, nem bújunk szakszavak mögé. A projekt kereteit tisztán és világosan meghúzza, tudjuk mennyi az annyi. Ptk-s hivatkozások, az aktuális jogi gyakorlatnak megfelelő mondatok, a Megrendelő többszörös védelme és a Vállalkozó örök kárhozattal való megfenyegetése. Olvasás közben szinte sírtam a gyönyörűségtől.

A szerződés második felét már szemmel láthatóan egy informatikai tanácsadó készítette: hibás vagy kétértelmű definíciók, ködösítés, felesleges dolgok kikötése, „mondok is meg nem is” stílusú kijelentések.
Feltehetőleg az informatika tanácsadó fogta az önmagában jó „jogászos” szerződést és belejavított „copy-paste” módszerrel.

Ennyi bevezetés után olvassunk bele a szerződésbe:

Tárgy, határidő, díjazás: Mestermunka, minden tömören és világosan írtak le. A munka „fixed bid” jellegű, tehát adott összegért kell elvégezni a munka adott határidőre.

Követelmény specifikáció: A részletes specifikáció nem ismert, azt a munka részeként kell előállítani. Ez bizonyos méretű kockázatot jelent a vállalkozó részére – a végső igénylista lehet hosszabb is a vártnál, ugyanakkor csökkenti annak a kockázatát, hogy egy kétes eredetű/minőségű specifikációból kelljen dolgozni. Szerintem ez a rész is jó.

4.3 Teszt-esetek: Az első hiba a szerződésben. Mi, informatikusok tudjuk, hogy a projekt szempontjából fontos teszt-eseteket nem a Vállalkozó, hanem a Megrendelő készíti el. Ezt a melót a Vállalkozó nyakába tolni súlyos szakmai hiba. Hogyan zajlik az elfogadási teszt, ha a Megrendelő nem csinált saját teszt-eseteket?
Az persze elvárható, hogy a Vállalkozó tesztelje le a munkáját (unit test) és ennek dokumentációját ossza meg a Megrendelővel, de ugye az más.

4.5 Integrációs teszt: Feltételezhető, hogy a szoftvereket nem önállóan, hanem az ügyfélnél meglévő egyéb szoftverekkel együtt, az ott lévő informatikai környezetben kell tesztelni és élesben indítani. Ennek az ellenőrzését (integrációs teszt) a Vállalkozó önállóan nem tudja elvégezni, ez legalább annyira Megrendelői feladat is. Akkor is, ha a szerződés szerint ezt a Vállalkozó nyakába toltuk.

4.7 Futtatási környezetek: Szó esik tesztkörnyezetről, de nem esik szó arról, hogy milyen futtatási környezetek léteznek. Ugye van az éles, de teszt környezetből több szokott lenni (fejlesztői, integrációs, adatmigrációs). Ha pedig léteznek teszt környezetek – amit a szerződés elfelejtett definiálni, akkor annak kialakításával és karbantartásával kapcsolatban feladatok is vannak – azokért ki felelős?

4.8 A tesztelés megkezdése: Az írás szerint a teljesítés határidejének lejárta előtti 20. nap az átvételi tesztelés kezdete. Szerintem ez kevés lesz, főleg mivel az igényeket sem ismerjük pontosan. Jobb lenne a felekre bízni az átvételi tesztelés ütemezését.
A 20. nap azt feltételezi, hogy a tesztelés tökéletesen sikeresen lefut, és nincs elnyúlt stabilizációs időszak. A valóságban ez sosincs így.

4.9 Átvételi tesztelés: Nem rossz, de egy-két szóval vitatkoznék. Például „az alkalmazás és/vagy a Vállalkozó hibájából adódóan” helyett simán „a Vállalkozó hibájából adódóan”, ugyanis lehetnek Megrendelő oldali alkalmazás hibák is. Nem tetszik, hogy a sikertelen elfogadási teszt után szankcionálják a Vállalkozót – a tesztelést nem a talált hibák száma minősíti -, de értem, hogy a Megrendelő szeretne kevés időt tölteni teszteléssel.

4.10. Hiba kategorizálás: Sajnos a hibaosztályok definíciója nem sikerült jól. Nincs definiálva az „alapfunkció”. A definíció szerzője szemmel láthatóan nem hallott még részleges működésről azaz amikor egy funkció nem működik, de attól még az üzletmenet folytatható. Nem hallott továbbá üzleti prioritásokról: nem biztos, hogy mindig a „napi funkciók” fontosak, lásd havonta egyszer lefuttatandó vezetői jelentés és pénzügyi hózárás, mint tipikusan nem napi de kritikus üzleti funkciók.
A definíció nem tesz különbséget csakis egy felhasználó vagy az összes felhasználót érintő hibák között.

4.12. SLA: A hibajavításra megadott határidők túlságosan rövidek, főleg úgy, hogy az átadás után a Vállalkozó papíron nem végez support jellegű tevékenységet (vagy legalábbis a Megrendelő nem fizet érte). Ezek az idők csakis akkor lennének reálisak, ha a Vállalkozó oldalán egy fejlesztő állandóan a telefon mellett ül és a hívásra vár.
Ha a rendszer tényleg ennyire fontos lenne, akkor havonta fizetni kellene a support-ért (a rendelkezésreállás is munkavégzés), vagy ha nem fontos akkor minimum duplázni ezeket a számokat és áttérni a „best effort”-ra.
Itt a Vállalkozó torkán lenyomtak valamit amit aztán úgyse fog tudni teljesíteni. Akkor se, ha a pokol tüzével fenyegetik.

4.19. Átadandók: Örülök hogy ez szépen definiálva van.

5.1. Továbbfejlesztés, technikai segítségnyújtás: Havi 1 fejlesztői nap semmire sem elég.

6.3. Indoklás nélküli felmondás: A Megrendelő indoklás nélkül elállhat a szerződéstől. Ezt eleve problémának érzek, hiszen ha egy szerződést aláírtak a felek, akkor az mindenkit köt. Öröm az ürömben, hogy a Vállalkozó megkapja a vállalkozói díj arányos részét – csak az maradt ki, hogy ezt hogyan számolják. Időarányosan vagy elvégezz munka arányában? Ha munka arányában, akkor ezt hogyan bizonyítja? Hosszú pereskedésnek néznek elébe, ha ez az eset bekövetkezik…

7.2-7-6. A Vállalkozó kézivezérlése: Váratlan fordulat! Az eddig többé-kevésbé jó szerződésbe valaki beleirkált pár pontot, amitől az egész borul.
Milyen marhaság az, hogy a Megrendelő utasításokat ad a Vállalkozónak? Az együttműködés tárgya a leírt szoftverek elkészítése. Hogy ezek hogyan készülnek elő, milyen módszerrel, milyen technológiát követve, azt bízzuk csak a Vállalkozóra. A Megbízó nem informatikus, hogy mikromenedzselje a fejlesztőket, a megállapodás nem erről szól.
Ha a Megbízó annyira nem bízik a beszállítóban, hogy közvetlenül kell utasításokat osztogatnia, akkor inkább ne is állapodjanak meg, helyette vegyen bérbe x darab fejlesztőt és csinálja maga.

Nevetséges a 7.5-ös pont, amikor is a Megrendelő szakszerűtlen utasításaiért a Vállalkozó nyakába rakjuk a felelősséget. A 7.5-ös pont egyenes következménye, hogy a Megrendelő minden egyes utasítása vitát fog kirobbantani annak hatásairól. El tudom képzelni, hogy az idő nagy része értelmetlen vita lesz érdemi munkavégzés helyett.

7.6. A Vállalkozó köteles a Megrendelővel való együttműködésre: Ezen a ponton érte el a szerződés a Blikk színvonalát. A két fél eleve azért írta alá a megállapodást, mert együtt akarnak működni, nemdebár? És ha véletlenül az egyik fél nem működik együtt, akkor mi lesz a büntetése? Pellengérre tűzik?
Azon felül hogy ennek a pontnak értelme nincs, de jogilag is megfoghatatlan, és nem áll mögötte szankció. Iskolapélda arra, hogyan ne írjunk szerződés.

7.7. A Vállalkozó köteles a szerződés teljesítéséhez szükséges feltételeket biztosítani: Újabb eszement kijelentés. Mert mi lesz, ha a Vállalkozó nem biztosítja a szükséges feltételeket? Nem fog teljesülni a szerződés, ezért megkötbérezik. Felesleges külön mégegyszer emlékeztetni erre.

7.10 és 13.2. Kötbért meghaladó kár: Az informatikai szerződések fontos kérdése az, hogy az informatikus mennyiben felelős az általa okozott üzleti kárban. Például programhiba miatt leáll az értékesítés, és 10 millió forint üzleti kár éri a céget. Kiszámlázható-e ez a 10 millió forint a szoftverfejlesztőnek?
A korrekt szerződésekbe beleteszik, hogy az okozott kár legfeljebb milyen mértékben terhelhető át, például mondjuk nem haladhatja meg a kötbért vagy a vállalkozói díj x százalékát.
Itt ebben az esetben a jogász szemérmesen „elfelejtette” ezt maximálni, sőt kimondottan utal rá hogy a Megrendelő érvényesítheti a kötbért meghaladó kárát. A 13.2-es tényszerűen kimondja, hogy a súlyos gondatlanságból okozott kárért teljes a Vállalkozó felelősségvállalása. (Találós kérdés: mi a „súlyos gondatlanság” definíciója?)
Vállalkozóként biztosan nem írnám alá ezt a szerződést, hiszen biztosítást kellene kötnöm a kártérítésre -> felesleges plusz költség. (Amit mellesleg a szerződésben külön szoktak kérni a Vállalkozótól, itt nyoma sincs)

8.1. Jótállás 36 hónap: Ez így sok. Főleg azokkal a szolgáltatási szintekkel, amikről már szó volt. Általában kis cégeknél pár hónapon belül vállalják az azonnali rendelkezésre állást szoftverhiba esetén, azon felül pedig 1-2 évig a „best effort” alapú garanciát. (Nem tudom pontosan, mennyit ír elő a magyar jog, 1 évre tippelnék)
A szoftvervásárlás „as is” jellegű. Ha a szoftver tisztességesen le lett tesztelve és jó ideig ment hibamentesen, akkor feltehetőleg kevés szükség lesz külső segítségre.
Ha az ügyfélnek szüksége van supportra, akkor fizessen érte. Nálunk legalábbis bevált, hogy fenyegetés helyett egy kisebb havidíjért azonnal lelkesen ugrik a fejlesztő.

8.2. Jogszabályi követés: Sajnos a jótállás olyan dologra is kiterjed, amire nem kellene: a jogszabályi követésre. Ez nem lehet tárgya a hibamenedzsmentnek, mert változás-kérelem. Az más kérdés, hogy a jogszabályi változás miatt kért fejlesztések lehetnek „ingyenesek”, azaz a support része.
Ellentmondás az 5.1-gyel ahol a jogszabályi követés nem jótállási kötelezettség, hanem fejlesztési munka.

9.2. Harmadik fél? Újabb meglepő fordulat: az eddig szigorúan kétoldalú kapcsolatban (Vállalkozó-Megrendelő) megjelenik a titokzatos „harmadik fél”, akit eddig nem definiáltak. Eddig azt hittem, hogy nincs harmadik érdekelt, valaki csakis egyik vagy másik oldalon áll, vagy a Vállalkozót vagy a Megbízót képviseli. Mi ez, szerelmi háromszög?

9.3. Újra felbukkan a harmadik fél: Van így ennek jogilag értelme? Ki felel a harmadik félért? Ki a felelős, ha a projekt megbukik a harmadik fél hibájából?
Csak mert a szerződést a Harmadik Fél (akit nem szabad néven nevezni) nem írta alá a szerződést, a szerződést csakis a Megrendelő és a Vállalkozó írta alá.

9.5 Kapcsolódó rendszerek tervezése és tesztelése? És ismét! Váratlan fordulat! Eddig azt hittem, hogy a szerződés keretében 3 szoftvert kell fejleszteni. Erre a 9.5-ben kiderül, hogy léteznek egyéb, kapcsolódó rendszerek, ráadásul ezek készítésében is részt kell vennie a Vállalkozónak.
Feltehetőleg a megállapodás írója soha nem hallott még rendszerintegrációról, és sutaságában így fogalmazta meg az igényt.

9.6 Újabb értelmetlen szövegek: A Vállalkozó köteles a Harmadik Fél érdekeinek megfelelően eljárni? Mi van???? Ki a fene az a Harmadik Fél és mik az érdekei????

9.8 Fellebbent a fátyol: Kiderül, ki az a titokzatos Harmadik Fél: a fejlesztés irányításával a Megrendelő külső informatikai tanácsadót bízott meg. Ráadásul úgy, hogy az illetőnek nincs joga a szerződés tartalmát érintő kérdésekben állást foglalnia.
Mi a gond ezzel?
- A Vállalkozó számára mindegy, hogy a Megrendelő saját vagy külső erőforrásból oldja meg a projektvezetést. A tanácsadó a Megrendelő sapkájában fog eljárni, nem holmi Harmadik Félként. Tehát minden erre vonatkozó utalás, az összes Harmadik Fél referenciát törlendő a megállapodásból.
- Nem tisztázott, hogy a fejlesztés irányítása mit jelent. A projektvezetés ugye azt jelenti, hogy a tanácsadó felelősséget vállal a projekt sikeréért, a csúszásért őt rúgják fenékbe + megkötbérezik. Igaz?
- Ráadásul kicsavartuk a kezéből azt a lehetőséget, hogy ténylegesen vezethesse a fejlesztést: döntést nem hozhat. Van is projektvezető, meg nincs is.
- Apropó, a szerződés nem nevezi a tanácsadót projektvezetőnek. Mert ugye a projektvezető feladata és felelőssége közismert. Jobb ködösíteni és zavarosban halászni.

Összegzésként azt mondanám, hogy feltehetőleg ennek a szerződésnek az alapja jó volt, csak jött valaki (feltehetőleg a Harmadik Fél) és tönkretette. A beleírások lehetetlenné teszik a minőségi szakmai munkát, távol állnak az elfogadott gyakorlattól.

Nagyon tanulságos, hogy miközben 15 oldalon át zúgnak a jogok és kötelezettségek, de pontosan arról nem esik szó, ami a lényeg: hogyan fog a két (három?) fél együttműködni azon, hogy a szoftver jó minőségben elkészüljön? Mintha ez nem lenne fontos…

Például:

Hogyan történik az elfogadás? Mi van, ha a szoftver részlegesen elkészül, és fázisosan indítható lenne?
Mi van a rendszerintegrációval? Ez ugyanis teljesen kimaradt mind a tervezésnél, mind a fejlesztésnél, mind a tesztelésnél, mind az éles indulásnál. Ki integrál, ki felelős az interfészekért, ki fog koordinálni a különböző fejlesztői csapatok között?
Ki mikor és hogyan fog ütemtervet készíteni a projektre? Mert ugye a projekt nem az átadás-átvétellel kezdődik, a feladatokat valahogy tervezni kell és ütemtervet kell csinálni.
Ki írja a Projektindító Dokumentumot?
Lesznek-e hetente státusz megbeszélések?
Ki a Projekt Szponzor?

Ezt a szerződést így ahogy van se Vállalkozóként, se Megrendelőként nem írnám alá. Egyrészt mert tele van butasággal. Másrészt pedig ott van benne a külső informatikai tanácsadó kerékkötőnek, meghatározatlan felelősséggel és döntési jogkör nélkül.
Vállalkozóként pedig azért sem írnám alá, mert irreális elvárásoknak nem tudnék megfelelni.
De ha én lennék az informatikai tanácsadó, akkor ez lenne a világ legjobb megállapodása és mindenkinek javasolnám az aláírását.

Sajnos már láttam a múltban olyan informatikai szerződést, amit informatikához sosem értő, de szakértőként tetszelgő emberek írtak. Ez pont olyan.

Ps. Ha a Vállalkozó kiválasztása közbeszerzési eljárás keretében történt, akkor ki választotta ki milyen eljárás keretében a külső tanácsadót?