Karrierlétra-sablon

Szoftverfejlesztői karrierlétra-sablon

Öt szint a Juniortól a Principalig, hat kompetenciában a kód szállításától a csapat fejlesztéséig.

Ingyenes csomag · Bankkártya nélkül

Ez a karrierlétra nagyjából 20–200 fős termékcégeknek készült: a fejlesztők elejétől a végéig maguk szállítják a funkciókat, a csapatok kicsik, és nincs HR-es, aki munkakör-struktúrát dolgozna ki. Öt szintet ír le, a pályája elején járó kollégától addig, aki az egész cég technikai irányát alakítja. A legfelső szint, a Principal Engineer, szakértői szint; a fejlesztők vezetését a külön fejlesztési vezetői karrierlétra írja le.

Minden szintet az határoz meg, amit az ember csinál, nem a szakmában töltött évek száma. A kompetenciamátrix egy sorát balról jobbra olvasva látod, hogyan nő egy elvárás; egy szint szakaszát olvasva egyben látod mindazt, amit azon a szinten elvárnak. Használd arra, hogy elmagyarázd, mit jelent a következő szint, hogy keretet adj az önértékeléseknek és a check-ineknek, és hogy az előléptetési javaslatok a csapatok között is összevethetők legyenek.

Tekintsd kiindulópontnak. Nevezd át a szinteket a nálatok használt titulusokra, vond össze vagy hagyd ki azokat a kompetenciákat, amelyek nem illenek a cégetekhez, és írd át az elvárásokat a saját szavaitokkal, mielőtt közzéteszed a karrierlétrát a csapatnak.

A szintek áttekintése

Junior fejlesztő
Megismeri a kódbázist, és útmutatással elvégzi a jól körülhatárolt feladatokat.
Hatókör
Egyedi feladatok a termék egy területén, amelyeket általában egy tapasztaltabb kolléga bont le.
Medior fejlesztő
Önállóan szállít funkciókat, és a csapat megbízható tagja.
Hatókör
Kis és közepes funkciók egy csapat területén belül, a rövid tervezési jegyzettől az éles környezetig.
Senior fejlesztő
Nagyobb munkákat vezet, és emeli a körülötte dolgozó csapat színvonalát.
Hatókör
Több szolgáltatáson vagy több emberen átívelő projektek, és egy csapat technikai döntései.
Staff Engineer
Csapathatárokon átnyúló problémákat old meg, és egy csapatnál tágabb körben irányítja a technikai döntéseket.
Hatókör
Több csapat vagy egy teljes termékterület, azokkal a problémákkal együtt, amelyek egyetlen csapathoz sem tartoznak.
Principal Engineer
Kijelöli a cég technikai irányát, és felel a hosszú távú technikai egészségéért.
Hatókör
A teljes fejlesztési szervezet és a cég technikai stratégiája a következő néhány évre.

Kompetenciamátrix

Minden sor egy kompetencia, minden oszlop egy szint. Olvass végig egy sort balról jobbra, és látod, hogyan nőnek az elvárások.

Mit jelentenek az egyes kompetenciák

Fejlesztés és szállítás: A követelmények működő, karbantartható szoftverré alakítása, és eljuttatása a felhasználókhoz.
Rendszertervezés: Olyan struktúrák, interfészek és kompromisszumok kiválasztása, amelyek a termék növekedésével is megállják a helyüket.
Minőség és megbízhatóság: A termék helyes, megfigyelhető és elérhető állapotban tartása, és tanulás a hibákból.
Együttműködés és kommunikáció: Hatékony munka más fejlesztőkkel, a termékes és a dizájnos kollégákkal és az üzlet többi részével.
Felelősségvállalás és termékhatás: Annak megértése, miért fontos a munka, és felelősségvállalás az eredményekért, nem csak a feladatokért.
Mentorálás és csapatfejlesztés: Segíteni másoknak a fejlődésben, és erősebbé tenni a csapatot bármelyik tagjánál egyedül.

