BlackRose#20
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.