Rátai Dániel feltaláló, informatikus. Tizennégy benyújtott szabadalmát jegyzik. Még nem töltötte be huszadik életévét, amikor Leonardo elnevezésű találmánya a világon elsőként tette lehetővé, hogy egy teljesen átlagos személyi számítógépet komplett virtuális valóság berendezéssé lehessen átalakítani. 2005-ben találmányával az INTEL ISEF-en a világ legnagyobb tudományos ifjúsági versenyén hat első díjat nyert az arizoniai Phoenix-ben. Magyar indulónak sem előtte, sem azóta nem sikerült ezt elérnie. Többek között átvehette a Gábor Dénes díjat, a Magyar Örökség díjat, a Magyar Tudományos Akadémián. Az Intelius International Enterpreneuership díjat a New York-i tőzsdén, valamint elnyerte a Tech Award-ot is, ami a Szilícium-völgy egyik legjelentősebb díja, mellyel az emberiség javát leginkább szolgáló technológiák alkotóit jutalmazzák. Jelenleg az ELTE-n egy új programozási paradigma kidolgozásán dolgozik, valamint Lead Consultant az EPAM-nál.

Vele beszélgettünk.

Megnéztem a TED előadásodat, aminek a címe a „Káoszból kozmoszt” és olyan nagy hatással volt rám, hogy muszáj, hogy ezzel kezdjük a beszélgetésünket. A téma egy olyan új programozási paradigma, melynek köszönhetően demokratizálható az információ áramlás. Az előadásra egy évvel ezelőtt került sor és az azóta eltelt időben éppen arra lenne talán a legnagyobb szükségünk, ahhoz, hogy élhető legyen a világ az emberiség számára, amiről te beszélsz, amit te kutatsz. Mi pedig laikusként benned és a kutatókban bízva szeretnénk egy kicsit optimisták lenni. Hogyan érzel a jelenlegi helyzettel kapcsolatban, annak fényében, hogy amikor tavaly elhangzott az előadásod, tulajdonképpen még a látóhatáron sem volt a COVID.

Ha nagyobb összefüggésében nézzük a jelenlegi helyzetet, akkor a középkorban magának az egyénnek sokkal nagyobb problémái voltak, mint egy ma élő embernek, ugyanakkor, ha össztársadalmi szinten vizsgáljuk ezt, már más a kép. Ha a középkorban egy nemzetnek volt egy problémája, az adott nemzetet érintette, ma pedig minden probléma globális szintű és ráadásul ezekre a problémákra, nincsenek megoldásaink egyelőre. Nézzük például a globális felmelegedést vagy az információs tér problémáit, lásd a Netflixen futó Social Dilemma című filmet, amelyben arról beszélnek, hogy ez a fajta mód, ahogy most működik a világháló, szinte törvényszerűen előbb-utóbb polgárháborús állapotokat idézhet elő globális szinten. Hogy azért némi optimizmusra adjak okot, ezek mellett a gerincroppantóan nagy problémák mellett a másik oldalon viszont ott áll, hogy olyan eszközeink is vannak ezeknek a problémáknak a megoldására, amik a történelemben soha eddig. Ma van egy olyan világhálónk, ami gyakorlatilag komplett idegpályaként köti össze az emberiséget és ebben olyan lehetőségek vannak, amit még messze-messze nem aknáztunk ki. Ahogyan most működik a kapcsolattartás, az egymás közötti kommunikáció az interneten, az mindennek nem a végleges formája, hanem csupán egy stáció, olyan, mint például az evolúció során a bogaraknál a dúc idegrendszer, melyből egyszer csak ki kellett alakulnia egy központi idegrendszernek és tovább kellett fejlődni annak a modellnek, ahogyan működik egy idegpálya. Hasonlóan ehhez a neten is nagy paradigmaváltások következnek és kiderül majd, hogy nagyon másfajta módon is tud működni az a globális idegpálya, ami behálózza az emberiséget. És ez meg hozhat magával megoldásokat olyan problémákra, amikről most még azt hisszük, hogy lehetetlen. Ezer szálon folynak a technológiai fejlesztések és én igenis látom azt, hogy kulturális-morális értelemben is - bár még természetesen bőven van hova fejlődni - de azért folyamatosan lépkedünk egyről a kettőre. Azért nagyon fontos látni, hogy honnan jöttünk és most hol vagyunk, merre tartunk, hogy ne feltétlenül egy pesszimista világkép éljen bennünk, mert iszonyatosan lélekterhelő tud lenni, hogyha azt érezzük, hogy ebből nincs kiút.

 Össze tudod foglalni a kutatásod lényegét, hogy mit is takar a „káoszból kozmosz”?

Az Eli Pariser által megfigyelt és általa elnevezett filter buborék talán már közismert fogalom. Ez tulajdonképpen azt jelenti, hogy a különböző „ajánló algoritmusok” a közösségi média különböző platformjaiban, több ezer mérési pont alapján vizsgálva a felhasználót összeállítják a találati listánkat, azt, ami megjelenik előttünk. Kattintásra maximalizálnak ezek az algoritmusok, aminek van egy olyan mellékhatása, hogy nagy élvezettel és addiktív módon fogyasztjuk a nekünk kínált tartalmakat. Mivel ezek úgy vannak kiválogatva, hogy a mi mintánkhoz illeszkednek, ezért nem találkozunk, vagy csak minimális számban ellenvéleményekkel vagy ellenkező álláspontokkal. Mindig a kényelmes tartalmak lesznek kiválogatva számunkra, amitől a szélsőségek még szélsőségesebbek lesznek. Mindennek következtében nem is vagyunk tudatában annak, hogy máshogy is működik a világ, hogy máshonnan is lehet nézni a dolgokat, hogy van egy másfajta valóság is. Pariser hívta fel a nagy tech óriások figyelmét arra, hogy hangolják úgy az algoritmusaikat, hogy minden oldalról érkezzenek információk a tartalomfogyasztóhoz, különben az emberiség a szélsőségek irányába halad és szétszakadozik a társadalom. Ezt a munkát el is kezdték a közösségi média cégek, például a Twitter, aki próbálja például tagekkel feltűzdelni a twittjeit, annak alapján, hogy mi az igazságtartalma egy-egy bejegyzésnek. Ezt mind manuális, mind algoritmikus úton keresve végzik, de ez felveti annak a kérdését, hogy mi alapján cenzúráznak, egyúttal a hatékonysága is megkérdőjelezhető ennek a munkának. Hiszen a probléma gyökere az, hogy emberi gondolkodást igénylő feladatot próbálunk meg rábízni egy gépre. Egy tartalomról eldönteni, hogy az helyes vagy nem helyes, morálisan megkérdőjelezhető-e vagy sem, ehhez morális világkép kell. Tehát egy algoritmustól várjuk el azt, hogy morális világképe legyen és ez alapján tudjunk szűrni információkat. Ma pedig még nem tartunk ott – talán szerencsére - hogy ténylegesen emberi agyat tudjunk szimulálni. Leegyszerűsítve, azt, hogy rendszerezzük az emberek által létrehozott információt, nem tudjuk másképp megoldani csak úgy, ha mi magunk emberek rendszerezzük. Az én alaphipotézisem, hogy mi lenne akkor, hogyha azt mondanánk, hogy behúzzuk a tudatunk egy mélyebb szintjét ebbe a rendszerezési folyamatba, a képi látás, a képi gondolkodás képességét használva. Hiszen ebben mind a mai napig erősebbek vagyunk, mint bármilyen szuperszámítógép. Pont ezzel a képességünkkel döntik el a különböző weboldalak is azt, hogy éppen egy élő hús-vér ember nézi a weboldat vagy egy algoritmus. Ha ezt a hatalmas információ mennyiséget képi módon, képi strukturálással, közös képi alkotással próbálnánk megrajzolni, együtt alkotnánk meg a központi idegrendszerét a világhálónak, akkor nemhogy kereshetővé válna az internet, - mint ahogy most is kereshető a Google által - hanem átláthatóvá is válna az, ami körbevesz minket.  Egy ilyen rendszernél már nem kerülünk filter buborékba, mert mindannyian ugyanabból a képből indulunk ki, mindannyian ugyanazt látjuk. És bár lehet, hogy valami minket jobban érdekel és valamilyen tudatalatti mechanizmus szerint éppen ennek a globális képnek az egyik része nekünk jobban tetszik, azt nagyítjuk ki, de tudjuk, hogy honnan mentünk oda és tudjuk, hogy mi minden az, amit nem fedeztünk fel. Erről szól ez a projekt, hogy hogyan lehet olyan képi alkotó szabályrendszert létrehozni, amit használva nagyon egyszerűen, de akár több millió vagy milliárd ember is közösen tud egy képet létrehozni. Olyat, ami egyébként linkel saját magára, ahogy az agyban a szinapszisok összekötik az agynak a szerkezetét, de linkel a teljes világhálóra is, egyfajta információs gerincet adva annak.

 Hol tartasz jelenleg a megvalósításban?

Ez annyira újfajta megközelítést és megoldásokat igényel, hogy a PhD kutatásom lényege is arról szól, hogy lehet mindezt technológiailag megvalósítani. Már szerencsére tartok ott, hogy ez elképzelésem megvalósítható és az is körvonalazódott, hogyan. De még rengeteg munka van hátra, hogy ez tényleg fel is épüljön.

Nagyon érdekelne az alkotás folyamata. Mi történik, amikor valamilyen felismerésre jutsz, ezen a tudományterületen miként jön az ihlet?

Többféle technikát is szoktam alkalmazni. Egyfelől van az, amikor egyszer csak jön az ötlet és heuréka és hú. Egyébként pont ez a kutatás is egy ilyen bevillanó ötlet volt, teljesen máson gondolkodtam és akkor állt össze a fejemben és jött az, hogy ÚRISTEN!

Emlékszel, hogy mit csináltál éppen?

Emlékszem igen, pont a feleségem szüleinél voltunk. Ültem a kanapén és azon gondolkoztam, hogyan tudok kitalálni és összerakni egy háromdimenziós modellező szoftvert, aztán bekattant, hogy az egyik algoritmussal közösségi képet is lehetne csinálni és gyakorlatilag másodpercek alatt, szinte villámcsapás szerűen állt össze, hogy ez mihez vezethet. Sokkoló élmény volt és onnantól fogva nem hagyott nyugodni, össze is raktam az első prototípust egy hétvége alatt. Megint épp egy családi összejövetel zajlott, jöttek hozzánk és volt ott egy 11-12 éves srác, aki remek tesztalanynak tűnt. Feküdt a szőnyegen, odaadtam neki a laptopot, hogy tessék, akkor próbálgasd és két órán keresztül nem tudtuk leszedni a gépről, mert csak ezt rajzolgatta, próbálgatta. Később még hat különböző prototípust építettem, mire eljutott a dolog odáig, hogy tényleg működik és beindul a képi evolúció, jelenleg pedig már a skálázódáson van a hangsúly. Visszatérve az alkotási folyamatra olyan is előfordul, hogy nincs idő várni az ihletre, amikor muszáj gyorsan ötletet vagy olyan technológiai megoldást produkálni, ami egyszerűen idáig még nem volt. Ilyenkor nekem az a technikám, hogy megpróbálom a fejemből kikapcsolni a dumagépet. Amikor gondolkodunk, akkor általában egy „beszélőgép” megy a fejünkben, ami a gondolatainkat nyelvvé alakítja.  Tudatosan hátra lépek egy kicsit és kikapcsolom ezt a beszélőgépet, próbálom elengedni a gondolataimat, hogy természetes formájában történhessen a gondolkodás. Merthogy minden egyes szó lassítja ezt, illetve be is szűkíti azt a halmazt, amire gondolni tudunk. Van egy pár ezer szavas szókincskészletünk és ennek szavaihoz hozzátapadnak a gondolataink, közben pedig a természetes gondolkodás sokkal szabadabb ennél. Megpróbálom ebbe az irányba irányítani magamat és általában jó dolgok szoktak születni. Aztán ott a klasszikus brainstormingos megoldás, amikor van egy probléma és leírom az első száz megoldást, ami eszembe jut. Gondolkodás nélkül, jó vagy nem jó, tök mindegy. Ha pedig valamit írni kell és nincs ötletem, apu megoldását szoktam alkalmazni, miszerint, nem baj, ha rossz, amit írok, de kezdjem el írni. Így beindul az alkotás folyamata.

