Egy tech cég kulisszatitkai

Küldetése: kockázatmentesítés – Interjú Bartók Tamás, Solution Architecttel

„A szakmai kapcsolati háló a legjobb módja, hogy értéket teremtsünk, közvetítsünk.”

2021. június 21. - Kárpáti Judit

Bartók Tamás, a szegedi EPAM-nál Solution Architect, akire egy új szervezeti egység felépítését bízták rá, amely arról gondoskodik, hogy a már "sokat látott", tapasztalt kollégák, a saját projektjükön kívül is elérhetők legyenek, hogy tudásukat megosszák más szervezetekkel, projektekkel. Az új formáció egyúttal azt is szavatolja, hogy a senior kollégák egyfajta "guru" szerepben, új kihívásokat találjanak, így maguk is tudnak fejlődni.

bartok_tamas.png

Mindig is színes személyiségnek tartottam magam, egész életemben rendkívül sok minden érdekelt, sajnos mindig egyszerre, amit nem mindig könnyű menedzselni.” – így jellemzi magát az EPAM-nál 2013 óta dolgozó szakember. Már fiatalon céltudatosan halad előre, az egyetemen demonstrátorként tevékenykedik, később munka mellett végzi el a doktori iskolát. Az EPAM-hoz is azért igazol, mert „...fiatalként úgy gondoltam, hogy nincs végtelen időm arra, hogy kivárjam, míg a környezet ideálissá válik számomra. Fontosnak tartottam, hogy ezt a környezetet én magam alakítsam.” A céghez senior fejlesztőként lép be, szinte azonnal rábízzák egy csapat vezetését és nemsokára vezető fejlesztővé léptetik elő. További szakmai tapasztalatokkal gazdagodva – oktatás, technikai architect feladatok, korai projekt előkésztés különböző projekteken – négy év alatt jut el jelenlegi Solution Architect szerepköréig.„Ezen a skálán is vannak további lépcsőfokok, aktívan dolgozom rajta, hogy lépkedhessek felfele.”- mondja jelenlegi céljairól. 

A témánk fókusza az az új szervezeti egység, amit tavaly, 2020-ban kezdtél építeni. Hogyan mutatnád be, mi a lényege ennek az építkezésnek?

A magyar menedzsment kérésére, 2020-ban kezdtem el a meglévő pozícióm mellett ezt a munkát. Ahhoz, hogy megértsük, miért volt szükség erre a szervezeti egységre, látni kell, hogyan épül fel az EPAM. Különböző szervezeti struktúrák mentén szerveződik a fejlesztés; az egyik ezek közül az un. Delivery, azaz a leszállításért felelős struktúra, mely méretét tekintve talán a legnagyobb. Emellett vannak jelen a Solution Practice-ek az üzleti, szervezeti oldal. Miután a Business Unit-ban töltöttem el három évet, kértek fel arra, hogy a már említett Delivery egységben építsek egy új organizációt. Mégpedig azzal a célkitűzéssel, hogy kiszolgáljuk, segítsük a különböző egyéb szervezeti egységeket, projekteket azáltal, hogy tapasztalt, senior kollégákat szerepkörüktől függetlenül egymással összekötünk. Ezáltal aztán még több tudást, értéket tudunk szállítani az ügyfelek, valamint különböző szervezeti egységek részére is.

Korábban nem volt ilyen, miért támadt erre igény éppen 2020-ban, amikor amúgy is nehezített pályán kellett mozogni?

Azt láttuk, hogy az üzleti oldalnak problémát okoz, hogy minden egyes alkalommal, amikor egy új ügyfélnek ajánlatot szeretnénk adni, olyan senior kollégák kerültek egy csapatba, akik sokszor még soha korábban nem dolgoztak együtt. Mivel nem volt közös munkatapasztalatuk, nehezen volt garantálható, hogy az elvárt magas minőséget szállítsuk. Azt is észrevettük, hogy számos tapasztalt kollégánk, bár maga mögött tudhat jó néhány projektet, már évek óta ugyanabban a feladatkörben dolgozik. Egy idő után repetitívvé / unalmassá válhat a feladat, ami egyfajta lefelé vezető spirált indíthat el az illető karrierjében. Ahhoz, hogy ezt megtörjük színesebb feladatokat kell biztosítani. Így két legyet ütöttünk egy csapásra ennek a szervezetnek a létrehozásával. Mindemellett volt egy harmadik tényező is; ez az utóbbi időben a technológiai fejlesztés iránt jelentkező kereslet emelkedése - globálisan. Egyre több ügyfél érdeklődik a szolgáltatásaink iránt, így meg kell vizsgálnunk, melyik ügyféllel fogunk együtt dolgozni, mennyire illik a portfoliónkba és mi magunk mit szeretnénk nyújtani. Ezt azonban nem biztos, hogy egy Business Development-el foglalkozó kolléga egymaga képes eldönteni, fontos, hogy legyen egy olyan, magasan képzett, nagyon tapasztalt csapat, akikre támaszkodhat ebben.

 Milyen szerepkörökben dolgoznak a csapat különböző tagjai?

