Az informatikusokat két részre lehet bontani aszerint, hogy véleményük szerint az informatikai projektben kövessük-e a nagykönyvben leírtakat (mert ez a helyes) vagy ne kövessük (hiszen az élet egészen más).

Az informatikusokat két részre lehet bontani aszerint, hogy véleményük szerint az informatikai projektben kövessük-e a nagykönyvben leírtakat (mert ez a helyes) vagy ne kövessük (hiszen az élet egészen más).

Egyszer annó már írtam arról, mi a teendő, ha a projektem állatorvosi lóra hasonlít. Akkor ott azt írtam, hogy nincs megoldás, csodák nincsenek, legfeljebb lehet hinni a lottónyereményben és a Télapóban.

Most ismét előkerült a kérdés, egy másik kontextusban. Ki a jó informatikus, az aki megbízhatóan végig tud vinni egy projektet HA a KÖRÜLMÉNYEK ADOTTAK, vagy az, aki eleve feltételezi, hogy a körülmények nem lesznek adottak, és alkalmazkodik?

A kérdés különösen állásinterjún tud kicsúcsosodni: amikor a fejlesztő az interjún szembesül azzal, hogy krízismenedzsmenthez is értenie kell majd az új munkahelyén.

Konkrétan miről is beszélünk? A szoftverfejlesztési projekt meg tud bukni olyan dolgokon, mint a gyenge ügyfél oldali projektvezető, a hozzá nem értő szakértő, vagy a nemtörődöm rendszerszervező által megírt csapnivaló specifikáció. A vezető fejlesztőnek minden nehézséggel meg kell birkóznia, ha határidőre szállítani akar.

Most jön az 1. számú felismerés: ezek a problémák már nagyon nem IT jellegűek, nem műszaki kérdések, nem tartoznak szigorúan a szoftverfejlesztés tárgykörébe. Akkor mégis kinek kellene ezeket megoldani?

2. számú felismerés: Ezek emberi problémák, amiket tipikusan a Projekt Menedzsernek kell(ene) megoldania. Van-e a projekten egyáltalán PM? És ha van, miért nem oldja meg ezeket?

3. számú felismerés: Hirtelen ráeszmélünk, hogy a projektet a vezető fejlesztő vezeti, nincs Projekt Menedzser. Ezért a vezető fejlesztő akarva-akaratlan kettős szerepet játszik: fejleszt is, és magára rántotta a PM felelősségét is. Innentől pedig már az a kérdés, hogy a vezető fejlesztő rendelkezik-e menedzseri kvalitásokkal. Ami ugye alapvetően nem adott.

4. számú felismerés: Ha a vezető fejlesztő nem képzett menedzser, akkor teljesen mindegy milyen módszertant fog alkalmazni, milyen technológiát használ, vagy mennyire képzett fejlesztő. Akkor csak vakon lő az éjszakába, remélve hogy valamit eltalál.

Visszakanyarodva az eredeti kérdésre… Aki a magyar piacon informatikai projektekben dolgozott, az tudja, hogy soha semmi nem úgy van, ahogy lennie kellene. Sok a meglepetés. Mennyire kell olyan fejlesztőket alkalmazni, akik „meglepetésállók”, vagy inkább maradjunk meg a fejlesztéshez értő fejlesztőknél?

Személy szerint én azt vallom, hogy a fejlesztő értsen a „normális” fejlesztéshez, aztán ha valami kivételes eset adódik, akkor azt majd megoldjuk, visszatereljük a projektet a normális mederbe.
Mások viszont úgy gondolják, hogy „normális projekt” vagy „normális meder” nem is létezik, ezért felesleges „ideális körülményekről” beszélni.
Kinek van igaza?

Az igazságot másképp közelíteném meg.
A történet valahogy nagyon hasonlít ahhoz a nőéhez, akinek az apja részeg volt, és bár a nő egy életre megutálta a részeg férfiakat, de mégis hozzámegy egy részeg férfihoz – azt már tudja kezelni, és nem hiszi el, hogy léteznek absztinens férfiak.

Vagy amikor az ember jogosítványt kap: előbb meg kell tanulni az elméletet, megtanulni szabályosan vezetni, gyakorolni, és csak utána kapunk jogosítványt. Pedig az utakon sokan nem vezetnek szabályosan, sok a kivétel (kopaszmercis, a jobbról előző BMW-s, vagy az elsőbbséget meg nem adó Suzukis), tehát mondhatnánk azt, hogy felesleges a Kreszt ismerni, az élet majd egész más lesz.
Az élet valóban más, mint papíron kresz-táblákat nézegetni. Viszont ahhoz, hogy ne balesetveszélyesen vezessünk, tisztában kell lenni a kresz-táblák jelentésével, a szabályos sávváltással, és úgy általában a szabályos autóvezetéssel. Ha valaki elhanyagolja a szabályos vezetést (mondván, hogy az élet egészen más), az előbb-utóbb felkenődik egy fára vagy a szembejövő kamionra.
Az élet tele van kivételekkel, de ezeket csak akkor tudjuk sikeresen legyőzni, ha tudjuk mi a „szabályos”.

Bónuszként pedig felvetném, hogy mi történik a „meglepetésálló” fejlesztővel, ha véletlenül normális projektbe, normális kultúrájú közegbe csöppen, esetleg jön egy külföldi megrendelő? Idegenül fogja érezni magát, hiszen nincsenek szekrényből kieső csontvázak, a megrendelő tudja mit akar, a szakértő érti a dolgát, és a rendszerszervező jó specifikációt írt.
Fog-e tudni ilyen körülmények között teljesíteni, határidőre szállítani?