Szoftverfejlesztő: elvárások kompetencia és szint szerint
Kompetencia	Junior fejlesztő	Medior fejlesztő	Senior fejlesztő	Staff Engineer	Principal Engineer
Fejlesztés és szállítás	Jól körülhatárolt feladatokat old meg olvasható kóddal és tesztekkel, ha elakad, néhány óra és nem néhány nap után kér segítséget, és a merge előtt kezeli a review-megjegyzéseket.	Egy funkciót kézen fogás nélkül visz végig a rövid tervezési jegyzettől az éles környezetig, könnyen átnézhető pull requestekre bontja, és ismerős munkára reális becslést ad.	Több szolgáltatáson vagy közreműködőn átívelő projekteket szállít, úgy ütemezi a munkát, hogy valami hasznos már korán kikerüljön, és még azelőtt elhárítja a kockázatokat, hogy megakasztanák a csapatot.	Csapatokon átívelően hárítja el a szállítás akadályait: kibogozza a közös függőségeket, elkészíti a több csapatnak szükséges eszközöket vagy levezényli a migrációkat, és sínen tartja a több csapatot érintő projekteket.	Alakítja, hogyan szállít a teljes szervezet – kiadási gyakorlatok, platformválasztások, build- és telepítési eszközök –, hogy minden csapat gyorsabban és biztonságosabban szállítson.
Rendszertervezés	Követi a kódbázis meglévő mintáit, és el tudja magyarázni, miért olyan a szerkezete annak a kódnak, amelyet módosított.	Komponenseket tervez egy meglévő szolgáltatáson belül, a nem triviális változtatásokhoz rövid tervezési jegyzetet ír, és legalább két lehetőséget összevet, mielőtt választ.	Vezeti a több szolgáltatáson átívelő funkciók tervezését, leírja a kompromisszumokat, hogy mások átnézhessék, és építő módon véleményezi más fejlesztők terveit.	Csapathatárokon átívelő architektúrát határoz meg – közös adatmodellek, szolgáltatásszerződések, saját fejlesztés vagy vásárlás –, és előre látja, hogyan kell változnia a rendszernek a következő egy-két évben.	Gazdája a cég technikai stratégiájának: mely technológiákra érdemes fogadni, melyeket kell kivezetni, és hogyan fejlődjön az architektúra az üzlettel együtt az elkövetkező években.
Minőség és megbízhatóság	Teszteket ír a saját változtatásaihoz, kiadás előtt ellenőrzi a munkáját, és kijavítja a hibákat abban a kódban, amelyhez hozzányúlt.	Monitorozást és riasztásokat ad az általa épített funkciókhoz, részt vesz az ügyeleti beosztásban, és a runbook alapján kezeli a rutinincidenseket.	Vezeti az incidenskezelést a csapat rendszereiben, hibáztatásmentes post-mortemeket ír, és gondoskodik róla, hogy a vállalt utólagos teendők valóban elkészüljenek.	Felderíti a rendszereken átívelő megbízhatósági és biztonsági kockázatokat, szabványokat állít fel, például a tesztelési stratégiát és a szolgáltatásszint-célokat (SLO), és csapatokon átívelően végigviszi a javításokat.	Meghatározza, mit jelent a cég számára a megbízhatóság, a biztonság és a minőség, a vezetőséggel együtt egyensúlyt teremt köztük és a sebesség között, és ő a végső eszkalációs pont a legnehezebb incidenseknél.
Együttműködés és kommunikáció	Nyíltan megosztja, hol tart és mi akadályozza, és világos kérdéseket tesz fel, ha egy követelmény nem egyértelmű.	Közvetlenül a termékes és dizájnos kollégákkal tisztázza a követelményeket, közérthetően elmagyarázza a technikai korlátokat, és olyan pull request-leírásokat ír, amelyeket a reviewerek könnyen követnek.	Képviseli a csapatot a tervezésben, a termékoldallal egyezteti a hatókört és a kompromisszumokat, és olyan dokumentumokat ír, amelyeket a fejlesztésen kívüliek is megértenek.	Több csapatot és funkciót hangol össze egy technikai terv mentén, feloldja a csapatok közötti nézeteltéréseket, és elmagyarázza a technikai kockázatokat a vezetőségnek.	Megbízható hang a cégszintű döntésekben, az üzleti stratégiát technikai irányra fordítja le és vissza, és szükség esetén képviseli a fejlesztést az ügyfelek, a partnerek vagy a befektetők előtt.
Felelősségvállalás és termékhatás	Érti a feladatai célját, ellenőrzi, hogy amit kiadott, működik-e a felhasználóknak, és addig foglalkozik vele, amíg nem működik.	Az indulás után is gazdája egy funkciónak: figyeli a használatát és a hibáit, kijavítja, ami elromlik, és a tapasztalatai alapján fejlesztéseket javasol.	Elejétől a végéig gazdája a termék egy területének, megkérdőjelezi azokat a követelményeket, amelyek nem szolgálják a felhasználókat, és olyan munkát javasol, amely előreviszi a csapat céljait.	Felkutatja a legnagyobb hatású problémákat egy termékterületen – azokat is, amelyeket egyik csapat sem vállalt magára –, és gondoskodik a megoldásukról.	Összeköti a fejlesztésbe tett befektetéseket a cég eredményeivel, és a nagy tétek mellett vagy ellen azok technikai és üzleti hatása alapján érvel.
Mentorálás és csapatfejlesztés	Visszajelzést kér és él vele, és leírja, amit megtanult, hogy a következő új kollégának könnyebb legyen a kezdés.	Alapos code review-kat végez, segít beilleszkedni az új csapattagoknak, és párban dolgozik a junior fejlesztőkkel a kód számukra ismeretlen részein.	Tudatosan mentorál egy-két fejlesztőt, olyan visszajelzést ad nekik, amely segít elérni a következő szintet, és részt vesz a felvételi interjúkon.	Csapatokon átívelően fejleszti a senior fejlesztőket, alakítja a felvételi folyamatot és a fejlesztési gyakorlatokat, és mások kifejezetten hozzá fordulnak tanácsért.	Felépíti a cég technikai kultúráját – hogyan születnek a döntések, és hogyan áramlik a tudás –, és kineveli a staff engineerek következő generációját.