A szervezetet eleve úgy építettük fel, hogy az alegységek tükrözzék a lefedni kívánt területeket. Ennek érdekében a különböző pozíciókra, címekre is figyelünk és alapvetően a feladatkörökre koncentrálunk. Van egy Project Management Office nevű szervezetünk, ahol alapvetően projektmenedzsmenttel foglakozó kollégák vannak. Ők különböző (jó)gyakorlatokat osztanak meg egymással, így pl. azon is dolgoznak, hogy ajánlatadásnál  rendelkezésre álljanak azonnal használható anyagok. Felállt egy un. Business Domain Practice, ők az üzleti domain területen átívelő tudást fogják össze. Erre azért van szükség, mert az adott iparág üzleti környezetének ismeretével, jobb ajánlatokat tudunk adni, illetve az ügyfélre is pozitív benyomást tusunk tenni, ha ismerjük és használjuk az ő "terminus technikusait". A harmadik csapat a Product Management Competency, akik elsősorban a termékfejlesztéssel foglalkoznak és az ügyfelek igényeinek lebontásában és a tervezésben - mennyi idő alatt, milyen funkciókat szállítsunk – vesznek részt. Végül a negyedik terület a Technology Excellence, ahol főként Architect, Principal Engineer kollégákkal dolgozunk, akik a projektek technológiai előkészítéséért felelnek.

Hogyan viszonyul ez a practice a Solution Practice-hez?

A Solution Practice-k valamilyen üzleti vagy technológiai domain mentén szerveződnek, ott egy erős kollaborációt hoznak létre a practice-en belül. Ez egyébként szintén un 'silókon' átívelő szervezet, ám ők egy adott domain mentén mozognak. Mi alternatívát kínálunk azoknak, akik nem feltétlenül szeretnének egy-egy Solution Practice-hez tartozni, ezáltal specializálódni. Ide leginkább azokat várjuk, akik színes, átfogó tudást szeretnének fenntartani és hajlandóak akár egyszerre több, különböző üzleti domainnel rendelkező projekten dolgozni, vagy "csak" szakmai tanácsadást végezni. Mivel silókat bontunk le, különböző kollégákat kötünk össze és erős kollaborációt hozunk létre, mégis nagyon hasonlítunk a Solution Practice-ekhez. 

Mi az, amivel te foglalkozol, milyen feladataid vannak ehhez kapcsolódóan?

Absztrakt megfogalmazásban, a pontokat, az embereket kötöm össze más szervezeti egységekkel és folyamatokkal. Mondhatnám úgy is, hogy egyfajta katalizátor vagyok. Szeretném elérni, hogy a csapat/practice-tagok, saját kapcsolati hálót is ki tudjanak építeni, mert ez a legjobb módja annak, hogy értéket szállítsunk egymásnak és a klienseinknek. Hiszem, a sokszínűség mindennek a záloga.

Hogyan fogalmaznád meg, mi a Solution Architect szerepkör lényege?

Ennek a feladatkörnek az esszenciája a kockázatmentesítés. Ez rendkívül fontos terület, hiszen így biztosítható, hogy a különböző ajánlatokat, követelményeket elviselhető kockázati profil mellett tudja vállalni maga az ügyfél és az EPAM is. A Solution Architect szerepe pedig, hogy megértse az üzleti domaint és mind technikai, mind követelmény tekintetében megvizsgálja a különböző aspektusokat, majd javaslatot adjon, hogy hogyan minimalizálható a bizonytalansági faktor. Eszköztárban nem csupán technológiai tudásra, de bizonyos interperszonális és kommunikációs képességekre is szükség van.

Folyamatosan keresitek az új kollégákat, kiket, milyen szerepkörben dolgozó szakembereket vártok leginkább?

Mindenkire szükségünk van, aki illeszkedik a profilunkba. Ha mégis ki kell emelnem pár szerepkört, akkor Software és Solution Architect valamint Product Managereket keresünk, de ha egy nagyon jó profillal rendelkező Project vagy Delivery Manager érkezik, őt sem fogjuk elutasítani. A szervezetünket olyan kollégák tehetik gazdagabbá, akik szerteágazó tapasztalatokkal rendelkeznek, több projektet láttak már szakmai életük során, ezáltal színesebbé tehetik a közegünket.

A bejegyzés trackback címe:

https://epam.blog.hu/api/trackback/id/tr6016595594

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

Nincsenek hozzászólások.
süti beállítások módosítása