ITÉlet

Mihez kezdjünk, ha megnyertük a nagy projektet/ügyfelet/megrendelést/állást? Hogyan lehet Magyarországról globálisan dolgozni?

Mihez kezdjünk, ha megnyertük a nagy projektet/ügyfelet/megrendelést/állást? Hogyan lehet Magyarországról globálisan dolgozni?

Mivel az EU része vagyunk és a 21. században már a globálisan gondolkodó informatikusoké a jövő, ezért érdemes elgondolkodni azon, hogyan is tudna egy magyar informatikus vagy egy magyar IT cég egy nagy külföldi ügyféllel nagy külföldi projekten dolgozni.

Ugyanis nem triviális.

Az alapprobléma az, hogy egy szoftver fejlesztési projektben a legnagyobb kockázat a kommunikációban van: nem értjük meg pontosan az ügyfél igényeket, félremegy valamilyen információ, amelynek eredményeképpen nem az, nem úgy és nem akkorra készül el. Ez simán előfordul akkor is, ha mind a megrendelő mind a beszállító magyar, és 1 km-en belül van telephelyük.

Egy európai vagy globális színtéren futó munka ennél hatványozottan hátrányosabb helyzetben van:

- A felek nem azonos nyelven beszélnek, már az is nagy dolog ha egyáltalán a szavakat értik, amit a másik mond

- Nehézkes személyesen találkozni

- Más kultúrából jöttek, ahol mindenhez másképp állnak hozzá és mást jelentenek a gesztusok

- Más munkamódszerekkel dolgoznak

- Másak a minőségi elvárásaik

- És másik időzónában vannak

Ezek a tényezők óriási akadályt jelentenek, ezért egy Magyarországról vezetett fejlesztésnél messze a legfontosabbnak tartom a megfelelő kommunikáció kialakítását. A jó kommunikáción áll vagy bukik a munka sikere.

Milyen eszközökkel lehet… illetve hogy pontosabban fogalmazzak, milyen eszközöket KELL használni ilyen helyzetben?

A nyelvi akadályok leküzdésére olyan embereket kell alkalmazni, akik tárgyalóképesen és stabilan beszélnek angolul (esetleg franciául vagy németül, az ügyféltő függően). Nem csak jól beszélik a nyelvet, de éltek is külföldön. És nem csak a menedzser beszél nyelvet, hanem minden projekt tag. Ilyen munkára csak olyanokat szabad felvenni, akik beszélik a nyelvet. Akkor is, ha külföldi üzleti partnerrel viszonylag ritkán találkoznak.

Tudom, hogy sokakban visszatetszést kelt, hogy egy ügyféllel közvetlenül nem dolgozó fejlesztőnek miért kell folyékonyan beszélnie angolul, és miért dobják ki ezért az állásinterjúról. Azonban a veszély valós.

Velem konkrétan előfordult olyan, hogy megrendelői oldalon ülve egy portugál kkv-vel dolgoztam, ahol a tulajdonos és a műszaki kapcsolattartó (vezető fejlesztő) jól beszéltek angolul. Azonban adódott egy súlyos hiba, aminek a megoldásához az kellett, hogy az egész szoftver architektúrát közösen átnézzük – rendszermérnökök és fejlesztők minden oldalról. Beszélnünk kellett volna nem csak a kapcsolattartóval, hanem más mérnökökkel is – akik viszont nem beszéltek angolul. Hogy még rosszabb legyen a helyzet, minden architekturális dokumentáció – sőt még a kód kommentek is – portugálul voltak. Pedig amit egyeztetni kellett volna, azt angolul 10 perc alatt lerendeztük volna. Így viszont hetekbe telt.

Tanulság: ha már fejlesztés és fejlesztői dokumentáció, akkor mindent csakis angolul! A kommentek, a változók és osztályok elnevezése, minden.

Nyelveket kell tanulni. Pont.

Az tény, hogy személyen találkozni nehéz egy külföldi partnerrel, és hogy a személyes találkozó a leghatékonyabb kommunikáció (akkor veszik el a legkevesebb információ). A teleconf, a videconf, az email és a prezentáció mind-mind kommunikációs veszteséget hordoz magában.

Ha komoly a projekt, akkor mindenképpen sort kell keríteni személyes találkozóra. Nem kell rendszeresen, de a több az mindig jobb, és a munka elején legyen lehetőség személyes kapcsolatok kialakítására.

A személyes kapcsolat alatt azt értem, hogy a munkát végzők találkozzanak egymással, azaz mérnök a mérnökkel, fejlesztő a fejlesztővel. A nyugati menedzserek is úgy szoktak kezdeni egy magyarországi projektet, hogy az elején idejönnek pár napra és intenzív helyszíni szemlét tartanak (elmennek a gembára…). A szemle arra is jó, hogy az összes résztvevővel megismerkedjünk, azokkal akiktől majd segítségre lesz szükségünk és akiknek majd mi dolgozunk be a keze alá.

