Első talán önző kérésnek tűnhet: jó lenne, ha a jövő üzleti vezetői és menedzserei értenének az IT-hoz és az informatikai projektek vezetéséhez. Le is írom, hogy miért.

Első talán önző kérésnek tűnhet: jó lenne, ha a jövő üzleti vezetői és menedzserei értenének az IT-hoz és az informatikai projektek vezetéséhez. Le is írom, hogy miért.

A menedzsment és a projektmenedzsment általános terület – éppúgy érvényes az informatikára, mint másra. A diákok, akik a jövő vezetői lesznek, nem tanulnak külön az informatikai projektekről, hiszen az általános menedzsmentet tanulják, ami – elvileg – simán alkalmazható informatikai projektekre is.

Ezzel valamennyire egyet is értek, viszont a gyakorlat azt mutatja, hogy egy informatikához – mint szakterülethez – kevéssé értő, üzleti területről érkező menedzsernek bizony gondjai támadnak, ha mondjuk egy szoftverfejlesztést kell az elejétől a végéig keresztülvinnie. Ezért jó lenne, ha a jövő menedzserei kimondottan „IT menedzsmentet” is tanulnának a sok „általános” tudomány mellé.

Kérem szépen, a 21. században élünk. Mindenhol mindenben számítógép van: az autónkban, a konyhánkban, a nappalinkban. Az informatika – ha tetszik, ha nem – az életünk részévé vált. Lehet ugyan számítógép és szoftver nélkül létezni, de az sokak számára kényelmetlen lenne.

Ugyanez a helyzet az üzleti életben. Nincs cég, ahol ne lenne legalább egy tucat szoftver, és ahol ne lenne a dolgozók jelentős részének számítógépe (vagy számítógép hozzáférése). Még annak az embernek az életét is számítógépek vezérlik, aki napi 8 órában, 3 műszakban dolgozik a szalag mellett. Lehet ugyan kockás papírral és tollal dolgozni, csak épp nem érdemes.

Mára a számítógép, a szoftver legalább olyan fontos és elengedhetetlen része lett az üzletnek, mint a tanácsadó, a szakértő, a folyamat, vagy a vezérigazgató titkárnője. A számítógép és a szoftver az, ami nélkül egyetlen vállalat sem tud létezni. Az informatikát mint feladatkört ki lehet szervezni, létezhet a vállalat informatikus nélkül, de informatikára akkor is szüksége lesz.

Ami még rosszabb: az üzleti folyamatok és a szoftverek annyira összefonódtak, hogy egyik sem létezhet a másik nélkül. Ha az üzleti folyamaton változtatni kell, a szoftveren is változtatni kell. Például az kevés, ha kiküldünk egy körlevelet az új ÁFA kulcsról az összes pénzügyesnek – ez helyett/mellett a számlázó programban is át kell állítani. Folyamat és szoftver együtt, kéz a kézben változik. Minden folyamatváltozás egyben szoftver változás, és minden szoftver változtatás folyamatváltozást eredményez.

Következmény: minden olyan menedzsment munka, ami változást tartalmaz (pl. projektek), az egyben szükségszerűen IT változás is lesz. Az IT feladat az üzleti projekt része lesz. Az üzleti menedzser ha akarja, ha nem, kénytelen lesz informatikai feladatokért is felelősséget vállalni, azokat vezetni.

Mondok egy példát: tegyük fel, hogy Románia 2012 január 1-vel bevezeti az eurót. Alapvetően ez egy pénzügyi átállás: gondoskodni kell a 2011-es zárásról a régi pénznemben, gondoskodni kell róla, hogy január 1-től a cég képes legyen eurós számlákat fogadni, könyvelni és azokat kifizetni (és még sok minden másról is, csak kiemeltem pár dolgot). Viszont a cég szoftvereket használ, például könyvelési rendszert és rendelési szoftvert, az átállás részeként – ami tisztán pénzügyi feladat – a szoftverekhez is hozzá kell nyúlni (pl. szoftver fejlesztés). A főkönyvelő vagy a kontrolling vezető, akit ezzel az átállással megbíztak, észrevétlenül vezetőjévé és felelősévé vált egy szoftver fejlesztésnek.

Az nyilván nem lenne helyénvaló, ha az IT az üzleti vezetéstől függetlenül dolgozna. A szoftvert az üzleti folyamatokkal együtt kell kezelni – az eurós példában a könyvelésnek és a szoftvereknek egyszerre, egyazon szabály szerint kell átállniuk, és ennek a szakértője a pénzügy.

