A QualityOnTime.eu blog hívta fel a figyelmet egy érdekes cikkre.

A QualityOnTime.eu blog hívta fel a figyelmet egy érdekes cikkre.

http://www.qualityontime.eu/extracts/management-myth-1-myth-100-utilization-johanna-rothman

Miről is van itt szó? Amikor az erőforrásokat és határidőket Excelben, papíron vagy MS Project-ben tervezzük, akkor azt feltételezzük, hogy 1 ember egységnyi idő alatt egységnyi munkát végez el.

Tehát ha mondjuk egy új funkció kifejlesztése 30 embernap, akkor 1 ember 30 nap alatt fogja elvégezni.

Ebből az egyenletből kiindulva az IT menedzserek – akik ugye tipikusan nem IT-sok és sosem programoztak – mindenféle rafinált terveket készítenek. Az Excel-ből úgy néz ki a világ, ha valami 30 embernap munka, akkor azt el tudja végezni 1 ember 30 nap alatt, 2 ember 15 nap alatt, 3 ember 10 nap alatt vagy 30 ember 1 nap alatt.

A tervezés – és a menedzser – minőségét abban mérik, hogy milyen pontos és részletes tervet készít. Amikor minden a feladat részfeladatokra van bontva, minden részfeladatra van felelős és határidő, amikor minden percre pontosan ki van számolva. Az ügyfél és a felsővezetés tudni akarja, mikor lesz kész melyik funkció és melyik hibajavítás.

A baj csak az, hogy a világ nem ilyen. Az 1975-ös The Mythical Man-Month óta tudjuk, hogy a 30 napos munkát nem fogja 3 ember 10 nap alatt elvégezni. Igen, ezt 1975 óta tudjuk, de a menedzserek nagy része nem olvasta ezt a könyvet.

De még ha fel is lehetne így osztani egy munkát (3 egyenlő részre), akkor se fogjuk tudni tartani pontosan a határidőt: ugyanis a szoftverfejlesztés kiszámíthatatlan. Lesz olyan fejlesztés, ami ütemterv szerint halad, viszont 99%-on az utolsó pillanatban, a tesztelés során derül ki, hogy rossz volt a koncepció és vissza kell térni a fejlesztéshez. Máshol viszont egy munkát komolynak gondolunk, de jobban megvizsgálva kiderül, hogy elég hozzá 1 sornyi új kód, vagy kiderül hogy létezik rá API és ezért a tervezett idő fele alatt megvalósítható.

Amikor becslést adunk egy szoftverfejlesztés céldátumára, akkor azt átlagok és az eddigi tapasztalat alapján tesszük. Az alapján, hogy egy ilyen típusú feladat átlagosan mennyi ideig tart – és nem az alapján, hogy ez a feladat pontosan mennyi ideig fog tartani. Esetleg még teszünk rá tartalék időt, hiszen bármi adódhat.

A terv tehát nem lesz más, mint fikció, tapasztalati úton adott átlagos idők, amik úgysem fognak teljesülni.

Akkor van-e értelme tervet készíteni?

Van, hiszen ha pontosan nem is, de nagyságrendileg tudjuk, mi mikor lesz meg. Ez különösen akkor fontos, ha a fejlesztés sokszereplős, vagy ha az IT fejlesztés egy nagyobb nem-IT projekt része, ahol mindenkinek igazodnia kell mindenkihez – és ezt adja meg a terv.

A csúszásokkal és a hamarabb befejezett munkával lehet úgy lavírozni, hogy a határidők többé-kevésbé teljesüljenek.

Arról nem is beszélve, hogy a terv önbeteljesítő jóslatként funkcionál. Ha tudjuk, hogy péntekre készen kell lenni, akkor meghajtjuk és készen lesz.

Amikor pedig tényleg fontos, hogy tartsuk a határidőket, és nem lehet csúszni, akkor kell tartalékokat beletenni a tervbe.

A lényeg az, hogy a terv összességében még teljesülhet, de nem úgy ahogyan azt eredetileg gondolták. Ezért nincs értelme percre lebontva és részletesen tervezni. Viszont az sem jó, ha nincs terv. Meg kell találni a kettő között az arany középutat, amikor van terv és pont annyit tervezünk, amennyit kell, de ugyanakkor megadjuk a projektnek a kellő szabadságot.

Visszatérve a Johanna Rothman cikkhez, a 100%-os hasznosításhoz. Az informatikai munka, a szoftverfejlesztés nem csak abból ál, hogy konkrétan programozunk. Az is a munka része, amikor a fejlesztők ebéd közben azon vitatkoznak, melyik függvényt érdemes meghívni egy adott feladat végrehajtásához. Amikor a fejlesztés közben rájönnek, hogyan lehetne bizonyos feladatokat hatékonyabban elvégezni és készítenek egy saját programot. Amikor új utakat keresnek. Amikor interneteznek és találnak egy hasznos szakmai cikket. Amikor újragondolnak egy már megírt és átadott kódrészletet. Amikor nem állnak neki azonnal programozni, hanem előzetesen utánajárnak, kinek milyen tapasztalata volt az adott kódrészlettel.

A programozás ugyanis nem olyan, mint a kapálás. Mármint ha jól csinálják. Ahhoz hogy egy kód jó legyen, végig kell gondolni a lehetséges megoldásokat, a lehetséges következményeket, majd meg kell találni a legjobb megoldást. Nem csak programozni kell, hanem gondolkodni, algoritmizálni, megismerni a hátteret, információt gyűjteni, másokkal konzultálni. És a végén visszamérni az eredményt. Ez sokkal több munka, mintha egyszerűen csak nekiállnánk programozni.

Viszont ha gondolkodás helyett nekiállnánk programozni, akkor az a program nem lenne jó. Illetve vagy jó lenne, vagy nem. És ha nem jó, akkor utána sokkal több időt fogunk eltölteni a javításával, mint amennyibe került volna jól csinálni elsőre. Arról nem is beszélve, milyen benyomásuk lesz a felhasználóknak a rossz minőség láttán.

Éppen ezért a jó szoftverfejlesztés erőforrás tervezése nem 100% és nem percre kiszámított. Ehelyett inkább maradjunk a 80%-nál, ami szép kényelmes munkát eredményez, viszont követeljük meg a minőséget, és hogy legyen az utólagos hibajavítás minimális. A 20% „semmittevés” ki fog fizetődni hosszú távon. A jó mérnökök nem lopják az időt, hanem amint van szabad idejük, próbálnak valami hasznosat csinálni. És sokszor ennek több az értéke, mint amit az előírt 80%-ban dolgoznak.

Nem véletlen, hogy bizonyos IT cégek a hét egy napján megengedik a beosztottaknak: azt csinálnak, amit akarnak.