Ismét kedvenc vesszőparipámon, a kommunikáción lovaglok. Hogyan kellene megszervezni az IT osztály belső kommunikációját? Vigyázat, nyomokban best practice-t tartalmazhat!

Ismét kedvenc vesszőparipámon, a kommunikáción lovaglok. Hogyan kellene megszervezni az IT osztály belső kommunikációját? Vigyázat, nyomokban best practice-t tartalmazhat!

Itt e blogban nagyon-nagyon sokszor írtam már kommunikációról. Ezen belül is elsősorban az IT-üzlet illetve IT-ügyfél relációban. Most az IT-n belüli kommunikációról írnék: hogyan kommunikálunk mi, informatikusok egymással házon belül, hogyan kellene ezt jól csinálni?

Volt már erről szó korábban a Hogyan kommunikálj az IT-n belül? című cikkben. Ott elsősorban az egyénre koncentráltam, most pedig azt a cikket kiegészítve a munkaszervezésről és a kommunikációs folyamatról írok.

Nos, kezdjük olcsó hatásvadász lózungokkal: jó kommunikációra szükség van. Ha nincs jó kommunikáció, akkor a munka is hátrányokat fog szenvedni. Ez mindenhol így van, de egy informatikai projektben különösen, ugyanis az átlagos kockásinges informatikus nem kommunikációs szakember – és nem is szeretnénk, hogy az legyen.

Valahogyan viszont a sok kockásingest össze kell hangolni, szükség van információ áramlásra. Ez a legtöbb esetben a „gyerekek, próbáljatok meg csapatban dolgozni”, a „segítsétek egymást”, és a „beszéljetek egymással” módszerek alkalmazása (bunkósbot módjára). A menedzserek kommunikációs problémákat megoldó taktikai atomfegyvere pedig az, hogy mindenkit összehívnak egy onsite meeting-re, bezárják az összes résztvevőt 1 szobába 1 napra, és csak akkor kapják meg az ajtó kulcsát, ha már megoldották a problémát.

Nos, mindez kevés és nem hatékony. A kommunikációs problémákat nem megoldani hanem elkerülni kell, amit megfelelő eszközökkel, folyamatokkal és munkamódszerekkel lehet elérni. Ezekért a vezető, személy szerint a CIO a felelős.

Hogyan kell(ene) mindezt jól megszervezni?

Rögtön bontsuk kétfelé a dolgot: az informatikai csapat, az informatikusok napi szintű kommunikációja, illetve a projekt kommunikáció.

A napi szintű kommunikáció szükségszerűen szabványosított. Ugyanis léteznie kell valamiféle szabványosított keretnek a munkavégzéshez, és ez a keret tartalmaz előírást a kommunikációra is. IT-n belül megkerülhetetlen, hogy legyen egy ticketing rendszer. Ide kerülnek be a problémák és feladatok, és ez az eszköz biztosítja a folyamat követését (workflow). Valahogy így:

1) Ticket létrehozása: Ha valakinek segítségre van szüksége az adott csapattól (fejlesztők, rendszermérnökök, stb) akkor létrehoz egy ticket-et. Ennek formája és tartalma szabályozott, tehát előírt, hogy mit kell egy feladatról vagy problémáról leírni. A rendszer kezeli, hogy több ticket esetén melyik a fontosabb.

2) A feladat végrehajtása: A ticket-ek lekérdezhetőek a rendszerből, azaz a fejlesztőnknek lesz egy listája arról, milyen feladatokkal kell foglalkoznia. Ezeket végrehajtja, szükség szerint visszajelez a rendszeren keresztül.

3) A ticket lezárása: Amikor a feladat kész, akkor azt ellenőrizni kell és visszajelezni az üzlet/felhasználók felé.

Elvárások a ticketing rendszerrel kapcsolatban:

- Csak egy rendszer, csak egy lista legyen. Ha több lista és több rendszer van, az biztosan kommunikációs hézagokat generál, illetve a listák/rendszerek között szinkronizálás fölösleges energiát igényel (ami veszteség).

- Ez a rendszer legyen általános, mindenki által használatos.

- Kövesse az elfogadott szabványos munkafolyamatot.

- Legyen visszakövethető, mikor mi történt, ki mit szólt az adott ticket-hez.

- Legyen egyértelmű és világos, tehát egy gombnyomással megnézhetem, hogy mik az én feladataim.

- Reporting, vezetői kimutatások

Fontos elvárás a megbízhatóság, de ez nem a rendszer sajátossága, hanem azoké, akik azt használják. Tehát ha valaki bedob egy feladatot a rendszerbe, akkor legyen garantált, hogy az a feladat valahova kerül, azzal valaki dolgozik, és nemcsak hogy 100% valószínűséggel, hanem még ráadásul adott időn belül.

