Már 15 évvel ezelőtt is komoly viták voltak arról, inkább tapasztalt vagy inkább kezdő programozókat alkalmazzunk-e, illetve hogyan osszuk fel a munkát tapasztalt és kezdő munkatársak között. Most ezt a témát fejteném ki egy kicsit bővebben.

Már 15 évvel ezelőtt is komoly viták voltak arról, inkább tapasztalt vagy inkább kezdő programozókat alkalmazzunk-e, illetve hogyan osszuk fel a munkát tapasztalt és kezdő munkatársak között. Most ezt a témát fejteném ki egy kicsit bővebben.

A témát a Hogyan válasszuk szét a fejlesztést és a támogatást? című cikk kapcsán vetette fel BPéter.

A félreértések elkerülése végett érdemes tisztázni a legelején: ez bizonyos fokig hitvita. A munkát többféleképpen lehet szervezni, több különböző modell létezik. A külső körülmények is jelentősen befolyásolhatják, hogy melyik az optimális megoldás. Ilyen például, hogy milyen a cég HR politikája (inkább piaci ár felett profikat vesznek fel, hogy inkább piaci ár alatt kezdőket), mekkora szeletet hasít ki az IT a céges kasszából (az IT-t az innováció motorjának vagy szükséges rossznak tekintik) vagy az adott iparág (nem mindegy, hogy web oldalt fejlesztünk egy biztosítónak vagy lélegeztető gépet egy korháznak).

Ugyanazon iparágon belül is többféle cég, többféle cégkultúra és többféle munkaszervezés létezik. Éppen ezért egyértelmű recept vagy azonosan mindenhol alkalmazott módszer nincs.

Megpróbálom összeszedni a legjobb gyakorlatokat, de bizonyosan sok szubjektív elem lesz. Kérek mindenkit, tekintse e cikket gondolatébresztőnek, és ne alkalmazandó szabványnak.

Mint a bevezetőben említettem, a téma egyidős az IT iparággal. Fejlesztő és fejlesztő nem ugyanolyan: ha másban nem, a tudásukba és a tapasztalati szintjükben eltérnek. Amint a szoftverfejlesztés furcsa hobbiból munkává vált, azóta keresik a vállalatvezetők, hogyan lehetne az informatikai munkát hatékonyabban szervezni és hogyan lehet a különböző feladatokat szétosztani a szakemberek között.

Három alapproblémát kell kezelni:

1) A tapasztalt fejlesztő drága

2) Nem minden feladathoz van szükség tapasztalt szakemberre

3) Más a motivációja a tapasztalt és a kezdő programozónak

Az első pont szokott a cégvezetőknek és pénzügyi vezetőknek fájni a legjobban. Elméletileg megtehetnénk, hogy az IT csapat minden tagja csupa profi, magasan képzett és mindenhez ért, és akkor a munka biztosan úgy haladna, mint a karikacsapás. Csakhogy a hatékonyságot nem kizárólag a teljesítmény (output) határozza meg, hanem a költségek is – és pazarlás lenne minden feladatra drága profit alkalmazni.

Vannak, akik megteszik, és ennek megfelelő munkakörnyezetet alakítanak ki.

A második pont tény: habár a programozás magasfokú kreatív mérnöki munka, de a programozáshoz kapcsolódik egy csomó olyan feladat, ami se nem magas fokú se nem kreatív, esetleg már nem is mérnöki. Ilyen például a tesztelés, az ügyfél kapcsolattartás, a koordináció, az oktatás, vagy a vizuális design meghatározása. Ezek mind fontos feladatok, de másfajta tudást és más tudásszintet igényelnek. Maga a programozás is szétbontható magas tudásigényű és alacsonyabb tudásigényű feladatokra.

Sőt: a nagyon tapasztalt és jó teljesítő programozókat zavarni szokta, ha alacsony tudásigényű feladatokkal kell az idejüket vesztegetni. Őket a kihívások motiválják.

És itt kapcsolódunk rögtön a harmadik problémához is: az emberek a karrierjük különböző szintjén másképp viselkednek, más feladatokkal lehet őket motiválni. Például egy kezdő programozó még elsősorban tanulni akar és tapasztalatot szerezni, illetve a saját határait próbálgatja – ezért minél több feladatot szeretne kapni. Egy tapasztalt fejlesztőt már nem maga a tanulás, hanem az önmegvalósítás és a kihívások motiválnak – kevesebb munkát szeretne, de azok legyenek komolyak. A kezdő fejlesztő alkalmazkodik és jól tanítható, a tapasztalt fejlesztő viszont már kialakult viselkedéssel/hozzáállással rendelkezik, ami nehezen változtatható.

Attól függően, hogy egy munkakör mennyiben igényli a „hozott anyagot” illetve az alkalmazkodást, lehet hogy egy fiatalabb munkatárs alkalmasabb, mint az idősebb.

