Avagy szükséges-e az informatikusnak terepre járnia, és kit hívnak labortechnikusok?

Avagy szükséges-e az informatikusnak terepre járnia, és kit hívnak labortechnikusok?

Sokat lehetne vitatkozni arról, hogy az informatika fehérköpenyes természettudomány-e, vagy farmeros mérnöki diszciplína, illetve hogy inkább okos vagy inkább tapasztalt informatikusokra volna-e szükség. De egyik esetben sem szoktak túl sokat beszélni arról, hogy léteznek felhasználók és létezik Gemba. Pedig ezek fontos dolgok.

Egyszer egy olyan cégnél dolgoztam, amelyik büszkén reklámozta: a mi szoftverünket nem labortechnikusok gyártották. Azt értették alatta, hogy a szoftverfejlesztő cégek klasszikus felállása szerint természettudományi diplomával rendelkező fejlesztők dolgoztak egy fejlesztőből vagy közgazdászból avanzsált menedzser alatt egy profitorientált tulajdonos cégénél, addig ők egészen másként nyúltak a témához.
A cég tulajdonosa ahhoz értet, amiben a szoftver segíteni akart. A menedzser pedig korábban tanácsadó volt az adott üzleti területen, nem informatikus. A tesztelő, a dokumentáció specialista és a cég nagy része úgyszintén. Pontosan tudták, kik a potenciális ügyfeleik, hogyan gondolkodnak, mik a szokás folyamatok, meg úgy egyáltalán hogy mi a terület know-how-ja.
Használható szoftvert akartak készíteni, amit a felhasználóik könnyen tudnak használni pont arra a problémára, amit meg akarunk oldani.

Ez így egyszerűen hangzik. A gond ott van, hogy a kivitelezéshez valóban ismerni kell az üzletet és a felhasználókat.

Ugyanezen probléma kerül elő, ha megvizsgáljuk a projektek bukásának egyik fő okát, ami viccesen megfogalmazva „teljesen jó eszközt alkotunk egy teljesen rossz célra”. Ez egybevág saját tapasztalataimmal: az informatikai projekt sikere kis részben függ az informatikusok műszaki tudásával – viszont nagyrészt azon múlik, mennyire jól ismerjük az igényeket. Tehát a felhasználókat ismerni kell.

Igaz ugyan, hogy akadnak „steril” informatikai munkák, például szerver felügyelet egy szerver parkban, vagy offshore programozó, de mindig minden valahol egy felhasználón vagy egy üzleti döntéshozón múlik.

Maguk a felhasználók is elvárják (jogosan vagy kevésbé jogosan), hogy a programozó az ő nyelvüket beszélje, értse a folyamataikat, és ne kelljen neki mindent elmagyarázni. Miközben ők maguk nem értenek és nem is akarnak érteni a szoftver fejlesztéshez.

Az informatikusok egymás között a tudás és a tapasztalat alapján rangsorolják egymást, miközben a felhasználók aszerint rangsorolják az informatikusokat, hogy kivel tudnak szót érteni. Tehát nem csak szakadék tátong a két csoport között, hanem a célok is egészen mások.

Nos, akkor hogyan tesznek szert az informatikusok üzleti ismeretre?
Az igazat megvallva sehogy. És ez egy óriási probléma.

Én sok időt töltök azzal, hogy megértsem az üzletet. Több országban jártam márkakereskedőnél, több raktárt és autógyárat láttam belülről. Cégünk mindegyik osztályát ismerem, tudom a folyamataikat, a módszereiket, tudom mit szeretnek és mit nem. Szeretek terepre menni, megismerni és megnézni a dolgokat a maguk valójában.

Ezáltal nem csak megfelelő tanácsot tudok adni az üzleti döntéshozóknak, hanem ez teszi lehetővé, hogy az üzleti döntéshozók egyáltalán megkérdezzék a véleményemet. Mert ha nem tudnám a dörgést, akkor nem kérdeznének meg.

Az IT oldalon pedig el tudom magyarázni a technikusoknak, az egyes döntéseik milyen következménnyel járnak, illetve hogy mi áll egy-egy igény vagy panasz mögött.

A vállalat tisztában van vele, hogy terepen jó vagyok, és ezt ki is használják J

Persze nem mindenki ilyen. Úgy általánosságban, ha mondjuk egy szobában 10 IT manager összegyűl, akkor kb 4 bitekben és bájtokban fog beszélni, 4 folyamatokban, és csak a maradék 3 nem jön zavarba, ha szóba kerül a felhasználó.

Ha az ember felfelé ívelő IT karriert akar csinálni, akkor nagyon hamar eljut arra a szintre, hogy üzleti szakértőkkel, üzleti vezetőkkel kell tudni beszélnie. Nagyjából a vezető fejlesztő az a szint, ahol még meg lehet lenni interperszonális képességek nélkül. Ennél tovább nem lehet menni. Az sem segít, ha valaki saját vállalkozást alapít – innentől kezdve az ügyfelekkel, könyvelővel, ügyvédekkel és hivatalokkal kell majd küzdenie.

Minél magasabb beosztású IT-s valaki, annál több múlik az üzleti döntéshozáson, és a nem-IT-s képességeken. (természetesen a hard skill-ek mellett)
IT-s felsővezetőként pedig már nem is informatikai célokról, hanem üzleti célokról beszélünk, amikben az IT részt vesz.

Hogyan ismerheti meg a programozó a Gembát egy multinál?
Nincs intézményesítve. Az ember megteheti, hogy ellátogat az üzlethez, látogatást szervez a gyárba, vagy megismeri az üzleti folyamatokat. Senki sem tartja vissza. Viszont ezen lépések hiánya hosszú távon gondot okozhat.

A multik eleve olyan informatikusokat vesznek fel, akik ismerik az üzleti domaint. Aki nem ismeri az üzletet, azt kisebb eséllyel veszik fel, tehát nem is lesz esélye azt valaha is megismerni.

Gyakran létezik bevezető training az újonnan felvett kollégáknak. Ez lehet néhány órás, néhány napos, egy egész hetes, de ismerek céget, ahol fél évig tart. Ezalatt a kolléga teljes áttekintést kap a cégről, a főbb folyamatokról, az osztályokról és azok működéséről, sőt meg is látogatja őket.

Zárszóként annyit mondanék, hogy az informatikai iparág fejlődésével szerintem egyre csökken a műszaki kérdések jelentősége. Ezért labortechnikusok helyett a terepet jól ismerő, sokoldalú veteránokra van szükség.