Típushiba, hogy csak a tulajdonos és a sales-es megy el az ügyfélhez barátkozni, a fejlesztőket jól eldugják. Aztán amikor a sales-es hazajön, akkor a fejlesztőkhöz vágja az ügyfél igények listáját, és ezzel a kommunikáció letudva. A végén pedig mindannyian csodálkoznak, hogy az ügyfélnek miért nem lett megfelelő a kifejlesztett szoftver.

Tehát személyes találkozásra szükség van, főleg a munka kezdetén, de utána óvatosan kell vele bánni. Az üzleti út időt vesz el, amit esetleg értékes munkával is lehetne tölteni a repülőtéren várakozás helyett. A fejlesztő és rendszermérnök egyébként is saját környezetében tud hatékonyan dolgozni, ha repülőre rakjuk őket és az ügyfél irodájában csücsülnek, azzal kvázi pénzt szórunk ki az ablakon.

Ha már a felek ismerik egymást, akkor üzleti utak helyett sokkal hatékonyabb a rendszeres telefonkonferencia és videó konferencia – mind pénzben mind időben. Ja igen, amikor valakivel megismerkedünk, próbáljuk meg kitalálni, mi a preferált kommunikációs csatornája: állandóan a fejéhez van tapadva a mobilja vagy utálja ha hívják, meetingről meeting-re szalad vagy feleslegesnek tartja azokat, elolvassa-e minden emailjét vagy legszívesebben betiltaná. Mindenki más.

A formális kommunikáció a legbiztonságosabb, amikor előre szabályozott és óramű pontossággal zajlik: ki mikor milyen rendszerességgel milyen információkat küld el vagy miről prezentál. Az ötletszerű „hívjuk egymást ha baj van” jellegű kommunikációs stratégia a létező legrosszabb.

A kulturális különbségek leküzdésére nem csak a más kultúrákat kell elfogadni és nyitottnak lenni, hanem követni kell a nemzetközi szinten elfogadott legjobb gyakorlatokat, az „általános munkavégzést”. A hozzáállásbeli különbségeket nagyon jól le lehet kezelni azzal, ha a projekt megfelelően szervezett. Tehát követjük az legjobb gyakorlatot, betartjuk a fázisokat, megtartjuk a szükséges meeting-eket és megírjuk a szükséges dokumentációt. Mindez extra bürokrácia és kissé lassítja a munkavégzést, ugyanakkor kiküszöböli a kulturális különbségből adódó félreértéseket.

Ha egységes folyamatot követünk, akkor nem fog a munkavégzés a kultúrák közötti harccá válni.

Ja, és majdnem elfelejtettem… ahhoz, hogy másokat elfogadjunk, annak része az, hogy magunkat is elfogadtatjuk. Azaz előbb arra figyelünk, hogy a mi kommunikációnk legyen jó és a mi munkánk legyen megfelelő, és csak utána foglalkozzunk azzal, hogy a másik mit és hogyan csinál.

Ugyanis a másik cég biztosan mindent másképp csinál és más munkamódszerei vannak. Ez talán még itthon sem meglepetés, de külföldiekkel dolgozva még élesebb az ellentét. Ezt úgy lehet a legegyszerűbben kikerülni, ha odamegyünk és megnézzük a másik cég módszereit. Már írtam a helyszíni szemléről, na az kiváló alkalom megismerkedni a módszerekkel. A szemle tehát ne csak unalmas prezentációkból és ismerkedésből álljon, hanem konkrétan oda kell menni a fejlesztőkhöz, bekukkantani a szerverszobába, és leállni csevegni a QA-sokkal a kávéautomatánál. Bezárva egy meeting room-ba, unalmas prezentációkat nézegetve sosem tudunk meg annyit, mint ott, ahol a munkavégzés zajlik.

És természetesen ugyanez visszafelé igaz: legyünk őszinték és mutassuk, mondjuk el módszereink.

Fontos dolog: a munka megkezdése előtt érdemes megegyezni, hogy kinek a módszerét követjük, milyen módszertant használunk, és azt milyen mértékben. Nagy meglepetés tud lenni, ha a fejlesztési projekt felénél derül ki: a beszállító Scrum-ot követ, de a megrendelő ragaszkodik a vízesés fejlesztéshez…

És az is nagy meglepi tud lenni, ha a projekt felénél az ügyfél hírtelen bevezeti a Scrum-ot, mert azt hallotta egy tanácsadótól hogy attól a projekt minden baja rögvest megoldódik.

