“Olyan cégeknek szeretnék segíteni, amelyeknek van hozzáadott értéke a világhoz.”

Hesz Roland 2010 óta dolgozik hazánk határain kívül üzleti elemzőként, jórészt Londonban.
Amikor kapcsolódtunk a Linkedinen, kíváncsivá tett, hogy vajon Anglia és Hazánk között milyen különbségek lehetnek a business analyst szerep megítélése között. Előljáróban annyit osztok meg, hogy máshol sincs kolbászból a kerítés.

Mivel foglalkoztál, mielőtt Londonba költöztél?

Business analyst voltam, már amennyiben létezik ez a szakma. Van egy szakirodalom szerinti megfogalmazása a munkakörnek, de nagyon függ attól, hogy hol dolgozunk, milyen kultúrában és hogy mire vesznek fel. Arról nem is beszélve, hogy az álláshirdetéseknél figyelni kell, hogy pénzügyi elemzést, adatbányászatot, vagy IT és üzlet közötti kapcsolatépítést keresnek. Az előbbi jellemző Londonra, mert itt rengeteg bank van, pénzügyi központ, ezért hamarabb futunk bele a monetáris tanácsadói álláshirdetésbe.

Az esetek 70%-ban a BA nem kerül közelébe az üzleti döntéshozásnak. Még ott tart a gondolkodás, hogy a Business Analyst írja le a követelményeket és pont. Aztán attól függően, hogy mennyire rugalmas, vagy “pofátlan”, megpróbálja befolyásolni az üzletet. Én is dolgoztam olyan agilis környezetben, hogy írjam le a követelményeket és szaladgáljak az üzlethez kérdéseket feltenni, hogy az üzlet ne zavarja a fejlesztőket. Ennek egyik szereplője a product owner, a másik pedig a BA, aki a proxy product owner (én magam itt nagyot nevettem 🙂 ) és a témák részleteit tisztázza.

Voltam olyan környezetben is, ahol kifejezetten azért vett fel a tulajdonos, hogy az új software bevezetés esetén mondjam meg neki, ha hülyeséget akar. Ilyenkor persze azt is meg kellett mondanom, hogy miért nem, és alternatívákat ajánlani helyette. Újként nem mondhatom neki csak úgy, hogy mit csináljon, hiszen Ő sok éve dolgozik a cégnél, én meg éppen csak megérkeztem.

Mi a kedvenc eszközöd?

A kedvenc eszközöm a kávé. Havasi Béla mondta anno, hogy a kezdő BA elmegy a meetingre és mindenkivel formálisan megbeszéli, hogy mit és hogyan kellene csinálni.

A hozzáértő pedig leül utána egy kávéra az alkalomazottakkal és megtudja, hogy hogyan működik igazán a folyamat.

A kávé mellett felszínre jönnek az őszinte információk, amelyek olyan kockázatokat tárnak fel, amelyet senki nem mer kimondani hivatalból.

A másik, hogy nem csak azzal kávézom, aki benne van a projektben Ehhez a szakmához szociális tőkét kell építeni, hogy a valós információkhoz nyíltan hozzá tudjunk jutni. Mi üzleti elemzők 70-75%-ban emberekkel dolgozunk. Az emberekből ki kell szedni a tudást, az infót. Kérni vagy ellentmondani csak úgy lehet, ha tisztelnek vagy elismernek. Ha nem vagyok hiteles, akkor nem tudom azt mondani, hogy ez nem ok, hanem helyette A vagy B vagy C kellene. Mi egy kommunikációs csatorna vagyunk. Minket nem érdekel, hogy javaban vagy c#-ban kell megoldani.

Nekem a jó megoldás kell, mert én képviselem az üzletet.

Te valóban az üzletet képviseled. Jól értem?

Egyik oldalról fontos látni, hogyha rugalmatlanul közelítünk és azt mondjuk, hogy 6 hónap a fejlesztés és nincs elkerülő megoldás, akkor addig nem adnak el belőle, addig nincs bevétel, és lehet, hogy egyszer nem tudnak kifizetni.

Azt mondom:

• Egyrészt tegyük lehetővé az üzletnek, hogy tudjon dolgozni, amíg mi a háttérben megoldjuk a problémát
• Másrészt priorizáljunk. Nézzük meg, hogy mi a fontos és ne feledjük el, hogy kinek.

Milyen módszertan szerint dolgozol?

Legtöbbször agilitás. Véleményem szerint az agilitást nehéz kivitelezni, hiszen a vezetőség sokszor a könnyen bevezethető, felszines dolgokra fókuszál. Vegyük például a user story-t.

