Derrick és Harry Projektmenedzsment Blogja

Van egy álmom

2012. április 30. - TanacsLajos

Egy álmot láttam az éjszaka. Az álom egy informatikai projektről szólt. A projektben egy nagy-nagy rendszert kellett megvalósítani egy nagy-nagy megrendelővel: az álom ott kezdődött, hogy ajánlatot készítettünk a projektre. Az volt a különös, hogy az ajánlatkérési felhívás letisztult, világos koncepció alapján készült olyan üzleti esetekre, amelyek valódi versenyelőnyt biztosítottak a megrendelőnek, ha elkészül az ezeket támogató rendszer.

 

Amikor írtuk az ajánlatot, az álmom még furcsábbá vált: egyáltalán nem úgy írtuk, ahogy azt egyébként szokás. Nem találgattuk, hogy vajon mekkora büdzsébe lehet beleerőszakolni a kívánt funkcionalitást, amik ezernyi értelmetlen és konszolidálatlan elváráson alapultak. Nem is készítettünk az ajánlathoz a feladat ismerete nélkül, az irreális ügyfélelvárásokhoz igazítva előre egy projekttervet, amelyről mindenki tudta, hogy teljesíthetetlen. Egyszerűen lebontottuk a jól definiált feladatot néhány napos tevékenységekre, megbecsültük a megvalósítási technológia mély és pontos ismeretének segítségével, és reális tervet készítettünk. Ezt a tervet – ami később ért véget hat hónappal, mint amit az ügyfél a kiírásban tervezett – beleírtuk az ajánlatba, mert úgy gondoltuk, a megrendelő őszinte és felelős szakértői véleményt vár tőlünk.

Az ajánlatok közül a miénk lett a legdrágább, de a pontos tervezés és szakszerű megoldás leírás, a kiválasztott technológia jövőbe mutató volta, és mély szakmaisága egyértelműen meggyőzte a megrendelő oldali döntéshozókat, akiket semmiféle belső politikai csatározás, személyes indíték vagy netán kenőpénz nem befolyásolt.

Az álmom ott folytatódott, hogy megkezdődött a munka, a tervezés és programozás. A furcsa az volt, hogy mindenki pontosan értette a dolgát, jól képzett szakemberek ültek minden pozícióban, akik ráadásul jó kedvvel, örömmel végezték a munkájukat. Sosem panaszkodott senki, hogy lehetetlen feladatot bíztak rá, sosem kerestek mondvacsinált indokokat arra, hogy miért nem tudják elvégezni a munkájukat. Tudták, hogy nehéz feladat előtt állnak, és hogy sokszor nem éppen ideális körülmények között kell majd célba érni, de egymást segítve, a közös célt szem előtt tartva dolgozott együtt a megrendelői és szállítói oldal.

Még szürreálisabb volt, hogy a projektvezetők egyáltalán nem cseszegették vagy kérték számon az embereiket, még kevésbé fenyegetőztek kirúgással, bónuszmegvonással, bírósággal. Ehelyett segítették őket prioritások kijelölésével, a munkakörülmények biztosításával, világos célkitűzésekkel. Egészen elképesztő módon az emberek így nem félelemből, hanem örömből dolgoztak.

Egy autó riasztója ekkor felébresztett álmomból, ittam egy pohár vizet, és visszaaludtam. Az álom pedig ott folytatódott, hogy a projekt nagy mérföldkőhöz ért, amikor menedzsment beszámolót kellett tartania a projektvezetőnek a saját főnökei felé a haladásról. A vállalat legfelsőbb vezetői mind egy kerek asztal körül ültek. Mindannyian tapasztalt, bölcs hölgyek és urak voltak, akik a szakmájuk mestereinek számítottak, egymással összhangban, egymást kiegészítve dolgoztak a torzsalkodás vagy a széthúzás leghalványabb árnyéka nélkül. Egyikükben sem merült fel egy pillanatra sem, hogy magas pozícióját kihasználja a saját személyes érdekeinek vagy ambícióinak érdekében. Megtiszteltetésnek érezték, hogy ennyi ember – a vállalat sok ezer dolgozója – sorsát befolyásolhatják döntéseikkel, és megrendíthetetlenül hittek abban, hogy ők vannak a dolgozókért és nem fordítva.

Amikor a beszámoló megkezdődött, és kiderült, hogy egyes előre nem látott nehézségek miatt csúszik a projekt, senki nem ordítozott, csapkodta az asztalt, vagy fenyegetőzött. Közösen megbeszélték a projektvezetővel, hogyan ütemezzék át a munkát. Nem akarták egyáltalán azt a benyomást kelteni, hogy jobban értenének a projektvezetéshez, mint a projekt menedzsere. Mivel mindenkinek világos volt, hogy az informatikai projektek bonyolultságuk és méretük miatt a legprofibb csapat leggondosabb munkája mellett is csúsznak időnként, nem kezdtek el bűnbakot keresni, hanem a projektet segítve hoztak olyan magas szintű döntéseket, amelyek segítségével a munka újra sínre került és haladhatott tovább.

