Karjeras kāpņu veidne

Programmatūras izstrādātāja karjeras kāpņu veidne

Pieci līmeņi no jaunākā izstrādātāja līdz galvenajam inženierim sešās kompetencēs — no koda piegādes līdz komandas izaugsmei.

Sākt bez maksas Lejupielādēt CSV

Bezmaksas plāns · Kredītkarte nav vajadzīga

Šīs karjeras kāpnes ir veidotas produktu uzņēmumiem ar aptuveni 20–200 darbiniekiem: inženieri paši piegādā funkcijas no sākuma līdz galam, komandas ir nelielas, un neviens personāla nodaļā neraksta amatu arhitektūru. Tās apraksta piecus līmeņus — no cilvēka karjeras sākumā līdz cilvēkam, kurš nosaka visa uzņēmuma tehnisko kursu. Augstākais līmenis, galvenais inženieris, ir speciālista līmenis; inženieru vadīšana ir aprakstīta atsevišķās izstrādes vadītāja karjeras kāpnēs.

Katru līmeni nosaka tas, ko cilvēks dara, nevis darba stāžs. Lasiet kompetenču matricas rindu no kreisās uz labo, lai redzētu, kā aug viena prasība; lasiet līmeņa sadaļu, lai vienuviet redzētu visu, kas šajā līmenī sagaidāms. Izmantojiet tās, lai paskaidrotu, ko nozīmē nākamais līmenis, lai strukturētu pašnovērtējumus un check-in sarunas un lai paaugstinājumu pamatojumi būtu salīdzināmi starp komandām.

Uztveriet tās kā sākumpunktu. Pārdēvējiet līmeņus atbilstoši saviem amatu nosaukumiem, apvienojiet vai izņemiet kompetences, kas jūsu uzņēmumam neder, un pārrakstiet prasības saviem vārdiem, pirms publicējat karjeras kāpnes komandai.

Līmeņi īsumā

Jaunākais izstrādātājs
Apgūst koda bāzi un ar atbalstu izpilda skaidri definētus uzdevumus.
Atbildības joma
Atsevišķi uzdevumi vienā produkta daļā, kurus parasti sadala kāds pieredzējušāks kolēģis.
Izstrādātājs
Patstāvīgi piegādā funkcijas un ir uzticams komandas dalībnieks.
Atbildības joma
Mazas un vidējas funkcijas vienas komandas atbildības jomā — no īsa dizaina apraksta līdz produkcijai.
Vecākais izstrādātājs
Vada lielākus darba apjomus un paaugstina apkārtējās komandas standartus.
Atbildības joma
Projekti, kas aptver vairākus servisus vai vairākus cilvēkus, un vienas komandas tehniskie lēmumi.
Vadošais inženieris
Risina problēmas, kas šķērso komandu robežas, un ietekmē tehniskos lēmumus ārpus vienas komandas.
Atbildības joma
Vairākas komandas vai vesela produkta joma, arī problēmas, par kurām neatbild neviena komanda.
Galvenais inženieris
Nosaka uzņēmuma tehnisko kursu un atbild par tā ilgtermiņa tehnisko veselību.
Atbildības joma
Visa inženierijas organizācija un uzņēmuma tehnoloģiju stratēģija nākamajiem gadiem.

Kompetenču matrica

Katra rinda ir kompetence, katra kolonna — līmenis. Lasiet rindu no kreisās uz labo, lai redzētu, kā aug prasības.

Ko nozīmē katra kompetence