Görgesd oldalra a táblázatot, hogy minden szintet láss.

Letöltés CSV-ben Megnyitható Excelben, Google Táblázatokban vagy Numbersben.

Junior fejlesztő: mit várunk el

Megismeri a kódbázist, és útmutatással elvégzi a jól körülhatárolt feladatokat. Egyedi feladatok a termék egy területén, amelyeket általában egy tapasztaltabb kolléga bont le.

Fejlesztés és szállítás: Jól körülhatárolt feladatokat old meg olvasható kóddal és tesztekkel, ha elakad, néhány óra és nem néhány nap után kér segítséget, és a merge előtt kezeli a review-megjegyzéseket.
Rendszertervezés: Követi a kódbázis meglévő mintáit, és el tudja magyarázni, miért olyan a szerkezete annak a kódnak, amelyet módosított.
Minőség és megbízhatóság: Teszteket ír a saját változtatásaihoz, kiadás előtt ellenőrzi a munkáját, és kijavítja a hibákat abban a kódban, amelyhez hozzányúlt.
Együttműködés és kommunikáció: Nyíltan megosztja, hol tart és mi akadályozza, és világos kérdéseket tesz fel, ha egy követelmény nem egyértelmű.
Felelősségvállalás és termékhatás: Érti a feladatai célját, ellenőrzi, hogy amit kiadott, működik-e a felhasználóknak, és addig foglalkozik vele, amíg nem működik.
Mentorálás és csapatfejlesztés: Visszajelzést kér és él vele, és leírja, amit megtanult, hogy a következő új kollégának könnyebb legyen a kezdés.

Medior fejlesztő: mit várunk el

Önállóan szállít funkciókat, és a csapat megbízható tagja. Kis és közepes funkciók egy csapat területén belül, a rövid tervezési jegyzettől az éles környezetig.

Fejlesztés és szállítás: Egy funkciót kézen fogás nélkül visz végig a rövid tervezési jegyzettől az éles környezetig, könnyen átnézhető pull requestekre bontja, és ismerős munkára reális becslést ad.
Rendszertervezés: Komponenseket tervez egy meglévő szolgáltatáson belül, a nem triviális változtatásokhoz rövid tervezési jegyzetet ír, és legalább két lehetőséget összevet, mielőtt választ.
Minőség és megbízhatóság: Monitorozást és riasztásokat ad az általa épített funkciókhoz, részt vesz az ügyeleti beosztásban, és a runbook alapján kezeli a rutinincidenseket.
Együttműködés és kommunikáció: Közvetlenül a termékes és dizájnos kollégákkal tisztázza a követelményeket, közérthetően elmagyarázza a technikai korlátokat, és olyan pull request-leírásokat ír, amelyeket a reviewerek könnyen követnek.
Felelősségvállalás és termékhatás: Az indulás után is gazdája egy funkciónak: figyeli a használatát és a hibáit, kijavítja, ami elromlik, és a tapasztalatai alapján fejlesztéseket javasol.
Mentorálás és csapatfejlesztés: Alapos code review-kat végez, segít beilleszkedni az új csapattagoknak, és párban dolgozik a junior fejlesztőkkel a kód számukra ismeretlen részein.

Senior fejlesztő: mit várunk el

