Hat dolog, amit vezető fejlesztőként tanultam

Júliusban volt »öt éve, hogy az ingatlan.com-nál dolgozom«, és július óta vagyok a fejlesztőcsapat vezetője. A cégen belül sok dolgot láttam már, sok projekten dolgoztam, de a legtöbbet egy csapatban és egy terméken: az ingatlan.com keresőjén. A többnyire ezen dolgozó csapatban nagyjából két évet töltöttem vezető fejlesztőként.

A vezető fejlesztő sok cégnél sok különböző dolgot jelent, nálunk ez nem egy pozíció, hanem egy szerepkör, úgymond sapka: minden csapatban van egy fejlesztő, aki ezt a sapkát viseli, és akinek feladatai a szoftverfejlesztést ezekkel egészítik ki:

• csapattagok szakmai fejlődésének figyelése és segítése,
• fejlesztési feladatok tervezése, összefogása és megvalósítása,
• technológiai akadályok feloldása,
• a termékmenedzser (vagy product owner) támogatása technológiai kérdésekben,
• kódolási irányelvek követésének figyelése,
• az adott termék életútjának egyengetése, karbantartása, valamint
• a hosszútávú technológiai “vízió” kialakítása az architecttel közösen és
• úgy általában a zöld buildek és a sikeres élesítések útjának megteremtése.

Vezető fejlesztőként rengeteg tapasztalatot szereztem, ezeket szeretném most összefoglalni. Ezt eredetileg egy blogbejegyzésnek szántam, de még vázlat korában volt lehetőségem előadni az ELTE Szakmai Esti Mesék eseményén, ahol végül egy előadás lett belőle, most viszont leporoltam a bejegyzés vázlatát is.

A poszt célja egyrészt jegyzet magamnak: amolyan emlékeztető, mivel pár év múlva szeretném visszaolvasni, mi az, amiről esetleg máshogy gondolkodom majd az idők során.

Másrészt azoknak, akiket érdekel ez a terület, vagy csak nemrég léptek erre a pályára, és mivel vezető fejlesztőnek senki sem tanul az iskolában, az irodában pedig furcsa lenne megkérdezni a HR-t, hogy mit hogyan kellene csinálni, talán másnak is hasznos lehet.

Ezeken kívül az is érdekel, hogy a különböző cégeknél mit értenek vezető fejlesztő pozíció vagy szerepkör alatt, és ez milyen feladatokkal, tapasztalatokkal, élményekkel jár.

1. Mindig szakíts időt a kódolásra

Sokaktól hallottam, sok helyen láttam már, hogy a vezető fejlesztő ritkán nyúl kódhoz, inkább kiosztja a feladatokat, tervez, megbeszélésekre jár.

Munkahelye és projektje válogatja, a saját tapasztalatom az, hogy mindig kell időt találni arra, hogy a konkrét fejlesztési feladatokhoz is hozzáférj. Lesz olyan sprint, időszak, projekt, amikor erre a tervezések és egyeztetések miatt nem került sor, de az esetek többségében én is a tűz közelében mozogtam.

Azért is fontos ez, mert ha nem kódolsz, kiesel a körforgásból, kiesnek a fejedből a mindennapi rutin dolgok és úgy általában véve kevesebb vagy előnytelenebb rálátásod lesz a fejlesztett rendszer állapotára, annak problémáira vagy mondjuk a folyamatok hiányosságaira. Az új technológiákról nem is beszélve.

A pozíció nevében is benne van, hogy vezető fejlesztő (vagy lead dev, tech lead, szenior fejlesztő stb.), így a saját fejlődésednek is fontos, hogy gyakran láss kódot, még ha idővel jóval kevesebb lehetőséged is van erre, mint korábban, és ha a feladataid 50%-a valóban nem a kódolásból áll.

2. Tudj nemet mondani

Elsőre biztosan hülyén hangzik, mivel “nemet mondani” egyszerűnek tűnik, meg akár nem is olyan dolognak, amiről triviális egy ilyen bejegyzésben olvasni, de valójában nem ez a helyzet.

Öt éve mindenre igent mondtam. Minden nyomorult feladatot bevállaltam, függetlenül attól, hogy mennyire volt nehéz vagy körülményes, mert fejlődni szerettem volna, illetve egyértelműen jelezni, hogy nekem nem büdös a munka, hadd jöjjön bármi.