Tehniskā izpilde: Prasību pārvēršana strādājošā, uzturamā programmatūrā un tās nogādāšana līdz lietotājiem.
Sistēmu projektēšana: Tādu struktūru, saskarņu un kompromisu izvēle, kas izturēs produkta izaugsmi.
Kvalitāte un uzticamība: Produkta pareizības, novērojamības un pieejamības uzturēšana un mācīšanās no kļūmēm.
Sadarbība un komunikācija: Efektīvs darbs ar citiem inženieriem, produkta un dizaina kolēģiem un pārējo uzņēmumu.
Atbildība un ietekme uz produktu: Izpratne, kāpēc darbs ir svarīgs, un atbildības uzņemšanās par rezultātiem, ne tikai par uzdevumiem.
Mentorings un komandas izaugsme: Palīdzība citiem pilnveidoties un komandas stiprināšana, lai tā būtu spēcīgāka par jebkuru tās dalībnieku.

Programmatūras izstrādātājs: prasības pēc kompetences un līmeņa
Kompetence	Jaunākais izstrādātājs	Izstrādātājs	Vecākais izstrādātājs	Vadošais inženieris	Galvenais inženieris
Tehniskā izpilde	Pabeidz skaidri definētus uzdevumus ar lasāmu kodu un testiem, lūdz palīdzību pēc dažām iestrēgšanas stundām, nevis dienām, un pirms sapludināšanas novērš koda pārskatīšanas komentārus.	Bez pastāvīgas uzraudzības aizved funkciju no īsa dizaina apraksta līdz produkcijai, sadala to viegli pārskatāmos izmaiņu pieprasījumos un sniedz reālistiskus novērtējumus pazīstamam darbam.	Piegādā projektus, kas aptver vairākus servisus vai dalībniekus, sakārto darbu tā, lai kaut kas noderīgs tiktu izlaists jau agri, un novērš riskus, pirms tie bloķē komandu.	Atbloķē piegādi starp komandām: atšķetina kopīgas atkarības, izveido rīkus vai veic migrācijas, kas vajadzīgas vairākām komandām, un notur vairāku komandu projektus pareizā kursā.	Veido to, kā visa organizācija piegādā programmatūru — laidienu praksi, platformu izvēli, būvēšanas un izvietošanas rīkus —, lai katra komanda piegādātu ātrāk un drošāk.
Sistēmu projektēšana	Ievēro koda bāzē esošos modeļus un spēj paskaidrot, kāpēc mainītais kods ir strukturēts tieši tā.	Projektē komponentus esoša servisa ietvaros, netriviālām izmaiņām uzraksta īsu dizaina aprakstu un pirms izvēles salīdzina vismaz divus variantus.	Vada vairākus servisus aptverošu funkciju projektēšanu, pieraksta kompromisus, lai citi tos varētu pārskatīt, un konstruktīvi pārskata citu inženieru risinājumus.	Nosaka arhitektūru pāri komandu robežām — kopīgus datu modeļus, servisu līgumus, lēmumus „būvēt vai pirkt“ — un paredz, kā sistēmai būs jāmainās nākamajā gadā vai divos.	Atbild par uzņēmuma tehnoloģiju stratēģiju: uz kurām tehnoloģijām likt, no kurām atteikties un kā arhitektūrai vairāku gadu laikā attīstīties kopā ar biznesu.
Kvalitāte un uzticamība	Raksta testus savām izmaiņām, pārbauda savu darbu pirms laidiena un labo kļūdas kodā, ko skārušas viņa izmaiņas.	Pievieno monitoringu un brīdinājumus funkcijām, kuras izstrādā, piedalās dežūru grafikā un ikdienišķus incidentus risina pēc rīcības instrukcijām.	Vada incidentu novēršanu komandas sistēmās, raksta pēcincidentu analīzes bez vainīgo meklēšanas un pārliecinās, ka turpmākās darbības tiešām tiek paveiktas.	Atrod uzticamības un drošības riskus, kas aptver vairākas sistēmas, nosaka standartus, piemēram, testēšanas stratēģiju un pakalpojuma līmeņa mērķus, un virza labojumus vairākās komandās.	Nosaka, ko uzņēmumam nozīmē uzticamība, drošība un kvalitāte, kopā ar vadības komandu līdzsvaro tās ar ātrumu un ir pēdējā eskalācijas pakāpe sarežģītākajos incidentos.
Sadarbība un komunikācija	Atklāti stāsta par progresu un šķēršļiem un uzdod skaidrus jautājumus, ja prasība nav skaidra.	Strādā tieši ar produkta un dizaina kolēģiem, lai precizētu prasības, vienkāršā valodā skaidro tehniskos ierobežojumus un raksta izmaiņu pieprasījumu aprakstus, kuriem pārskatītāji var izsekot.	Pārstāv komandu plānošanā, vienojas ar produkta kolēģiem par apjomu un kompromisiem un raksta dokumentus, kurus saprot arī cilvēki ārpus inženierijas.	Saskaņo vairāku komandu un funkciju darbu ap tehnisko plānu, atrisina domstarpības starp komandām un skaidro tehniskos riskus vadībai.	Ir uzticama balss uzņēmuma līmeņa lēmumos, pārvērš biznesa stratēģiju tehniskajā kursā un otrādi un vajadzības gadījumā pārstāv inženieriju klientu, partneru vai investoru priekšā.
Atbildība un ietekme uz produktu	Saprot savu uzdevumu mērķi, pārbauda, vai piegādātais lietotājiem darbojas, un seko līdzi, līdz tas darbojas.	Atbild par funkciju arī pēc palaišanas: seko tās lietojumam un kļūdām, labo to, kas noiet greizi, un iesaka uzlabojumus, balstoties uz gūtajām atziņām.	Pilnībā atbild par kādu produkta jomu, apšauba prasības, kas nekalpo lietotājiem, un ierosina darbu, kas virza komandas mērķus.	Atrod produkta jomā problēmas ar vislielāko atdevi — arī tās, kuras nav uzņēmusies neviena komanda, — un pārliecinās, ka tās tiek atrisinātas.	Sasaista ieguldījumus inženierijā ar uzņēmuma rezultātiem un argumentē par vai pret lielām likmēm, balstoties uz to tehnisko un biznesa ietekmi.
Mentorings un komandas izaugsme	Lūdz atgriezenisko saiti un rīkojas pēc tās, kā arī pieraksta iemācīto, lai nākamajam jaunpienācējam būtu vieglāks sākums.	Rūpīgi pārskata kodu, palīdz ievadīt darbā jaunus komandas biedrus un strādā pārī ar jaunākajiem izstrādātājiem pie nepazīstamām koda daļām.	Mērķtiecīgi mentorē vienu vai divus inženierus, sniedz atgriezenisko saiti, kas palīdz viņiem sasniegt nākamo līmeni, un piedalās darba intervijās.	Attīsta vecākos izstrādātājus vairākās komandās, veido intervēšanas procesu un inženierijas praksi un ir tas, pie kura citi nāk pēc padoma.	Veido uzņēmuma tehnisko kultūru — kā tiek pieņemti lēmumi un kā tiek dalītas zināšanas — un sagatavo nākamo vadošo inženieru paaudzi.

