Egy fejlesztő számára gyakran a Solution Architect szerepkör a vágyott cél, aminek eléréséhez változatos út vezethet. Oláh Bence az EPAM Solution Architecht-je a „Mit csinál a…?” sorozat aktuális alanyaként a saját útjáról és az általános EPAM-os gyakorlatról is mesélt.
Ha röviden kéne összefoglalnod, mi is az a Solution Architect, hogyan fogalmaznál?
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. Egy konkrét példa; ha egy iskolában szeretnének e-naplót bevezetni, akkor a folyamatban a Solution Architecht feladata az, hogy felmérje az igényeket és ezek alapján készítsen egy dizájnt vagy például figyeljen arra, hogy melyek azok az időszakok, amikor a tanárok egyszerre sokan használják ezt a rendszert. Fontos az is, hogy mi a stratégiája az adott cégnek - itt az iskolának - a termékkel és hogyan illik ebbe ez a megoldás. Az e-naplót csak arra használjuk, hogy adminisztráljunk vagy mondjuk arra is, hogy e-learning anyagokat adjunk a diákoknak, esetleg szeretnénk elindulni a digitális oktatás irányába, amikor tableteket használnak a diákok. Ezek mind olyan dolgok, amiket egy Solution Architecht-nek fel kell térképeznie és megérteni, hogy mi a stratégia és ennek alapján úgy megtervezni a rendszert, hogy az mindezt már tudja, vagy később képes legyen erre.
Mi a hierarchia, hogy jut el valaki oda, hogy Solution Architect lesz?
Ez egy technikai pozíció, technikai háttértudást igényel, azaz általában fejlesztő válik Solution Architect-é. Nekem is fejlesztői hátterem van és akkor választottam ezt az irányt, amikor már szerettem volna új dolgokat tanulni. Érdemes végig járni tehát a fejlesztői ranglétrát, de nem feltétlenül muszáj, inkább tanácsos a fejlesztői tapasztalat. Nálunk az EPAM-ban van arra lehetőség, hogy fokozatosan kapjunk olyan feladatokat, amelyek ehhez a szerepkörhöz vezetnek; én is így kezdtem. Ahogyan aztán egyre több ilyen, tanácsadó jellegű feladata lesz az embernek, úgy lesz kevesebb fejlesztői, míg végül hivatalosan is Solution Architet lesz belőle. A szakmai tudás mellett aztán szükség van még olyan készségekre is, mint a nyitottság és a jó kommunikációs készség, hiszen sokat kell ebben a munkakörben beszélgetni. Ráadásul sok résztvevős beszélgetések ezek, ahol meg kell érteni a különböző igényeket és ezek között kell egyensúlyozni, végül átlátni, melyek a különféle alternatívák. Nagyon sokféle készségre van szükség, amiknek nem mindig vagyunk birtokában, ezeket el kell sajátítani.
Mennyire kellett saját magadon felülemelkedned, hogy ezeket el tudd sajátítani?
Ez egy folyamat volt, mindig egy kicsivel kijjebb kellett lépnem a komfortzónámból. Nem dobtak a mélyvízbe, hogy „na, most itt van, tessék, csinálj valamit saját magad”, hanem fokozatosan tanultam és fejlődtem, nőttem fel a feladathoz. Az EPAM-nál ez a bevett gyakorlat.
Hogyan jutottál el oda, hogy ebbe az irányba indulj tovább a fejlesztői szerepkörből?
Kilenc éve dolgozom itt, kettes szintű fejlesztőként kezdtem, majd Senior fejlesztő lettem és néhány év csapatvezetési gyakorlattal a hátam mögött éreztem azt, hogy szeretnék más irányban is fejlődni. Számomra két opció volt; az egyik, hogy elmegyek menedzsment irányba, vagy maradok a technikai vonalon. Mielőtt a váltás mellett döntöttem volt bennem egy kis félelem, hogy elveszítem a lelkesedésemet, aggódtam, hogy milyen motivációt találok majd 10 év múlva a fejlesztésben. Az új pozíciómban azonban folyamatosan új kihívások elé állít a munka, mindig tanulok, miközben megmaradt a fejlesztői munkámból is egy kis rész, az ebben szerzett tapasztalataimnak is nagy hasznát veszem. Mindez biztosítja számomra, hogy hosszú távon jó választás legyen a Solution Architect szerep.
Ha visszagondolsz a fejlesztői illetve a jelenlegi munkádra, akkor mi a legjelentősebb különbség a kettő között? Mi az, amiben szignifikáns különbség van?
Például rögtön az, ahogyan viszonyulok egy adott helyzethez. Fejlesztői szemszögből megnéztem azt, hogy milyen technológiák vannak, mi az, ami érdekes belőle. Ma sokkal inkább azt nézem, hogy miért csináljuk a projektet, miért van értéke az ügyfél számára? Mi az, ami biztosítja az egész rendszer szempontjából, hogy megkapja az ügyfél, amit eredetileg szeretett volna? Ma tehát felülről tekintek az egészre.
Mivel telnek az Architect napjai, milyen feladatai vannak egy projekt egészét nézve?
Ez egy változó folyamat, de nagy általánosságban az Architecht már a projekt kezdetekor, illetve akár már előtte elkezdi a munkát. Azaz az ügyfelek vagy ügyfél jelöltek pályázatokat írnak ki, majd meghívnak rá „vendorokat”, akkor a benyújtandó dokumentáció, tervezett megoldás és timeline, költségvetés és csapatigény összeállítása az ő feladata. Ebben a fázisban gyakorlatilag úgy telik az ember napja, hogy vagy a potenciális ügyféllel beszélget, vagy a csapattal, akik a pályázaton dolgoznak. Ez tehát egy tervezési fázis gyakorlatilag. Ezt követően optimális esetben a cég megnyeri a projektet, ilyenkor kiutazunk az ügyfélhez, megismerkedünk vele és még pontosabban feltérképezzük, mi a feladat. Majd a design fázis és az egyeztetés után egy kicsit gyakorlatiasabb implementációs fázisba kerül a projekt, amikor prototípusokat kell fejleszteni. A feladataim jellemzően dizájn és kollaboráció jellegű feladatok némi implementációval fűszerezve, ezek váltakoznak, attól függően, éppen hol tartunk a munkában.
Mi az, ami számodra a legélvezetesebb ebben a munkában?
Az, hogy változatos.
Milyen az ideális Architect?
Erre nem könnyű válaszolni, mert az Architecht szerepkörnek is több szintje van. Az alsóbb szintű Architect-ek inkább egy adott rendszerért felelősek, technológiailag számítanak szakértőnek, kevésbé az üzleti területen. Ahogy lépünk egyre feljebb a szinteken ez nyilvánvalóan fordítottan változik. Itt már érteni kell, hogy az adott üzleti domain hogyan működik, mik a trendek, ezekben hogyan lehet részt venni. Ez már inkább konzultáns szerepkör, ahol nemcsak együtt dolgozol az ügyféllel, hanem megpróbálod eladni és képviselni az üzleti ötleteidet is. Ehhez mindenképp nyitottabb személyiség szükséges, aki kíváncsi mások ötleteire, ugyanakkor megtalálja az egyensúlyt aközött, amikor nyitott, és amikor kicsit autokratikusabb és ő hozza meg a döntést.
Nemrég született a második gyermeked, és egy kisbaba egyértelműen sokat követel az embertől, különösen munka mellett. Hogyan tudod megoldani ezt az élethelyzetet?
Szerencsére az EPAM biztosítja azt a fajta rugalmasságot, amivel élhet az ember, ha az élete azt kívánja meg. Dönthetsz, milyen típusú projekteket vállalsz el. Például én most olyan projekten vagyok, ami már az implementációs fázisban van, tehát kevesebb utazással jár, így több időt tudok a családommal tölteni. Ha pedig valakinek gyereke születik, - a projekt függvényében persze - ehetősége van arra is, hogy kicsit többet dolgozzon otthonról.
Ha a gyereknevelésben valamit az ember az elején elront, nem könnyű feladat helyrehozni, ahogyan egy projektre is igaz ez. Mi az, amit apaként, a munkádban tanultakból hasznosítani tudsz?
Ha szülőként eltervezel valamit, nagy esély van arra, hogy az nem úgy fog működni, mert a gyerek éppen mást szeretne csinálni, valami közbejön, folyamatosan változnak a dolgok. Számomra újdonság volt, hogy valami ilyen mértékben kiszámíthatatlan és úgy érzem, hogy ezt nagyon jól tudom a munkámban kamatoztatni. Nem ér váratlanul, ha valami teljesen másként történik, mint, ahogy vártuk. A másik oldalról pedig az apaságban nagyon sokat jelent az a tapasztalat, amit a munkám során szereztem. Hiszen itt sok múlik azon, hogyan tudsz másokkal együttműködni, hogyan reagálsz vagy éppen hogyan lehetett volna egyes helyzetekre reagálni. Szóval az apaságom és a munkám egyaránt, oda-vissza hatnak egymásra és mindkettőben folyamatos a tanulás.
A beszélgetést teljes egészében itt tudod meghallgatni!
