ITÉlet

Avagy melyik módszer a hatékonyabb informatika projektekben?

Avagy melyik módszer a hatékonyabb informatika projektekben?

SLA-k kötésekor gyakran alkalmazzuk azt a kitételt, hogy az informatikai beszállítónak bizonyos hibákat (az alacsony súlyosságúakat) best effort alapon kell megoldania. Vagyis akkor foglalkozik velük, ahogy ideje engedi. Persze ez nem azt jelenti, hogy sosem, hanem azt, hogy a legelső adandó alkalommal azonnal. Ünnepnapon és hétvégén nem, akkor se ha éppen más fontos dolgot kell csinálni. De ha nincs más dolog, akkor bizony a hibát ki kell javítani. A best effort amolyan kézfogásos garancia: garantálja hogy meg lesz csinálva, csak azt nem, hogy mikor. Nem súlyos hibáknál nyilván nem kell rohanni, csak az a lényeg hogy valamikor ki legyenek javítva.

A best effort egyfajta rugalmasságot biztosít. A megrendelő enged egy picit, hogy a beszállító terhelése könnyebben kezelhető legyen.

Ugyanis a szoftverfejlesztés munkaigénye nem kiszámítható. Még ha a szakterület legjobb szakértője méri is fel a feladatokat, az a felmérés nem lesz pontos. Előfordulhat, hogy a feature kifejlesztésénél nem várt nehézségekbe ütközünk, vagy az elsőre jónak gondolt megoldásról a tesztelés során kiderül, hogy mégsem jó – és ilyenkor az eredetire becsült idő kétszeresét, háromszorosát töltjük el. Tipikusan a bugjavítás kiszámíthatatlan: ha tudom mi a hiba oka, akkor 5 perc megoldani, de azt nem tudom, hogy mikor találom meg a hiba okát.

Szerencsére a másik végletre is akad példa bőven: egy bonyolult feature kifejlesztésénél kiderül, hogy van már hasonló funkció amit le lehet másolni, vagy pont van egy olyan mező az adatbázisban amit fel lehet használni – és a fejlesztési idő a töredékére csökken.

Előfordul, hogy egy fejlesztő egy trükkös problémával napokat, heteket tölt el, miközben máskor pedig több hibát is kijavít/több fejlesztést is befejez 1-2 nap alatt.

A szoftverfejlesztés adottságai olyanok, hogy nehéz a munkát becsülni.

Nem véletlen, hogy az informatikai projektekre adott ajánlat tudományossága a horoszkópkészítéssel és jövendőmondással vetekszik.

Nagy tételnél, hosszú távon az átlag (a fejlesztő szaktudása) fog érvényesülni, de rövid távon minden kiszámíthatatlan.

Szóval amikor best effort alapú elvárásaink vannak, azzal elismerjük az informatikai sajátosságait, és a fejlesztő hatékonysága érdekében elvetjük a határidőt. Ugyanezen okok miatt népszerű az informatikai munkát T&M alapon mérni és számlázni – ha sokat kell dolgozni egy új funkció fejlesztésén, akkor sokat fizetünk, ha keveset akkor keveset.

Az üzleti életben jobbára ismeretlen a „best effort” alapú munka. Írtam is korábban, hogy best effort nem egyenlő projekt: az üzletszerű „komoly” munkának mindig van ütemterve és határideje. A vezetőség és a minőségbiztosítás csakis abban érdekelt, hogy az előre megadott határidőre elkészül-e a munka vagy nem. Ha elkészül, akkor zöld a lámpa és örülünk. Ha nem készül el, akkor ejnye-bejnye.

Ugyanis az informatikai projekt nem önmaga gyönyörűségére létezik, hanem egy üzleti környezetben: a szoftver új verzióját be kell harangozni, el kell készíteni a kézikönyveket, betanítani a felhasználókat, és úgy általában felkészülni az átállásra. Vagyis nagyon nem mindegy, hogy augusztus 1-re készül el az új verzió vagy később. Ha később, az esetleg plusz költséget, üzleti kárt jelent a megrendelőnek. Szóval a megrendelőt az érdekli, hogy megállapodtunk valamiben, megállapodtunk egy határidőben, legyen kész a szoftvert, és akkor fizetek. Ha pedig nem lesz kész, akkor az nem lesz jó.