Nagyobb munkákat vezet, és emeli a körülötte dolgozó csapat színvonalát. Több szolgáltatáson vagy több emberen átívelő projektek, és egy csapat technikai döntései.

Fejlesztés és szállítás: Több szolgáltatáson vagy közreműködőn átívelő projekteket szállít, úgy ütemezi a munkát, hogy valami hasznos már korán kikerüljön, és még azelőtt elhárítja a kockázatokat, hogy megakasztanák a csapatot.
Rendszertervezés: Vezeti a több szolgáltatáson átívelő funkciók tervezését, leírja a kompromisszumokat, hogy mások átnézhessék, és építő módon véleményezi más fejlesztők terveit.
Minőség és megbízhatóság: Vezeti az incidenskezelést a csapat rendszereiben, hibáztatásmentes post-mortemeket ír, és gondoskodik róla, hogy a vállalt utólagos teendők valóban elkészüljenek.
Együttműködés és kommunikáció: Képviseli a csapatot a tervezésben, a termékoldallal egyezteti a hatókört és a kompromisszumokat, és olyan dokumentumokat ír, amelyeket a fejlesztésen kívüliek is megértenek.
Felelősségvállalás és termékhatás: Elejétől a végéig gazdája a termék egy területének, megkérdőjelezi azokat a követelményeket, amelyek nem szolgálják a felhasználókat, és olyan munkát javasol, amely előreviszi a csapat céljait.
Mentorálás és csapatfejlesztés: Tudatosan mentorál egy-két fejlesztőt, olyan visszajelzést ad nekik, amely segít elérni a következő szintet, és részt vesz a felvételi interjúkon.

Staff Engineer: mit várunk el

Csapathatárokon átnyúló problémákat old meg, és egy csapatnál tágabb körben irányítja a technikai döntéseket. Több csapat vagy egy teljes termékterület, azokkal a problémákkal együtt, amelyek egyetlen csapathoz sem tartoznak.

Fejlesztés és szállítás: Csapatokon átívelően hárítja el a szállítás akadályait: kibogozza a közös függőségeket, elkészíti a több csapatnak szükséges eszközöket vagy levezényli a migrációkat, és sínen tartja a több csapatot érintő projekteket.
Rendszertervezés: Csapathatárokon átívelő architektúrát határoz meg – közös adatmodellek, szolgáltatásszerződések, saját fejlesztés vagy vásárlás –, és előre látja, hogyan kell változnia a rendszernek a következő egy-két évben.
Minőség és megbízhatóság: Felderíti a rendszereken átívelő megbízhatósági és biztonsági kockázatokat, szabványokat állít fel, például a tesztelési stratégiát és a szolgáltatásszint-célokat (SLO), és csapatokon átívelően végigviszi a javításokat.
Együttműködés és kommunikáció: Több csapatot és funkciót hangol össze egy technikai terv mentén, feloldja a csapatok közötti nézeteltéréseket, és elmagyarázza a technikai kockázatokat a vezetőségnek.
Felelősségvállalás és termékhatás: Felkutatja a legnagyobb hatású problémákat egy termékterületen – azokat is, amelyeket egyik csapat sem vállalt magára –, és gondoskodik a megoldásukról.
Mentorálás és csapatfejlesztés: Csapatokon átívelően fejleszti a senior fejlesztőket, alakítja a felvételi folyamatot és a fejlesztési gyakorlatokat, és mások kifejezetten hozzá fordulnak tanácsért.

Principal Engineer: mit várunk el

Kijelöli a cég technikai irányát, és felel a hosszú távú technikai egészségéért. A teljes fejlesztési szervezet és a cég technikai stratégiája a következő néhány évre.

Fejlesztés és szállítás: Alakítja, hogyan szállít a teljes szervezet – kiadási gyakorlatok, platformválasztások, build- és telepítési eszközök –, hogy minden csapat gyorsabban és biztonságosabban szállítson.
Rendszertervezés: Gazdája a cég technikai stratégiájának: mely technológiákra érdemes fogadni, melyeket kell kivezetni, és hogyan fejlődjön az architektúra az üzlettel együtt az elkövetkező években.
Minőség és megbízhatóság: Meghatározza, mit jelent a cég számára a megbízhatóság, a biztonság és a minőség, a vezetőséggel együtt egyensúlyt teremt köztük és a sebesség között, és ő a végső eszkalációs pont a legnehezebb incidenseknél.
Együttműködés és kommunikáció: Megbízható hang a cégszintű döntésekben, az üzleti stratégiát technikai irányra fordítja le és vissza, és szükség esetén képviseli a fejlesztést az ügyfelek, a partnerek vagy a befektetők előtt.
Felelősségvállalás és termékhatás: Összeköti a fejlesztésbe tett befektetéseket a cég eredményeivel, és a nagy tétek mellett vagy ellen azok technikai és üzleti hatása alapján érvel.
Mentorálás és csapatfejlesztés: Felépíti a cég technikai kultúráját – hogyan születnek a döntések, és hogyan áramlik a tudás –, és kineveli a staff engineerek következő generációját.