Ez a garancia – hány órán belül old meg az informatikai szervezet egy problémát/feladatot – amit nevezhetünk Service Level Agreement-nek (SLA) is. Mivel a feladatok végrehajtása összetett és több kolléga/specialista munkáját is igényli, ezért az IT csapatok között is szükség van valamilyen megállapodásra a garantált végrehajtásra – Operational Level Agreement (OLA).

Az SLA és az OLA meghatározza a szolgáltatást és a szolgáltatás minőségét, ami mérhető és visszaellenőrizhető. Ez egyrészt segítség a CIO-nak, hiszen az üzlet felé konkrétumokat tud letenni az általa garantált szolgáltatásról, illetve formálja a vele szembeni elvárásokat. Másrészt pedig ha a szolgáltatás nem megfelelő, akkor megfogható, pontosan miért nem és hol van baj.

A ticketing rendszer egységesíti a munkát, azonban ne felejtsük el, hogy az IT osztály nagyon összetett. Sok, egymástól teljesen különböző hátterű és tudású informatikus végez egymástól nagyon különböző munkát, hogy a végén aztán ez a sok különféle munka egységes egésszé álljon össze. Bizonyos méreten túl nem lehet a munkavégzést egységesíteni. Szükség van arra, hogy az egyes szakterületek és csapatok saját folyamatokat és saját sztenderdeket alkothassanak (amik illeszkednek a közös folyamatba). Például ha valaki a rendszermérnököktől új szervert kér az egyik projektjéhez, ahhoz a rendszermérnököknek tudniuk kell, pontosan mit fog csinálni az új szerver, milyen műszaki paraméterekkel rendelkezzen, mi legyen rá telepítve, és ki állja a felmerülő költségeket (hardver és licensz). Ehhez alkotnak egy szerver igénylési formanyomtatványt és folyamatot.

Az IT szervezet működéséhez szükséges, hogy ezek a specifikus folyamatok valahol – egy közös helyen, gyorsan megtalálhatóan – le legyenek írva, elérhető legyen a kitöltendő formanyomtatvány, legyen róla minta, és a specifikus folyamat ellenőrizhető, visszamérhető legyen. Ezen leírások és dokumentumok tárolására szükség van egy (szigorúan egy) web site-ra, tipikusan az intraneten. Amolyan policy & procedure repository. Ezen a web site-on a dokumentumok tematikusan és kereshetően rendezve vannak. Ha valaki valamit nem tud akkor odamegy, megkeresi, elolvassa, kitölti a megfelelő adatlapot és elküldi a megfelelő email címre.

Szükséges a dokumentumok rendszeres frissítése, hiszen a folyamatok változnak.

Ha már létezik ilyen web site-unk, akkor azon további funkciók is lehetnek: hírek, hírlevél, fényképes szervezeti ábra és telefonkönyv, fórum, blog, érdekes információk, képek és videók, közérdeklődésre számot tartó report-ok.

Amikor új kolléga érkezik a céghez, neki nagy segítség lesz, hogy ilyen web site létezik. Nekik azonban ennél többre is szükségük lesz. Ahhoz, hogy jól tudják követni a közös és az egyedi folyamokat, betanításra lesz szükségük. A „learn on the job” időrabló és keserves tapasztalatai helyett sokkal hatékonyabb a célirányos oktatás (induction training), ami még hatékonyabb, ha az oktatás online történik. Az oktatói anyagokat elő lehet készíteni videó vagy prezentáció formájában, így rengeteg időt és energiát spórolva meg.

Ha már IT, akkor mondanom sem kell, hogy biztosítani kell a kommunikáció TECHNIKAI feltételeit: asztali és mobil telefon, vállalati IM, confcall és video conf eszközök, hordozható számítógép, mindenkinek legyen webkamerája, fejhallgatója és mikrofonja, legyenek handfree phone eszközök, meg lehessen osztani a képernyőt távoli munkatársakkal, legyen VPN, az emaileket távolról is meg tudjam nézni, sőt akár az okostelefonomon, tudjak interneten keresztül az amerikai és az ázsiai üzleti partnereimnek EGYSZERRE prezentálni, fájlokat és dokumentumokat megosztani. Csak mert mindez a 21. században a minimumot jelenti.

Talán nem triviális a csoportmunka eszközök használata. Lehessen projekt, csapat vagy feladat szinten saját web site-ot vagy mikroszájtot létrehozni, ahol az adott projekt vagy adott csapat dokumentumokat, adatokat vagy prezentációkat oszt meg, azokon közösen dolgozik. A legtöbb esetben ez egy shared folder szokott lenni, de léteznek ennél jobb – és hatékonyabb – eszközök is.

Az IT szervezeti egységekről feltételezzük, hogy azok önmaguk belső kommunikációját megszervezik. Elvárjuk tőlük, hogy a belső kommunikációjukat, a belső információáramlást megoldják, például saját szabályok és folyamatok felállításával. Feltételezzük róluk, hogy vannak saját fórumaik és meeting-jeik, ahol ezeket kezelik.

