Derrick és Harry Projektmenedzsment Blogja

Az elmélet szépsége és a valóság ridegsége. Projektszemlélet a vállalatoknál

2014. április 27. - Oberinspektor Derrick

 2014.április 11.-én „Az elmélet szépsége és a valóság ridegsége. Projektszemlélet a vállalatoknál” címmel előadást tartottunk a CIO Hungary konferencián. Több szempontból is komoly mérföldkő ez életünkben. Először is nem voltam otthon a feleségem születésnapján – na jó ilyen már volt, de akkor „csak” szimplán megfeledkeztem róla ennek minden következményével együtt, most tudtam és mertem. (És viselem a következményeket.) Másodszor, első ízben fordult elő, hogy nem a munkánkkal és munkahelyünkkel kapcsolatban hívtak meg minket, hanem kimondottan a blog és az általa közölt szellemiség miatt. Mondhatnám az első komoly siker. De nem mondom, mert szerény vagyok, meg az eddig szervezett eseményeink is sikeresek, de azért egy CIO Forum, az mégiscsak CIO Forum na!

CIOForum_1.jpg

Ottani előadásunk kis performansszal indult, kiálltunk a színpadra és a következőket mondtuk a fenti kép előtt:

Komoly munkahelyeken dolgozunk, komoly munkát végzünk, de nem emiatt kaptunk ide most meghívást, hanem azért, mert van a szakmai énünknek egy másik (gerilla?) oldala. Lassan három éve lesz, hogy anonim módon blogot indítottunk, mert frusztráció volt bennünk, és nem láttuk a megoldást. Láttunk egy világot a szakmai konferenciákon, tréningeken, szakkönyvekben, és egy másikat a valódi életben. A kettő között óriási szakadékot éltünk meg a mindennapjaink során. Ezt a szakadékot szeretnénk most érzékeltetni egy kis előadással: Derrick a megreccsent IT vezető, Harry a skatulyából előrántott tanácsadó, mind a kettő elmondja, hogy zajlik le egy projekt.

 

Harry

Derrick

Projektindítás

 

A projekt kezdetén az első és legfontosabb feladat a stakeholderek azonosítása. A részvételükkel szervezzünk egy kick-off megbeszélést, ahol ismertetjük a projekt magas szintű céljait, a résztvevők megismerik egymást, ismertethetik a projekttel kapcsolatos elvárásaikat. A kick-off megbeszélésen a felek megegyeznek a projekt alapvető működési rendjéről, a felelősségi körök tisztázásra kerülnek, és megegyezünk a legfontosabb üzleti célokról.

A board már nagyon piszkál, hogy mikor lesz már meg az a fejlesztés, amit két éve tolunk magunk előtt. Még mindig nem tudja senki, hogy mit is kellene csinálni, de hogy úgy tűnjön, történik valami, tartunk egy kick-off meetinget. Az végül is senkinek se fáj. A meghívottak fele nem jön el, akik meg eljöttek, azok 15 percen belül összemarakodnak egy előző napi értekezleten, aminek ehhez semmi köze. Ne tűnjön úgy, hogy rajtam múlik…

Projektszervezet

 

A kick off után felállítjuk a projekt szervezet, nevesítjük a szerepeket, formálisan is kinevezzük a projekttagokat, hozzájuk egyértelmű felelősségi köröket rendelünk, azonosítjuk a kockázatokat és lehetséges kezelésük módját, definiáljuk a projekt működési szabályzatát.

Kéne egy projektvezető. Van az a Géza gyerek a számvitelen, ő mintha csinált volna valami hasonlót, rátolom az egészet, küszködjön ő az üzlettel. Nyilván az lesz, mint mindig, az a 10 ember lesz a projektben, aki mindig benne van a projektekben, talán egyszer össze lehet hívni őket, de utána esélytelen, a projekttagok – akik mindig minden projektben a projekttagok – azt sem tudják majd melyik sapkájukban kommunikálnak egymással. Idővel szépen besorolunk az ugyan 3 éve futó, de eredményt még soha nem szállító projektek közé. Lényeg, hogy a projekt státusz lámpa legalább az első félévben zöld legyen, utána sárga.

Felmérés

 

Az üzleti igények felmérésével kezdünk. Elővesszük a módszertan szerinti template-eket és végiginterjúzzuk az üzleti területeket. Az eredményt egy Business Requirements dokumentumban foglaljuk össze, melyet minden kulcsterület képviselője részletesen megvéleményez, a változásokat konszolidáljuk, a dokumentumot véglegesítjük, majd sikeresen elfogadtatjuk mindenkivel.

Jönnek majd a tanácsadók szép öltönyeikben, tankkönyv ízű kérdéseikkel, már előre sajnálom őket. Úgy nyilván könnyű lenne, ha tudnánk, mit akarunk, de ez sosem volt erősségünk. A legnagyobb baj, hogy az üzlet egy részének fogalma sincs mit akar, de azt azonnal, a másik meg nem tudja elmondani. Elvonatkoztatási képességük a nullával egyenlő, idejük nincs, részben vagy egészben utálják egymást, még az sem kovácsolja őket egységbe, hogy minket IT-t a legjobban. Ezek fogják specifikálni a rendszert? Röhej. Az lesz mint mindig: Kezdődik majd a „jó-jó, hogy ez van leírva, de én nem erre gondoltam, te vagy a fekete öves tanácsadó, tudnod kellett volna, ezért választottunk benneteket”. Mindegy aláírunk valamit, egy példányt jól el kell tennem a fiókba, jól jön az még a végén, az egymásra mutogatásnál. Ez tavaly is bejött a SAP bevezetésnél.

Fejlesztés

 