Pár éve  itt a LifeInTech blogon meg is jelent egy interjú, amiben sokat beszélgettünk a kisgyerekkorodról, a gyerekkorodról. Hogyan éled meg a mai fejeddel azt, amin keresztül mentél a sikerekig, amikor elismerték a tudásodat?

Már nem tudom hány éves voltam csak az érzésre emlékszem, hogy felnőttekkel vagyok, akik talán a szomszédaink, nem közvetlenül a család és bennem van az érzés, hogy sokkal többre vagyok képes gyerekként, mint amit ők gondolnak rólam. Emlékszem, nem értettem, hogy miért hiszik azt, hogy egy gyerek csak ennyire képes. Ők már elfelejtették azt, hogy milyen volt, amikor ők voltak gyerekek? Nagyon erősen emlékszem, hogy megfogadtam magamnak, hogy soha nem fogom elfelejteni, hogy milyen gyereknek lenni.

Amikor elkezdtünk beszélgetni mondtad, hogy lehet, hogy fogok madárcsipogást hallani, ami nem egy madártól származik, hanem a nyolchónapos kislányodtól. Ő jó alany arra, hogy ezt a fogadalmadat leteszteld.

Igen, ez eszembe is jut néha. Nagyon érdekes, hogy szülőként az ember mennyi mindent átél a gyerekkorából és mennyire előjönnek dolgok. Pláne, mikor keresgéljük, hogy mi a helyes a gyereknevelés szempontjából, mit, hogy érdemes csinálni. Ilyenkor óhatatlanul is előjön az, hogy ez velünk, hogy volt a gyerekkorunkban. Próbáltam mindig is megőrizni a játékot magamnak, azt, hogy merni kell idiótának lenni, abból jönnek ki a jó dolgok.

Vagy hogy játéknak tekinted, amit csinálsz és akkor attól működhet. Hogy nem veszed olyan komolyan, hogy az megakadályozza utána a legvadabb dolgoknak a kiagyalását is.

Előfordult, hogy annyira őrült ötletem támadt egy háromdimenziós megjelenítő létrehozása kapcsán az akkori cégünkben, hogy az alvállalkozó fogta magát és azt mondta, most akkor elmegy, ezt nem vállalja, lehet, hogy fizetünk érte, de szerinte ez teljes badarság. Egyébként igaza volt, tényleg, csak ugye az, hogy merni kell idiótának lenni, az alapja annak, hogy utána jönnek azok az ötletek is, amik nem hülyeségek. Hogy ilyen vagyok, azt nagyban köszönhetem a szüleimnek. Ha azt mondtam, hogy kitaláltam az örökmozgót, akkor anyu kérte, rajzoljam le és menjünk együtt a szabadalmi hivatalba, szabadalmaztatjuk az örökmozgót.

A gyerekkori ötleteken, a Leonardon, saját cégen keresztül hogyan jött a képbe az EPAM?

Éppen véget értek a „Leo-s idők”, a saját céges tapasztalatokon is túl voltam, szerettem volna kipróbálni, milyen, ha egy olyan cégnek dolgozom, ami nem az enyém. Elmentem a HVG állásbörzéjére szétnézni, hogy milyen lehetőségek vannak.

A sikerek, díjak, elismerések özöne után, fogtad és besétáltál egy HVG állásbörzére?

Persze. Láttam, hogy jön egy új időszak az életemben, tájékozódni akartam, gondoltam, miért ne menjek el? Nézelődtem, amikor egyszer csak rám köszönt egy ismerős, „Szia Dani, te mit csinálsz itt?”  Kiderült, hogy az EPAM-nál dolgozik a HR-en, mondta, hogy „Gyere hozzánk!”. Így indult, aztán úgy folytatódott, hogy hamarosan megállapodtunk, hogy tanácsadóként fogom erősíteni az EPAM csapatát.

Hogyan alakult aztán ez az együttműködés?

Olyan projekteken voltam, ahol épp az én extra tudásom hiányzott vagy ahol úgy tudtam hozzáadott értéket nyújtani, hogy közben én is fejlődhettem. Volt, ahol Big Data szakértőként dolgoztam, volt, ahol a Leonardo-s tapasztalatokkal tudtam segíteni, részt vettem pre-sales folyamatban, máskor egy cég 3D-s grafikával kapcsolatos projektjébe hívtak meg. Számomra azért volt nagyon fontos ez a váltás, mert az EPAM-nál kapcsolódhattam egy olyan bázishoz, ahol irdatlan mennyiségű tudás és tapasztalat van felhalmozva, rengeteget tanulhatok és fejlődhetek ezáltal. Most pedig lehetőségem van emellett a PhD-men dolgozni, úgy, hogy szinte teljesen erre fókuszálhatok.

Sokszor felmerül egy-egy interjú kapcsán, hogy mi a következőkre a motiváció. De itt annyira esetlennek érzem ezt, hiszen az, amit csinálsz egy hihetetlen horizont, a megvalósítása hatalmas távlat. Milyennek látod ezt a távlatot?

Jó kérdés, mert bár látom már a megoldás technológiai részét, de azért nagyon komplex mindezt összerakni. Még évekbe telik. Szokták kérdezni, hogy mi az, amivel foglalkozom, mondjam el, röviden. Akkor viccesen azt szoktam mondani, hogy világbéke. Szeretem az olyan projekteket, aminél kockázatosabb a kimenetel, aminél kérdés, tényleg összeáll-e. Mert itt bármikor lehetséges, hogy a feltételezés nem úgy működik, hogy valami hibádzik abban a rendszerben, ami épül, hogy lehetnek tényezők, amik keresztbe húzzák a dolgokat. Sokkal egyszerűbb valami olyat felépíteni, ahol van egy fix üzleti terv, megvan, hogy ki a vásárló, mi a hozzáadott érték, milyen problémát, hogyan oldunk meg. De én valahogy nagyon szeretem az ilyeneket, hogy igen, kockázatos, na de ha sikerül... Akkor Atyaúristen, felrobban a világ és valami hatalmas dolgot sikerül csinálni.

Hallgasd meg a podcastokat is!

Gyökeresen változtathatja meg az internetezést a magyar kutató, Rátai Dániel munkája - 1. rész

Rátai Dani kutatói karrierjét az óvodában kezdte - 2. rész

Otthon vagyunk, ki-ki, a maga asztala mellett, külön, mégis egymással a gépeinken keresztül kapcsolódva. Létrejön így is, pont az, amit együtt, egy szobában, egy épületben, közösen alkotunk.  Most kicsit másra hívunk, mást alkotunk, együtt másoknak valami mást adunk. Idén otthonról, egyenként, mégis, mint szoktuk, ugyanúgy közösen adunk. Ha adni jó, segítő közösséget szervezni, ezáltal segíteni, még jobb!

 Amikor azokkal a szervezetekkel, akiket most csokorba gyűjtöttünk, egy-egy projekt során együtt dolgozunk, rengeteget tanulunk tőlük. A segítő alapítványok, szerveződések olyan dolgokat vállalnak ügyükként, melyet egyenként, egyedül valószínűleg nem tennénk, tehetnénk meg. Kijárni, megtalálni az utakat, hogyan és kinek, miként a legjobb az adományozás, a segítségük nélkül nehezen menne. De, amikor aztán egyénként veszünk részt ezekben a kampányokban, mégis hozzá tehetünk a közös ügyhöz. Kialakul egy közösség, a segítők közössége, aminek részei leszünk és a miénk lesz az érzés, hogy adni jó, együtt, közösen, még jobb.

 Összegyűjtöttük azokat a szervezeteket, akikkel együtt dolgoztunk, akik szervezetté teszik a segítségnyújtást, a listában található alapítványokról és az általuk szervezett gyűjtésekről pedig bővebben is olvashattok, hogy könnyebb legyen a döntés, kinek szeretnétek segíteni. Várjuk egyúttal az ötleteiteket is az oldalon, dobjátok be ti is a közösbe, szerintetek, kiknek jöhet jól a segítség, egész évben vagy most, decemberben!

Együtt többet tehetünk, segítsünk azoknak közösen, akiknek a legnagyobb szüksége van rá!

Nagy András István Solution Architect szerepkörben dolgozik, szakterülete a Big Data és a Machine Learning, a LifeIntech podcast csatornára készült beszélgetésből kiderül, hogyan alakult a karrierje és milyen feladatai vannak jelenleg és mi az a két szó, amivel az EPAM-ot leginkább jellemezné

 Hogyan vezetett az utad az EPAM-ig?

Egy magyar cégnél dolgoztam tíz éven keresztül, előbb Java fejlesztőjeként, majd vezető fejlesztőként, végül Solution Architect szerepkörben, mielőtt az EPAM-hoz jöttem volna, hét évvel ezelőtt. Az utóbbi pár évben főleg Big Data-val és mostanában Machine Learning-el foglalkozom. Ezen a területen nem magukat a Big Data eszközöket fejlesztjük, hanem azokra épülő vállalati data platformokat építünk (tipikusan cloud-ban), és valamilyen üzleti problémát megoldó Big Data alkalmazásokon dolgozunk.

Milyen feladatai vannak egy Solution Architect-nek általánosságban, illetve a te szakterületeden?

Elsődlegesen szoftver megoldások tervezése a feladat, amibe a konkrét tervezési munkán kívül sok minden beletartozik. A technológiák nagyon gyorsan változnak, főleg a Big Data területen, és tudni kell, hogy adott környezetben, egy-egy adott problémára mi lenne a legmegfelelőbb megoldás. Ehhez naprakésznek kell lenni a technológiák és az eszközök tekintetében. A környezet alatt pedig egyrészt értem a megrendelőt, az iparágának, cégének az adottságait, szabályozását, vagy akár a szervezeti felépítését, nyitottságát is az új dolgokra. Másrészt ebbe a környezetbe beletartozik a team is, aki az implementáción dolgozik. Pusztán technológiai szempontok mellett nyilván az is számít, hogy egy csapatnak mivel van tapasztalata, mivel dolgozik hatékonyan.