A user story definíciója, a 3 résszel egy narratíva. Az igazi user story a másik, az üzleti oldalon van. Ami vagy 32 oldal vagy 2 oldal, attól függően, hogy milyen kiegészítő információ szükséges. Ezt legtöbbször nem dokumentálják le, mert azt hiszik a módszertan ezt mondja.
De, le kell írni. Ugyanis a fejlesztő legtöbbször nem ül együtt az üzlettel egy szobában, hogy real time kapja az információkat. Ez egy fontos része lenne az Agilis metódusnak, de általában nem történik meg, viszont ilyenkor ezt a részét a módszertannak valahogy potolni kell.
Amikor valóban együtt ültek, akkor bizony megérkezett egy új jelenség, a karámozási probléma. Ez azt jelenti, hogy az üzlet 3 hónap után a fejlesztőket tekintette saját csapatának és már nem az üzlet érdekeit képviselte. Ezt viszont nagyon kevés helyen kezelik tapasztalatom szerint, azon túl, hogy amint egyszer megtörténik, a gyakorlatot egyszerűen megszüntetik.

Szembetűnő, mikor az IT-t leválasztják és nagy lesz közöttük a szakadék. Bármelyiküknek van a másik területével kapcsolatban meglátása, javaslata, lesöprik az asztalról, még ha jogos is lenne. Egyre nagyobb lesz közöttük a szakadék és már nem is akarnak rálátni egymás munkájára.
Az üzlet nem lát rá, hogy miért tart olyan “sokáig” a fejlesztés vagy a hibajavítás, az IT pedig nehezen látja be, hogy amíg nem javítja ki, addig az üzletnek kézzel, elkerülő megoldással kell élni, ami általában jóval nagyobb energia. Patthelyzet. Ezt a két problématerületet közelebb kell vinni egymáshoz.

Mennyire vesznek részt a tesztelésben az üzleti elemzők?

Ez attól függ. Nálunk nem is tudnak a business analystek tesztelni. Van egy csapat, aki UAT tesztet végez, de egyébként automatizált tesztjeink vannak (ami amúgy nagyon jó, mindenhol kell). Az automata tesztelés kifejezetten elterjedt. Eddig mindenhol ahol dolgoztam, jelen volt a folyamatban. Jellemző, hogy automata teszteléshez értő szakembert hamarabb vesznek fel, mint üzleti elemzőt. A BA majdhogynem luxus. Nagyon sok vállalatnál az agilis transzformációval megjelent a product owner és azt gondolják, hogy nem kell mellé a business analyst, hiszen a PO valójában egyenlő BA. De sajnos ez nem így van.

Az agilis fejlesztés nem arról szól, hogy elindulok terv nélkül és aztán valahová megérkezem. Nem indulhatunk el, hogy kell egy számlázó program és aztán végül lesz belőle egy szövegszerkesztő. Ez nem agilitás.

Le kell fektetni, hogy Barcelonában vagyunk és Münchenbe szeretnénk menni.
Azt is el kell dönteni, hogy nyaralni megyünk vagy a nagybácsit meglátogatni.

Az agilitás ebben annyi, hogy vonattal megyünk, vagy autóval, esetleg úgy megyünk autóval, hogy a szép helyeken megállunk. A célokat előre kell kitalálni.
Az agilis fejlesztésnek nagyon sok értéket tulajdonítanak, amellyel nem feltétlenül rendelkezik. Viszont ami elvitathatatlanul a sajátja, hogy sokkal hamarabb kiderül, ha hiba van, és ez nagy hozzáadott érték.

Sok helyen egyébként inkább kanban modellre térnek át. Főleg, ahol lehet tudni, hogy a sprint-be muszáj lenne bevenni az időközben beeső elemeket.

Kedvenc mondásom, hogy nincs ezüstgolyó. Szakdolgozatomat az SS ADM-ből írtam, amely egy strukturált rendszerszervezői módszertan. Foglalkoztam Rational Unified Process-el (RUP) és Unified Process-el. Aztán dolgoztam Extreme Programinggal (EP). Viszont ami fontos, hogy

az első fejezet minden módszertanban leírja, hogy ismerd meg a módszertant, ismerd hozzá a saját működésedet és csak azt vedd át, amire szükség van.

Testre kell szabni minden projekt esetén. Nem szabad egy módszertant A-tól Z-ig bevezetni.

Van egy kedvenc interjúkérdésem, amikor én vagyok az alany. Amikor mondják, hogy agilisan működünk, én pedig megkérdezem, hogy MIÉRT. Ezt nem szeretik és gyakran nem is tudnak válaszolni, és előfordul, hogy emiatt nem vesznek fel 🙂

Van, amikor én interjúztatok gyakran megkérdezem, hogy mit nem szeretsz az agilisben? Ugyanis ezt nem írja le a tankönyv. Ha erről van véleménye, az már jó eséllyel a sajátja.