Ritiniet tabulu uz sāniem, lai redzētu visus līmeņus.

Lejupielādēt CSV Atveras programmās Excel, Google Sheets vai Numbers.

Jaunākais izstrādātājs: ko sagaida

Apgūst koda bāzi un ar atbalstu izpilda skaidri definētus uzdevumus. Atsevišķi uzdevumi vienā produkta daļā, kurus parasti sadala kāds pieredzējušāks kolēģis.

Tehniskā izpilde: Pabeidz skaidri definētus uzdevumus ar lasāmu kodu un testiem, lūdz palīdzību pēc dažām iestrēgšanas stundām, nevis dienām, un pirms sapludināšanas novērš koda pārskatīšanas komentārus.
Sistēmu projektēšana: Ievēro koda bāzē esošos modeļus un spēj paskaidrot, kāpēc mainītais kods ir strukturēts tieši tā.
Kvalitāte un uzticamība: Raksta testus savām izmaiņām, pārbauda savu darbu pirms laidiena un labo kļūdas kodā, ko skārušas viņa izmaiņas.
Sadarbība un komunikācija: Atklāti stāsta par progresu un šķēršļiem un uzdod skaidrus jautājumus, ja prasība nav skaidra.
Atbildība un ietekme uz produktu: Saprot savu uzdevumu mērķi, pārbauda, vai piegādātais lietotājiem darbojas, un seko līdzi, līdz tas darbojas.
Mentorings un komandas izaugsme: Lūdz atgriezenisko saiti un rīkojas pēc tās, kā arī pieraksta iemācīto, lai nākamajam jaunpienācējam būtu vieglāks sākums.

