ITÉlet

Találós kérdés: mi az, amit a legtöbb szoftverfejlesztési szerződésből kifelejtenek?

A cikksorozat 1. része, 2. része, 3. része, 4. része, 5. része és 6. része után ismét előkerült a téma. Egy kollégám keresett meg azzal, hogy segítsek neki SLA-t írni.

Az történt, hogy egy projekt kapcsán külső beszállítóra volt szükségük, találtak egyet, egymás kezébe csaptak, majd megindult a munka. Viszont ahogy a projekt egyre inkább haladt a végkifejlet felé (átadás), elkezdtek azon gondolkodni, hogy mégis csak kellene valamilyen support – amiről korábban nem igazán beszéltek.

A helyzet – sajnos azt kell mondjam – elég tipikus. A legtöbb esetben, amikor valakinek új szoftverre, új web oldalra van szüksége, akkor csak odáig gondolkodik, hogy a munka el legyen végezve. Az átadás-átvételt, a fizetést, a késedelmet, a felmondást és a felelősséget jogi értelemben jól körbejárják – de az el szokott felejtődni, hogy mi történik a sikeres teljesítés UTÁN.

Mert ugye ilyenkor a beszállító megkapja a pénzét és levonul – a megrendelő pedig ott marad a szoftverrel. Ilyenkor már nincs tétje a rossz minőségnek és a nem-teljesítésnek, hiszen a programozó megkapta a pénzét. Innentől kezdve már pusztán személyes szimpátián múlik, hogy az utólagos problémákat orvosolják-e vagy sem. A szerződés annyit ér, amennyire betartják.

Ráadásul itt nem is arról van szó, hogy a beszállító rosszindulatú lenne, hanem egész egyszerűen neki ez nem betervezett munka, amire nincs erőforrása (a fejlesztők más projektre lettek allokálva), neki ez munkavégzéssel jár (a fejlesztőt ki kell fizetnie), viszont pénzt nem lát.

A valóság ugyebár az, hogy a szoftver sosem statikus. A szoftver idővel változik, hiszen az üzlet változik, a folyamatok változnak. Egy elkészült és átadott szoftver nem a történet vége, hanem éppen ellenkezőleg, a történet eleje. A kész szoftveren még rengeteg változtatás és hibajavítás fog történni. Éppen ezért a szoftverfejlesztési beszerzés során minden esetben ki kell térni az éles indulás utáni alkalmazás támogatásra, beleértve a hibajavítást, az új változtatásokat és a törvényi utánkövetést.

Fogalmak tisztázása végett: az SLA (Service Level Agreement) jelenti az alkalmazás támogatásra kötött megállapodást. Fizikai formája: szerződés, amelynek mellékletében, vagy amely alapján a felek megállapodnak a rendelkezésreállásban és a szolgáltatás minőségében.

Amikor megrendelünk egy új szoftvert, célszerű már akkor megbeszélni az SLA keretszámait és beletenni a szerződésbe.

Aki úgy gondolja, szétválaszthatja a kettőt (fejlesztési szerződés és támogatási szerződés) – a fejlesztési szerződést a projekt elején, a támogatási szerződést pedig a projekt végén aláírni.

Azonban mindenképpen fontos, hogy a keretszámok már az ajánlattételben szerepeljenek, későbbi félreértések elkerülése végett.

Kisméretű projektek, kkv-k esetén felesleges a papírmunkával vesződni, a két szolgáltatást egy közös szerződésbe be lehet rakni.

A lényeg annyi: ne úgy vegyünk szoftvert, mint kiló krumplit a piacon. Nem kell zseninek lenni, elég ha az alapvető dolgokra odafigyelünk, és ezzel nagyságrenddel lecsökkentjük a várható problémákat.

Mi a teendő, ha válságmenedzserként beledobnak egy olyan szituációba, amikor adott egy már meglévő szoftver, ami üzletileg kritikus, de elfelejtettek SLA-t megkötni, és emiatt rendelkezésre állási problémák, esetleg beszállítói problémák vannak?

A lehető leghamarabb le kell ülni a beszállítóval tárgyalni, hogy SLA-t kell kötni. A tiszta helyzet neki is érdeke. Az SLA azt jelenti, hogy a beszállító havonta fizetséget kap a rendelkezésre állásért és az alkalmazás támogatásért, cserébe viszont mérhető, számonkérhető módon biztosítja az alkalmazás működését.

Ha nincs SLA, akkor nincs mit számonkérni, de addig nincs is mire fizetni.