A minőségi elvárások tisztázása kulcsfontosságú a munka sikeréhez, és rögtön a munka elején – még az előkészítés fázisban – meg kell tenni. Ahhoz viszont, hogy az ügyfél elvárásait tisztázzuk, előbb tisztázni kell, hogy ki is az ügyfél!

Nagyon egyszerűnek tűnik, és nagyon nem az.

Amikor a projekt elkezdődik, készíteni kell egy szervezeti ábrát az ügyfélről, a beszállítóról és a projekt szervezetről, ahol szerepel mindenkinek a neve, szerepe, beosztása, feladatai, elérhetősége, és a főnökei neve.

Tisztázni kell, hogy a munkára ki adja a pénzt, ki a felelős a projektért, ki ellenőrzi a projektet, ki írja alá a teljesítést, kiket kell bevonni a projekt végrehajtása során, kiket érint a projekt, és kik azok, akik élet-halál jellegű kérdésekben dönthetnek.

Típushiba, hogy ez teljesen elmarad, esetleg készül ugyan valamilyen lista a résztvevőktől, de szervezeti hierarchia helyett inkább magánnyomozói részletességgel lényegtelen információk szerepelnek: milyen ételt szeret, mennyire ért a technológiához, milyen diplomája van.

Az is típushiba, hogy mi magyarok inkább az informális kommunikációt preferáljuk. Sokkal nagyobb jelentőséget tulajdonítunk a pletykáknak mint a hivatalos kommunikációnak, és elsősorban azokkal beszélünk akikkel szeretünk (akiket kedvesnek, okosnak, segítőkésznek tartunk), nem pedig azokkal, akikkel a funkciójuk alapján beszélnünk kellene.

Így előfordulhat például az, hogy van egy okos+értelmes fejlesztő a másik cégnél, ezért egy idő után őt hívjuk minden dologgal, és vele beszéljük meg a fejlesztési kérdéseket. Például megegyezünk vele, hogy az egyik kért funkciót inkább nem fejlesztünk ki, mert aránytalanul sok munka lenne. Ezt ő logikusan tartja és megegyeztük. De aztán amikor kiadjuk a szoftver release-t, akkor a vezetőség dühösen visszadobja, mert az a funkció hiányzik belőle. És az okos+értelmes fejlesztő hirtelen álláspontot vált – immár szerinte kell az a funkció. Na az ilyen szituációk elkerülése miatt nem a fejlesztővel, hanem a megfelelő szinten a megfelelő döntéshozóval kell meghozatni a megfelelő döntést – és ehhez tudni kell, hogy ki hol miben dönthet.

Az időzónák által jelentett probléma elsősorban ázsiai vagy amerikai projekteken bukkan fel. Mivel csak a nap egy részében (kis részében) van átfedés a munkaidőben, ezért a kommunikáció az általános „real time” helyett (amikor bármikor felhívhatok valakit) „offline” lesz. Tehát nem telefonálgatunk annyi, hanem inkább emaileket írunk, és majd másnapra megkapjuk a választ.

Egy ilyen felállásban szükség van offline kommunikációs eszközökre. Az email tökéletes. Amikor kérdésük vagy véleményünk van, akkor megírjuk, és a másik fél amikor beér az irodájába akkor elolvassa és válaszol. Ez egyrészt azt jelenti, hogy azonnal sosem kapunk választ (ami rossz), de azt is, hogy másnap reggelre minden kérdésre választ kapunk (ami jó). Mármint ha követjük azt a rutint, hogy az emaileket minél gyorsabban megválaszoljuk, és nem parkoltatjuk őket hetekig.

Informatikai projektben nagyon sokat tud segíteni egy incidens kezelő vagy hibakövető rendszer. Az ügyfél nap közben beleönti a problémáit a rendszerbe, éjszaka pedig a fejlesztők mindent megnéznek és válaszolnak rá.

Ha ezeket a dolgokat jól csináljuk, az időeltolódás hátrányból előnyre válik: a munkatársak biztosak lehetnek benne, hogy másnap reggelre mindenre lesz válasz és/vagy megoldás, nem kell ott izgulni a fejlesztők fölött hogy mikor lesznek kész. Amit este elküldünk, az reggelre kész.

Összességében az látható, hogy megfelelő szintű szervezettséggel és önfegyelemmel ellensúlyozható a távolság okozta akadály a kommunikációban.

A tanulság talán az lehet, hogy minden megoldható, ha az ember tisztában van az előtte álló akadállyal és a helyes eszközöket alkalmazza ahelyett, hogy a rajta kívül álló okokat hibáztatja és megpróbálja feltalálni a spanyolviaszt.