Most éppen minden oké

Az augusztus-szeptember őrület volt a munkahelyemen. Szeptember végén zártuk a kerek egy éve indult projektemet. Ez azt jelenti, hogy akkor volt annak az új biztosítási terméknek az indulása, amin az előző egy évben dolgoztunk a projekt csapattal.

De előtte még a projekt hajrában be kellett fejeznünk néhány elhúzódó tesztelést és meg kellett terveznünk az összes rendszernek az implementációját, amiből volt vagy egy tucat. Ezek nagy része csak egyszerűbb módosítás volt, de 3-4 nagyobb és összetettebb rendszer változtatás is akadt, ami elég komoly felkészülést igényelt.

Mit csinálunk ilyenkor? Megpróbálom magyarul leírni.

Projekt zárás előtt leülök a Designer-rel, aki a változást megtervezte (esetleg le is fejlesztette) és átvesszük, hogy mi változik a rendszerben, ő ezt ledokumentálja, összeállítja a csomagot, ami lehet új program rész és/vagy pl egy script csomag az adatbázis módosításokhoz. Én közben leírom a tervet, ki mikor mit fog csinálni. Megnyitom a változási jegyet, átrugdosom a kb 4 jóváhagyói körön, tartunk implementációs terv megbeszélést a projekt csapattal, azzal az adminisztrációs területtel aki a felhasználó lesz és persze az szoftver üzemeltetéssel, aki a projekt után felelős lesz a mindennapi problémák megoldásáért, esetleg bevonunk adatbázisos embereket, vagy web hostingos embereket, attól függően, hogy mit fejlesztettünk.

Aztán jön maga az implementáció, ami szerencsés esetben egy hétköznapon (mainframe esetében), vagy vasárnap éjjel történik, ha ügyfél vagy ügynöki rendszer az érintett.

Ezt a kb 1,5 hónapos kemény időszakot egy másik senior IT PM-el együtt csináltuk, ami nagyon hasznos volt, mert megfeleztük a rendszereket és nekem “csak” 7 rendszer jutott a teljes tervezéssel, végrehajtással és az előre nem látható problémákkal.

Idén szerencsére minden implementációm hétköznap történt, tehát a vasárnap hajnali telepítés nem nekem jutott. Nem volt szándékos, véletlenül így alakult, de nem bánom. 😀

A termék értékesítése tehát időben megindult, a projekt költségek kiválóan alakultak, sőt vissza is adtunk egy csinos kis összeget a portfoliónak, majd jött az általában 2 hetes garancia idő, ami az én esetemben először 3 hét volt, majd mivel a tervezettnél lasabban váltak “élő” státuszúvá a szerződések, ezért még két héttel megtoldottuk. Az éles indulás után alig volt néhány hibajavítás, de szerencsére semmi kritikus, ami miatt nagyon rohanni kellett volna a megoldással.

A szerencsének és/vagy a jó munkának köszönhetően az októberem nyugis volt, ha itthonról dolgoztam, akkor elmentem egy órát tekerni délután, ha meg bent voltam a munkahelyemen, akkor lementem az épületben működő konditerembe. Ha kellett, akkor este még visszaültem dolgozni 1-1 órát, de még így is maradt pár extra ‘csúszó’ napom azokból az időkből, amikor hetente egy extra napot túlóráztam…

A fennmaradó időmet pedig az új portfólió menedzseri feladatomra tudtam fordítani, mert már csináljuk a 2020-as tervezést.

Ez azt jelenti, hogy megkaptuk a 2020-as projekt listát a megrendelő területektől, hozzuk létre az új projektek vázát a mindenféle projekt adminisztrációs rendszerben, dolgozunk azon, hogy a projektekhez rendeljenek PM-eket és nagy vonalakban egyeztetjük, hogy a projektek milyen rendszereket érintenek és próbáljuk úgy időzíteni őket, hogy lehetőleg ne akadályozzák egymást.

Úgy tűnik, hogy a 2018-2019-es teljesítményem többeknek tetszik, mert idén nem kaptam egy darab projektet, hanem megkérdeztek, hogy Ákos mit szeretnél jövőre csinálni? Wow!

Először nem álltam ilyen jól, mert a fele munkaidőm portfólió menedzsment és úgy tűnt, hogy csak valami egyszerűt kapok, ami belefér ennyi időbe. De aztán előjöttem azzal, hogy láthatóan jövőre is lesz egy nagyobb termékfejlesztési projekt és azt szívesen vezetném úgy, hogy ha kapok PM segítséget. Úgyhogy most úgy áll a dolog, hogy én indítom a projektet, aztán később 1-2 PM-et fogok vezetni, mert ez az új termékfejlesztési projekt kb kétszer akkora, mint az idei projektem volt. Persze a cégünknél az a biztos ami már megtörtént, úgyhogy majd iszunk a medve bőrére, ha novemberben jóváhagyták a projektet és elkezdek rajta dolgozni.

