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.