Izstrādātājs: ko sagaida

Patstāvīgi piegādā funkcijas un ir uzticams komandas dalībnieks. Mazas un vidējas funkcijas vienas komandas atbildības jomā — no īsa dizaina apraksta līdz produkcijai.

Tehniskā izpilde: Bez pastāvīgas uzraudzības aizved funkciju no īsa dizaina apraksta līdz produkcijai, sadala to viegli pārskatāmos izmaiņu pieprasījumos un sniedz reālistiskus novērtējumus pazīstamam darbam.
Sistēmu projektēšana: Projektē komponentus esoša servisa ietvaros, netriviālām izmaiņām uzraksta īsu dizaina aprakstu un pirms izvēles salīdzina vismaz divus variantus.
Kvalitāte un uzticamība: Pievieno monitoringu un brīdinājumus funkcijām, kuras izstrādā, piedalās dežūru grafikā un ikdienišķus incidentus risina pēc rīcības instrukcijām.
Sadarbība un komunikācija: Strādā tieši ar produkta un dizaina kolēģiem, lai precizētu prasības, vienkāršā valodā skaidro tehniskos ierobežojumus un raksta izmaiņu pieprasījumu aprakstus, kuriem pārskatītāji var izsekot.
Atbildība un ietekme uz produktu: Atbild par funkciju arī pēc palaišanas: seko tās lietojumam un kļūdām, labo to, kas noiet greizi, un iesaka uzlabojumus, balstoties uz gūtajām atziņām.
Mentorings un komandas izaugsme: Rūpīgi pārskata kodu, palīdz ievadīt darbā jaunus komandas biedrus un strādā pārī ar jaunākajiem izstrādātājiem pie nepazīstamām koda daļām.

Vecākais izstrādātājs: ko sagaida

Vada lielākus darba apjomus un paaugstina apkārtējās komandas standartus. Projekti, kas aptver vairākus servisus vai vairākus cilvēkus, un vienas komandas tehniskie lēmumi.

Tehniskā izpilde: Piegādā projektus, kas aptver vairākus servisus vai dalībniekus, sakārto darbu tā, lai kaut kas noderīgs tiktu izlaists jau agri, un novērš riskus, pirms tie bloķē komandu.
Sistēmu projektēšana: Vada vairākus servisus aptverošu funkciju projektēšanu, pieraksta kompromisus, lai citi tos varētu pārskatīt, un konstruktīvi pārskata citu inženieru risinājumus.
Kvalitāte un uzticamība: Vada incidentu novēršanu komandas sistēmās, raksta pēcincidentu analīzes bez vainīgo meklēšanas un pārliecinās, ka turpmākās darbības tiešām tiek paveiktas.
Sadarbība un komunikācija: Pārstāv komandu plānošanā, vienojas ar produkta kolēģiem par apjomu un kompromisiem un raksta dokumentus, kurus saprot arī cilvēki ārpus inženierijas.
Atbildība un ietekme uz produktu: Pilnībā atbild par kādu produkta jomu, apšauba prasības, kas nekalpo lietotājiem, un ierosina darbu, kas virza komandas mērķus.
Mentorings un komandas izaugsme: Mērķtiecīgi mentorē vienu vai divus inženierus, sniedz atgriezenisko saiti, kas palīdz viņiem sasniegt nākamo līmeni, un piedalās darba intervijās.