Fordítsuk vissza kérlek egy pillanatra. Mit nem szeretsz az agilitásban?

Azt, hogy az emberek nem tudják használni. Én azt nem szeretem benne, hogy nem veszi figyelembe, hogy esetleg hozzá nem értő emberek fogják olvasni és bevezetni. Ez nem a módszertan hibája, az Agile Manifesto írói szerintem úgy gondolták, hogy az emberek gondolkodnak, mielőtt elkezdik használni. Leírja, hogy az emberek a fontosak a processek és dokumentáció felett. És ebben a pillanatban ezt mindenki úgy értelmezi, hogy nem kell dokumentálni. Ezt hallják meg, mert mindenki utál dokumentálni. Pedig kell. Hasznos leírni, lehet benne modelleket használni, de az információt át kell adni.

Van egy könyvem business analyst eszközökről, amely 72 esszenciális eszköz a sikerhez. De ha jól végiggondoljuk, akkor

két eszközünk van üzleti elemzőként. A kategorizált lista és a doboz meg nyíl, ami valójában kategorizált lista.

Nem kell más a sikerhez. Amint van előttem egy lista, amelyet kategorizálni kell, annak meg kell határozni a vizsgálati szempontjait, ezután pedig könnyebb eldönteni, hogy milyen formában a legjobb prezentálni: mátrix, táblázat, grafikon, pie-chart, folyamatábra stb. Az adott szituácónak megfelelően tudjuk alakítani a prezentációt, hogy az a legjobban segítse a megértést.

Ebből a fő tanulság az, hogy ha tudom, hogy egy listát bárhogy kategorizálhatok, meg ábrázolhatok, akkor nem az a kérdés, hogy melyik nevesített technikát kellene itt használnom, hanem ha épp úgy hozza a helyzet, akkor megcsinálom a sajátomat, amelyik az adott szituációnak a legjobban megfelel.

Jó, ha ismerjük a módszertanokat, de annak sokszor csak egy kis részét használjuk. Érdemes azokat testreszabni. Például nem UML ábrát viszek a workshopra a közös megértés biztosítása végett, hanem egy dobozt és nyilat, mert azt mindenki érteni fogja, fejlesztők is, üzlet is, az árurakodótól az ügyvédig.

Van olyan modelled, amely kedvenc?

Igazából, ha valami komplikáltat kell csinálni, akkor UML, mert olyan elemei vannak, amelyek tisztává és áttekinthetővé teszik az információkat. Ha nem kell, akkor marad a doboz és nyíl rombusszal, illetve a párhuzamos vastag vonalak a párhuzamos futáshoz.

Kitől tudsz a környezetedből tanulni?

Mindenkitől. Kollégák, üzlet, fejlesztők.
Youtube.
Valamint olvasok filozófiát, pszichológiát, szociológiát, politikát, mozi- és irodalomkritika elméletet.

Ettől jobb BA leszel? Segíts kérlek megértenem 🙂

Valaki készített a youtubon egy remek dokumentumfilmet. Elkezdte bemutatni, hogy a különböző kameraállásoknak, vágásoknak és zoomolásnak milyen hatása van. Ha belegondolsz, mi sztorikat mondunk embereknek. Ezzel megértem, hogy hogyan lehet egy sztorit jól felépíteni, milyen analógiákat érdemes használni annak érdekében, hogy a célomat elérjem.

A másik, amelyet most nézek, az a következőkről szól: fűzőtörténet, miért nem viselünk kalapot, divattörténet a kosztümös filmek vonatkozásában. Számomra lenyűgöző az az összefüggés, hogy azért nem viselünk kalapot, mert bizonyos társadalmi változások történtek a világháborúk során. Bemutatja, hogy rendszerszinten hogyan épülnek egymásra a változások, amelyek hatására ma már nem hordunk kalapot.

Ezekről egyrészt a kollágékkal jól el lehet beszélgetni, amely hozzáadott érték a kávézás részhez visszacsatolva.
Másrészt megismerem az erre épülő logikákat, hogy a változások milyen láncolaton mennnek végig. Ezáltal megismerem, hogy apró változások hogyan hatnak nagy rendszerekre és bizony azt látom, hogy ez nem csak társadalmi, hanem szervezeti szinten is igaz.

A tapasztalatokat is azért tudjuk mi business analystek hasznosítani különböző iparágak között, mert egyel hátrébb lépünk.

Amikor a pénzügyi világból átmentem a raktározás világába, elég sok mindent tudtam hasznosítani. Mi az üzleti portfólió? Jönnek dolgok be, mennek dolgok ki. Mi a raktárkészlet? Jönnek dolgok be, mennek dolgok ki. Amiben különböznek az a folyamatok időzítése. Ettől a ponttól már az egyik tapasztalatát át lehet emelni a másikba.