Hát ennyi röviden, mint említettem a címben, most éppen minden ok. A következő hetekben fel kellene építenem a következő évet (nagy vonalakban) a Delivery csapattal és az első negyedévet pedig nagyon pontosan. Plusz ha novemberben elfogadják az új termék üzleti tervét, akkor el kell kezdenem a munkát. Jó lenne idén elkezdeni az üzleti követelményeket, hogy 2020. elején már ne vakarózzunk, ha folyamatban legyen a munka.

Milyen PM-nek lenni egy nagy kanadai biztosítónál?

Ez lesz az a bejegyzés amikor leírom, hogy annál a cégnél hogyan működik a projekt szervezet, ahol PM-ként dolgozom. Tudom, hogy van néhány olvasó, többnyire volt kollega az AEGON-tól, akiket érdekel ez a téma.

Aki követi a blogot az tudja, hogy március elejétől dolgozom új munkáltatómnál IT területen, Senior IT Projekt menedzserként. (Lassan már két hónapja… de rohan az idő)

Jelenleg egy projektem van, ami egy több éve folyó fejlesztési csomag folytatása. A büdzsé 850-900e CAD, ami kb 1100 fejlesztési napot jelent. A projekt menedzserek általában több projektet visznek, de ez a projekt elég bonyult, több alprojektje van, úgyhogy egyedül bírkózom vele, cserébe nem kell másik projektet vezetnem.

A projekten belül többféle egyéni életbiztosítási rendszert fejlesztünk, ahol a cégünk a több százezer szerződést tartja nyilván. Van olyan rendszer ami 30 éve fut, van ami kevesebb mint 10 éve.

A legnagyobb nehézség, hogy a fő rendszerekhez rengeteg kisebb rendszer kapcsolódik, ahol pl a banki feldolgozás, a kárügyintézés, a csekk kezelés, online ügyfélszolgálat, ügynök portál, stb kapcsolódik.

Ezeket a kapcsolódásokat fel kell tárni, az adott rendszer szakértőjét, fejlesztőjét, üzleti gazdáját be kell vonni a projektbe, így a végén a projekt csapatom kb 20 ember lesz és ezen felül legalább 50 érintett, akit képben kell tartani, meg kell hallgatni az igényeiket pl az ütemezést illetően.

De ne rohanjunk ennyire előre. Hogy indul a projekt és hogy néz ki a projekt szervezet?

A büdzsé gazdája az üzleti és operációs területeket támogató szervezet. Őket business-nek hívjuk, de ez félrevezető, mert valójában nem igazán üzleti területről van szó. Nem ők adják el a termékeket, hanem ők azok a rendszert használó ténylegesen üzleti terület igényeit értik. Ezen a területen van néhány szakértő, akik a folyamatokat és a rendszereket értik.

A terület fejlesztési listája a Háború és Békét idézi, ezeket a fejlesztési ötleteket folyamatosan priorizálják a hatás alapján, majd ha zöld utat adnak valaminek, akkor a területen dolgozó Business Projekt Menedzsernek (BPM) adják az ügyet, aki a követelmények összegyűjtéséért felel (high-level requirements), esetleg csinál egy business case-t, és bevonja az IT területet, hogy ezt szeretnénk csinálni, mondjátok meg, hogy ez mennyi idő és mennyi pénz.

Itt jövök én képbe. IT projekt menedzserként én vezetem az IT terület tevékenységét és a megadott info alapján összeszedem, hogy milyen emberekre van szükségem, a resource managerrel megtárgyalom, hogy ki az elérhető, kit javasolnak. Összeáll egy kezdeti projekt csapat, főleg Business System Analyst (BSA), Lead-design, Lead-tester és esetenként egy Architect van benne. A BSA-vel együtt szerveztünk néhány requirements elicitation sessiont, ami egy facilitált megbeszélés az üzleti követelmények összegyűjtése érdekében, melyet a BSA dokumentál, majd jön az erőforrás becslés és az ütemezés készítés. Az én dolgom, hogy ez a tevékenység ne folyjon szét, a megfelelő kérdések elhangozzanak, a dokumentáció is meglegyen. Pl ha valamire azt mondják, hogy ez 50 nap, akkor feltegyem a kérdéseket, hogy miért ennyi, majd a válasznak megfelelően pl megfelelőn lebontsuk a tervet.

Az ütemterv még trükkösebb, mert itt a csapatommal, az üzleti PM-el és a resource managerekkel is tárgyalok egyszerre. Egy példa, hogy érhető legyen: jelenleg 8 hónap van év végéig, amiből a nyár és az év vége miatt kb nettó 6 hónap marad, az erőforrás igény 300 nap, hány ember kell milyen képességekkel, hogy november 30-ig meglegyen az implementáció. Mondjuk a fejlesztés 60 nap, akkor egy ember csinálja, vagy 2 vagy 3, hogy elérjük a célt és van-e annyi elérhető ember? Elmondom az igényem, a resource manager csóválja a fejét, visszamegyek a business PM-hez, ő is csóválja a fejét, ezért bevonom a Delivery Directort, aki hat a resource managerre, majd összerakják, hogy a portfóliót hogyan rendezik át a prioritások mentén.

