Olvassuk a módszertanokat, elején még értjük, figyelünk nagyon – itt a tuti – igyekszünk betartatni, jól is megy, jönnek a pozitív visszajelzések, az első sikerek. Valljuk be, nem nehéz. A kötelező dokumentumok (Projekt Indító Dokumentum, Követelmények, stb.) még széles kör számára érthetőek, logikusak, különösen akkor, ha korábban semmi nem volt helyette. Ahogy az igények megértése helyett egyre inkább a megvalósítás felé tolódik a hangsúly, válik a dokumentálás egyre terhesebbé, maguk a dokumentumok (különböző mélységű rendszertervek, tesztjegyzőkönyvek) egyre kevésbé érthetővé. Jön az átadás, a kezdeti lelkesedés helyét átvette a rezignáltság, a projekt csúszik, az ügyfél őrjöng, a csapat egy utolsó huszáros rohammal leszállítja a release-t, élesítés. Zárni kellene a projektet, hogy is?

Erre az időpontra a módszertan, már többször lekávézva, néhány lapjára mindenféle jegyzetelve a fiók mélyén, elő kellene venni, mert a főnök – aki már rég csinált projektet, viszont újabban Q&A könyveket olvas - ragaszkodik a záráshoz. Megkeressük, fellapozzuk, örülünk, - mert egyik oldal alján felleljük annak a helyes lánynak a mobilszámát, akivel két hete a büfében futottunk össze - és nekilátunk. Rossz hír, dokumentálni kell. Utolsó release-t lezsírozni, leírni mi van benne, biztos helyre tenni. Ha hasonló projekteket csinálunk a Főnök nyaggat majd minket az újrafelhasználható elemekért, megyünk a fejlesztőkhöz, akik eddigre már kiheverték a másnaposságukat, szeretnék az egészet az elfelejteni, különben is már másik projektre vannak beosztva. A nagy rohanásban nem update-elődött az architektúra rajz, a funkcionális leírások, jó lenne legalább utólag megcsinálni. Sikerült ez már valakinek? Alibiből valamit leadunk, de ha ezt kellene a következő projekten használni, nagy bajban lennénk.

Pénzügyi elszámolás, timesheet-ek lezárása, alvállalkozók kifizetése, maradék megszámolása, eltérés megmagyarázása. Ha voltak KPI-ok a projektben, akkor ezeket is értékeljük, ha nem voltak, definiáljuk utólag az elvárt eredmény függvényében vagy hagyjuk a fenébe.

Mivel várható még a projektnek egy 2.0 sőt egy 3.0 változata is, fontos, hogy a tanulságokat levonjuk. Nagy nehezen összehívunk egy „lessons learnt” szeánszt, mérsékelt érdeklődés mellett – bár a főnök eljön – mit csináljunk legközelebb másképp. Meg fogunk lepődni, ilyesmiket fogunk hallani:

• Ne vállaljunk be lehetetlen határidőket, már az elején látható volt, hogy ezt a felsővezetők által diktált határidőt nem tudjuk majd tartani
• Szánjunk több időt a tervezésre
• Ne hagyjuk, hogy az ügyfél folyamatosan változtassa az igényeit
• Az egész projekt alulstaffolt, csak a végére – mikor már nagyon égett a tető – kaptuk meg a megfelelő erőforrásokat
• Jó lenne nem két hetet hagyni a tesztelésre, és jó lenne, ha lenne dedikált tesztelő, legalább egy
• Ez a – tetszőleges technológia, kész szoftver elem, 3rd party komponens neve behelyettesíthető – egy kalap szar, mondtuk, hogy ebben ne dolgozzunk
• Ésatöbbi, ésatöbbi

Jó esetben valóban tanulunk az egészből, rosszabb esetben a formális emlékeztetőt eltesszük a fiókba és kilépésünkkor ledaráljuk.

Mi a mai gyakorlat? Jó esetben megállunk egy pillanatra és örülünk a sikernek, legalább egy közös vacsora, de még inkább beb@szás formájában. Ezt tegyük meg mindenképp, muszáj megtörni a monotonitást és azt a pillanatnyi sikert megélni, ami oly kevés van az életben. Nyomjunk ki zsét a menedzsmentből, ha nagyon nem megy másképp tartsuk meg önköltségesen, sőt olyat is láttam, ahol a projektvezető állta cech-et. Magunknak legalább írjuk fel a tapasztalatainkat. Kivel, milyen volt dolgozni, tényleg mit csinálnék másképp, nem kell nagy feneket keríteni neki, de egy órát megér. Különös tekintettel a becslések helyességét mérjük vissza, kinél kell kettővel szorozni, kinél öttel. Megint csak magunknak, tegyük el azokat a dokumentum template-eket, melyek használhatónak bizonyultak, még akkor is, ha nem a „hivatalos” példányok. Jól jön ez még bárhol is ér minket a következő kihívás.

A legextrémebb példa, amit megéltem, bementem a heti projektértekezletre, ahol is az ügyfél oldali projektvezető közölte, hogy elfogyott a pénz, lehet hazamenni. Értsem úgy, hogy pakolunk és levonulunk, most? Igen. Kasza-kapa eldob, hazamegy, projektzárás elintézve egy mondattal: ügyfélnek elfogyott a pénze, hazaküldött minket.

Látszólag nyűg, mégis akkor minek? Mert a fix projekt költség nem fedezi az élesbe állás utáni támogatást, arra van support, támogatás, rendelkezésre állás. Ügyfeleink viszont hajlamosak beleérteni a scope-ba, ezáltal elemi érdekük az idő húzása, hetek mennek el vitatkozással, hogy az egyes issue-k az eredeti terjedelem részei-e vagy nem, csapatot lehozni addig nem lehet, megy az idő, csökken a profit. A mi érdekünk a mielőbbi, korrekt lezárás, akár még ismert hibákkal vagy pótolandó dokumentációval együtt is, de legalább van egy tiszta helyzet. Tán a legfontosabb mérföldkő, itt úszhat el minden, legyünk tudatában ennek.