Jól látható, hogy az üzleti területen dolgozó nem-IT-s menedzsereknek akarva-akaratlan lesz IT-s szerepe és felelőssége. Mennyire felkészültek erre? Semennyire.

Jobbik esetben egyszerűen csak akadályként vagy nehézségként kezelik a szoftvereket, rosszabb esetben ellenségként. Hiszen az informatika kívül van a komfortzónán, a „megismert világon”. Az IT az a terület, amit nem értenek, nem is akarnak érteni, viszont maximálisan függenek tőle.

Mivel ez a függés fennáll, és mivel a nem-IT-s menedzserek is kénytelen IT-s feladatokkal dolgozni, ezért jó lenne, ha valaki valahol megtanítaná őket informatikai menedzsmentre. Nem kell érteniük a technológiához és a részletekhez – erre valók az igazi IT-sok – de azért jó lenne minimálisan átlátniuk, nekik mint ügyfélnek, megrendelőnek vagy mint menedzsernek hogyan kell(ene) kezelni az IT-t. Az az igazság, hogy az ügyfélnek és a megrendelőnek is van egy szerepe, amit el kell játszania egy projektben, és azt is nagyon el lehet rontani.

Arról nem is beszélve, hogy az informatikai menedzsment – jó, most megint a saját területemet dicsérem – nagyon fejlett. Egy nagyobb szoftverfejlesztési feladatot nem lehet kellő szervezeti struktúra és szervezettség nélkül végrehajtani (vagy lehet, de akkor az szívás lesz). E miatt a kényszer miatt egy informatikai projektek – szerintem – igenis szervezettek, messze jobban, mint a hasonló méretű „egyéb” projektek.

Biztosan akadnak kivételek is, de az a megfigyelésem, hogy míg egy informatikussal szemben alapvető elvárás, hogy projektszerűen tudjon dolgozni, egy nem-informatikai területen ez már a bónusz kategória.

(Nem egy olyan embert ismerek, aki miután IT területen megtanulta a strukturált munkát és projektvezetést, utána átment üzleti területre, és ott pusztán ezzel a tudásával messiás lett.)

Egészen pontosan mit kellene a jövő menedzsereinek megtanulni?

1) Megrendelőnek lenni

A számítógép nem csinál se többet, se kevesebbet, mint amire programozzák. A hibák egy része is abból fakad, hogy az a fránya számítógép nem tud gondolatot olvasni és nem tudja saját magát úgy átprogramozni, ahogy szeretnének. Aki megrendelő, képesnek kell lennie felismerni és megfogalmazni, mire van szüksége.

A programozás tipikusan úgy működik, hogy vannak megfogalmazott – konkrét – igények, amely igények elkészülnek, ellenőrzésre kerülnek és átadják. Még az agilis módszertanok is abból indulnak ki, hogy létezik egy igénylista (backlog).

Tipikus hiba: kifizetünk x millió forintot, és azt gondoljuk, hogy ettől majd minden jó lesz.

2) Önismeret

Ahhoz, hogy meg tudjunk rendelni egy szoftver változtatást, kell hogy legyen a fejünkben egy világos kép arról, hogyan fog a folyamat majd a jövőben működni. Ha ez nincs meg, akkor teljesen mindegy milyenek a programozók és mennyi pénzt fizetünk ki, az úgy nem lesz jó. Minden informatikai projekt ott kezdődik, hogy először az üzleti oldal saját magával legyen tisztában.

Tipikus hiba: amikor a fejlesztőktől kérdezik meg, hogyan zajlik egy folyamat. A fejlesztő lehet hogy tudja, de ha az üzleti szakértő nem tudja jobban, akkor ott valaki gyenge láncszem.

3) Kommunikáció

A szoftverfejlesztések egyik kihívása, hogy sikerül-e az üzleti szakértő/üzleti döntéshozó fejében lévő képet átkommunikálni az adott szakterülethez nem nagyon értő programozó fejébe. A programozó bármit meg tud csinálni, feltéve hogy valaki el tudja neki mondani, mit is kell megcsinálni. Egyszerűnek hangzik, de nehezen jön össze – ugyanis a programozó másképp gondolkodik, mint az üzleti szakértő.

Ezen felül minden menedzsert megtanítanék helpdesk bejelentést írni: mik azok az alapvető információk, amiket egy hibajegyben fel kell tüntetni, pl. hány felhasználót érint a hiba, mi a szoftver neve, mi az üzleti kihatása a hibának, mi az elvárt és mi a tapasztalt jelenség.