Mit látsz különbségként a két ország között?

Egyrészt itt sincs kolbászból a kerítés. Másrészt azt látom, hogy a nyelv nagy akadály. Mire egy szakirodalom lefordításra kerül angolról magyarra, az 8-10 év. Akkorra a nemzetközi gondolatok elavulnak. Harmadrészt olyan drága lesz a könyv a kicsi piac miatt, hogy akkor meg azért nem tudják megvenni.

Mi az erősséged neked, mint üzleti elemző?

A humorérzékemet rendre kiemelik a stakeholderek, hogy a krízishelyzetekben is megmarad, amely elősegíti a stressz oldását.
Szerintem az egyik hogy nagyon sok helyen dolgoztam és rugalmas vagyok, a másik pedig, hogy van annyi önbizalmam, hogy a leghülyébb kérdéseket is feltegyem. Szoktam mondani, hogy az én munkám, hogy hülye kérdéseket tegyenek fel.
Rengetegszer felteszem a kérdést, hogy

• Miért így csináljátok?
• Mert mások is így csinálják.
• Jó, de ti miért így csináljátok?

Mire kiderül, hogy 15 éve valamiért csak így tudták megoldani.

És ez az a pillanat, amikor iparági standard-é válik a work around.

Ilyenkor elmondom, hogy most itt a lehetőség, hogy határozd meg, hogyan szeretnél dolgozni. Minden amit nem szeretsz, azt kidobhatunk. Ne a régit fejlesszük le megint. Mondd el az ideális folyamatodat. Igaz, hogy azt nem fogjuk lefejleszteni, de a kompromisszumokat ahhoz képest kell majd meghozni, az lesz a baseline, nem pedig a minimum.

Úgy indítottál, hogy üzleti elemző vagy, már amennyiben ez a szakma létezik. Szerinted miért nem létezik?

Azt látom, hogy van az üzleti elemzés, mint tevékenység, amelyet nagyon sok mindenki csinál, akár tud róla, akár nem. Ahogyan a módszertanban le van írva, úgy pedig még sehol nem láttam. Sokféleképpen értelmezik ezt a titulust, ezért nem olyan egyértelmű, mint a favágás. Ha engem felvesznek valahová üzleti elemzőnek, nem tudom megmondani, hogy valójában mit fogok csinálni. Én vagyok most elemző, első vonal beli support, meg tesztmenedzser, delivery menedzser stb.

És akkor mi a mesterséged? Elszakadva a szerepköröktől.

Mr. Wolf a Pulp Fictionból. A tisztító. Ha az embereknek van problémája, akkor oldjuk meg…és akkor én megoldom.

Hogy mit szeretnék csinálni? A tanácsadói cégemet szeretném felfuttatni, amely kisvállalkozások vezetőit segíti, hogy tudjanak élni. Ne azért éljenek, hogy legyen egy üzletük, hanem azért legyen egy üzletük, mert élni szeretnének az üzleten kívül és céjaik vannak. Ez az én value proposition-om. Olyan cégeknek szeretnék segíteni, amelyeknek van hozzáadott értéke a világhoz. Kell, hogy tudjak azonosulni a missziójukkal.

Hogy mi lennék? Zenész. A zeneelmélet az, ami legjobban hasonlít a business analyst működésre. A zeneelméletben is vannak bizonyos szabályok, de a lényeg, amikor az ember már élesben dolgozik, akkor azt figyelmen kívül hagyja. Tudjuk a skálákat, de amikor zenélünk, az nem egy skála. El kell engedni a skálát és szabadon játszani.

Köszönöm Roland!

Ez a legszebb végszó az én matek-ének szakos lelkemnek.

Van egy olyan mondás, hogy tanulj meg a hangszeren kottából játszani, majd dobd el a kottát és csak játsz. Valahogy így működnek az üzleti elemzők, akik gyűjtik a sok kincset a szerszámos ládájukba, hogy azt megfelelő pillanatba saját kreativitásuk szerint fel tudják használni.

A beszélgetés során kikerekedett, hogy a legerősebb kapcsolódó kompetenciák a struktúrálás, vagyis a doboz és nyíl, valamint a kommunikáció, hogy ne féljünk hülye kérdéseket feltenni.

Ezért (IS) hoztam létre üzleti elemzők és projektszereplők számára a MODELLEZÉS GONDOLKODÁST és a KÉRDEZÉSTECHNIKÁT fejlesztő tréningjeimet, ahol lehetőséged van ezen képességedet tudatosítani, fejleszteni.

Pörgesd végig a tréning honlapját és ha felkeltette érdeklődésedet, jelentkezz a linken elérhető űrlapon.

Találkozunk a tréningen 🙂