Vadošais inženieris: ko sagaida

Risina problēmas, kas šķērso komandu robežas, un ietekmē tehniskos lēmumus ārpus vienas komandas. Vairākas komandas vai vesela produkta joma, arī problēmas, par kurām neatbild neviena komanda.

Tehniskā izpilde: Atbloķē piegādi starp komandām: atšķetina kopīgas atkarības, izveido rīkus vai veic migrācijas, kas vajadzīgas vairākām komandām, un notur vairāku komandu projektus pareizā kursā.
Sistēmu projektēšana: Nosaka arhitektūru pāri komandu robežām — kopīgus datu modeļus, servisu līgumus, lēmumus „būvēt vai pirkt“ — un paredz, kā sistēmai būs jāmainās nākamajā gadā vai divos.
Kvalitāte un uzticamība: Atrod uzticamības un drošības riskus, kas aptver vairākas sistēmas, nosaka standartus, piemēram, testēšanas stratēģiju un pakalpojuma līmeņa mērķus, un virza labojumus vairākās komandās.
Sadarbība un komunikācija: Saskaņo vairāku komandu un funkciju darbu ap tehnisko plānu, atrisina domstarpības starp komandām un skaidro tehniskos riskus vadībai.
Atbildība un ietekme uz produktu: Atrod produkta jomā problēmas ar vislielāko atdevi — arī tās, kuras nav uzņēmusies neviena komanda, — un pārliecinās, ka tās tiek atrisinātas.
Mentorings un komandas izaugsme: Attīsta vecākos izstrādātājus vairākās komandās, veido intervēšanas procesu un inženierijas praksi un ir tas, pie kura citi nāk pēc padoma.

Galvenais inženieris: ko sagaida

Nosaka uzņēmuma tehnisko kursu un atbild par tā ilgtermiņa tehnisko veselību. Visa inženierijas organizācija un uzņēmuma tehnoloģiju stratēģija nākamajiem gadiem.

Tehniskā izpilde: Veido to, kā visa organizācija piegādā programmatūru — laidienu praksi, platformu izvēli, būvēšanas un izvietošanas rīkus —, lai katra komanda piegādātu ātrāk un drošāk.
Sistēmu projektēšana: Atbild par uzņēmuma tehnoloģiju stratēģiju: uz kurām tehnoloģijām likt, no kurām atteikties un kā arhitektūrai vairāku gadu laikā attīstīties kopā ar biznesu.
Kvalitāte un uzticamība: Nosaka, ko uzņēmumam nozīmē uzticamība, drošība un kvalitāte, kopā ar vadības komandu līdzsvaro tās ar ātrumu un ir pēdējā eskalācijas pakāpe sarežģītākajos incidentos.
Sadarbība un komunikācija: Ir uzticama balss uzņēmuma līmeņa lēmumos, pārvērš biznesa stratēģiju tehniskajā kursā un otrādi un vajadzības gadījumā pārstāv inženieriju klientu, partneru vai investoru priekšā.
Atbildība un ietekme uz produktu: Sasaista ieguldījumus inženierijā ar uzņēmuma rezultātiem un argumentē par vai pret lielām likmēm, balstoties uz to tehnisko un biznesa ietekmi.
Mentorings un komandas izaugsme: Veido uzņēmuma tehnisko kultūru — kā tiek pieņemti lēmumi un kā tiek dalītas zināšanas — un sagatavo nākamo vadošo inženieru paaudzi.

Kā pielāgot šīs kāpnes

