Manapság komoly fejtörést okoz a HR-eseknek, hogy a fejlesztők még meg sem melegedtek egy helyen, máris továbbállnak. Ilyenkor aztán borulnak a fejlesztési tervek, csúsznak a projektek, mindenki ideges, az üzlet nem halad... Az okok összetettek: van itt generációs jelenség, foglalkoztatáspolitika, egyéni motiváció is. De vannak olyan szervezeti kultúrával, menedzsmenttel összefüggő elemek is, melyek viszonylag könnyen megváltoztathatók, és javítják a dolgozók motiváltságát (ezáltal csökkentik az elvándorlás esélyét).

Egy amerikai szotfvermérnök, stratupper, Michelle Lim (jelenleg a DevOps-támogatáshoz fejlesztett Warp egyik alapító-befektetőjeként fut) egy nagyon egyszerű, mégis a fejlesztési szemléletet alapjaiban átalakító javaslattal állt elő: számoljunk le az egyébként teljesen általános frontend/backend felosztással.

Lim indoklása: ez nem felel meg a fejlesztőmérnökök gondolkodásának. Így sok fejlesztő csak a projekt kellős közepén jön rá, hogy olyan helyre csöppen, ahol semmi keresnivalója. Ez csökkenti a motivációját, így nagyobb a valószínűsége, hogy idő előtt lelép. Arról nem is beszélve, hogy munkájában már nem a legjobb megoldást keresi, hanem megy a legkisebb ellenállás irányába. És mindez végső soron az egész vállalati szervezeten csattan majd.

Gondolkodj termékben és infrastruktúrában

A startupper saját keserű tapasztalatai és néhány szerencsés véletlen nyomán bukkant rá a szerinte üdvözítő megoldásra: legyen a gondolkodás és csapatszervezés tengelye a termék/infrastruktúra felosztás. Ez ugyanis pontosabban leképezi azt a pszichológiai folyamatot, hogy hogyan köteleződik el egy projekt mellett a fejlesztő. Lim tapasztalatai szerint ugyanis a fejlesztőket a feladatok megközelítése szempontjából két alaptípusba lehet sorolni.

1. Vannak az ún. product-first mérnökök, aki úgy állnak egy feladathoz, hogy abban a kód csupán eszköz egy felhasználói probléma megoldására. Ők a termékfejlesztők.

2. És vannak az ún. code-first mérnökök, akik megszállottjai a kódban megformálódó absztrakcióinak. Őket az architektúra, az eszközök, a könyvtárak stb. hozzák izgalomba, és amit el akarnak érni: az elegáns kód (jelentsen az bármit is). Ők az infrastruktúra-fejlesztők.

A product-first fejlesztőket elsősorban maga a probléma érdekli: olyan funkciók létrehozása, bevezetése és karbantartása, melyek megoldást adnak a felhasználó egy adott problémájára. Ők azok, akik szívesen dolgoznak együtt, akár egy szobában is a tervezőkkel és a termékmenedzserekkel, mert kíváncsiak a majdani felhasználóikra. Felhasználói szempontból is proaktívak, az okoz számukra örömöt, ha sikerül egy olyan technikai lehetőséget találni, ami javít az adott termék használhatóságán.

A code-first mérnökök főleg az infrastruktúra-építésben jeleskednek. Szívesen foglalkoznak olyan feladatokkal olyan platformok fejlesztésével, amelyek támogatják az alkalmazásokat (CI/CD pipeline kialakítása, naplózás megvalósítása stb.). Érdeklődésük arra sarkallja őket, hogy folyamatos fejlesszék programozási készségeiket, minden új technológiát megnéznek, és szívesen ki is próbálnak.

Eltűnnek a régi határvonalak?

A szemléletváltás elsősorban a fejlesztőcsapatok kialakítására, a csapaton belüli feladatok elosztására lesz hatással. A frontend/backend felosztás ugyanis nem tűnik el. Ám mindegy, hogy valaki frontendre vagy backendre specializálódik, mindkét helyen vannak termékfejlesztés jellegű (a product-first programozóknak) és infrastruktúra-fejlesztés jellegű (code-first programozóknak) feladatok.

És hogy miért fontos ezen rugózni? Ha valóban komolyan gondoljuk, hogy a lehető legszélesebb körben elérhetővé tesszük a fejlesztőmérnöki munkát, akkor olyan kereteket kell teremtenünk, amely segít az erre a pályára lépőknek megtalálni azt, ahol olyan testhezálló munkát tudnak végezni, ami kielégíti őket. Ez alkalomadtán a hosszabb távú megtartásukban is segíthet.