Ebből aztán lehetnek érdekes dolgok, így alakul ki pl, hogy a BSA-m Montreálban van, az egyik fejlesztőm tőlem 20 méterre dolgozik, a másik állandó home office-ban van Ottawában, a Test Lead pedig Manilában van, aki a kezdés után 2 héttel bejelenti, hogy várhatóan júniusban leveszik a projektről, de a tervezést még megcsinálja, utána viszont kell egy új ember. Ezt az állandó változást attól függően szívod meg, vagy nem, hogy mennyire kulcs a projekted, mennyire kritikus, mennyire kockázatos, stb.

Vissza az erőforrás becsléshez és menetrendhez. Ha azzal minden ok és az üzlet is leokézta, akkor elindul a fejlesztés, amikor az már megy, akkor Design dokumentációt, fejlesztési tervet, tesztelési tervet készítünk, felkészítjük a teszt környzetet, kitaláljuk, hogy lesz-e automatizált teszt, vagy manuális teszt lesz, lesz-e batch futás, screen test, smoke test, integrációs teszt. Ez mind a kockázattól, az adott rendszertől és az adottságoktól függ. Pl van amihez van teljes integrációs környezet, van ami csak egy egyszerű interface és elég azt ellenőrizni, hogy az adat átmegy-e A-ból B-be. A tesztelés elején elindul az implementáció tervezése, majd az egész végén az implementáció, garanciális időszak, projekt zárás, a csapat feloszlatása.

Sajnos a cégünk meglehetősen lineárisan fejleszt, pedig egyre több területen már van agilis módszertan. Ez azt jelenti, hogy egy fejlesztési csomagon elvagyunk 3-5 hónapot, addig a megrendelő nem lát semmit, az üzlet pedig folyamatosan változik. Ezért én jobban szeretem az agilis fejlesztést, pl a Safe Agile-t, de ahol ennyi kapcsolódó rendszer van, ott érhető, hogy miért Waterfall módszertant használnak. A komplexitás egyszerűen túl magas ahhoz, hogy az agilis fejlesztési módszertan használható legyen.

A nehézséget az is növeli, hogy az egyik alprojektben már tesztelünk, közben a másikban most indulunk, a harmadikban követelmény írás van, a negyedikben vakarom a fejemet, hogy miért akarják az egyik legfontosabb emberemet átvinni másik projektre. Sok embert, igényt, és korlátozó tényezőt kell fejben tartanom, és zsonglőrködök, hogy haladjon minden, ne lépjük át a büdzsét, a határidőket tartsuk.

Gyártom a dokumentációt, a projekt tagot engem keresnek a változási igényeikkel, pl erről a modulról azt mondtuk, hogy nem érintjük, de most mégis úgy tűnik, hogy kell, mehet-e? Ilyenkor bevonom az összes érintettet, megbeszéljük, hogy mennyivel nő a kockázat ha csináljuk, vagy ha nem csináljuk, büdzsé, menetrend változik-e. A válaszoktól függően csinálunk egy dokumentált Change Request-et, vagy csak készítünk egy nagyon alap dokumentációt és én PM-ként jóváhagyom a Scope kismértékű változtatását.

A projekt menedzsment technikáról kb ennyit, most arról pár szó, hogyan telik a hetem:

Mostanában hetente 2 napot vagyok az irodában és 3 napot dolgozom otthonról. Ha az irodában vagyok, akkor a helyi kollegákkal szervezek találkozót, próbálom a kapcsolatokat építeni, minél több embert megismerni az IT-ről. Ha otthon vagyok, akkor a nap felében általában konferencia hívásaim vannak a projekt tagokkal, van amelyik fél órás, van ami több.

A fennmaradó időben tervezek, dokumentálok, büdzsét készítek, jelentést írok, válaszolok a projekt tagok kérdéseire, összekötöm őket, megbeszéléseket szervezek és néha arra is jut időm, hogy a kötelező onboarding trainingeket csináljam.

Azt nagyon szeretem, hogy annyit vagyok bent az irodában amennyit szükségesnek tartok, senki sem nézi, hogy mennyit dolgozom naponta. Azt mondják, hogy az a lényeg, hogy a projekt menjen és úgy is kiderül, ha valaki nem dolgozza le az idejét. Mivel én új vagyok, ezért az a jellemző, hogy 1-1,5 órával többet dolgozom, mintha bent lennék az irodába, mert nem kell 3 órát vezetnem.

Augusztustól változik majd a helyzet, mert akkor a tervek szerint Kitchener-Waterloo-ba költözünk, azaz max fél órára leszek majd az irodától. Azt tudom, hogy ha karriert szeretnék építeni, akkor többet kell ott lennem és minél több embert kell megismernem.

Valamikor a jövőben írok majd az IT szervezetről, de ehhez még több tapasztalatra van szükségem.