Nagyon sok olyan funkció lesz, ahol több csapatnak vagy csoportnak közösen kell dolgoznia. Tipikusa azért, mert az egyik csapat szolgáltató, a másik az ügyfél szerepében van. Például a rendszergazdák felügyelik a szervereket, amelyeken a fejlesztők dolgoznak. Ha műszaki hiba lépne fel, a fejlesztők (ügyfél) szólnak a rendszergazdáknak (szolgáltató), akik elhárítják a hibát. Éppen ezért szükség van valamilyen fórumra, ahol a szervereket érintő változásokat közösen áttekintik és döntéseket hoznak. Sem az nem jó, hogy a rendszergazdák egyedül döntenek szerver változtatásokról a fejlesztők nélkül, sem az nem jó, hogy a fejlesztők a rendszergazdák nélkül. Ennek a közös fórumnak szintén meglesz a saját folyamata, saját szokásai és dokumentumai.

Eddig nagyrészt célzott, formális kommunikációról írtam, most jöjjön egy kicsit informálisabb. Egy IT szervezetben – de ez bizonyára mindenhol így van – nem csak pici fogaskerekek vagyunk a gépezetben, hanem véleményünk, kreativitásunk és fejlesztési szándékunk is fontos. Tehát nem csak munkafolyamatok mentén érintkezünk egymással, hanem ötleteket vitatunk meg a kávéautomata mellett, szabad időnkben hobbi projektek dolgozunk, esetleg másik osztályhoz tartozó kollégákkal közösen egy új ötletet dolgozunk ki. Ez a fajta kommunikáció is fontos, sőt lehet, hogy nagyobb hasznot hoz a cégnek, mint a standard: kiaknázzuk a közösség erejét.

Ezt a fajta kommunikációt nem csak támogatni kell, hanem generálni is. A kommunikációs eszközökkel lehetővé kell tenni, hogy a szervezeti hierarchiától eltérve is lehessen közösen dolgozni. Erre jó például egy vállalati social website, ahol nyílt fórumok és blogok segítik a csoportmunkát.

A mátrix szervezet már annak a felismerése, hogy az egyirányú monolit szervezeti ábra nem működik. Lehetővé kell tenni, hogy szükség szerint bárki bármikor létrehozhasson egy virtuális csapatot, a virtuális csapat közösen dolgozhasson, a közös munka eredményei pedig ne vesszenek el.

Időről időre szándékosan is virtuális csapatokat kell építeni, hogy megadjuk a gyújtószikrát a közös munkának. Ilyen lehet egy adott (mindenkit érintő) problémára felállított válogatott csapat, akik mind-mind más osztályról vagy más telephelyről jönnek.

Megemlíteném még a job rotation-t, mint tipikus best practice.

Röviden ennyit, és most jöjjön a projekt kommunikáció.

Mivel a projekt egy adott célra, adott csapattal jön létre, ráadásul időben behatárolt (van eleje és vége), ezért a projekt kommunikáció nagyon specifikus. Előre meg kell határozni a projekt kommunikációs tervét, azaz ki mikor milyen céllal mit beszél meg, és arról ki értesül. Nagyon nehéz a jó kommunikációt ledefiniálni, de talán egyik fajta definíciója lehetne az, amikor a kommunikációs tervet sikerül teljesen követni és tökéletesen végrehajtani.

A kommunikáció eszközei ugyanazok, mint korábban írtam: website, csoportmunka eszközök, ticket-ek, nyilvántartás, dokumentáció, és a szükséges fórumok.

Alapvetően a projektnek a következő kommunikációra van szüksége:

- Operatív kommunikáció: feladat végrehajtás, információ megosztás, például daily standup meeting vagy workshop

- Projekt kontrol: a projekt állapotának ellenőrzése, például heti státusz

- Reporting: a stakeholderek és szponzor felé

- Eszkaláció és változtatás: részben erre szolgál a felügyelőbiztossági ülés

Mindegyik kommunikációs csatornát ki kell dolgozni, figyelembe véve azt, hogy a projektben több szereplő is van, ezért lehet, hogy a különböző szereplőkkel különböző fórumokon és különböző módon kell kommunikálni.

Nagyjából ennyi, és a végére szerencsedió-bölcsesség: szükség van tervezett kommunikációra és ad-hoc kommunikációra, de ha lehet, akkor az ad-hoc kommunikációt hagyjuk meg a kivételes helyzetekre, és amit csak lehet próbáljunk meg formalizálni. Ugyanakkor a túl sok meeting és túl sok report sem jó. Meg kell találni a lényeget, hogy a sok információból pontosan mire van szükség, milyen gyakran és milyen gyorsan, ki tudja ezeket szolgáltatni, és mi az a legegyszerűbb módszer, amihez ehhez hozzáférhetünk.

Találd meg a harmóniát :)