Hogyan igazítsd a saját cégedhez

Igazítsd a szinteket a titulusaitokhoz
Ha nálatok a titulusok Developer I, II és III, nevezd át a szinteket, de minden valódi hatóköri lépcsőhöz egy szint tartozzon. A legtöbb 100 fejlesztőnél kisebb cégnek még nincs szüksége Principal szintre: hagyd ki, amíg valaki ténylegesen el nem kezdi végezni ezt a munkát.
Maradj öt–hét kompetenciánál
Hétnél többet senki sem olvas el; négynél kevesebbel nagyon különböző emberek is egyformának tűnnek. Vond össze azokat a kompetenciákat, amelyeket mindig együtt értékeltek, és csak akkor vegyél fel újat, ha az egy valódi döntést megváltoztatna.
Írd át az elvárásokat látható dolgokká
Minden cellánál kérdezd meg: tudna-e egy vezető példát mutatni rá az elmúlt hat hónapból? Az olyan szavakat, mint az „erős” vagy a „mély”, cseréld arra, amit az illető ténylegesen csinál, például „vezeti az incidenskezelést a csapat szolgáltatásaiban”.
Próbáld ki valódi embereken, mielőtt közzéteszed
Kérj meg két-három vezetőt, hogy helyezzék el a csapattagjaikat a vázlaton. Ahol nem értenek egyet, ott a megfogalmazás kétértelmű: javítsd ki, tedd közzé a karrierlétrát, és állapodjatok meg, hogy hat hónap múlva újra átnézitek.

GYIK

Kérdések erről a létráról

Hány szintje legyen egy szoftverfejlesztői karrierlétrának?

Egy 20–200 fős cégnél négy–hat szint a jellemző. Kevesebb szintnél az előléptetés ritka és óriási ugrás; többnél két szint között túl kicsi a különbség ahhoz, hogy le lehessen írni. Ez a sablon ötöt használ: Junior fejlesztő, Medior fejlesztő, Senior fejlesztő, Staff Engineer és Principal Engineer.

Vezetővé kell válnia egy fejlesztőnek ahhoz, hogy fejlődjön?

Nem. Ez a karrierlétra a szakértői karrierutat írja le: a Staff és a Principal Engineerek hatóköre és befolyása úgy nő, hogy nem vezetnek embereket. Használd a fejlesztési vezetői karrierlétrával együtt, hogy a vezetői szerepbe lépés karrierútváltás legyen, ne előléptetés.

Hogyan használjuk a fejlesztői karrierlétrát az előléptetési döntésekhez?

Azokat léptesd elő, akik már következetesen a következő szinten dolgoznak, ne azokat, akik talán képesek lennének rá. Kérd meg az érintettet és a vezetőjét, hogy a célszint minden kompetenciájához gyűjtsenek konkrét példákat, és minden esetet ugyanahhoz a mátrixhoz mérj, hogy a döntések a csapatok között is következetesek maradjanak.

Hogyan illeszkedik a karrierlétra a check-inekbe és az 1:1-ekbe?

Használd a rendszeres check-inek napirendjeként: az illető értékeli magát a jelenlegi szintjéhez mérve, a vezető ugyanezt teszi, és a kettő közötti eltérésekből néhány konkrét fejlődési feladat lesz a következő hónapokra.

Milyen gyakran frissítsük a fejlesztői karrierlétrát?

Évente egyszer-kétszer nézd át, és akkor is, amikor a cég szerkezete megváltozik – például amikor platformcsapatot hoztok létre, vagy elkezdtek staff engineereket felvenni. Írj át minden olyan cellát, amelyen az értékelések újra meg újra elakadnak.

Építsd fel ezt a karrierlétrát a LadderKitben – ingyen

Állítsd be a szintjeit és készségeit a csapatodnak, mérd hozzájuk az embereket a check-ineken, és tartsd következetesen az előléptetési döntéseket.

Kezdd el ingyen Próbáld ki a demót Regisztráció nélkül