Különösen a pályafutásod elején ez egy rendkívül hasznos és jó hozzáállás, számtalan előnye van, például, hogy szélesebb körben megismerheted a rendszert, amin dolgozol és látsz egy-két rázósabb feladatot is. De ha eljutsz oda, hogy néhány területnek már ténylegesen a szakértője, akár felelőse vagy, nem csak bevállaod a hozzá tartozó feladatokat jófejségből, akkor néha kell az erős nem:

• nem, ez a fejlesztés tényleg nem oldható meg olcsóbban, mert össze fogjuk csapni, és később sok baj lesz vele vagy drágább lesz a fenntartása, módosítása,
• nem, ezt a fejlesztést tényleg meg kell előzze egy nagyobb rendrakás-átnézés, mert négy éve senki nem nyúlt a kódhoz,
• nem, most az egyszer sem hagyjuk ki a tesztek megírását, futtatását,
• nem, nekem erre most tényleg nincs időm, kérlek, keress meg mást és
• nem, erre nem tudok válaszolni azonnal, szeretném jobban átnézni, megérteni a kérdésedet.

Félre ne értsen senki, nem azt akarom mondani, hogy mindent le kell passzolni, de — és hangsúlyozom, főként mint egy vagy több területért felelős szakemberként — igenis fontos, hogy tudj priorizálni, aminek része vagy akár első lépése a nemet mondás és bizonyos feladatok delegálása.

Mint ahogyan az sem ciki, ha valamit nem tudsz. Megintcsak a pályafutása elején hajlamos az ember kellemetlenül érezni magát, ha valamihez nem ért, valamire nem tud válaszolni. Ehhez nagyon érdekes és hasznos olvasmány a Dunning-Kruger-hatás, ami azt is segít megérteni, hogy tapasztaltabb szakemberként miért nem olyan kényelmetlen azt mondanod, hogy nem értesz valamihez: minél többet tudsz egy területről, annál pontosabban látod, hogy mekkora is ez a terület, így azt is pontosabban kezded látni, hogy mekkora részét nem érted. És ez éppen fordítva működik a területtel való ismerkedés elején: egy kevés tudás után már úgy érzed, nincs legyőzhetetlen akadály, mert nem látod át pontosan, mekkora területhez nyúltál.

3. A PO és/vagy a PM a barátod

Product owner, product architect, product manager, project manager, vagy akármi is legyen a pozíció pontos megnevezése.

És nem azért mondom ezt, mert szerencsére csak nagyon jó termékmenedzserekkel dolgoztam együtt, akikkel jóban is voltam, hanem azért, mert ha ezt nem tudod figyelembe venni, akkor a saját véleményem szerint sosem leszel jó vezető fejlesztő, mindig görcsösen fogod kezdeni a napot, nem fogod tudni a csapat érdekeit képviselni és nem lesz meg a kémia a természetéből adódóan mindig egymásnak feszülő üzleti és technológiai felek között.

A legfontosabb, amit látnod kell: a termékmenedzser pontosan ugyanazt csinálja, mint egy fejlesztő. Valóban nem kódol, de ugyanolyan felelőssége van a termék tervezésekor illetve úgy általában az életútjának követésekor. És ő ugyanúgy felelőse annak a terméknek, ugyanúgy beszámol valakinek, ugyanúgy hoznia kell a számokat, így ha egy pl. tényleg keresztfunkcionális scrum csapatban a termék és a kód gazdája nem beszélnek közös nyelvet, tuti, hogy sok lesz a bukott sprint, de ha a sprintek nem is buknak, a termék biztosan sérülni fog.

Ha a termékért és kódért felelős ember közös nyelvet beszélnek, akkor mindketten meg tudják érteni egymás igényeit (ez a feature ezért kell; ezt a kódot ezért kell újraírni stb.) és legalább egy lépéssel közelebb kerülhetnek a sikeres termék- és csapatműködéshez.

4. Új feature tervezésekor az első pillanattól legyél jelen

Munkahelye válogatja, van, ahol alapvetően közös tervezésekkel indul a fejlesztés, mi is ezt az irányt próbáljuk követni.

Ettől függetlenül az apróbb ötleteknél, egyszerűbbnek tűnő fejlesztéseknél is fontos, hogy vezető fejlesztőként ott legyél az első gondolatoktól. Te egy ugyanolyan “stakeholder” vagy, aki a technológia oldaláról érkezik az igényeivel, problémáival és meglátásaival.

