Új sorozatot indítottunk a LifeIn Tech podcast csatornán és a blogon! A téma pedig; a szoftverfejlesztésben milyen pozíciókhoz, milyen feladatok tartoznak, milyen tudásra van szükség az egyes szerepekben?
Az első részben Fejes Róberttel, az EPAM Senior Delivery Managerével beszélgettünk.
Térjünk a lényegre azonnal; mit csinál a Delivery Manager (DM), mit takar ez a pozíció az EPAM-nál?
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? Ha a PM, valamilyen nehézségbe ütközik, elég, ha megír egy emailt, hogy probléma merült fel, ezzel hátradőlhet, elvégezte a munkáját. Ezzel szemben a DM ilyenkor a megoldásra fókuszál; amellett, hogy természetesen tájékoztatja az érintetteket és döntéshozókat arról, hogy probléma van, amely hatással lehet majd magára a szállításra, próbál megoldást is találni. Például, ha a fejlesztett terméknek egy másik beszállító által fejlesztett rendszertől függ, amely valószínűleg nem fog elkészülni határidőre, akkor a DM a csapatával és a megbízóval együttműködve keres egy olyan technikai megoldást, mely lehetővé teszi a fejlesztés tovább haladását. Ilyen megoldás például a külső rendszer működését szimuláló kis szoftver komponens mely a fejlesztés alatt helyettesíteni tudja a hiányzó modult. A DM fő szempontja tehát, hogy szállítson. Régen csak PM-ek léteztek és nagyon erősen elszeparálódtak a felelősségi körök, napjainkban azonban a felgyorsult szállítási kényszerben, egy gyorsan változó világban az agilis technológiák erősödnek. Így aztán egyre inkább a piaci előnyök hangsúlyozására került át a fókusz, a minél előbbi piacra kerülés teremtette meg az igényt arra, hogy egy új management szerepkört vezessünk be, amely képes nemcsak azonosítani és más hatáskörébe átutalni a problémákat, hanem ténylegesen megoldani is azokat, mind képességek, mind autoritás szempontjából. Ez a felismerés az EPAM-nál nagyjából 3-4 éve született meg és ez teremtette meg a DM szerepkört. Amely nem tisztán management feladatokkal járó munka, hanem igen sok technikai hátteret is igényel. A junior DM-től is elvárás már az, hogy értse, mi történik a fejlesztésben, hogyan lehet hatékonyabbá tenni különböző krízis szituációkban, milyen technikai megoldások vannak. Ilyen például a Continous Delivery felépítése és annak finomhangolása, hogy minél előbb piacra kerülhessen a termék. Szintén mély technológiai ismereteket igényel a fent említett, külső beszállítótól való függőség csökkentése is. Vagy akár a skálázódásból - növekvő felhasználói terhelés az eredeti rendszeren, mely kezdi, vagy már meg is haladta az eredeti rendszer képességeit – származó igény a felhő alapú megoldásokra való átállásra.
Milyen képzettséget igényel mindez?
Viszonylag széles horizontális tudásra van szükség; egyrészről kell egy mérnöki véna, hogy a technológia problémákat felismerje, és megoldási javaslatot tudjon tenni vagy legalább feltenni azokat a kérdéseket a csapatnak, aminek segítségével meg tudják oldani a problémát. Emellett kell hozzá gazdasági ismeret, hiszen egy gazdasági kontextusban dolgozunk, management oldalról pedig kell az a képesség, amely segít döntéseket hozni. Erre azért van szükség, mert nagyon sokszor nem tökéletes mérnöki megoldásra van szükség, hanem gazdaságilag indokolt, profitábilis megoldást kell találni. Nem lehet a végletekig tökéletesítgetni a rendszert, pont azért, hogy figyelni tudjuk a piacot és képet kapjunk, hogy annak, amit csinálunk, van-e értelme a piacon vagy nincsen.
A tudás mellet mely készségek azok, amikre szerinted leginkább szüksége van egy igazán jó Delivery Managernek?
Mérnöki oldalról nézve, főleg a probléma megoldás, strukturálás, megértés, amik nagyon fontos területek. Érteni kell, hogyan lehet egy nagyobb problémát lebontani kisebb részekre, hogyan lehet a csapatnak segíteni, hogy ezeken végig tudjanak haladni. Hogy megértsük, a probléma honnan ered, a szoftver melyik rétegében kezdjünk el keresgélni. Ehhez mély, mérnöki gondolkodásra van szükség. Ha a management oldal felől közelítünk, akkor ki kell emelni, hogy emberekkel dolgozunk, ide nagyon fontosak a soft skillek, az empátia, annak megértése, hogy mit szeretne a csapat. Azt szoktam tanácsolni a managereknek, hogy tartsák fejben, ők dolgoznak a csapatáért és nem a csapat értük. A DM feladata, hogy segítse a csapatot, értéket tudjon teremteni, ami egyfajta alázatot, empátiát igényel. Mindemellett közvetlenül kapcsolatban állunk ügyfelekkel is! Nekik nagyon nehéz egy komplex rendszer esetében megfogalmazniuk, hogy pontosan mit szeretnének, ezért képesnek kell lenni arra, hogy belehelyezkedjünk az ő helyzetükbe, megértsük az ő álláspontjukat, azt, hogy amit kérnek, sokszor nem tűnik logikusnak.
Jellemzően milyen nehézségeket okoz ez a fejlesztés során?
Gyakran találkozunk olyan helyzettel, hogy felfedezünk egy hibát, ezt jelezzük az ügyfélnek és nagyon sokszor kapunk olyan választ, hogy nem baj, ettől függetlenül piacra kell dobnunk a terméket a végfelhasználóknak. Ezt néha nagyon nehéz elmagyarázni a csapatnak, amikor azonnal jönnek különböző, teljesen jogos érvekkel, hogy milyen, akár gazdasági következményei lehetnek az adott hibának. Mégis meg találnunk az egyensúlyt, amikor az ügyfél vállalja a kockázatot, mert információt akar szerezni a piacról, hogy van-e értelme a szoftvernek, amit készítünk, egyáltalán van-e felhasználó, aki használni akarja az adott terméket.
Kikkel és milyen kapcsolatban vagy más részlegek tekintetében, azaz kik azok a kollégák, akikkel mindennapos együttműködésben dolgozol?
A saját példámon keresztül igyekszem ezt bemutatni. Nagyjából 160-an dolgozunk a jelenlegi ügyfelünknek. Egy ekkora csapatban természetesen nem lehet mindenkivel napi kapcsolatot tartani. Egy ekkora projekt már al-projektekre (úgy nevezett work streamekre) van bontva, minden work streamnek van saját DM-je. Ők alkotják az én közvetlen csapatomat. Ők látják át, mi történik az egyes work streameken, hozzájuk 15-20 ember tartozik, rajtuk keresztül tudok segíteni nekik, hogy stratégiailag megfelelő irányba haladjunk. Ezen felül együtt dolgozom az Account Managerrel, aki főleg a pénzügyekért, illetve az ügyfél kapcsolatért felelős. Ő az, aki az ügyfél kapcsolatot kézben tartja az értékesítés szempontjából, azaz, hogy mit és hogyan adunk el. Mi DM-ek pedig abból a szempontból tartjuk a kapcsolatot az ügyféllel, hogy mit és hogyan szállítunk. Más részről együtt dolgozom a humán erőforrás menedzserekkel is, akik azért felelősek, hogy a megfelelő emberek dolgozzanak az egyes projekteken. Együttműködünk a jogi osztállyal, hiszen nagyon sok jogszabály szabályozza azt, hogyan kell dolgozni. Ilyen például a GDPR, vagyis az általános adatkezelési szabályzat. Garantálnunk kell azt, hogy semmilyen személyes adat nem tud kiszivárogni, illetve nincs az adott személy jóváhagyása nélkül felhasználva. Ez komoly kihívást jelent a munkánk során.
Hova lehet eljutni ebben a pozícióban, mi a csúcs?
Mint minden szerepkörben, itt is 5 szint van az EPAM-on belül, a 3-as a senior szint, ahol jelenleg én is vagyok. Az 1-es a csapatvezetőhöz hasonlítható, amikor 5-7 embert vezet valaki szakmailag is és delivery oldalról. Segít döntéseket hozni, fő feladata, hogy maga a fejlesztés egységes koncepció irányában haladjon, mindamellett már az ügyféllel is kapcsolatban áll, de van mellette egy tapasztaltabb DM, aki felügyeli és támogatja a munkáját. Egyes esetekben, főleg, ha kisebb projektekről van szó, az Account Manager látja el ezt a feladatot. Ez tehát a belépő szint. A következő a 2-es szint, ez esetben már több csapat tartozik a DM-hez, az én csapatomban is ilyen szintű DM-ek dolgoznak, ők 2-3 csapatot felügyelnek 15-20 emberrel, napi szinten dolgoznak együtt az ügyfelekkel, azok technikai és üzleti embereivel. Az ő felelősségük már egy nagyságrenddel nagyobb, ők részt vesznek akár szerződéskötéshez kapcsolódó, vagy pénzügyi tevékenységekben is. Úgy, mint egy keretszerződésbe tartozó alszerződések kidolgozása, vagy akár project bővítése új munkákkal, lehetősége felismerése a bővülésre. Ezt követi a Senior szint; 50-100 ember tartozik hozzá. Két fő feladatrész különül el; az egyik a projekt megvalósításához, a tényleges szállításhoz kapcsolódik, a másik pedig az ügyféllel való konzultáció, segítségnyújtás abban, hogy megtalálja azokat a megoldásokat, melyek a jövőbeni problémáira választ adhatnak. Ez utóbbi sokkal inkább üzletileg igényel mély tudást egy-egy speciális területen, például a bankszakmában. A legmagasabb szintek a Director és Senior director, mely már kicsit elszakad a napi projekt munkától, inkább arra fókuszál, hogyan lehet az ügyfeleknek jobb és jobb szolgáltatásokat nyújtani, az üzletet bővíteni.
Milyen képzések állnak ehhez rendelkezésre házon belül, miben kell folyamatosan keresni a fejlődés lehetőségét, hol vannak ezek a pontok?
A DM életpályában sokféle segítséget nyújt az EPAM. Akár már belépő szinten vannak különböző management tréningjeink, de olyanok is, melyek a technikai készségek erősítésére fókuszálnak. Ezt követően pedig egy úgynevezett DM Schoolon keresztül lehet továbblépni, ahol tapasztaltabb DM-ek, Account Managerek, vezető technológiai szereplők és az üzleti élet prominens képviselői tartanak előadásokat és szélesítik a DM-ek látásmódját. 3-as, 4-es szinten a hangsúly már inkább a mentoráláson és a személyes coaching-on van, ezek mentén lehet fejlődni.
Eljutva ezen az úton a jelenlegi pozíciódig, neked mi volt a legnagyobb sikered, mire tekintesz vissza igazán büszkén ebben a pillanatban?
Sok tréninget tartok, mentorálok, így jelenleg számomra a legnagyobb siker az, hogy az elmúlt évben két mentoráltamat is EPAM Impact Award-al jutalmazták. Ez az egyik legjelentősebb elismerés a cégen belül, a több mint 30, 000 EPAM-osnak csupán 3 százaléka dicsekedhet vele. Így nem csoda, hogy ez az egyik legnagyobb büszkeség számomra.