A tudomány jelenlegi állása szerint a munkaszervezés alapja az, hogy szerepköröket/feladatköröket azonosítunk, illetve munkafolyamatokat építünk. A szoftverfejlesztés egy folyamat mentén történik, ahol a folyamatban különböző szerepkörben lévő munkatársak vesznek részt. Ez igaz akkor is, ha a folyamat maga nem látszik vagy ha az egyéneket a folyamatok fölé helyezzük.

Csak rajtunk áll, hogy szervezzük ezeket a folyamatokat és szerepeket. Megtehetjük például azt, hogy a munkavégzést erősen a folyamathoz kötjük, és akkor kevésbé képzett szakemberek is el tudják végezni a munkát (droid). Vagy ellenkezőleg, építhetünk arra, hogy az egyének átlátják a munkájuk értelmét, és majd megfelelő szituációban megfelelő módon döntenek (agilitás).

A szerepköröket is szervezhetjük úgy, hogy szétválasztjuk a magas tudásigényű és alacsony tudásigényű szerepeket, így meghatározva a kezdő és a tapasztalt programozó feladatkörét.

Többféle felosztás létezik. Például kis cégekre tipikusan jellemző, hogy a fejlesztési feladatot az elejétől a végéig ugyanaz az ember csinálja végig, akinek így sokoldalúnak kell lennie és mindenhez értenie. Vagy éppen ellenkezőleg, egy outsourcing szolgáltatásokra szakosodott nagyvállalatnál a fejlesztésben sok ember vesz részt, mindenki egy adott feladatra specializálódott, és mindenki csak a saját kis munkáját hajtja végre.

Ennyi bevezető után rátérnék a szoftverfejlesztés megszervezésének gyakorlati oldalára.

Amikor egy cég vagy egy szervezet szoftvert fejleszt, akkor tipikusan 4 féle funkcióra lesz szükség:

1) Fejlesztés: Új funkciók kifejlesztésére, ez az amit általában szoftverfejlesztés alatt értünk.

2) Üzemeltetés: A már kifejlesztett és átadott szoftverekben lehetnek hibák illetve lehetnek apró módosítási igények, ezért valakinek a régi kódon is dolgoznia kell.

3) Menedzsment: A fejlesztések összefogása, koordinálása, a szükséges kommunikációs feladatok elvégzése, adminisztráció.

4) Minőségbiztosítás: Tesztelés, dokumentáció, oktatás, auditok, code review, metrikák, stb.

Hova tud beilleszkedni egy kezdő programozó?

Fejlesztés: Itt nagyon jól tud működni a mester-inas páros, azaz a kezdő fejlesztő egy tapasztalt fejlesztő keze alatt dolgozik. A tapasztalt szakember egyrészt elmondja, hogyan kell programozni és mi a célravezető megoldás az adott feladatot illetően, majd ellenőrzi ennek végrehajtását (megfelelő minőségű-e a kód, követi-e a standard-ot, stb)

Üzemeltetés: Az ITIL 3-as felosztását tekintem alapnak, tehát van egy 1. szintű helyi helpdesk a triviális hibák elhárítására, van egy 2. szintű helpdesk (akik a hibák nagy részét megoldják), és van a tapasztalt 3. szint a trükkös hibák elhárítására. A kezdő fejlesztő nagyon jól alkalmazható a 2. szinten. Az üzemeltetés egyébként is erősen folyamat orientált, ami segíti egy kezdő fejlesztő beilleszkedését.

Menedzsment: Ez tipikusan az a terület, ahol nagy tapasztalat szükséges. Egy kezdő informatikus számára kevés munka van.

Minőségbiztosítás: A legtöbb esetben csak józan paraszti észre és az alapok ismeretére van szükség. Egy pályakezdő is tud ezen a területen értékes munkát végezni, feltételezve persze azt, hogy valahol a pályakezdők csapata mögött van egy profi is, akitől szükség esetén kérdeznek.

Hova érdemes rakni kezdő informatikusokat?

Szigorúan saját vélemény követezik.

Az abszolút kezdők számára (pl. gyakornok) nagyon jó indulási terület a minőségbiztosítás – itt megismerhetik a cég előírásait, folyamatait és szervezeti felépítését. Olyan ez, mint amikor a szakács-jelölt az elején krumplit pucol, a fazékhoz nem nyúl.

Kezdő informatikusokat semmiképpen ne rakjunk menedzsment területre (kivéve a menedzser asszisztens, kivétel erősíti a szabályt).

Mind az üzemeltetés, mind az új fejlesztés olyan terület, ahol egy kezdő sokat tanulhat és megfelelő kihívásokat talál. Eljutottunk a nagy kérdéshez: hova érdemes inkább kezdő és hova inkább tapasztalt fejlesztőket tenni?

Mindkét terület olyan, hogy a kezdők segítség nélkül nem fognak boldogulni (és kárt okoznak a cégnek). A fejlesztési területen szükség van egy architekt-re, aki átlátja a szoftver-architektúrát és ezért meg tudja mondani a fejlesztőknek, hogyan kell egy adott új funkciót megvalósítani a szoftver konzisztenciájának megzavarása nélkül. Az üzemeltetési területen pedig szükség van arra a bizonyos 3. szintre, a profikra, akik a trükkös hibáknak utánamennek és megoldják azokat.