Solution Architect-ként egyébként a technológia mellett egyre többet dolgozom emberekkel. A szoftverfejlesztés minden lépésénél mindenki folyamatosan tervez és hoz döntéseket. Az Architect feladata az is, hogy világosak legyenek azok az elvek, amik alapján mindenki meg tudja hozni ezeket a döntéseket, vagyis hogy egy adott rendszerben bizonyos problémákat hol és hogyan oldjunk meg, hogy a rendszer egy koherens egész legyen, ami jól megérthető és jól karbantartható.

Ehhez a szerepkörhöz milyen szakmai tapasztalatra, tudásra, készségekre van szükség?

Solution Architect-ként egyrészt arra van szükség, hogy átlásd a rendszer egészét, annak kapcsolódását más rendszerekhez, meglegyen a „big picture”, beleértve azt is, hogy a rendszer hogyan segíti az ügyfél üzleti modelljét. Ugyanakkor fontos az is, hogy szükség esetén le tudj ásni a megvalósításban, képes legyél segíteni egy-egy konkrét alacsony szintű probléma megoldásában. Projektenként, csapatonként is változik, hogy ezek milyen súllyal jönnek elő az SA munkájában. Nagyon fontos még a kommunikáció, az együttműködés készsége vagy éppen a konfrontáció, a konfliktusok vállalása is. Nagyra tartom Gregor Hohpe-ot (akit a legtöbben talán az „Enterprise Integration Patterns” című könyv szerzőjeként ismernek), akivel egy német konferencián találkoztam, ő fogalmazta meg, hogy az Architect alapvetően extrovertált személyiség. Én eredendően kevésbé vagyok extrovertált – bár ez nyilván nem egy lineáris dolog, hanem egy spektrum - de SA-ként ezen túl kell lépni, az SA egy „influencer” kell legyen mind a csapat, mind az ügyfél felé. Ha pedig szakmailag valamivel nem tudok azonosulni, akkor ennek érdekében fel kell vállalnom konfliktusokat, akár az ügyfelekkel is. Az egyébként a tapasztalatom, hogy az ügyfelek ezt értékelni szokták – igazából azért keresnek meg minket, mert a tapasztalatainkra, a szakértelmünkre van szükségük.

Igénybe vettél tréningeket ahhoz, hogy fejlődj ezekben a készségekben?

A Solution Architect community az EPAM-nál folyamatosan szervez képzéseket, tréningjeik jól meghatározott tematikán haladnak végig belsős és külső előadókkal. Ilyen program például az SA School, illetve az erre épülő SA University, melyen én is részt vettem és nagyon hasznosnak tartom. A képzés végén a Sofware Engineering Institute által kiadott certification-t kapnak azok, akik elvégezték azt. Emellett szintén az SA community révén hozzáférésünk van szakirodalomhoz, online tréningekhez is. A projektekről is rendszeresen tartunk belső online session-öket, amikor megnézünk egy-egy konkrét esetet, amin valaki dolgozott és annak a tapasztalatairól beszélünk.

Hol van a belépési pont és mi a csúcs, hova lehet eljutni ezen a területen?

Ez is egy olyan terület, amiben az a jó, hogy mindig lehet fejlődni, szakmai vonalon is. Az EPAM körülbelül úgy különbözteti meg az egyes szinteket, hogy milyen volumenű projektet tud vinni valaki architectként, és ezzel változik az is, hogy mi a szerepe, mire lesz elsődlegesen hatással az ügyféllel való együttműködés során. Egyre többször olyan szerepben dolgozom, ahol inkább csak egy nagyon magas szintű vision van meg az ügyfél részéről, és szokszor már a konkrétan megoldandó probléma meghatározásán is közösen dolgozunk. Egy konkrét esetben, amin nemrég dolgoztam, az ügyfél egyik nagy befektetőjének a képviselőjétől származott ez a high level vision. Az ügyfél itt egy nagy multinacionális pénzügyi szolgáltató volt, a vision pedig körülbelül arról szólt, hogy a jelenlegi erősen manuális folyamataikra, döntéseikre, az egyes alkalmazottak személyes kapcsolataira építő szervezetet hogyan lehetne elindítani egy inkább szoftver-driven, data-driven átalakulás felé. Ehhez terveztünk ott egy data platformot és kerestünk olyan use case-eket amik a szervezet felé jól tudják demonstrálni ennek a megközelítésnek az erejét. Ez például egy olyan feladat, aminek nagy a hatása, impact-je, és ezért különösen érdekes tud lenni.

Hogyan tudnád összegezni az EPAM-os munkádat? Miként fogalmazod meg, ha valakinek, akit nem ismersz, elmondod, hogy itt dolgozol és ezzel foglalkozol?

Talán még ma is az a legnagyobb kihívás, hogy hogyan hozzuk össze a valós üzleti igényt egy szoftverben megvalósított megoldással. Valahol minden lead szerepkör feladata ennek a támogatása. Nyilván ebben másra fókuszál egy Delivery Manager, egy Business Analyst vagy egy Solution Architect, de mindenkinek fontos értenie, hogy mi a valós probléma, amit szoftverrel meg akarunk oldani, és én is ennek egy vetületén dolgozom. A Solution Architect feladata nagyon leegyszerűsítve az, hogy a „miért?” kérdés minél alaposabb megértésével segítsen az ügyfélnek a „hogyan?” és a delivery team-nek a „mit?” kérdést megválaszolni, egy koherens szoftver architektúra tervre lefordítva, hogy végül egy hatékony, jól karbantartható és az ügyfél üzleti célkitűzéseit előmozdító rendszer szülessen a csapat munkája által.

Megszokott kis játék a beszélgetéseink végén: mit jelent számodra pár szóban az EPAM?

Egy közösséget, ahol kapcsolatban vagyok olyan kollégákkal, akik hasonló problémákon, hasonló környezetben dolgoznak. Változatosságot, mert az EPAM egy olyan munkahely, ahol úgy tudok munkát váltani, hogy nem kell munkahelyet váltanom.

Tóth Kinga négy és fél, Varga Gergely három éve dolgozik Recruiterként az EPAM-nál, ma már mindketten Senior pozícióban. A LifeInTech podcast csatornán arról beszélgettünk velük, pontosan hogyan zajlik a toborzás folyamata, mire kell figyelni és min nem érdemes görcsölni. Részletes útmutató mindazoknak, akik interjúra készülnek és azoknak is, akik még csak fontolgatják a váltás lehetőségét.

Milyen lépései, folyamata van a toborzásnak? Mi az, ami kifejezetten EPAM specifikus?

Varga Gergely: Az EPAM-nál end-to-end recruitmentet folytatunk, ami azt jelenti nagy vonalakban, hogy a jelöltek megszólításától, megkeresésétől egészen az EPAM-hoz való belépésükig nyomon követjük a jelöltek útját. Az első és legfontosabb rész megtalálni és megszólítani a releváns jelölteket. Leggyakrabban a LinkedIn-ről illetve egyéb különböző forrásokból találjuk meg őket és akár telefonon, akár e-mail formájában történik a kapcsolatfelvétel. Ha érdeklődést mutatnak a cég felé, akkor először az ún. HR vagy első körös interjúra kerül sor. Hogyha ezt sikerrel veszik a jelöltek akkor egy technikai interjú a következő része a folyamatnak. Amennyiben ezen is sikerrel járnak, akkor egy menedzser interjút szervezünk, aminek optimális esetben a vége egy ajánlat. Ha ezt az ajánlatot elfogadja a jelölt, akkor már csak be kell lépnie az EPAM-hoz. Az interjúk adott esetben még kiegészülhetnek „project fit”, vagy „team fit” interjúkkal, melyeknek az a lényege, hogy megtaláljuk a lehető legjobb pozíciót a jelöltnek, ezzel is elősegítve azt, hogy a lehető legrelevánsabb pozícióban tudjon csatlakozni az EPAM-hoz.

Tóth Kinga: Amit mindenképp kiemelnék, az talán a szakmai interjú, mely a második lépés a kiválasztási folyamatban. Szerintem ez van a legnagyobb hatással a jelöltekre, időben is a leghosszabb, egy-másfél órás beszélgetés szokott lenni. Itt már a szakmai kérdésekről van szó és EPAM-os kollégák az interjúztatók, lehetőség nyílik arra, hogy akár a jövőbeli csapattagokkal is találkozzanak a jelöltek. A legtöbb pozitív visszajelzés ezek kapcsán érkezik, ezt a kört élvezik a legjobban, ugyanakkor ennek van a legnagyobb jelentősége is. Azon túl, hogy felmérik a jelölt tudását, attitűdjét, a szakmai interjúztatók azok, akik a leghitelesebb információt tudják nyújtani arra vonatkozóan, hogy milyen nálunk dolgozni, milyen projekteken dolgoznak ők.

Ez a beszélgetés is egészen másképp zajlik, mint egy évvel ezelőtt zajlott volna, amikor szemtől szembe ültem és láttam az interjúalanyaimat. Más készségeket igényelt részemről és az alanyaim részéről is. Ugyanez valószínűleg egy ilyen helyzetben is fennáll. Mi az, ami megváltozott most, ebben a helyzetben nektek és valószínűleg a jelölteknek is?

VG: Hagyományosan, a COVID előtti időszakban nagy hangsúlyt fektettünk a személyes beszélgetésekre és a találkozásra. A jelölt korábban bejött az irodába, látta azt a környezetet, ahol esetlegesen dolgozni fog, maga az iroda, az impozáns környék is egy „selling point” tudott lenni. Mindez most kiesett, átkerült az egész az online térbe. Mindez azonban nem okozott nagy fejtörést vagy problémát nekünk, hiszen maga a „home office" kultúra is a céges kultúránk része volt, hamar át tudtunk erre térni. Nyilván nagyon hiányzik az, hogy személyesen találkozzunk a jelöltekkel, ahogy neked is hiányzik az, hogy személyesen találkozz az interjúalanyaiddal, de azt gondolom, hogy a modern technikának köszönhetően a lehető legkönnyebben meg tudtuk oldani, hangsúlyozva, hogy a hatékonyságunk nem csökkent ennek következtében

Milyen tanácsaitok vannak, hogyan lehet felkészülni egy ilyen folyamatra, ami nem a szakmai, hanem az emberi részét illeti a dolognak? Mik azok a legfontosabb sarokpontok, amiket ti kiemelnétek?

TK: Amit tanácsolni szoktam a jelölteknek, hogy próbáljanak meg felkészülni kicsit saját magukból, ha ez így elsőre viccesen is hangzik. Azt gondolnánk, hogy magáról mindenki tud összeszedetten beszélni, mégis fontos, hogy az ember végig gondolja, hogy kerek mondatokban, megszakítás nélkül el tudja mondani a tapasztalatait, válaszolni tudjon a kérdésekre. Az interneten rengeteg segítséget lehet találni ehhez és nagyrészt azért átfedésben van mindez azzal, amit mi is meg szoktunk kérdezni a jelöltektől. A legnagyobb „vízválasztó” a folyamat során mindig a szakmai interjú, sokat is nyom a latban, hogy ez hogyan sikerül. Azonban itt is mindig  segítenek a jelölteknek az interjúztató kollégák. Elméleti kérdéseken kívül, például a fejlesztőknél mindig vannak kódolós feladatok is. Mindezeken kívül még az angoltudás az, ami fontos, hiszen nálunk minden projekt külföldi ügyfelekkel zajlik, akikkel napi szinten kommunikálni is kell. Éppen ezért javaslom, hogy ne csak magyarul, hanem angolul is próbálják meg összeszedni a gondolataikat.