Ha üzleti oldalról, vezetőként nézzük az informatikai projektet, akkor szó sem lehet best effort-ról. Csakis előre meghatározott ütemterv szerint lehet dolgozni, ahol feladatok, felelősök és határidők vannak.

Az a baj, hogy hiába létezik ugyanannak a dolognak (a szoftverfejlesztésnek) kétféle nézőpontja, mégiscsak ugyanarról beszélünk. Akármennyire is igyekszünk egy szoftverfejlesztést beszorítani határidők közé, a szoftver továbbra is csak akkor készül el, amikor a fejlesztő befejezte. Ha hamarabb vagy később próbálnánk meg befejeztetni (erőszakkal), akkor abból baj lesz. Vagy azért, mert a rendszeres túlórák miatt romlik a motiváció és a minőség, vagy azért, mert az unatkozó fejlesztők elégetik a profitot.

Mi a megoldás?

A legfontosabb azt felismerni, hogy a hullámzás kiegyenlítéséért az informatikai menedzser, a csapatvezető felelős. Sem azt nem lehet megtenni, hogy ne adnánk határidőket (és ne tartanánk be), és azt sem lehet elvárni, hogy a hullámzást a fejlesztők egyenlítsék ki.

A menedzser kezében megvannak az eszközök, amivel segítheti – vagy hátráltathatja – a fejlesztést. Ilyen például az előrejelzés minél pontosabbá tétele, a kockázatok kezelése, a munka ütemezésének folyamatos felülvizsgálata, a szükséges információk és eszközök beszerzése, a folyamatos kommunikáció, vagy a cost-scope-schedule háromszög proaktív kezelése.

A baj ott szokott lenni, amikor valaki vaknak bizonyul az egyik vagy másik irányba. Vagy mert nem hajlandó tudomásul venni ügyfele elvárásait és kizárólag a fejlesztő igényeit követi. Vagy mert csak az ügyfél elvárásait képviseli a fejlesztőkkel „szemben”. Egyik sem jó.

Hogyan kezelik ezt a problémát a nagyvállalatok és a kis cégek?

Kis cégeknél tipikusan alultervezik a projektet. Nincs pénz, kevés az ember, sok a munka, de valamit ki kell hozni belőle. Ha esetleg mégis csak lenne elég pénz és ember, akkor onnan elveszik, mert máshol kell. Szóval a munka több mint az ember, és az a cél, hogy a meglévő erőforrásokat minél hatékonyabban használjuk ki.

Egy munkába akkor is belevágnak, ha nincs meg hozzá a szükséges erőforrást, szaktudás vagy technológia, hiszen hátha történik valami csoda. (Ezt úgy is nevezhetjük, hogy innováció)

Mivel a projektet alultervezték, ezért garantált, hogy nem lesz kész a munka határidőre és a szükséges minőségben. De egy kis cégnél nem is ez a cél, hanem az, hogy minél olcsóbban (azaz nagy hatékonysággal) elkészítse a munkát. A profit abból adódik, hogy kevesebb ember csinálja meg ugyanazt.

Nagyvállalatoknál ennek pont az ellenkezője történik: a projektek tipikusan felültervezetettek, hiszen az a fontos, hogy határidőre és megfelelő minőségben elkészüljön. Addig bele se vágnak egy munkába, amíg a szükséges erőforrások, szaktudás és technológia nem áll rendelkezésre. Ugyanis ha valami nem áll készen, akkor nem garantált a projekt sikere, és ha nem garantált, akkor kidobott pénz lenne bármennyit is beletenni. Félkész házba senki sem fog beköltözni.

Itt talán azt kell kihangsúlyozni, hogy a két módszer nem csereszavatos. Egy kis cég élete az innováció, a késhegyen egyensúlyozás. A nagy cégé pedig a határidőre szállítás. Nem szabad összekeverni.