Na jó, de melyik területen alkalmazhatóak a kezdők nagyobb számban, és hova kellenek a profik?

Folyamatszervezés oldaláról nézve a szoftver üzemeltetés, a hibajavítás jól megszervezhető. A hibák kategorizálhatók, a tipikus hibákra tipikus megoldások adhatók. A hibák nagy részét egy kevéssé képzett programozó is ki tudja javítani.

Sőt továbbmegyek, ez a tevékenység ki is szervezhető. A managed contract vagy performance contract azon alapul, hogy a hibák tipikusak lesznek, adott idő alatt adott módon kijavíthatóak – és ehhez nincs szükség atomfizikusra. Lesznek kivételek, de azt az 5%-nyi „egyéb” hibát majd kezeljük valahogyan.

Ezzel szemben az új fejlesztések nehezen kategorizálhatók és nehezen tipizálhatók. Lehet, hogy egy igény pár sor kód beszúrásával megvalósítható, miközben a másik igényhez a program jelentős részét át kel írni.

Ezek alapján sokan vannak, akik szerint a kezdőket rakjuk az üzemeltetésre, a profik pedig írják az új feature-ket.

A személyes véleményem ennek pont az ellenkezője. A gondolatmenet ugyanis hibás – rossz volt a nézőpont. Nem az a kérdés, hogy melyik munka sztenderdizálható, hanem az, hogy mi kell az ügyfélnek. Bárki bármit mond, de az ügyfél számára a jól működő program (azaz a hibajavítás) fontosabb, mint az új funkciók. A felhasználók azonnal lemondanának bármilyen új fejlesztési igényükről, ha cserébe a beígért és leszállított funkciók úgy működnek, ahogyan azoknak kellene.

Egy rosszul működő vagy lassú üzemeltetés óriási kárt okoz. Nem csak az ügyfélnek, hanem saját maguknak: a hibajavítás sok időt vesz el és újabb hibákat generál.

Végül pedig nézzük a kérdést a hatékonyság szempontjából. Akkor dolgozunk hatékonyan, ha minél kevesebbet kell a vezető fejlesztőnek a kezdők munkáit bogarászni, és ha minden javítás elsőre sikerül. Ha hibajavításra rakunk kezdő fejlesztőket, akkor annak ára lesz: a tapasztalt fejlesztők idejük nagy részében ezzel kell foglalkozniuk. A kezdő fejlesztő félreérti a hibát, rossz okot próbál meg kijavítani, stb. Majdnem annyit fognak a vezető fejlesztők foglalkozni ezzel, mintha ők maguk javítanák ki a hibát.

Konkrétan: amíg egy új feature fejlesztésénél elég az új design-t nagy vonalakban egyeztetni és pusztán iránymutatást adni, addig egy hiba kijavításánál minden apró részletre oda kell figyelni.

Minél inkább igyekszik a vezető fejlesztő távolabbra helyezkedni a hibajavítástól, annál több lesz a rossz kommunikáció, a félreértés és a regressziós hiba. Akkor pedig már lehet, hogy összességében jobban járunk, ha a profikat eleve erre a területre orientáljuk.

Egy kezdő programozónak milyen lehetséges karrierútjai vannak?

Az alkalmazás üzemeltetési és az új fejlesztési munka szakmai szempontból nagyon hasonló, ezért azok kvázi azonosnak tekinthetők. (Kivéve persze azt a tényt, ha valaki projekt munkára jelentkezik, akkor korábbi projekt munka előnyt jelent.)

Aki elindult a programozási vonalon, az általában nem szívesen megy minőségbiztosítási vonalra. Ennek ellenkezőjére sem láttam példát, nem tudom mennyire tipikus (pl amikor valaki tesztelőből „igazi” fejlesztő lesz).

Menedzsmenttel tapasztalt informatikusok foglalkoznak, és igaz az, hogy minőségbiztosítási területről valamiért jobbak az esélyek. Sokkal gyakrabban lesz a tesztelési vezetőből projektvezető, mint a vezető fejlesztőből.

Outsourcing és kezdő fejlesztő

Már több cikkben írtam, hogy az outsourcing káros a fejlesztői karrierútra. Az outsourcing kvázi azt jelenti, hogy a nem tudásigényes (vagyis kezdő) pozíciókat/feladatokat a vállalaton kívülre helyezik. Ez azt jelenti, hogy a vállalaton belül csakis nagy tapasztalatot igénylő pozíciók lesznek, és egy kezdő programozó egész egyszerűen nem fog találni a vállalaton belül állást. Az outsourcing-ra jellemző fluktuáció miatt túlkereslet lesz kezdő informatikusra, miközben a tapasztalatot igénylő pozíciókat fűnyíróval vágják, az ilyen szakemberekből túlkínálat lesz. Még az is előfordulhat, hogy a pályakezdő és a profi hasonló fizetést kap, a megszerzett tudás ellenére.

Mi hát a megoldás? Kezdő vagy inkább tapasztalt fejlesztők?

A válasz az, hogy a vegyes csapat a legjobb.