Azt mondják az IT projektek 70%-a megbukik és csak 20%-át lehet éppen csak félig sikeresnek mondani, ez leginkább éppen azért van így, mert a vezetõség kifog egy hülye idõkeretet, a fejlesztõk meg álltalában ezt lenyelik... elég régota vagyok az IT-ben sõt 3 éve vezetõi pozícióban, és tudom, hogy ez sajnos így igaz, mert minden projekten komoly összeütközésem van a felsõbb vezetéssel csupán azért, mert nem fogadom el a marhára rövid határidõket de már rögtön az elején. Eddig 2 cégnél dolgoztam a CMMI bevezetésén éppen azokból az okokból, hogy a fejlesztési ciklus jobban kezelhetõ legyen és még ebben az esetben is a cég vezetõsége rekoridõ alatti bevezetésrõl álmodozott. Szóval ez olyan mint a tojásfõzés, lehet 1 perc alatt is, de akkor az még nyers tojás... egy komolyabb huzavona után sikerül meggyõznöm a felsõ vezetést, hogy elfogadhatatlan a kerelmük, és ekkor indul meg az igazi munka. Na most ami a teljesítményalapú munkaterhelést illeti, az IT-ben ez tökéletessen megoldható, csak néhány dologhoz kell tartani magunkat, na de ez már régen kijönne ebbõl a topicból ha most itt részletes software development process-eket irnánk le, de megemlíteném, hogy sok Best Practices és egy nagyon fontos dolog amit úgy hívnak, hogy Personal Software Process a fontos. Ez fõleg kis csapatoknál lényegessen csökkenti a projektól való eltérést. Na meg minden fejlesztõi stósznak van valami nagy "hátránya" pl. a RUP-nál azt lehet tapasztalni, hogy kell a csapatba olyan ember(ek) aki tud objekt orientált gondolkodást kifejteni (tapasztalatból mondom, hogy erre csak kevesebb mint 10% fejlesztõ képes, a többi csak vonszolja magát), ha ez hiányzik a csapatból akkor az egéssznek nincs sok értelme, a dokumentáláson túl. Akkor pl. a leggyakrabb marhaság, hogy vagy semilyan specifikáció után dolgoznak, vagy egy 200 oldalas vaskos kötetet irkáltatnak le valakivel ami aztán ott rodhad a polcon, tehát gyakorlatilag itt is specifikáció nélkül dolgoznak. A csapatban sokszor nem tudni ki a task tulajdonossa, és ami még rosszabb, ha 2-nél több ember felelõs egy dologért és nem tudnak megegyezni akkor a fõnökük dönt, holott õ tud a legkevesebbet az ügyrõl... na de mesélhetnék még sokat az érdekes történetekbõl az igazság az, hogy a fejlesztõk legtöbbször kivannak szolgálva a tudást mélyen hiányló vezetõségnek, de munkahelyüket féltve nem mernek beleszólni hanem elfogadják a melót és aztán nyomják napi 12+ órán át, és persze, hogy ilyen stressz teli munkakörnyezetben némi kikapcsolódásra is szükség van.
Benoke - azt a 2 órás melót meg azért irtam le, mert ez is megtörténik, néha találkozunk esetekkel amikor a vezetõség alulmunkáltat egy fejlesztõt, mert nem akarja saját pozícióját elveszteni, ugyanis olyan melót adnak neki amit õ már régen kinõt. Ez ritka de megtõrténik, holott az ilyen fejlesztõk kellene, hogy legyenek a vezetõk... ahol így van ott nincs is nagy baj, de sajnos kevés helyen van így.