Egy hirtelen váltással az álmomban a programozókat láttam: ők nem azon keseregtek egész nap, hogy ilyen körülmények között nem lehet rendesen dolgozni, és nem töltötték hasztalan és egoista szakmai vitákkal a napjaikat. Érdekelte őket a szoftver, és szívesen beleásták magukat abba az üzleti területbe, amelynek a rendszert készítették. Tudták, hogy az igényeket értő, és nem csak bután leprogramozó fejlesztőként sokkal jobb minőséget produkálhatnak. Értették, hogy a dolguk az, hogy az adott körülmények és idő alatt a lehető legjobb minőségű szoftvert állítsák elő, és hogy időnként kompromisszumokra kényszerülnek majd. Nem féltek attól, hogy a tesztelők hibát találnak majd a programban, hiszen tudták, hogy ők közösen a tesztelőkkel azért dolgoznak, hogy minél jobb minőségű eredményt állítsanak elő. Hihetetlen módon a tesztelők sem méltatlankodtak és szidták a rendszert. Tudták, hogy a minőség az idő előrehaladtával rohamosan javulni fog, ha mindannyian jól végzik dolgukat, és ez így is történt.

 Az álombéli projekt lassan a befejezéséhez közeledett, de túlórázni, hétvégézni mégsem kellett senkinek. A motivált, lendületes csapat kihasználta a normál munkaidőt, és a projektvezetők meg a menedzsment tudta, hogy fölösleges túlórákkal terhelni őket, mert ez csak rontaná az összteljesítményt. Senkinek nem volt szüksége arra, hogy embertelen terheket róva a csapatra bizonygassa, hogy mennyire kemény munka folyik, és senki sem lazsál, és mártírszerepben sem akart tetszelegni senki. A többiek iránti bizalom – bármennyire is elképzelhetetlen ez, de hát ne feledjétek, az álmokban bármi megtörténhet – mindenkiben megvolt a másik iránt, senki nem fúrt senkit a háta mögött, hiszen tudták, ezzel is csak maguknak ártanának.

Végül már csak az élesítés volt hátra, ami simán ment (nem így). Éppen a go-live party szervezésénél tartott a projekt, amikor megszólalt a telefonom az éjjeliszekrényen, és darabokra tépte ezt a csodálatos álmot, és visszarántott a valóságba. 

Feküdtem az ágyon, a plafonra meredtem. Lassan rádöbbentem, hogy mindebből semmi sem igaz, és hogy a mai projektstátuszon már megint ordítozás lesz, a projekt kátyúban, mindenki egymásra mutogat, fogalmam sincs, hogyan tovább, örömtelen és nyomasztó napok várnak rám. Milyen kár, hogy mindez csak álom marad, és nem lehet másként!

De tényleg, miért is nem lehet ez másként?

A bejegyzés trackback címe:

https://derrickesharry.blog.hu/api/trackback/id/tr464480901

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

boldogok_a_sajtkészítők 2012.05.02. 00:05:57

Derrick egy történet (bocs..) Ráadásul munkaszüneti napon projektstátuszni...
Komolyra fordítva: lehet másként, van ahol van is. Ahol mégsem, ott ezermillió dolog lehet: például legritkább esetben fordul elő, hogy 100%-ig racionálisan vannak kiválasztva / definiálva a projektek. (nagycég-viszialendület, kiscég-fogalmasincs és ami ezek között van) A megrendelő a legtöbb esetben nem tudja mit szeretne, jó esetben legalább a célt tudja. A szállítóban (megérdemelten vagy sem) a bizalom szinte sosem teljes.

Ja, meg az emberi természet... de azt hiszem az már egy másik szakterület.

boldogok_a_sajtkészítők 2012.05.02. 00:10:00

De ha már itt vagyok, van kérdésem is: szerintetek mennyire kell a projektvezetőnek (egységsugaró üzleti projektvezető, az informatikusok más téma) szakértőnek is lenni, avagy milyen mélyre kell belelátnia az adott problémába (vegyünk egy hétköznapi példát, ERP rendszer, ilyet már legtöbben közelről-távolról láttak) - az addig oké, hogy az informatika mélyébe nem lát bele (mondjuk) de pl. számviteli szakértő legyen? Vagy kontroller? Üzleti folyamatokat messziről szemlélje, vagy tudja kívülről a részleteket is?

TanacsLajos 2012.05.02. 13:46:31