VG: Technikai oldalról igazából az első és a legfontosabb dolog, a stabil internet kapcsolat az interjúfolyamathoz. Ha ez nem feltétlen tud megvalósulni, akkor akár mobilinternet kapcsolat is legyen, mint B opció. Ha valaki asztali gépről dolgozik otthon, akkor legyen hozzá egy webkamera, mert ez mindenképp fontos lesz az interjúfolyamatban. Érdemes keresni egy nyugodt sarkot, szobát, ahol lehetőség szerint nem nagyon adódnak zavaró tényezők.

Nemrég láttam egy mémet, amiben egy nő ül otthon a gépe előtt és a gyereke vastag celluxszal a háta mögött a földhöz van ragasztva. Egy otthoni szituációban váratlan helyzetek is adódhatnak, akár a gyerekek, háziállatok vagy más tényezők miatt. Mennyire vagytok rugalmasak e tekintetben?

TK: Szerintem nagyon rugalmasan. Velem is előfordult, hogy hallottam, hogy ott egy kisbaba vagy zajlik az élet a háttérben. Az élet sokszor közbeszól, de ezt a jelenlegi helyzetben feladatunk is megoldani, illetve tolerálni, úgyhogy ebből nem szokott gond lenni.

Az időtényezőről még nem beszéltünk. Mennyi ideig tart a toborzás folyamata onnantól kezdve, hogy mondjuk a LinkedIn-en felfedeztek egy megfelelő jelöltet, egészen odáig, hogy „leigazoljátok” az EPAM-hoz?

VG: Nemrégiben zajlott a „Hiring Week”, ennek az ideje alatt nagyon gyorsan, akár pár óra lefolyása alatt EPAM-ossá válhatott valaki. Ezen az időszakon kívül átlagosan másfél hét alatt zajlik le a folyamat, az ún. HR kör, a technikai interjú és a menedzser interjú. Ha egy másik munkahelyről érkezik a jelölt, akkor a felmondási időtől függ, mikor kezdhet nálunk.

Mik lehetnek a legnagyobb buktatók vagy nehézségek, esetleges bakik, amit elkövethetnek a jelöltek az interjúk alatt?

VG: Nagyon fontos, hogy a technikát, amin keresztül zajlik majd az interjú, kipróbálják a jelöltek, illetve, hogy emellett olyan környezetet biztosítsanak, amiben nyugodtan tudnak koncentrálni az interjúra. Ami még fontos lehet a második, technikai körön, hogy ne próbáljanak meg puskázni, mert kiszúrják az interjúztatók és véget is ér a beszélgetés. Inkább próbálják meg a legőszintébb technikai tudásukat nyújtani.

TK: Igazából az első kör, meglehetősen informális beszélgetés, ezért is szeretem inkább kötetlen beszélgetésnek hívni, mint interjúnak. Ezért viszonylag nehéz elrontani vagy bakizni benne, mert tényleg nagyon türelmesen és nyitottan állunk minden jelölthöz.

Talán érdemes azt is elmondani, hogy mi az, ami jó benyomást tesz.

VG: Hogyha a jelölt összeszedetten tud beszélni a szakmai tapasztalatáról, nyíltan tud válaszolni minden kérdésünkre, érdeklődik az EPAM iránt, az mind jó pont. Ezek mind olyan dolgok, amik nagyban megkönnyítik a mi döntésünket is. Fontos a kommunikatív személyiség is. A céges kultúránkban nagyon fontos az, hogy olyan kollégákkal dolgozzunk együtt, akik az ügyfél előtt is megállják a helyüket.

TK: Nagy pozitívum szokott lenni mind a menedzsereknek, mind a szakmai interjúztatóknak, ha a jelölteknek a munkájukon kívül van valamilyen saját kis projektjük, amit otthon, a saját szórakozásukra vagy önfejlesztő jelleggel készítenek.

Mit érdemes felvenni? Milyen ruhában üljenek a jelöltek a gép elé?

TK: Szerintem pizsamán kívül bármi megfelelő lehet. Az EPAM-nál nincs dress code. Nyilván strandruhában nem illik bejárni az irodába sem, de sokszor pulóverben, pólóban interjúznak a jelöltjeink, nem kell sem inget, sem öltönyt felvenni.

Ha már a toborzásról beszélgetünk, érdekes lehet az is, milyen a ti munkátok az EPAM-nál? Miben áll az itt dolgozó recruieterek munkájának lényege vagy miben más, mint esetleg más cégeknél?

VG: Ahogy már az elején is említettem, mi end-to-end recruitmentet folytatunk az EPAM-nál, ám ha valaki recruiterként csatlakozik hozzánk, a toborzás minden részletét meg tudja tanulni. Ehhez egyfelől adott a céges kultúra, a technológiai környezet és a csapat is, hiszen nagyon erős a csapatszellem a recruitmenten belül is. Mindenki nagyon segítőkész a másikkal, bárkihez, bármikor, bármilyen kérdéssel lehet fordulni. Olyan kollégákat várunk egyébként, akik agilisak, asszertívak és proaktívak. Ha ez a három tulajdonság adott, akkor nagy baj nem lehet, mi pedig mindent lehetőséget biztosítunk a fejlődéshez.

TK: Az EPAM-nál a recruitment folyamat, illetve maga a HR élesen elkülönül egymástól, két külön csapatról is beszélünk. Nálunk, ahogy a jelölt elfogadja az ajánlatot igazából véget ér a munkánk.

VG: Valóban fontos kiemelni, hogy ellentétben sok céggel, az EPAM-nál a toborzás elkülönül mind a HR-től, mind pedig a marketingtől. Szorosan együttműködünk velük, de a toborzó kollégáknak sem HR-es, sem marketinges feladataik nincsenek. Mi kizárólag a toborzásra koncentrálunk.

Vissza tudtok emlékezni a saját interjúitokra, kinél, hogyan zajlott egykor ez?

TK: Egy telefonos előszűrés volt az első lépés, utána pedig a jelenlegi vezetőmmel zajlott egy úgynevezett menedzseri kör. Mindenki nagyon segítőkész volt, így tényleg élveztem is a folyamatot, pedig először pályáztam teljes munkaidős állásra, úgyhogy nem kis izgalommal vágtam bele. Szerencsére nagyon gyorsan reagáltak, még aznap, majdnem rögtön, ahogy kisétáltam az épületből meg is kaptam az ajánlatomat. Ez is egy nagy pozitívum volt, hogy azt éreztem, szeretnének engem a csapatba. Az elmúlt négy és fél év azt bizonyította, hogy jó döntés volt, hogy akkor elfogadtam ezt az ajánlatot. Ha valaki recruiterként csatlakozik hozzánk, itt nemcsak munkatársakat, hanem barátokat is talál az ember.

VG: Az én utam kicsit hosszabb és kacifántosabb volt, mint Kingáé. Először ajánlás útján kerültem a céghez, egy volt kolléganőm, aki időközben EPAM-os lett, szólt nekem, hogy van egy lehetőség, próbáljam meg. Akkor végül nem úgy alakult a dolog, de fél év múlva megkerestek újra, hogy most lenne itt az alkalom, jöjjek el egy újabb beszélgetésre. Pár nappal később pedig ajánlatot tettek, amit el is fogadtam és azóta sem bántam meg, hogy csatlakoztam a céghez. Kinga útja tényleg egy klasszikus, a „nagy könyvben” megírt, gyors folyamat volt. Az én példám viszont azt mutatja, hogy érdemes nyíltan, jól kommunikálni, mert ha első körben esetleg nem is sikerül valamilyen oknál fogva bejutni az EPAM-hoz, lehet, hogy lesz újabb esély. Minden jelöltnek azt tudom tanácsolni, hogy ne adja fel a próbálkozást és ha elsőre nem jön össze, másodszorra sikerülhet!

Józsa Péter négy éve dolgozik PM- ként az EPAM-nál, ahova nem programozói háttérrel érkezett. Mégis sikerült olyan karriert építenie ebben a szerepkörben, ami a vezetők figyelmét is felkeltette.

Miben változott a munkád, a korábbi hasonló szerepkörben végzett munkádhoz képest?

Két dolgot emelnék ki, az egyik, hogy az EPAM-nál nagyobb és komolyabb projektekkel, ügyfelekkel kezdhettem el a foglalkozni, míg korábban 2-4 fős projektjeim voltak, most nem ritka az 50 fős sem. A másik jelentős különbség, hogy az EPAM-os folyamatok nagyon kidolgozottak, a munkakörök sokkal jobban definiáltak és sokkal jobban követik, be is tartják az emberek ezeket. Nincs az a „svájci bicska érzés”, mint egy kis cégnél, ahol 100-150 fő dolgozik és mindenki éppen azt csinálja, amit kell.

Ha nem az EPAM-os munkádat vizsgáljuk, hanem csak úgy általánosságban egy projektmenedzser munkáját, akkor ez mit jelent pontosan?

A projekt időben és térben jól körülhatárolt feladat, mely a kijelölt céloknak megfelelő tevékenységek révén, rendelkezésre álló erőforrások összehangolt, észszerű felhasználásával valósítható meg. Tehát van egy világos cél, adott kompetens embereknek egy csoportja, akik minden erejükkel azon dolgoznak, hogy a célt határidőre megvalósítsák, a költségeket nem túllépve, kiváló minőségben. Azonban az ilyen példaszerű projekt olyan, mint a jeti, csak néhányan látták vagy nekik is csak meséltek róla, azaz nincs. Egy projekt ezerféleképpen csúszhat el, kezdve onnan, hogy az ügyfél nem tudja pontosan, hogy mit akar vagy pontosan tudja, de igazából nem arra van szüksége. Vagy éppenséggel tudja, hogy mit akar, de nem tudja jól elmondani, a fejlesztők nem értik pontosan. Előfordulhat, hogy alábecsülték az erőforrásokat, nem a megfelelő emberek ülnek a megfelelő székekben, rosszul válogatták össze a csapatot, rosszak a folyamatok. A projektmenedzsernek pedig az a dolga, hogy mindezeket a potenciális problémákat, kockázatokat megoldja. Tehát kicsit olyan, mint a ponyvaregényben Mr. Wolfe, a „megoldóember”. Azzal a különbséggel, hogy a projektmenedzsmentben a projektmenedzser nemcsak megoldja ezeket a problémákat, hanem előre látja a kockázatokat és még azelőtt kézbe veszi őket, mielőtt ezekből problémák válnak. Rengeteg dologra kell odafigyelni, a különböző területeket – ütemezés, költségek, minőség, emberek, kommunikáció, kockázatok, beszerzés - folyamatosan monitorozni kell a projekt teljes életciklusa alatt.

Ez nagyon sokrétű és sokféle odafigyelést igényel. Alapvetően milyen készségekre, képzettségre, tapasztalatra van szüksége egy PM-nek?

