ITÉlet

Érdemes-e az alkalmazás-támogatást elválasztani a szoftver fejlesztéstől?

Amikor programozásról beszélünk, akkor mindig elfelejtjük tisztázni, pontosan milyen céllal is tesszük azt. Ugyanis a programozás kétféle lehet:

1) Fejlesztés, azaz új funkciók vagy új alkalmazás készítése

2) Alkalmazás támogatás, azaz a meglévő funkciók hibáinak kijavítása

A kétféle munka teljesen különböző hozzáállást és módszereket igényel. Az első inkább kreatív, hosszú időtartami, fix határidővel. A második esetben a munka inkább sziszifuszi, alaposságot és kitartást igényel, általában sok apró feladatról van szó, amiket nem határidőre hanem minél hamarabb kell megcsinálni.

A kétféle feladat kezelésére 3 modell terjedt el:

a) Ugyanaz a csapat és ugyanazok a fejlesztők végzik el mind a fejlesztési, mind a támogatási feladatokat

b) Szétválasztják a fejlesztést a támogatástól, tehát külön fejlesztő írja a kódot és külön fejlesztő javítja a hibákat

c) Az első kettő keveréke, amikor ugyanaz a csapat végzi a fejlesztést és a támogatást, de a csapaton belül a fejlesztők tipikusan egyik vagy tipikusan másik feladatot végzik

Most nézzük meg részleteiben, mit is jelentenek ezek a modellek.

a) Ugyanaz a csapat csinál mindent

Ez a legtipikusabb felállás, különösen kisvállalkozásoknál. A tudás a fejlesztők fejében koncentrálódik, akik a létező összes feladatot ellátják, legyen az új igény vagy hibajavítás.

Az erőforrások az igények függvényében mozgathatók a feladatok között. Emiatt a munka változatos és hatékony. A programozók rálátnak arra, ki mit csinál, ezért ki tudják használni a közösség erejét illetve a szinergiákat. A változtatások egy kézben (vagy legalábbis közös kézben) vannak.

Óriási előnye a modellnek, hogy a csapat motivált a minőségi, hosszú távú megoldásokra – ugyanis a gyenge megoldások utána „takarítást” ugyanazoknak az embereknek kell végeznie.

A modell hátránya, hogy a fejlesztési projektek teljesítése a véletlenszerűen felmerülő hibaelhárítás miatt bizonytalan. Magyarul: megegyezünk, hogy mikorra lesz kész a fejlesztés, de ha felbukkan egy súlyos hiba a rendszeren, akkor értelemszerűen azzal kell foglalkozni, és a határidő elúszik.

A fejlesztők egy idő után frusztráltak lesznek, hogy az „értékteremtő” fejlesztést rendszeresen megszakítja az „unalmas” támogatási munka. Ha az alkalmazás elég nagy, akkor garantált lesz a sok „megszakítás”, amivel egy idő utána kezdeni kell valamit.

b) A fejlesztés és a támogatás szétválasztása

Nagy cégeknél, ahol sok támogatási feladat van (a nagy méretek miatt), gyakran szétválasztják a fejlesztést a támogatástól, nagyjából az alábbi előnyök miatt:

- A támogatási feladatatok sok esetben unalmas pepecselő munkát jelentenek, amit egy kezdő fejlesztő is el tud látni.

- Tehermentesítik a „guru” szintű fejlesztőket, hogy ők a projektekkel tudjanak foglalkozni.

- Az olcsóbb fejlesztők bevetése a támogatási feladatokra alacsonyabb költséget jelent. (Vagy nézzük másképp: a drága fejlesztők nem égetik az idejüket rutin feladatokkal)

- Az alkalmazás támogatás folyamat alapú (lásd ITIL), jól megszervezhető és mérhető, függetlenül az adott alkalmazástól vagy technológiától. A szinergiák kiaknázhatóak a támogató csapatok összevonásával.

A költséghatékonyság és a triviális előnyök mellett azonban a modellnek hátrányai is vannak:

- Senki nem lesz motivált abban, hogy hosszú távú megoldásokat készítsen. A fejlesztők nem érdekeltek benne, hiszen más takarít fel utánuk, miközben a „takarítók” a minél gyorsabb munkavégzésre lesznek rászorítva a minőségi megoldások helyett. Összességében, az alacsonyabb árat a rosszabb minőséggel fogjuk „kifizetni”.

- Nehéz fenntartani a motivációt az alkalmazás támogatóknál.

- A műszaki döntéseket a fejlesztők (a projekt csapat) hozza, miközben nincs rálátásuk arra, mit fognak jelenteni azok a döntések a napi munkára.

- A valóságban a fejlesztők is fognak alkalmazás támogatást végezni. Mivel a fejlesztők kezében van az alkalmazás tervezés, ezért szükségszerűen lesznek hibák, amiket a támogatók nem tudnak kijavítani. (Valójában csak az 1. és 2. szintű támogatást végzi másik csapat, a 3. szintű megmaradt)

Összességében tehát a költséghatékonyság látszólagos – kevesebbért elvégzik a munkát a támogatók, de az elvégzett munka is kevesebb lesz. A minőség romlik, ami hosszú távon plusz munkát és költséget fog okozni.

b2) A fejlesztés és a támogatás szétválasztása - kiszervezéssel

Modell szempontjából nem külön eset, de megemlítem azt a helyzetet, amikor az alkalmazás támogatást teljes egészében a cégen kívülre szervezik – mint nem „core” tevékenység.

A legjobb gyakorlat az ilyen kiszervezésre az, hogy az IT szolgáltatót hibajegyek alapján fizetik, valamilyen incentive rendszerben, ami egyszerre rugalmas (annyi munkát kell elvégezni, amennyire szükség van, amennyi ticket generálódik) és olcsó (az egy ticket-re fizetett árat jelentősen a saját költségek alá lehet vinni). Az IT szolgáltató alkalmazás támogatásra specializálódott, nagy tételben tudja a ticket-eket kezelni, az erőforrásokat igény szerint átcsoportosítani, tehát hatékonyabb tud lenni, mint a belső helpdesk.

Ez az elmélet.

A gyakorlatban ezzel két óriási probléma van:

- Ha a fejlesztőket azért fizetik, hogy hibát javítsanak, akkor ott sok hiba lesz

- A támogatás kiszervezésével óriásira növekszik a távolság a belső architect (aki műszaki döntéseket hoz és aki átlátja az architektúrát) illetve a hibajavító support között. Eredmény: olyan megoldások fognak születni, amik megborítják a szoftver egységét, további hibákat generálva.

c) Keverék megoldás: azonos csapat, de külön személyek

Az első két megoldás ötvözete, amikor is szétválasztjuk a funkciókat, de a fejlesztői illetve támogatói munkát végző informatikusok ugyanazon helyen ugyanazon csapat tagjaként dolgoznak. Ennek számtalan előnye van:

- Nem lesz információs szakadék az architekt és a support között

- A support látja az átfogó képet, értesül a műszaki döntésekről

- Ugyanakkor a feladatokat külön emberek végzik, megvalósul a guruk tehermentesítése

- Hatékonyan tud összedolgozni az „A” ligás és a „B” ligás fejlesztő – mindenki a saját területén a saját speciális feladataival foglalkozik

- Karrier lehetőség – átjárhatóság lesz a két feladatkör között, ami erős motivációs tényező

- Erőforrások mozgatása szükség szerint

Szerintem a „c” megoldás a legjobb, de az aktuális iparági ajánlás a „b”. Ami a kiszervezés miatt „b2” lesz.