Szerintem ahhoz mindenképpen kell értenie a projektvezetőnek, amit a projekttagok csinálnak a mindennapi munka során. Egy egyedi fejlesztési projektnél igenis értenie kell, hogyan történik az igényfelmérés, a tervezés, vmennyire látnia kell, mit jelent például egy JSF oldal elkészítése, hogyan tesztelnek a tesztelők, milyen gyakorlati problémákkal szembesülnek nap mint nap.
Ha ERP bevezetésről van szó, akkor meg a termék testreszabásának menetét kell ismernie, a termék tulajdonságait átlátnia. Nem minden részletig terjedő módon, de tudnia kell, mi történik körülötte. Nem elég annyit tudni pl. a tesztelésről, hogy az egy tevékenység, ami június 1-től 22-ig tart 3 héten át. Fel kell tudnia ismerni időben, ha nem megfelelően halad egy adott feladat, látnia kell, hogy a születő becslések mennyire reálisak, meg kell tudnia objektíven ítélnie a projekttagok képességeit.
Szóval ezer feladat van, amit nem lehet hitelesen végezni valamilyen mélységű szakértelem és korábbi tapasztalat nélkül.
Én sem vállalnám el egy hídépítési projekt levezénylését, mert nem ismerem a domain-t, nem látom a dolog témaspecifikus buktatóit, jellegzetességeit.

vérpv_a_bűbáj 2012.05.25. 21:34:54

@Kriminalhauptmeister Harry: én korábban fejlesztő voltam (10 éve ez igaz). Ma nem venném a bátorságot, h én becsüljem meg egy fejlesztés időszükségletét. Arra van a vezető fejlesztő. Én azt gondolom, h nyilván én sem mennék el hidat építeni (báár egy jó kis híd...), de a szakmai csapatok (konzulensek, fejlesztők, tesztelők, stb) vezetőiben igenis meg akarok bízni, szükségem van arra, h tudjamm hiteles infókat kapok tőlük. Nyilván, azt azért el tudom dönteni, ha egy 8 órás taskot 24 órásra becsülnek, h kamu. De ha sok 8 órásat 10-11-re, már nem biztos. Szerintetek a PV tényleg az az ember aki mindenhez a legjobban ért? Akkor minek a szakmai csapatok élére vezető? Vagy ha egy tök új fejlesztő csapatot kapok, akiket nem ismerek, honnan tudjam, egy adott feladatról, h az melyiküknek mennyi idő lefejleszteni, még ha azt tudom is, h ez a munka nem lehet több 16 óránál? Nem azért van a vezető fejlesztő ebben a csapatban, mert ő ezt tudja (tudnia kellene)? Szal egy 6000 órás nettó fejlesztési feladatnál nem mindegy, h én elszámolgatok 10%-ot, mert ÉN nem vagyok a terület szakértője. És ez csak a fejlesztés volt...

vérpv_a_bűbáj 2012.05.25. 21:42:11

kedvenc mondásom ; " Fájó ez én tudom, de mély szakmai alázattal be kell látnunk: ma már nicsenek polihisztorok, csak poliészterek"

vérpv_a_bűbáj 2012.05.25. 21:53:12

és ha már így belejöttem, még egy nyüansz, nagyon érdekel a meglátásotok: vany egy 320 órásra becsült, 2 emberkés fejlesztési taszkom. az ugye 1 hónap. Tegyük fel, ez full üzleti logika, nem leht úgy ellenőrizni az előre haladást, h este belopakodok és jól megnézem, mert teszem azt, látható eredménye 320 jó magyar forintokban fizetett órának, majd csak az utolsó napon lesz, mer ez egy olyan dolog. Ezt a 2 szép fejlesztő urat hogyan ellenőrzöm? Mert ugye mindenki hazudik, és vagy Lupusa, vagy autoimmunja van. Ha a hónap végén derül ki, h végig hazudtak, sehol sem tartanak, akkor így jártam én és a projekt? Tudom, h ez azért elég szélsőséges (meg ilyen szituba rendes PV nem kerül), de ha már homár, legyen kövér...

TanacsLajos 2012.05.29. 19:08:26