Sokan azt gondolják, hogy ehhez a szerepkörhöz programozói vagy valamilyen gazdasági szakirányú végzettség kell. Nos, ezzel szemben az igazság az, hogy mindez előnyt jelenthet, de nem követelmény, nem feltétlenül a jó programozókból vagy a jó közgazdászokból lesznek a jó projektmenedzserek. A PM nemcsak a programozókkal – akik szintén nagyon heterogén, sokféle tudással rendelkező csoport - dolgozik, hanem Designerekkel, UXesekkel, Solution Architechtekkel, Scrum Masterekkel, Data Scientistekkel, Business Analystekkel. Neki tehát mindannyiuk munkájához kell érteni annyira, hogy tudja, hogy milyen elvárásai lehetnek velük szemben és mire van szükségük ahhoz, hogy jól tudják végezni a munkájukat. Hogy a problémáikról, nehézségeikről érdemben tudjon velük beszélgetni és hatékonyan tudjon rá megoldást keresni. A PM-nek az a dolga alapvetően, hogy projekten dolgozó szakembereknek minden feltétel biztosított legyen ahhoz, hogy optimálisan tudják végezni a munkájukat. A készségek tekintetében a hard skill-ekkel szemben a soft skill-ekre helyezném a hangsúlyt. A legfontosabb talán a kommunikációs készség, illetve az alkalmazkodás készsége. A PM munkája 90 százalékban a kommunikáció. Szóban, írásban, nonverbálisan. Kommunikál a csapattal, az ügyféllel, a különböző stakeholder-ekkel. Fontos a már említett alkalmazkodóképesség, a gyors helyzetfelismerés. Minden projekt, minden nap más, egy projekt életében, a legkülönbözőbb helyzetek fordulhatnak elő és fontos, hogy a PM tudja, mit, hogyan lehet az adott helyzetben, az adott emberekkel a legjobban kezelni. Kezdve onnan, hogy mikor vonuljon háttérbe, mikor vegye kezébe az irányítást, mikor legyen asszertív, mikor legyen kompromisszum kereső. Nagyon fontos még a munkabírás, a stressztűrés is, illetve az, hogy a kockázatokat jól mérje fel. Ugyanúgy, mint az autóvezetésnél a jó sofőr nem akkor fékez, amikor előugrik egy óvodás a busz takarásából, hanem már akkor rajta van a fékpedálon a lába, amikor megközelíti a buszt, amelyik utána megáll. A jó PM-re is igaz mindez.

Honnan indul egy PM karrier?

Sokan fejlesztőként, tesztelőként, vagy akár Business Analyst-ként kezdik a karrierjük építését és menet közben váltanak a projektmenedzsment karrierútra. Junior projektmenedzserek lesznek és innen haladhatnak felfelé a ranglétrán, egészen a Senior Director szintig, ahol már elszakad a munka a napi feladatoktól és sokkal inkább az irányok meghatározásán, stratégiaalkotáson van a fókusz.

Te hol tartasz a karrieredben ezen a skálán?

Senior PM vagyok és nem kizárt, hogy ezen a ranglétrán nem felfelé fogok haladni, valószínűbb, hogy „kilépek oldalra” a Delivery Manager irányba, ami nagyon hasonlít a projektmenedzserhez, azonban egy kicsit technikaibb jellegű feladatkör, félúton a Solution Architecht és a projektmenedzser között.

Sokszor beszélgetek a LifeInTech podcastokban különböző szerepkörben, különböző szinten álló emberekkel és gyakran elhangzik, hogy bár az EPAM egy munkahely, egy közösség, mégis olyan változatosak a lehetőségek egy-egy karrierút során, mintha több, különböző munkahelyen dolgozna az illető.

A beszélgetésünk elején kérdezted, hogy mi volt a különbség a korábbi munkahelyem, egy kis cég és az EPAM-os munkám között. Az EPAM több mint 38.000 főt számlál globálisan és ennek megfelelően nagyon sok ügyféllel, technológiával dolgozik, nagyon sokféle projektet visz. Sok olyan kollégát ismerek az cégen belül, akik elindultak egy karrierúton és menet közben kezdtek bele egy új szakmába. Itt lehet valaki tesztelőből Resource Manager vagy fejlesztőből projektmenedzser. Az EPAM nagyon is támogatja az ilyenféle váltásokat, mert ebben a fejlődést látja. Ami szintén idézőjelben luxust jelent az EPAM-nál, hogy egy-egy konkrét szakmán belül is nagyon sok lehetőség van arra, hogy különböző dolgokat kipróbáljunk. Például, ha valaki Java fejlesztő, de elkezdi érdekelni a felhő alapú szolgáltatás, mint technológia, nem kell elmennie egy másik céghez, hiszen itt számos olyan projekt van, ahol belekóstolhat ebbe.

A te EPAM-os karrieredben mi volt szerinted a legnagyobb siker?

Megtisztelő, hogy az idén rám bízták egy több, mint 50 fős projekt vezetését, de azt is említhetném, nekem nincs markáns IT hátterem, két éve mégis megkaptam az Impact Award-ot, ami talán a legmagasabb szintű belső elismerés, az alkalmazottak 2-3 százaléka kapja meg és azokat jutalmazzák ezzel, akik abban az évben a legjobban teljesítettek, valami kiemelkedőt nyújtottak.

A LifeInTech podcast csatornán futó, különböző szerepköröket bemutató sorozatunkban Nagy Gábor DevOps Team Lead-el beszélgettünk a munkájáról, a pozíciójához kapcsolódó feladatokról, a fejlesztésnek a DevOps-ost érintő feladatairól.

Hogyan alakult a karriered a kezdetektől?

Viszonylag régóta vagyok a szakmában, a ’90-es évek vége felé kezdtem el dolgozni. Egy kisebb utazási irodánál először webfejlesztéssel, majd ennek folyományaként szerverek karbantartásával foglalkoztam. Megtetszett az üzemeltetés, ez az akkor még nagyon klasszikus rendszergazdai szerepkör, így végül váltottam a fejlesztési részről üzemeltetési irányba. Ezt követően volt egy hosszú, tíz éves szakasz az életemben, amikor a légiirányításban dolgoztam különböző informatikai szerepkörökben. A 2010-es években felismertem, hogy a rendszergazdai szerepkör meg fog változni, át fog alakulni. Már látszott a piaci hangulatból, az eszközökből, a módszertanokból, amik akkor bejöttek, hogy váltásra lesz szükség, ha továbbra is a szakma élvonalában lévő technológiáival szeretnék foglalkozni. Ekkor úgy döntöttem, hogy otthagyom a légiirányítást és kiköltöztem három évre Norvégiába, ahol cloudos, automatizációs technológiákkal dolgoztam. Miután családi döntés eredményeként hazaköltöztünk, egy Big Data-val foglalkozó cégnél helyezkedtem el, ekkor már kifejezetten Bild Engineer, Infrastructure Engineer, illetve DevOps Engineer szerepkörben. Majd körülbelül egy éve jött a váltás, átkerültem az EPAM-hoz és azóta is itt, a jelenlegi pozíciómban dolgozom.

Mit takar pontosan ez a pozíció, amiben dolgozol, mit csinál a DevOps-os nap, mint nap?

Nagyon sokféle definíció létezik, én azt mondanám, hogy nincs egy nagyon pontos leírás, mindenki kicsit mást ért alatta, így csak az én olvasatomat mondhatom el. A DevOps Engineer egy olyan szerep, megközelítés, ami a szoftverfejlesztési ciklust elejétől a végéig felöleli. Onnantól kezdve, hogy a fejlesztő leül fejleszteni a kódját a saját laptopján, egészen odáig, hogy ez a kód kikerül egy cloudba és kiszolgál egy nagy alkalmazást. A DevOps Engineer ezt az egész folyamatot különböző területeken támogatja és segíti, hogy mindez minél zökkenőmentesebben és gyorsabban tudjon megvalósulni. Ebből is látszik, hogy kell hozzá szakmai tapasztalat a különböző területeken, így DevOps-osnak a szakma különböző területeiről érkeznek. Van, aki fejlesztői vénával, fejlesztői pozícióból gondolja úgy, hogy egy kicsit más irányba szeretne menni. Van, aki - mint én - inkább a rendszergazdai oldalról érkezik és innen kerül bele a dologba.

Van-e valami speciális az EPAM-nál ebben a szerepben, az általános DevOps-os pozícióhoz képest?

Inkább úgy fogalmaznám meg, az, hogy a DevOps-os mennyire tudja támogatni a fejlesztési folyamatot, a vállalat, a projekt érettségétől függ. A döntéshozók akik kitalálják, hogyan épüljön fel az adott projekt, az ő víziójukon, a szervezett érettségén múlik, hogy a DevOps Engineer, mennyire tudja jól összekötni a szereplőket és segíteni a szoftverfejlesztési életciklust és lesz belőle valóban DevOps-os vagy csupán átnevezett System Administrator. Úgy gondolom, hogy ebben az EPAM elöl jár, itt ez egy több életcikluson átívelő szerepkör valóban.

Említetted korábban, hogy tapasztalatra, előképzettségre van szüksége annak, aki ezzel szeretne foglalkozni. Milyen készségekre van szükség a szakmai tudáson kívül?

Akár fejlesztői, akár rendszergazdai irányból jön át valaki erre a pozícióra, az attitűd meg kell legyen benne, hogy meg akarja szeretni, ismerni, tanulni azt a részét a munkának, amit eddig kívülről ismert csupán. Ez a szépsége és a nehézsége is egyben ennek, hogy rendelkezz bármilyen típusú tudással, meg kell szerezd a hiányzó tudásrészt, ami a munkádhoz szükséges. Eszembe jut régről a tipikus mém: „Én: Nálam fut a program, részemről rendben! Rendszergazda: Ez itt nem fut, oldjátok meg, mert valami probléma van!” Ma egy teljesen más szemléletmódra, van szükség, hogy közösen próbáljuk meg kialakítani és elérni a célt. Emellett, jó, ha szinte minden területbe, ami kapcsolódik a fejlesztéshez - a tesztelésbe, az üzemeltetésbe, adott esetben egy kis projektmenedzsmentbe - valamennyire belelát az ember és össze tudja ezeket kapcsolni és az egész workflow-t egyben látni. Nyitottságra, analitikus látásmódra tehát mindenképp szükség van. Szintén fontos a jó kommunikációs készség, hiszen nagyon sokat kell másokkal egyeztetni, megérteni mások problémáit, gondolkozását, hogy egy adott dolgot ő, miért éppen úgy szeretne csinálni. Hiszen az én feladatom, hogy támogassam és segítsem, hogy meg tudja valósítani, amit elképzelt.

Mi az, ami esetleg nehéz, vagy amiben neked is fejlődnöd kellett?

Mivel – rövid fejlesztői múlttal - rendszergazdai irányból jöttem, meg kellett ismernem a fejlesztési és az ehhez kapcsolódó tesztelési módszertanokat, hogy amikor például egy rendszer kialakításáról beszélgetünk, akkor azt az eszközkészletet, szókészletet tudjam használni, amit a fejlesztő vagy a tesztelő használ. Jelenleg is próbálok ezen a területen fejlődni, mert úgy gondolom, hogy itt vannak kis hiányosságaim, rések, amiket mindenképp érdemes betömni.