Pielāgojiet līmeņus saviem amatu nosaukumiem
Ja jūsu amati ir „Izstrādātājs I, II un III“, pārdēvējiet līmeņus, bet saglabājiet pa vienam līmenim katram reālam atbildības apjoma solim. Lielākajai daļai uzņēmumu ar mazāk nekā 100 inženieriem galvenā inženiera līmenis vēl nav vajadzīgs: neiekļaujiet to, kamēr kāds šo darbu tiešām nedara.
Paturiet piecas līdz septiņas kompetences
Ja to ir vairāk par septiņām, neviens tās nelasa; ja mazāk par četrām, ļoti atšķirīgi cilvēki izskatās vienādi. Apvienojiet kompetences, kuras vienmēr vērtējat kopā, un pievienojiet jaunu tikai tad, ja tā mainītu kādu reālu lēmumu.
Pārrakstiet prasības kā redzamu rīcību
Par katru šūnu pajautājiet, vai vadītājs varētu norādīt piemēru no pēdējiem sešiem mēnešiem. Aizstājiet tādus vārdus kā „spēcīgs“ vai „dziļš“ ar to, ko cilvēks patiešām dara, piemēram, „vada incidentu novēršanu komandas servisos“.
Pārbaudiet tās uz reāliem cilvēkiem pirms publicēšanas
Palūdziet diviem vai trim vadītājiem novietot savas komandas dalībniekus melnrakstā. Kur viņu vērtējumi atšķiras, formulējums ir divdomīgs: izlabojiet to, publicējiet karjeras kāpnes un vienojieties tās pārskatīt vēlreiz pēc sešiem mēnešiem.

BUJ

Jautājumi par šīm kāpnēm

Cik līmeņu vajag programmatūras izstrādātāja karjeras kāpnēm?

Uzņēmumam ar 20–200 darbiniekiem parasti pietiek ar četriem līdz sešiem. Ja to ir mazāk, paaugstinājumi kļūst reti un milzīgi; ja vairāk, atšķirība starp diviem līmeņiem ir par mazu, lai to aprakstītu. Šajā veidnē ir pieci: jaunākais izstrādātājs, izstrādātājs, vecākais izstrādātājs, vadošais un galvenais inženieris.

Vai inženieriem jākļūst par vadītājiem, lai augtu?

Nē. Šīs ir speciālista virziena karjeras kāpnes: vadošie un galvenie inženieri aug atbildības apjomā un ietekmē, nevadot cilvēkus. Izmantojiet tās kopā ar izstrādes vadītāja karjeras kāpnēm, lai pāreja uz vadību būtu karjeras virziena maiņa, nevis paaugstinājums.

Kā izmantot karjeras kāpnes lēmumos par paaugstinājumu?

Paaugstiniet tos, kuri jau pastāvīgi strādā nākamā līmenī, nevis tos, kuri varētu. Palūdziet darbiniekam un viņa vadītājam savākt konkrētus piemērus katrai mērķa līmeņa kompetencei un salīdziniet katru gadījumu ar to pašu matricu, lai lēmumi dažādās komandās būtu konsekventi.

Kā karjeras kāpnes iederas check-in sarunās un 1:1 tikšanās reizēs?

Izmantojiet tās kā regulāro check-in sarunu darba kārtību: darbinieks novērtē sevi pret savu pašreizējo līmeni, vadītājs dara to pašu, un atšķirības starp abiem vērtējumiem kļūst par dažiem konkrētiem attīstības uzdevumiem tuvākajiem mēnešiem.

Cik bieži jāatjauno izstrādātāju karjeras kāpnes?

Pārskatiet tās vienu vai divas reizes gadā un ikreiz, kad mainās uzņēmuma uzbūve — piemēram, kad izveidojat platformas komandu vai sākat pieņemt darbā vadošos inženierus. Pārrakstiet šūnu, ja novērtējumos pie tās atkal un atkal paklūp.

Izveidojiet šīs karjeras kāpnes platformā LadderKit — bez maksas

Iestatiet to līmeņus un prasmes savai komandai, vērtējiet cilvēkus pēc tiem check-in sarunās un pieņemiet konsekventus lēmumus par paaugstinājumiem.

Sākt bez maksas Skatīt demoversiju Bez reģistrācijas