A BRD alapján elkészül a logikai majd a fizikai rendszerterv. Az architect ismerteti a kódolási szabványt és code review-k formájában ennek betartását folyamatosan ellenőrzi. A projektvezető az architect bevonásával fejlesztési taszkokat rendel az egyes fejlesztőkhöz, melyek előrehaladásáról a vezető fejlesztő státuszol legalább egyszer a héten. Az infrastruktúra team felállítja a nightly build szervert és kialakítják az automata tesztelési környezetet. A tesztelési lefedettségről minden reggelre egy automatikus riport készül.

Na, legalább eljutottunk idáig, most van egy kis nyugi. A szállító fejleszt magában, néha kérdez egyet, azt megválaszoljuk, legalább 4 hónap csönd. Ezt a részt szeretem a legjobban.

 

Tesztelés

 

A tesztelést alaposan meg kell tervezni. A lezárt üzleti követelmények alapján felvesszük a teszteseteket és ezeket dokumentált formában végrehajtatjuk a tesztelő munkatársakkal. 3-5 kör után UAT teszt a végfelhasználók bevonásával. Ezzel párhuzamosan performancia tesztet végzünk automatizált tesztszkriptekkel.

Basszus, megint a tesztelés. Tesztelő munkakör nincs a cégnél – bár tavaly már majdnem elfogadták, hogy kéne, csak azt nem sikerült kitalálni, kinek legyen a költséghelye. Az üzlet nem ér rá, arra sem emlékszik mit kért, szanaszét fogják szedni a rendszert olyan igényekkel, amiket még csak nyomokban sem tartalmaz a soha alá nem írt business requirements document. Az lesz, mint mindig. A szállító valahogy leteszteli, mi meg belefáradunk az újra és újra előbukkanó hibák rögzítésébe, a hatszor módosított, már harmadszor véglegesnek tekintett határidő közeledtével, kitesszük élesbe, ahogy van. Kemények vagyunk, élesben javítunk, de utálom.

Élesítés

 

Az élesítés dátuma előtt egy hónappal befagyasztjuk a kód változtatását, és elvégezzük az eddig sikeresen lezárt teszciklusokra épülő végső regressziós tesztet. Hibajavítás már csak az itt feltárt kritikus hibákra történhet. Az élesítés előtt két héttel teljes code freeze-t vezetünk be. Átállási, migrációs és visszaállási terv készül, melyeket validáltatni kell a megfelelő szervezeti felelősökkel, akik összehangolják a tevékenységeket más projektek esetleges párhuzamos élesítéseivel. Az élesítés dátumát, az élesítéssel kapcsolatos teendőket és elvárt jelenlétet a projekttagoktól, az esetleges leállásokat az ügyfelek és dolgozók felé hivatalos értesítésben kommunikáljuk.

Az élesítés időpontja négy és fél hónapon keresztül a következő hét szombatja. Ennek megfelelően minden hétvégén bent izzad az egész csapat, hiszen permanensen pont élesítés előtt állunk. A kritikus hibák száma ugyancsak permanensen 5 és 50 között oszcillál, attól függően, hányan tesztelik a rendszert. Az egésznek a projekt board üvöltése vet véget, illetve az, hogy egy fejlesztőt elvisz a mentő egy szombat délutáni fejvesztett hibajavítás után. Nincs mese, kirakjuk élesbe, terv nincs, csak imádkozunk, hogy sikerüljön. Aztán persze csak a harmadik nekifutásra sikerül. A hibajavítás az élesítés után is ugyanolyan ütemben folytatódik, csak most már éles üzemi supportnak nevezzük.

Projektzárás

 

A projektet formálisan lezárjuk, a dokumentumokat archiváljuk, a kódot letétbe helyezzük, megtartjuk a lessons learnt workshopokat, ezek eredményét visszavezetjük a céges módszertanba és template-ekbe, projektzáró vacsorát tartunk, kiosztjuk a díjakat.

Ne oda menjünk, ahova legutóbb, ott nincs csapolt fácán.

 

És a végén megkérdeztük a közönséget, ki, milyen projektben vett eddig részt inkább az életében. Mit gondoltok mi volt a szavazati arány? Ha a nullával való osztás is megengedett :)

A bejegyzés trackback címe:

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

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.

BigTom 2014.04.27. 20:26:07

A jobb oldali oszlop szerinti működés két dolognak az eredménye. Egyrészt a baloldali oszlopnak. Úgy értem, hogy egy projektet egészen máshogy kellene csinálni. Ez egy múltszázadi módszertan, és nem véletlen, hogy nem lehet vele azt elérni, hogy a megrendelő (vagy az üzlet) lenyűgözött legyen.
Másrészt annak a következménye a jobb oldali működés, hogy nem transzparens az érintettek, elsősorban az üzlet számára, hogy, amit csinál az egyenértékű azzal, mintha bankjegy kötegekkel fűtene be hideg téli estéken. Pazarlás felső fokon. Csakhogy ezt a szőnyeg alá söprik. Azt gondolják, hogy ezt nem lehet máshogy. Dehogy nem lehet. Csak egyszer kell feltenni a következő kérdést: Kedves igazgató úr. Van itt ez a BMW. Ez az öné lehet, ha egy valódi projektvezetőt tesz a projekt élére. Vagy kinevezheti a Gézát. Melyiket kéri? Csak fel kell tenni ezt a kérdést plasztikus, megfogható módon.

HighTroller 2014.06.05. 08:36:43

Nagyon sokszor van az, hogy a hangzatos módszertanok működtetése akkora overhead a projekten, hogy az érdemi munkavégzést akadályozza (true story).

Viszont kurvajó ez a blog, ahogy olvasom, kavarognak bennem az emlékek mítingekről, sztendápokról, meg minden ilyen szar bázzvördökről, hétvégékről, éjszakákról:D
süti beállítások módosítása