Kik azok pontosan, akikkel közvetlen kapcsolatban vagy a napi munka során?

Nézzünk egy ideális, elképzelt DevOps-os szerepkört! A DevOps-os már a tervezési fázisba beszáll, hiszen ő tud abban segíteni, hogy lehet minél gyorsabb ciklusokban fejleszteni, ezeket könnyen kirakni különböző környezetekre. Ilyenkor az  architecht-ekkel és részben az ügyféllel kell beszélni, illetve különféle projektmenedzserekkel, hiszen ők tudják megmondani, hogy milyen ciklusokban milyen gyorsan szeretnének iterálni. A munka egészében pedig leginkább a fejlesztőkkel kell egyeztetni, mert valójában az ő munkájukat támogatjuk, segítjük. Ebbe a körbe vonnám be a tesztelőket is, illetve a folyamat végén azt is, aki a szoftvert üzemelteti majd, hiszen az ő munkáját is segíteni kell. Amikor megtervezem, hogy egy szoftver hogyan kerül ki az éles rendszerre, akkor figyelembe kell vennem, hogy aki majd üzemelteti, hogy fog hozzányúlni, neki mi a szempont, milyen metrikákat szeretne arról a rendszerről látni, igy nyilván vele is kell egyeztetni. Összegezve, viszonylag kevés ember van a szoftverfejlesztési folyamatban, akivel egy DevOps-osnak nem kell beszélnie, mire lezárul egy projekt.

Mi ebben a szakmában a csúcs, hogyan épül fel a hierarchia?

Az EPAM-os szakmai karrierszinteknek megfelelően itt is van junior, medior, senior, lead és chief szint. DevOps Engineer-ként amíg junior, medior az ember, ennek az egész szoftverfejlesztési folyamatnak egyes részeivel foglalkozik, abban merül el jobban. Ahogy aztán fejlődik, halad előre a szakmai ranglétrán és bővül a tudása is, egyre jobban átlátja a rendszert, akkor már inkább azzal foglalkozik, hogy az elejétől a végéig, hogy fog jól, olajozottan működni az egész folyamat.

Hogy látod, nálad mi a következő lépcsőfok?

Azért is jöttem az EPAM-hoz, körülbelül egy éve, mert szerettem volna a technológiai mellett egy kicsit kitekinteni a People Management irányába. Bár mindenképp szeretnék a szakmánál maradni, de az emberekkel való foglalkozás, mások útjának az egyengetése is érdekel, a közeljövőben ezzel szeretnék foglalkozni.

Vajon valós az a vélekedés, hogy az IT szektorban a magasabb, senior szinteken, tizenéves tapasztalattal a hátad mögött kiüresedik a fejlődés lehetőségének fogalma? Hogy nehéz olyan képzéseket, tréningeket találni, amelyek valóban előre mutatnak és segítik a továbblépést? Ezt a témát járta körbe a Tech Talk Motivációs kerekasztal beszélgetése, három senior szakemberrel, Margaritisz Oresztész, Beján Csaba Senior Software Engineer-ekkel és Verhás Péter Senior Architect-el. Alábbi posztunkban összefoglaltuk a legfontosabb tanulságokat!

Az idő tényező

Ebben a karrierszakaszban a tréningek, képzések elvégzésének az egyik legnagyobb nehézsége az időhiány. Ennek egyik oka az, hogy ezen a szinten nagyon ritka vagy egyáltalán nem fordul elő két projekt közötti szünet, a senior kollégák számára nem igen akadnak üresjáratok, kevésbé nélkülözhető a tudásuk, szakértelmük. Mivel egy-egy tréning, továbbképzés fél vagy akár egy egész napot is igénybe vesz, ezért ritkán jut idő ilyen jellegű tanulásra. A megkérdezett szakértők egyöntetű véleménye, hogy a senioritás egyik sajátossága éppen az, hogy a tanulás nem időszakos, hanem folyamatos és nem szervezett kereti vannak, hanem autodidakta kötelesség. Félórás, negyvenperces videók megnézése, hírlevelek, esettanulmányok stb. elolvasása a napi rutin része, mindezek szinte kötelező részei a tudás szintentartásának. Az EPAM maga is folyamatosan állít elő és tesz elérhetővé online anyagokat, rengeteg tech-közösség működik, és ezek mind lehetőséget teremtenek a fejlődésre vagy a "nem lemaradásra".

„Egy senior, azért Senior, mert hallgatja, olvassa a konferenciák anyagait, ismeri a legfontosabb irányokat, letölti az Early Releasek-et. Ezen a szinten akkor megy el valaki egy tréningre, ha valamiben lemaradt és érzi a hiányát annak a tudásnak egy adott projekt esetében. A technikai tudás egy része így megszerezhető, a többit kipótolja a Senioritás.” – Verhás Péter

 Technikai vagy általános?

A fejlődés azonban nem csupán technikai értelemben lehet igénye ezen a szinten is az embereknek, hanem a készségek fejlesztésének terén is, dacára a sok éves tapasztalatoknak. Senioroknál is lehetnek olyan elakadások, melyeknek nem a szakmai tudáshiánya az oka, hanem valamely tanulható skillt szükséges erősíteni. Fontosak tehát a készségfejlesztő tréningek, hiszen van, akinek ez még nagyobb nehézséget jelent, mint egy-egy technikai jellegű ismeret elsajátítása. Bizonyos szakmai tapasztalat birtokában fel kell ismerni mi a probléma, hol az elakadás, technikai vagy készségfejlesztés szükséges.

 „Nagyon sok türelemre van szükség, míg rájön az ember, mi akadályozza a haladásban és el is kezd ezzel foglalkozni. Szerettem volna megvalósítani valamit, de éreztem, hogy nem tartok ott, nem tudok felnőni a feladathoz és ennek nem szakmai hiányosság az oka, hanem egy belső konfliktus, mely készségszintű megoldást kívánt.” - Margaritisz Oresztész

 Tudás: megosztva jó

A különböző képzések, tréningek és tudásanyagok mellett igen fontos tényező a seniorok fejlődésében is a tudásmegosztás, melynek nem csupán a párhuzamosan haladókkal van haszna. Lehetőséget nyújt a tanulásra a fiatalabb, tapasztalatlanabb kollégákkal folytatott eszmecsere. A senior szinten elvárható a megszerzett tudás átadása, publikációk, blogbejegyzések, esettanulmányok készítése. Sokszor abból születnek új felismerések, ha az alapvető dolgok újrafogalmazva látnak újra és újra napvilágot. Erre azért is van szükség, mert sokszor a magasabb szinten dolgozók már nem firtatják a miérteket, a szokás elvén működtetnek dolgokat. A fiatalabb kollégák triviálisnak tűnő kérdéseire választ adva valódi válaszok, új nézőpontok, megoldások is születhetnek. A sokat látott szakemberek közös tapasztalata, hogy „nincs hülye kérdés, csak hülye válasz”, ha valaki mer kérdezni, az sokkal jobb, mintha túl sokáig ragad le valaminél, amit bátran megkérdezhetett volna. Nagyon fontos attitűd, hogy így álljon a Senior a Juniorhoz! A tudásmegosztás ugyanakkor sokszor akadályokba ütközik, ezt próbálták kiküszöbölni a szegedi EPAM seniorjai, amikor olyan platformot hoztak létre, ahol juniorok is megoszthatják a tapasztalataikat. Hiszen attól, hogy valaki junior, a tapasztalatai seniorok számára is lehetnek relevánsak.

Legnagyobb tanulás, legjobb tapasztalat

Ahány senior, annyi út, hiába értek el mind egy magas szintre, vannak közös tapasztalataik, mindenkit más mozgat. Van, akinek nem a tréningek jelentik a fejlődést, hanem a személyiségfejlesztés. A motivációt az jelenti, ha a tudásnak tényleges, gyakorlati haszna van, nem kell olyan dolgokat „elraktározni, amik nem kerülnek felhasználásra”. A képzések helyett inkább az jelenti a haladást, ha egy projekt nem ad lehetőséget a kényelemre, ki kell mozdulni a komfortzónából és a megoldáshoz szakmai erőfeszítéseket kell tenni. Lehet nagy lehetőség a fejlődésre egy saját vállalkozás is, ahol minden hibát maga fizet meg az ember, de egy bejáratott rutin után egy külföldi tapasztalat is segíthet abban, hogy új lendületet vegyen egy Senior karrierje, hiszen ismét bizonyítani kell és számos nehézség adódik, ami az otthoni „kényelemben” nem.

 „Ha már dolgozol, van egy nyolcórás munkád, akkor igazi zsonglőrmutatvány szinkronba hozni ezt azzal, ami érdekel, ami hajt. Ha ezt egyszerre találod meg egy projektben, amin dolgozol, az csodálatos. De van, hogy fel kell adnod valamit az érdeklődésedből, a munka javára. Az EPAM-ban az a jó, hogy van lehetőség rotációra, így, ha nagyon elmegy egymás mellett a kettő, a munka és az érdeklődés, válthatsz. Hogy szinkronba tudj kerülni azzal, ami érdekel és azzal, amit csinálsz nap mint nap.” - Beján Csaba

 Nézd meg a beszélgetést!

Ígéretünkhöz híve, egy külön posztban összeszedtük a nézőkben felmerült kérdésekre adott válaszokat is. Kattints a linkre és olvasd el ezeket. 

Tech Talk Motivációs kerekasztal: Kérdések és válaszok!

A beszélgetés összefoglalása mellett, ahogyan ígértük, hozzuk a beszélgetés után, a nézőkben felmerült kérdésekre adott válaszokat is!

Lajos kérdése:

Jelenleg egy kisebb szegedi marketing ügynökségnek dolgozom, landing és céges weboldalakat készítek, igaz csak Wordpressel, de váltani szeretnék és komolyabban bele merülni a webfejlesztésbe. Alap html, css, javascript tudással rendelkezem és az Angular/ Typescriptet tanulom jelenleg. Mit javasoltok, hogy csináljak saját projekteket?  Szerintetek ezáltal könnyebb lesz elhelyezkednem? M. Lajos

Beján Csaba, Senior Software Engineer válasza:

„Az első lépés a passzív tanulás, de a valódi tudást akkor szerzi meg az ember, amikor elkezdi a gyakorlatban is alkalmazni a megszerzett tudást és sorban oldja meg a felmerülő problémákat, amik egyébként elkerülhetetlenek. A neten elég jó kurzusok vannak, melyek az elméletet és a gyakorlatot a megfelelő arányban „keverik”, Courserán például biztosan találsz neked való képzést. Nagyon jó, ha ezen kívül van egy github repo-d, ahol a saját munkáidat össze tudod gyűjteni, mert ezekre aztán referenciaként hivatkozhatsz, ami sokat jelent egy interjún. Ha mellé tudsz rakni egy certificate-et, az már csak hab lesz a tortán!”

Csilla kérdése:

Nektek mi a fontosabb: a Junior jelentkező számszerű, években mérhető tapasztalata vagy a tudása, ahogy megoldja a feladatokat? Erről mi a véleményetek? Legtöbb helyen már élből elutasítják a Juniorokat, mert nincs 3 év tapasztalatuk. Szerintetek ennyire együtt ját a tapasztalat a tényleges tudással?