@vérpv_a_bűbáj: Ha reális lehetőség a hazudozás, akkor nyilván nincs meg alapvetően a szükséges bizalmi viszony közted és köztük. Ezt sajnos rohadt nehéz kiépíteni, és mindkét fél kell hozzá, ez jelen esetben biztosan nem opció.
A javaslatom a 320 órás feladat feldarabolása maximum 2 embernapos részfeladatokra. Üzleti logikákhoz nagyon jól lehet unit teszteket írni, írják meg ezeket is (nyilván valahogy úgyis tesztelik, amit csinálnak, ugye, ugye??) és mérd a haladást azon, hogy hogyan készülnek el ezekkel az 1-2 napos feladatokkal.
Te meg tudod állapítani, hogy a unit tesztek értékelhetők-e, és lefutnak-e sikeresen? Ha igen, ezen tudod mérni a haladást, ha nem, kerítened kell valakit, akiben bízol és meg tudja neked szakérteni.
De a lényeg a darabolás: a 320 óra kontrollálhatatlanul sok, még jóakarattal is nagyon el tud csúszni. Így érzik a nyomást (vagy a törődést) napi szinten, számon vannak folyamatosan kérve, illetve korán felismerheted, hogy csúszás lesz.

TanacsLajos 2012.05.29. 19:15:18

@vérpv_a_bűbáj: Hülyén fogok válaszolni (a korábbi kérdésedre) de szerintem az IT projektvezetőnek az IT projektek vezetéséhez kell a legjobban érteni. Ennek persze része az is, hogy valahogy el kell érned, hogy értelmes becslésekkel rendelkezz például. Ezt különböző módokon el lehet érni: ismerheted te magad a domaint és a technológiát, és akkor átnézed a becsléseket. Vagy keresel valakit a projektben, akinek az értékítéletében megbízol, és szakértő. Persze akkor el kell hinned, amit mond, ami nem mindig könnyű. Nem csak akkor, amikor azt hallod, amit hallani akarsz. Sokszor nem a becslésekkel van a gond, hanem azzal, hogy szembenézzünk azzal, amit mutatnak...

Amúgy meg a becslések mindig és biztosan tévedni fognak, néha 10, néha meg 100%-ot. Ezzel mindig számolni kell: alapvető adottságként kell kezelni a becslés hibás voltát, így legalább valamennyire fel tudsz akkor készülni a kezelésére. Ez persze plusz pénzügyi kockázatot hoz a projektbe, amit valahogy kezelni kell.

boldogok_a_sajtkészítők 2012.05.29. 20:11:33

@vérpv_a_bűbáj: Igenbizony, egyetértek Harryvel, 320 órás feladat márpedig nincs.
Egyszer megcsináltam két fejlesztővel, hogy a 100 órás feladatot darabolják 8-10 órásakká, legalább becslés szinten. Öt órát ültünk egyhelyen, de kiizzadták.
(persze unit tesztekről ők nem hallottak, avagy 'a rendszer ehhez túl bonyolult' és hasonpaci kifogások, de ez már egy másik mese)

vérpv_a_bűbáj 2012.05.29. 20:51:43

@boldogok_a_sajtkészítők: igen, az természetes, hogy nincs 320 órás task. én éppen a zárójeles mejegyzésedről elmélkednék, ami ugye egy másik mese. Mert "túl bonyolult lenne!" , meg " jó én megcsinálom, de akkor az még x csillió óra lesz" - stb. Ilyenkor persze a menedzsment hajlamos nagyvonalúan lemondani a számon kérhetőségről, ami persze a végén kínosan hiányzik. Ilyenkor mit tesztek? Amikor a divízió vezetője áll be a sorba, rosszul értelmezett kollegalitásból "hagyjad már szegény fejlesztőket ezekkel a unit tesztekkel, meg a két napos taszkokkal! Ezek jó srácok, megcsinálják!" Aztán persze soha nem csinálják meg...

boldogok_a_sajtkészítők 2012.05.30. 11:05:07

@vérpv_a_bűbáj: Ajjaj.. Hozzánemértés ellen sok minden nem véd. Illetve a tények, esetleg (ha még maradt belátás az épületben): folyamatosan szembesíteni mindenkit az ígéreteikkel és a valósággal.

Amit én szoktam (nem biztos hogy ez a legjobb, sőt.)

Projekt elején: a becslést bizonytalansági állandóval szorozni (1,5-2,5, attól függ). Kockázatként jelezni, nagyvonalúság általi elengedést nem hagyni. (ha lehet)

Projekt közepén: ha mégis 320 órás a task (szerintük) akkor mondjanak státuszként %-ot, hogy állnak: erre még hajlamosak szoktak lenni. Biztos nem veszik szívesen, hogy a 320 órának nem csak az elején meg a végén nézel rájuk, de túl kockázatos teljesen rájuk bízni a dolgot, ha látszik, hogy nem megy nekik.

Projekt végén: imádkozni és fedezékbe vonulni.

Többiek?

Oberinspektor Derrick 2012.06.03. 22:00:32

@boldogok_a_sajtkészítők: Per pillanat fedezékben vagyok és imádkozok. Az öt világvallás kevésnek bizonyult, keresem az alternatív lehetőségeket. Mentségemre szóljon, hogy a végén csöppentem bele.
süti beállítások módosítása