Tipikus hiba: 1 mondatos fejlesztési igény.

4) Minőségbiztosítás

Sajnos a legtöbb ügyfél egészen egyszerűen nem érti, hogy mitől lesz jó minőségű a szoftver. Nem attól, hogy senki nem hibázik, hanem attól, hogy betartjuk a technológiát és ellenőrizzük a végeredményt. Ez szükségszerűen maga után vonja, hogy az ügyfélnek is részt KELL vennie a minőségbiztosításban.

Tipikus hiba: a szoftver validálását 100%-ban beszállítói feladatként kezelni.

5) Az ügyfél aktív részvétele a fejlesztésben

A minőségbiztosításból és kommunikációból látszik, hogy bizony az ügyfélnek is aktívan részt kell vennie a fejlesztésben. Nem, nem az ügyfél fejleszt, de az ügyfélnek is időt, munkát, energiát kell beletennie. Sokat, a munka teljes időszakában.

Tipikus hiba: „nekünk nincs időnk a fejlesztéssel foglalkozni, azért fizetünk benneteket, hogy mindent megcsináljatok”.

6) Projektszerű működés

A nagyobb fejlesztési feladtok tipikusan projektszerűen hajtódnak végre. Szokás még használni az SDLC = Software Development Life Cycle kifejezést. Mindkettőben az a lényeg, hogy a fejlesztésnek fázisai vagy iterációi vannak, létezik egy terv (projekt terv, ütemterv, software design), és e szerint a terv szerint haladunk előre. A terv végrehajtása során dokumentumokat és/vagy különböző leszállítandókat kell előállítani, amiket ellenőrizni kell, majd elfogadni.

Tipikus hiba: „csak a minimálisan kötelező adminisztrációt csináljuk meg”

7) Felelősségvállalás

Egy IT projektben az üzleti oldali projektvezető (és szakértő) számára a legnehezebb dolog a felelősségvállalás. Kimondottan akkor, amikor valamiről dönteni kell. Például amikor elkészült a szoftver, és át kellene venni: felelősségteljesen el kell dönteni, hogy ez így most jó, vagy ha nem jó, akkor miért nem.

Valljuk meg őszintén: elő szokott fordulni, hogy a szoftverben hiba van. Ilyen az élet. De nem baj, mert majd a fejlesztők kijavítják. Feltéve, ha valaki ki tudja mondani, hogy mit kell megcsinálni és mikor lesz kész a munka.

Sajnos előfordul, hogy a szakértők egész egyszerűen nem elég szervezettek és nem tudják eldönteni, hogy a szoftver jó-e. Vagy pedig csak félnek aláírni a teljesítést, mert attól tartanak, hogy a programozók azonnal lelépnek amint megkapják a pénzüket.

Tipikus hiba: már 1 hónapja átvette a szoftvert az ügyfél, de nem hajlandó nyilatkozni se pro, se kontra a teljesítésről.

8) Merjünk nemet mondani

Informatikusként azt mondom, hogy szükség van olyan ügyfelekre, akik nemet mondanak egy fejlesztésre. Mert vannak kontárok, rosszul megírt szoftverek, csapnivaló minőség. Ezektől csak úgy lehet megszabadulni, ha az ügyfelek nem vesznek át akármilyen szoftvert, csakis olyat, ami pontosan azt és úgy tudja, ahogyan kell.

Félig kész, nehézkesen használható, bug-os programot senki se vegyen át.

Tipikus hiba: írjuk alá a teljesítést mert itt az év vége, aztán majd okosban kijavítjuk a hibákat.

9) Üzemeltetési folyamat

Kicsit utópisztikus, de jó lenne, ha az üzleti döntéshozók alapvető szinten ismernék az üzemeltetési folyamatot. Ugyanis ha történik valamilyen esemény (mondjuk szoftver hiba vagy váratlanul felmerülő apró fejlesztési igény) akkor jó lenne tudni, mit kell vele csinálni. Például legyen világos, hogy van egy ticketing rendszer, minden bejövő igény regisztrálva lesz, és ezek a ticket-ek vándorolnak egyik csapattól a másikhoz.

Üzletmenet folytonossághoz kapcsolódóan jó tudniuk az üzleti vezetőknek, hogy vészhelyzet esetén milyen segítséget kapnak (pl. callout plan). Ugyanis vészhelyzet esetén a saját embereiket berendelhetik munkára, de arról nincs elképzelésük, mi történik IT oldalon és kit kell felhívni.