Beján Csaba, Senior Software Engineer válasza:

„Ha élből elutasítják a Juniorokat, mert nincs tapasztalatuk, az azt jelenti, hogy nem Juniorokat szeretnének felvenni. Szerintem a tapasztalat csak az évekkel jön meg, pusztán attól, hogy viszont, hogy valaki több évet dolgozik valahol, nem biztos, hogy releváns a tapasztalata. Junior szinten sokkal nagyobb hangsúly van a potenciálon, hogy ki mennyit hajlandó tanulni, mennyire kíváncsi. Ha ez a helyén van, megfelelő problémamegoldó készséggel ötvözve, akkor a cég egy rövid távú befektetéssel hosszabb távon jól járhat. Sok helyen azonban ezt túl kockázatosnak ítélik és inkább kerülik a Juniorokat.”

Verhás Péter, Senior Architect válasza:

„Amikor interjúztatok, a CV-t csak az interjú második felében nyitom ki, amig a jelölt el van foglalva a kódolási gyakorlattal. Persze azt is együtt oldjuk meg, de az elején, amíg elolvassa, megérti, van néhány perc. A CV is csak azért érdekel, hogy amikor visszajelzést adok az interjú végén, akkor, ha valami nagyon rossz a CV-ben, tudjak valamit arra is mondani. Ehhez látni kell a CV-t. És mindig adok visszajelzést. Ez azt is jelenti, hogy engem nem érdekel az évek száma az interjún. Amikor azonban a CV-k alapján döntjük el, hogy kit interjúztassunk, akkor nincs más, mint nézni az évek számát. Csak azok az évek számítanak, amit kommerciális, professzionális környezetben fejlesztéssel töltött el a jelentkező. A “pincér voltam” éveket feketével húzom ki, hogy ne is látszódjon. Mindegy mi van a szövegbe írva, én adom össze az éveket és sokszor kevesebb jön ki, mint, ami a CV-ben szerepel. A CV-t, ha lehet nem olvasom el előre, mert észrevettem kb. 7 éve, hogy megvezet, és prekoncepcióval kezdek neki az interjúnak. Mostanában minden interjút úgy kezdek, hogy ez a jelölt lesz a legjobb, akivel valaha is találkoztam.”

Gábor kérdése:

Gyakran érzem a kölcsönös értetlenséget, aminek az állandó időhiány is lehet az akadálya. Keresem azt a közeget, ahol legalább a kölcsönös türelem megvan. Miről ismered meg azt a közeget, ahol ez a generációs türelem megvan?

Beján Csaba, Senior Software Engineer válasza:

„Bár lehet, hogy ennek a kérdésnek érdembeli megválaszolásához túl fiatal vagyok, de talán a legjobb indikátor az lehet szerintem, ha az ember kevesebbszer próbál meggyőzni műsokat az igazáról.  Érdemesebb inkább egymás mondanivalójára építeni és úgy haladni előre. Így nem azzal telik az idő, hogy az abszolút – vagy inkább nem létező – igazság lefektetésén vitatkozunk.”

Gábor kérdése:

A senior-interjúnál mire figyeltek?

Beján Csaba, Senior Software Engineer válasza:

„Ezen a szinte már nagyon sokat elárul az emberről, hogy mit és hogyan tanul. Hogyan tartja szinten magát technológiai fronton. Ezen felül nagyon fontos, hogy mennyire tud csapatban dolgozni, mennyire hajlandó megosztani a tudását, illetve tanulni. Lehet valaki bármennyire jó, nagyon kevés olyan lehetőség van, ahol a csapatmunka és a közös cél, fejlődés nem fontos. Ezen felül a konkrét tudás számít. Igen könnyű leellenőrizni egy interjún, hogy az önéletrajzában tapasztalatként megjelölt technológiákban milyen a tudása. Sokszor kiderül, hogy ha mélységében is kérdezel, akkor elbizonytalanodik a jelölt és kiderül, hogy csak ott volt a csapatban, hallott valamit a dologról, de nem ő, hanem mások csinálták. Ez nem jó jel.”

Verhás Péter, Senior Architect:

„Senior interjúnál azt próbálom meg kideríteni, hogy tényleg Senior-e, megvan-e az évek számának megfelelő tapasztalata a jelöltnek. Ha megvan, akkor eljutott idáig, fog tovább is fejlődni. Ha nincs, akkor ő az úgynevezett “örök Junior” kategória. Az ilyen emberek is sikeresek és boldogok a maguk szintjén. A nagy baj akkor van, ha nagyon más a jelölt önképe, mint ami valójában a helyzet. Idősebb ember esetében ilyenkor nem tudok feedback-et adni, mert nagy a veszélye, hogy nem tudja felhasználni, viszont megsértődik. Ez persze Juniornál is előfordul. Ott is nagyon nehéz ilyenkor a feedback. Nagyon kemény tud lenni, nagyon ki kell „párnázni” a választ, de itt még van esély, hogy valaki változni tud. Ezen 25 évesen átestem, és iszonyú szerencsém volt, hogy részletes visszajelzést kaptam. Ennek ellenére dühös voltam rájuk sokáig, bár tudtam, hogy igazuk van és sok munka volt feldolgozni és tudatosan megváltozni. A technikai tudást illetően van néhány olyan kérdésem, amik elég jól megmutatják, hogy ki mennyire ismeri a Java nyelvet. Nem az a lényeg, hogy pont ezeket tudja-e a jelölt, de ha egyet sem tud, akkor gyanús, hogy a tudása felületes. Egyébként, ha olvastam a CV-t, mert mondjuk részt vettem az előszelektálásban, akkor olyat fogok kérdezni, ami ott szerepel. Minden nem lehet tudni. De, amit tud valaki és leírja a CV-ben azt mennyire tudja. Vagy olyan, az illető, aki CV-je szerint mindenhez IS ért?”

 A LifeInTech podcast csatornán és a LifeInTech blogon futó „Mit csinál a ...” című sorozatunkban arra adunk válaszokat, hogy az IT-ban, a különböző szerepkörökben dolgozóknak pontosan mik a feladatai, egy-egy pozíció, elnevezés valójában mit takar. Most összeszedtük az eddigi epizódokat, interjúkat, így könnyedén képbe kerülhetsz, ki, „mit csinál ...”.

Amikor az EPAM podcast csatornáján elkezdtük a sorozatot, melyben az IT különböző szerepköreiben dolgozó szakemberek meséltek a munkájukról, feladataikról. A célunk az volt, hogy idővel átfogó képet nyújtsunk arról, milyen munkák, munkakörök léteznek a tech világban ma és hogyan változnak, alakulnak a feladatok a technológia fejlődésével. Mostanra olyan, hiánypótló ismeretanyag gyűlt össze, melyet szerettünk volna egyben is megosztani. Íme, tehát linkekkel, lényegre törő idézetekkel a sorozat epizódjai a csatornáról, ezek interjú verziói a blogról!

 "Mit csinál a ... Delivery Manager?"

„A DM pozíciót gyakorta keverik össze a Projekt Manager (PM) pozícióval, ami nem véletlen. Hiszen röviden, egy PM fő feladata, hogy biztosítsa az időben, a megfelelő minőségben és költségeken való szállítást. Ezzel szemben egy DM azzal foglalkozik, hogy biztosítsa az időben, a megfelelő minőségben és költségeken való szállítást. De hol vannak akkor a különbség?”  - Fejes Róbert, Senior Delivery Manager.

Podcast: "Mit csinál a ... Delivery Manager?" - Beszélgetés Fejes Róbert Senior Delivery Managerrel

Interjú a blogon: Új sorozat! Mit csinál a... Delivery Manager? Interjú Fejes Róbert, Senior Delivery Managerrel

 „Mit csinál a ... Business Analyst?”

„Egy analógiával élve, ha egy ház úgy épül fel, hogy egy építész pontosan megtervezi azt az adott funkciójának megfelelően, akkor a business analyst a szoftverfejlesztésben egy nagyon hasonló munkakört takar. Komplex tevékenység; gyakorlatilag egy tökéletes terméket, megoldást gyártunk bizonyos emberek, bizonyos típusú problémájára.”- Kiss Katalin, Chief Business Analyst.

Podcast: "Mit csinál a ... Business Analyst?" - Beszélgetés Kiss Katalinnal, az EPAM Chief Business Analyst-jával

Interjú a blogon: „A kulcs a belső igény a fejlődésre, ami nem a szintet és rangot célozza.”

„Mit csinál a .... Solutions Architect?"

„Alapvetően mindenki kicsit másképp értelmezi, mi az a Solution Architecht, de ha tényleg nagyon egyszerűen egy mondatban kell megfogalmaznom, akkor a business és az IT közötti kapcsolatot teremti meg.„ – Oláh Bence, Solutions Architect.

Podcast: "Mit csinál a .... Solutions Architect?" - Beszélgetés Oláh Bencével, az EPAM Solutions Architect-jével

Interjú a blogon:„Nem dobtak a mélyvízbe, fokozatosan nőttem fel a feladathoz”

"Mit csinál a .... Presales?"

„Rengeteg új lehetőséggel, potenciális projekttel találkozom és amennyiben ez olyan feladat, amit még soha nem csináltunk, akkor ez különösen izgalmas számomra. Fel kell fedezni, nincs még rá minta, kész megoldás, ezért inspiráló, hogyan lehetne a legjobban megcsinálni.” -Tárkányi Ferenc, Director of Client Engagement Office.

Podcast: "Mit csinál a .... Director of Client Engagement Office?" - Beszélgetés Tárkányi Ferenccel

Interjú a blogon: „Ez egy üst, amiben sok minden fő egyszerre és mindenbe bele lehet kóstolni.”

„Mit csinál a ... tesztelő?”

„Csapatommal a tesztelő kollégák szakmai életét terelgetjük. Segítünk nekik egy következő szintre lépni a munkájukban, akár mentorálás, akár konkrét tananyagok segítségével, illetve bármilyen egyéb eszközzel, ami rendelkezésünkre áll. Feladataim közé tartozik, hogy a projekteken segítsek megtalálni a megfelelő embert egy-egy pozícióra. „-Iván József, Software Testing Manager.

Podcast: "Mit csinál a ... tesztelő?" - Beszélgetés Iván Józseffel, az EPAM Software Testing Manager-ével

Interjú a blogon: Mit csinál a ... tesztelő? Avagy „...jobban szeretem megtalálni mások munkájában a hibát, mint a magaméban.”

 "Mit csinál a… People Experience Specialist?”

„Sok ember számára a karrier adja a siker egyik fontos forrását és hogyha valaki napi 8 órát dolgozik egy olyan pozícióban, ahol nem érzi igazán jól magát, akkor az egy demoralizáló és depresszív állapot lehet. Viszont, ha valaki szereti és jól csinálja azt, amit csinál, akkor el tud repülni ez a 8 óra.” - Bánky Bea, People Experience Specialist.

Podcast: "Szerintem a legszexibb munkák nem léteztek 10 évvel ezelőtt, de még 5 évvel ezelőtt sem" - Mit csinál a… People Experience Specialist?

Interjú a blogon: A (munkahelyi) boldogság nyomában