Ráadásul nagyon sok helyen látom és tapasztalom, hogy sokszor egy csapat “legszeniorabb” fejlesztője rendelkezik viszonylag nagy termékismerettel, hiszen valószínűleg részt vett a kódok megírásában, karbantartásában.

Sokszor láttam már apróságnak tűnő fejlesztéseket, amik végül háromszor annyi időt vettek igénybe, mert a fejlesztők az utolsó pillanatban lettek bevonva, és kiderült, hogy az, amit az ötlet gazdája egyszerűnek, pár órás feladatnak gondolt, valójában nagyjából kétheti munka, a rendszer tulajdonságaiból adódóan.

És persze, erre vannak a közös tervezések, a scrum, az esztimáció, a sprint planning. Mégis, ha vezető fejlesztőként már az első, szűkebb körben zajló tervezéseknél jelen vagy az észrevételeiddel, tapasztalataiddal, rendszerismereteddel, sokkal könnyebben tudod a fejlesztők nyelvére lefordítani mondjuk az adott sztorit, és nem fogsz belefutni abba, hogy darabjaidra szednek az esztimáció első öt percében. Az üzleti oldal képviselői pedig nagyon hálásak lesznek, hogy ár/érték arányban megfelelő fejlesztéseken dolgozhat a csapat.

5. Tölts időt a csapatoddal

Még ha nem is vagy feltétlenül a közvetlen vezetőjük, fontos, hogy legyen közös időd a csapattal.

Egyrészt a teljes csapatot tekintve (sörözés, szabadulós játék, kirándulás, csak úgy kiülni a teraszra dumálni, valamilyen közös játék, pl. csocsó az irodában, stb.), másrészt egyesével is.

Ha figyelsz az emberekre, és látod az apróbb hangulatbeli ingadozásaikat, ismered a személyiségüket, az neked is segítség, mert azt is észreveszed, ha valami nem halad jól, és ők is örülni fognak, mert nem érzik azt, hogy senki nem foglalkozik velük és a problémáikkal.

És ehhez tényleg nem kell közvetlen vezetőnek lenned. Legyen akármilyen Coelho-i gondolat, a technológiához mindig az embereken át vezet az út, és önmagában csak tech ismeretekkel nem tudsz jó technológiai döntéseket hozni. Legtöbbször egyébként is olyan szoftvereken, termékeken dolgozunk, amelyeket végül emberek fognak használni.

6. Ne legyél ilyen

Igen, te felelsz a technológiáért, de ne csak annak a keretei között gondolkodj. Néha olyan döntést is hoznod kell, hogy egy adott fejlesztésnél erősebben veszed figyelembe az üzleti oldal szempontjait, mint a technológiai aspektusokat.

Biztos láttál már olyan feladatot, ami tegnapra kell, cserébe jól össze lett kuszálva a megvalósítás. Mindig lehet találni arany középutat, amikor egy olyan megoldás születik, amivel még a fejlesztők is együtt tudnak élni, és a PM-ek sem kapnak infarktust a vállalt határidőtől, fejlesztési költségtől.

Ilyenkor a PM ismét a barátod: ha bevállalsz valamit, amiről tudod, hogy szakmailag “azért szebben is lehetett volna, ha lett volna idő”, alkudj lehetőséget annak is, hogy később legyen idő rendet rakni. Erre mindig figyelj, mert ha ez nincs egyensúlyban, akkor sorra születnek a technológiai adósságok, amiket évek múltán sokkal nehezebb lesz kirobbantani a rendszerből.

Tudnék még nagyjából nyolc-tíz dolgot írni, de szokásomhoz híven így is hosszabb a bejegyzés, mint amit a legtöbben elolvasnának, és a szerintem nagyon fontos dolgokat összeszedtem.

Vezető fejlesztő, tech lead, lead dev vagy bármi olyan megnevezésű pozícióban dolgozol, és ismerősek a sztorik? Esetleg nem értesz egyet valamelyik ponttal? Vagy csak dolgozol együtt ilyen emberrel? Megosztanád a tapasztalataidat? Király, tekerj kicsit lejjebb, és írj bátran!

A borítóképet az októberi hackathonunk során lőttem és kollégáim szerepelnek rajta.