„Mit csinál a ...Scrum Master? "

„Maga a scrum egy keretrendszer az agilis projektmenedzsmentben, ő határoz meg bizonyos szerepköröket a scrum csapatban, melynek ő a támogató vezetője. Tulajdonképpen olyan, mint egy coach, aki a csapatot támogatja annak érdekében, hogy az elérje a céljait, segít egy biztonságos légkör kialakításában. Olyat, ahol az emberek mernek hibázni, mely hibákból aztán tudnak tanulni és folyamatosan fejlődnek, megosztják egymással a tudásukat, az esetleges elakadásokat, amibe beleütköznek.” – Sólyom Zsófia, Scrum Master.

Podcast: “Gyakorlat teszi a me(a)stert, a Scrum Mastert… " - Sólyom Zsófiával, az EPAM Scrum Masterével beszélgettünk

Interjú a blogon: „A Scrum Master célja, hogy ne legyen rá szükség.”

“Mit csinál a … DevOps-os?”

„A DevOps Engineer nem is egy megfogható munkakör, egy olyan szerep, megközelítés egy olyan kultúra, ami a szoftverfejlesztési ciklust felöleli az elejétől a végéig. Kell hozzá szakmai tapasztalat a különböző területeken, hogy támogatni tudja az egész folyamatot. Különböző területekről jönnek azok, akik DevOps-osok lesznek.” - Nagy Gábor, DevOps Team Lead.

Podcast: “Mit csinál a … DevOps-os?"

Interjú a blogon: "Mit csinál a ... DevOps-os?"

 „Mit csinál a .... Data Analyst?”

„Ami megfogott ebben a pozícióban az, hogy szoros együttműködésben kell az ügyfelekkel dolgozni, megérteni a problémáikat, és ezeket úgy rendszerbe helyezni, illetve segíteni nekik, hogy az adatot értelmezni tudják és eszerint hozzanak döntést. „ – Birinyi Boglárka, Data Analyst.

Podcast: "Mit csinál a .... Data Analyst?"

Interjú a blogon: Mit csinál a .... Data Analyst? 

 „Mit csinál a ... Project Manager?”

„A projekt menedzser kicsit olyan, mint a ponyvaregényben Mr. Wolf, a megoldóember. .... A legkülönbözőbb helyzetek fordulhatnak elő és fontos, hogy a PM tudja, mit, hogyan lehet éppen az adott helyzetben, az adott emberekkel kezelni.” - Józsa Péter, Senior Project Manager.

Podcast: "Mit csinál a ... Project Manager?"

Interjú a blogon: Hamarosan!

"Mit csinál a ... Big Data-s?"

"Az IT-ban ma még mindig az a legnagyobb kihívás, hogy hozzuk össze a valós igényt egy szoftverben megvalósított megoldással. Valahol minden lead feladat, ennek a támogatása."  - Nagy András István, Solution Architect.

Podcast: "Mit csinál a .... Big Data-s Solution Architect?

Birinyi Boglárka majd’ hét éve BI Developerként kezdett el az IT-ban dolgozni, innen vezetett az útja az EPAM-hoz, ahol ma már Lead Data Analyst pozícióban támogatja a fejlesztéseket. Interjúnkban erről a sokrétű és viszonylag új szerepkörről, az adatok alapján hozott döntésekről és az EPAM kínálta lehetőségekről beszélgettünk.

A kettő közül melyik vagy te, egyenes út az IT világba vagy éles kanyar után az IT világba?

Az ELTE-re jártam, egészséggazdaságtani szakértő mesterképzésre, úgyhogy nem a klasszikus utat jártam be, ha azt nézzük, kiből lesz vagy lehet Data Analyst. De talán ez is jól mutatja, hogy nem feltétlenül az számít, milyen iskolát végez az ember, hanem inkább a hozzáállás és a személyiség.

Mi volt az, ami miatt ez a terület végül magával ragadott, olyannyira, hogy aztán ezzel foglalkozz?

Ami megfogott ebben a pozícióban az, hogy szoros együttműködésben kell az ügyfelekkel dolgozni, megérteni a problémáikat, és ezeket úgy rendszerbe helyezni, illetve segíteni nekik, hogy az adatot értelmezni tudják és eszerint hozzanak döntést. Nagyon érdekes végig kísérni, hogy egy adott problémát egy adatelemzéssel vagy egy BI riporttal egy dashboard-dal, hogyan tudunuk láthatóvá, értelmezhetővé tenni a számukra.

Egyébként az EPAM-os Data Analyst pozíció különbözik valamiben egy másik cég hasonló pozíciójától?

Szerintem inkább az elnevezések között van különbség, mert ezt a pozíciót hívhatják máshogy is. Akár BI Analyst, amiben talán kicsit jobban benne van, hogy Business Intelligence-el foglalkozik. De úgy látom, hogy közös jellemző mindenhol, hogy nagyon közel dolgozunk az ügyfelekkel. Nagyon sokrétű munka ez egyébként, mert valaki ugyanebben a Data Analyst pozícióban inkább a back-end részét viszi, valaki a dashboard-okat, ami már a front-end-nek a része.

Ez egy viszonylag új szakma, szerepkör. Mióta van ennek egyáltalán egy direkt elnevezése, hogyan alakult ki erre egy külön szerep?

Nálunk, az EPAM-nál elég új, két éve létezik. Korábban Business Analyst-ok voltunk, mert nagyon hasonlít abból a szempontból, hogy mi is az ügyfelekkel tartjuk a kapcsolatot. Meg kell értenünk az ő business logikájukat, ezt le kell fordítanunk egy konkrét tervre, requriement-re. Abban viszont különbözünk, hogy mi adott esetben a fejlesztést csináljuk, ami nem klasszikus értelemben vett szoftverfejlesztés, hanem a BI Reportot, dashboard-ot, a back-end-ben pedig az adat transzformációkat, ETL-t fejlesztünk. Ez az, ami igazán megkülönböztet minket a Business Analystoktól. Ezért született meg az igény az EPAM-on belül is, hogy ez mégis legyen egy külön ág. Egyre több cég látja be azt, hogy ezzel az adatalapú döntéshozatallal nagyon sokat tudnak spórolni és racionalizálni tudják bizonyos folyamataikat. Ennek a pozíciónak nagy jövője van.

Kik azok, akiknek való ez a munka szerinted? Milyen háttérrel, milyen tapasztalattal jöhetnek és dolgozhatnak ebben a pozícióban azok, akik esetleg keresik még az IT-ban a helyüket?

Az mindenképp nagyon fontos, hogy egy alapvető statisztikai, logikai tudása legyen az embernek. Ez általában közgazdaságtani végzettségűeknél adott, de rengeteg például a szociológus közöttünk, akik az egyetemen sokat foglalkoznak statisztikával. Ami talán még ennél is fontosabb, hogy legyen egy proaktív szemlélete, problémamegoldó képessége, egy, a problémákat felismerő készsége, analitikai gondolkodása, annak, aki ezzel szeretne foglalkozni.

Hogy néz ki egy projekted az elejétől egészen addig, míg lezárul?

Mint a szoftver fejlesztésnek a mi projektjeinknek is hasonlóak a főbb stádiumai. Az elején meg kell értenünk az ügyfél céljait, főbb motivációját valamint a cégen belül meglévő rendszereket/adat struktúrákat. Ezek alapján építjük fel a projekt tervet, és kezdjük el a BI riportok fejlesztését. Ebben a stádiumban folyamatosan kapcsolatban állunk az ügyfeleinkkel, ami azért fontos, hogy folyamatában lássák a munkát, közben is tudjanak véleményt alkotni vagy módosítani a logikán, ha arra van szükség. A módosítások elég általánosak, mivel a fejlesztés során derülnek ki a pontos részletek az adatuk minőségéről például. A fejlesztési szakasz lezárásával, pedig elkezdődik a tesztelés a végleges felhasználók bevonásával. A fejlesztési és tesztelési szakaszt az én ügyfelemnél mindig ketté osztjuk. Az első fejlesztés/tesztelés az adatra vonatkozik, ilyenkor azt nézik meg a felhasználók, hogy a kalkulációink, modelljeink jó eredményt adnak-e, illetve, hogy minden adat rendelkezésre áll-e, amire a munkájuk során szükségük lehet. A második fejlesztés/tesztelés pedig már a BI riport / dashboardra vonatkozik. Ilyenkor már magát a riportot tesztelik, hogy minden funkció úgy működik-e, ahogy kell. Miután a tesztelés lezárul a riportot elérhetővé tesszük az összes felhasználónak és pár hétig, hónapig, - ez mindig egyéni megállapodás - még szorosabban együtt működünk velük, hogy az esetleges apróbb hibákra, észrevételekre gyorsan tudjuk reagálni. Nyilván ez egy nagyon általános és ideális projekt görbe, ahol az elejétől a végéig részt vesz az ember. De sokszor csak a közepén csöppenünk bele egy projektbe vagy csak egy bizonyos szakasznál van szükség ránk.

Hova lehet eljutni ebben a pozícióban, mi a csúcs?

A Lead Data Analyst pozíció felett, - amiben én is vagyok - már csak egy szint van, ez a Chief Data Analyst. De el lehet indulni más irányba is, például lehet valaki Data Analyst konzultáns, ami már sokkal inkább ügyfélmenedzsmentre épül, újabb lehetőségek behozatalára. Ott inkább az a fontos, hogy egy vagy több business domain-t is annyira jól ismerjünk, hogy felismerjük a lehetőségeket és be tudjuk csatornázni azokat a jelenlegi projektekbe. De el lehet indulni projektmenedzser irányba is, ez is egy lehetőség. Az EPAM-on belül szerintem nagyon jól működik az, hogyha valamilyen irányba el szeretnél menni, mert menet közben rájössz, hogy valami más neked jobban tetszik, vagy jobb vagy benne, akkor út közben könnyen át tudsz mozogni egy másik pozícióba. Tök jó tréningjeink, mentor programjaink vannak, amiken a részvételt kifejezetten támogatják is.

Esetleg ki tudsz emelni egy képzést, amin te is részt vettél?

Hihetetlen mennyiségű belső tréning érhető el, kettőt tudnék kiemelni. Az egyik a menedzser mentoring program, ami nagyon izgalmas, mert úgy épül fel, hogy van egy úgynevezett mentor pool, ahol nagyon sok kritérium szerint tudsz szűrni és kiválasztani magadnak azt a mentort, aki szerinted segíteni tudna neked. A másik, a team lead grow tréning, aminek a lényege, hogy felkészítsen a vezetői szerepre.

Mi az, ami a te személyes célod a következőkben?

Jó kérdés, mert ezen még én is gondolkozom. Most inkább egy belső pozícióra koncentrálok, ez motivál, a country discipling head szerep, ami szakmai vezetőt is jelent. Ezen a területen, úgy látom, hogy még rengeteg mindent lehet csinálni.

Ahány EPAM-os annyi motiváció, út, lehetőség. Te milyennek látod az EPAM-ot, mit jelent neked?

Lehetőséget. Azt, hogy mind a tanulásban, mind a projektekben annyira szerteágazó, annyira sok lehetőség van benne. Az EPAM a lehetőségek kifogyhatatlan tárháza.