Шаблон на кариерна стълбица

Кариерна стълбица за софтуерен разработчик: шаблон

Пет нива от Junior до Principal и шест компетенции — от писането и пускането на код до развитието на екипа.

Безплатен план · Без банкова карта

Тази кариерна стълбица е написана за продуктови компании с около 20–200 души: разработчиците сами довеждат функционалностите до продукция, екипите са малки и няма HR отдел, който да изгражда система от длъжности. Тя описва пет нива — от човек в началото на кариерата си до човек, който определя техническата посока на цялата компания. Най-високото ниво, Principal инженер, е експертно ниво, а управлението на разработчици е описано в отделната стълбица за Engineering Manager.

Всяко ниво е описано чрез това, което човек прави, а не чрез години опит. Четете ред от матрицата на компетенциите отляво надясно, за да видите как расте едно очакване, или раздела на дадено ниво, за да видите всичко, което се очаква на него. Използвайте я, за да обяснявате какво означава следващото ниво, да структурирате самооценките и чек-ините и да правите предложенията за повишение сравними между екипите.

Приемете я като отправна точка. Преименувайте нивата според вашите длъжности, обединете или махнете компетенциите, които не пасват на компанията ви, и пренапишете очакванията със свои думи, преди да публикувате стълбицата за екипа.

Нивата накратко

Junior разработчик
Опознава кодовата база и изпълнява ясно дефинирани задачи с помощ от колегите.
Обхват
Отделни задачи в една част от продукта, обикновено разбити от някой по-опитен.
Mid разработчик
Самостоятелно разработва функционалности и е надежден член на екипа.
Обхват
Малки и средни функционалности в зоната на един екип — от кратка дизайн бележка до продукция.
Senior разработчик
Води по-големи задачи и вдига стандарта на екипа около себе си.
Обхват
Проекти, които обхващат няколко услуги или няколко души, и техническите решения на един екип.
Staff инженер
Решава проблеми, които прекрачват границите на екипите, и насочва техническите решения отвъд един екип.
Обхват
Няколко екипа или цяла продуктова област, включително проблеми, които не принадлежат на нито един екип.
Principal инженер
Определя техническата посока на компанията и отговаря за дългосрочното ѝ техническо здраве.
Обхват
Цялата инженерна организация и техническата стратегия на компанията за следващите няколко години.

Матрица на компетенциите

Всеки ред е компетенция, а всяка колона — ниво. Четете реда отляво надясно, за да видите как растат очакванията.

Какво означава всяка компетенция

Разработка и реализация: Превръщане на изискванията в работещ и поддържаем софтуер и доставянето му до потребителите.
Проектиране на системи: Избор на структури, интерфейси и компромиси, които ще издържат, докато продуктът расте.
Качество и надеждност: Продуктът да работи правилно, да е наблюдаем и достъпен, и екипът да се учи от сривовете.
Сътрудничество и комуникация: Ефективна работа с други инженери, с продукта, дизайна и останалата част от бизнеса.
Отговорност и влияние върху продукта: Разбиране защо работата е важна и поемане на отговорност за резултатите, а не само за задачите.
Менторство и развитие на екипа: Помощ на другите да се развиват и изграждане на екип, по-силен от всеки отделен човек в него.

Софтуерен разработчик: очаквания по компетенции и нива
Компетенция	Junior разработчик	Mid разработчик	Senior разработчик	Staff инженер	Principal инженер
Разработка и реализация	Изпълнява добре очертани задачи с четим код и тестове, иска помощ, когато е блокиран от няколко часа, а не от няколко дни, и отработва коментарите от прегледа преди сливане.	Довежда функционалност от кратка дизайн бележка до продукция без постоянен надзор, разделя я на pull request-и, които лесно се преглеждат, и дава реалистични оценки за позната работа.	Реализира проекти, които обхващат няколко услуги или участници, подрежда работата така, че нещо полезно да излезе рано, и премахва рисковете, преди да блокират екипа.	Отблокира реализацията между екипите: разплита общи зависимости, създава инструментите или провежда миграциите, от които се нуждаят няколко екипа, и държи проектите на няколко екипа в график.	Оформя начина, по който цялата организация пуска софтуер — практики за релийзи, избор на платформи, инструменти за build и deploy, — така че всеки екип да доставя по-бързо и по-безопасно.
Проектиране на системи	Следва съществуващите модели в кодовата база и може да обясни защо кодът, който е променил, е структуриран по този начин.	Проектира компоненти в съществуваща услуга, пише кратка дизайн бележка за нетривиални промени и сравнява поне два варианта, преди да избере един.	Води проектирането на функционалности, които обхващат няколко услуги, описва компромисите писмено, за да ги прегледат други, и конструктивно преглежда дизайна на други инженери.	Определя архитектурата отвъд границите на екипите — общи модели на данни, договори между услуги, решения дали да се създава или купува — и предвижда как системата трябва да се промени през следващите година-две.	Отговаря за техническата стратегия на компанията: на кои технологии да се заложи, кои да се изведат от употреба и как архитектурата да се развива заедно с бизнеса в рамките на няколко години.
Качество и надеждност	Пише тестове за собствените си промени, проверява работата си преди релийз и поправя бъговете в кода, който е пипал.	Добавя мониторинг и аларми за функционалностите, които разработва, участва в дежурствата и се справя с рутинни инциденти по наръчника.	Води реакцията при инциденти в системите на екипа, пише post-mortem анализи без търсене на виновни и следи последващите действия наистина да бъдат изпълнени.	Открива рискове за надеждността и сигурността, които обхващат няколко системи, задава стандарти като стратегията за тестване и целевите нива на услугата (SLO) и движи поправките между екипите.	Определя какво означават надеждност, сигурност и качество за компанията, балансира ги спрямо скоростта заедно с ръководството и е последната точка на ескалация при най-тежките инциденти.
Сътрудничество и комуникация	Открито споделя напредъка и пречките и задава ясни въпроси, когато изискване не е ясно.	Работи директно с продукта и дизайна, за да изясни изискванията, обяснява техническите ограничения на разбираем език и пише описания на pull request-ите, които рецензентите могат да следват.	Представлява екипа при планирането, договаря обхвата и компромисите с продукта и пише документи, които хората извън инженерството разбират.	Обединява няколко екипа и функции около общ технически план, разрешава разногласията между екипите и обяснява техническите рискове на ръководството.	Е доверен глас в решенията на ниво компания, превежда бизнес стратегията в техническа посока и обратно и при нужда представлява инженерството пред клиенти, партньори или инвеститори.
Отговорност и влияние върху продукта	Разбира целта на задачите си, проверява дали пуснатото работи за потребителите и продължава, докато наистина заработи.	Отговаря за функционалност и след пускането ѝ: следи използването и грешките, поправя проблемите и предлага подобрения въз основа на наученото.	Отговаря изцяло за една област от продукта, оспорва изисквания, които не помагат на потребителите, и предлага работа, която придвижва целите на екипа.	Открива проблемите с най-голям ефект в цяла продуктова област — включително такива, които никой екип не е поел — и се грижи да бъдат решени.	Свързва инвестициите в инженерството с резултатите на компанията и защитава или оспорва големите залози според техническото и бизнес въздействие.
Менторство и развитие на екипа	Иска обратна връзка и действа по нея и записва наученото, за да е по-лесно началото на следващия новодошъл.	Прави внимателен преглед на кода, помага при въвеждането на нови колеги и работи в двойка с junior разработчици по непознати части от кода.	Целенасочено е ментор на един-двама инженери, дава обратна връзка, която им помага да стигнат следващото ниво, и участва в интервютата при наемане.	Развива senior инженери в различни екипи, оформя процеса на интервюта и инженерните практики и е човек, при когото другите идват за съвет.	Изгражда техническата култура на компанията — как се вземат решения и как се споделя знание — и развива следващото поколение Staff инженери.

Превъртете таблицата хоризонтално, за да видите всички нива.

Изтеглете като CSV Отваря се в Excel, Google Sheets или Numbers.

Junior разработчик: какво се очаква

Опознава кодовата база и изпълнява ясно дефинирани задачи с помощ от колегите. Отделни задачи в една част от продукта, обикновено разбити от някой по-опитен.

Разработка и реализация: Изпълнява добре очертани задачи с четим код и тестове, иска помощ, когато е блокиран от няколко часа, а не от няколко дни, и отработва коментарите от прегледа преди сливане.
Проектиране на системи: Следва съществуващите модели в кодовата база и може да обясни защо кодът, който е променил, е структуриран по този начин.
Качество и надеждност: Пише тестове за собствените си промени, проверява работата си преди релийз и поправя бъговете в кода, който е пипал.
Сътрудничество и комуникация: Открито споделя напредъка и пречките и задава ясни въпроси, когато изискване не е ясно.
Отговорност и влияние върху продукта: Разбира целта на задачите си, проверява дали пуснатото работи за потребителите и продължава, докато наистина заработи.
Менторство и развитие на екипа: Иска обратна връзка и действа по нея и записва наученото, за да е по-лесно началото на следващия новодошъл.

Mid разработчик: какво се очаква

Самостоятелно разработва функционалности и е надежден член на екипа. Малки и средни функционалности в зоната на един екип — от кратка дизайн бележка до продукция.

Разработка и реализация: Довежда функционалност от кратка дизайн бележка до продукция без постоянен надзор, разделя я на pull request-и, които лесно се преглеждат, и дава реалистични оценки за позната работа.
Проектиране на системи: Проектира компоненти в съществуваща услуга, пише кратка дизайн бележка за нетривиални промени и сравнява поне два варианта, преди да избере един.
Качество и надеждност: Добавя мониторинг и аларми за функционалностите, които разработва, участва в дежурствата и се справя с рутинни инциденти по наръчника.
Сътрудничество и комуникация: Работи директно с продукта и дизайна, за да изясни изискванията, обяснява техническите ограничения на разбираем език и пише описания на pull request-ите, които рецензентите могат да следват.
Отговорност и влияние върху продукта: Отговаря за функционалност и след пускането ѝ: следи използването и грешките, поправя проблемите и предлага подобрения въз основа на наученото.
Менторство и развитие на екипа: Прави внимателен преглед на кода, помага при въвеждането на нови колеги и работи в двойка с junior разработчици по непознати части от кода.

Senior разработчик: какво се очаква

Води по-големи задачи и вдига стандарта на екипа около себе си. Проекти, които обхващат няколко услуги или няколко души, и техническите решения на един екип.

Разработка и реализация: Реализира проекти, които обхващат няколко услуги или участници, подрежда работата така, че нещо полезно да излезе рано, и премахва рисковете, преди да блокират екипа.
Проектиране на системи: Води проектирането на функционалности, които обхващат няколко услуги, описва компромисите писмено, за да ги прегледат други, и конструктивно преглежда дизайна на други инженери.
Качество и надеждност: Води реакцията при инциденти в системите на екипа, пише post-mortem анализи без търсене на виновни и следи последващите действия наистина да бъдат изпълнени.
Сътрудничество и комуникация: Представлява екипа при планирането, договаря обхвата и компромисите с продукта и пише документи, които хората извън инженерството разбират.
Отговорност и влияние върху продукта: Отговаря изцяло за една област от продукта, оспорва изисквания, които не помагат на потребителите, и предлага работа, която придвижва целите на екипа.
Менторство и развитие на екипа: Целенасочено е ментор на един-двама инженери, дава обратна връзка, която им помага да стигнат следващото ниво, и участва в интервютата при наемане.

Staff инженер: какво се очаква

Решава проблеми, които прекрачват границите на екипите, и насочва техническите решения отвъд един екип. Няколко екипа или цяла продуктова област, включително проблеми, които не принадлежат на нито един екип.

Разработка и реализация: Отблокира реализацията между екипите: разплита общи зависимости, създава инструментите или провежда миграциите, от които се нуждаят няколко екипа, и държи проектите на няколко екипа в график.
Проектиране на системи: Определя архитектурата отвъд границите на екипите — общи модели на данни, договори между услуги, решения дали да се създава или купува — и предвижда как системата трябва да се промени през следващите година-две.
Качество и надеждност: Открива рискове за надеждността и сигурността, които обхващат няколко системи, задава стандарти като стратегията за тестване и целевите нива на услугата (SLO) и движи поправките между екипите.
Сътрудничество и комуникация: Обединява няколко екипа и функции около общ технически план, разрешава разногласията между екипите и обяснява техническите рискове на ръководството.
Отговорност и влияние върху продукта: Открива проблемите с най-голям ефект в цяла продуктова област — включително такива, които никой екип не е поел — и се грижи да бъдат решени.
Менторство и развитие на екипа: Развива senior инженери в различни екипи, оформя процеса на интервюта и инженерните практики и е човек, при когото другите идват за съвет.

Principal инженер: какво се очаква

Определя техническата посока на компанията и отговаря за дългосрочното ѝ техническо здраве. Цялата инженерна организация и техническата стратегия на компанията за следващите няколко години.

Разработка и реализация: Оформя начина, по който цялата организация пуска софтуер — практики за релийзи, избор на платформи, инструменти за build и deploy, — така че всеки екип да доставя по-бързо и по-безопасно.
Проектиране на системи: Отговаря за техническата стратегия на компанията: на кои технологии да се заложи, кои да се изведат от употреба и как архитектурата да се развива заедно с бизнеса в рамките на няколко години.
Качество и надеждност: Определя какво означават надеждност, сигурност и качество за компанията, балансира ги спрямо скоростта заедно с ръководството и е последната точка на ескалация при най-тежките инциденти.
Сътрудничество и комуникация: Е доверен глас в решенията на ниво компания, превежда бизнес стратегията в техническа посока и обратно и при нужда представлява инженерството пред клиенти, партньори или инвеститори.
Отговорност и влияние върху продукта: Свързва инвестициите в инженерството с резултатите на компанията и защитава или оспорва големите залози според техническото и бизнес въздействие.
Менторство и развитие на екипа: Изгражда техническата култура на компанията — как се вземат решения и как се споделя знание — и развива следващото поколение Staff инженери.

Как да адаптирате тази стълбица

Съобразете нивата с вашите длъжности
Ако длъжностите ви са Developer I, II и III, преименувайте нивата, но запазете по едно ниво за всяка реална стъпка в обхвата. Повечето компании с по-малко от 100 инженери все още нямат нужда от ниво Principal: не го включвайте, докато някой наистина не върши тази работа.
Ограничете се до пет–седем компетенции
Ако са повече от седем, никой не ги чете; ако са по-малко от четири, много различни хора изглеждат еднакво. Обединете компетенциите, които винаги оценявате заедно, и добавяйте нова само когато тя би променила реално решение.
Пренапишете очакванията като неща, които се виждат
За всяка клетка се запитайте дали мениджърът би могъл да посочи пример от последните шест месеца. Заменете думи като „силен“ или „задълбочен“ с това, което човекът реално прави, например „води реакцията при инциденти в услугите на екипа“.
Изпробвайте я върху реални хора, преди да я публикувате
Помолете двама-трима мениджъри да разпределят членовете на екипите си по нивата в черновата. Където не са съгласни, формулировката е двусмислена: поправете я, публикувайте стълбицата и се договорете да я прегледате отново след шест месеца.

Въпроси

Въпроси за тази стълбица

Колко нива трябва да има кариерната стълбица на софтуерен разработчик?

За компания с 20–200 души обичайно са от четири до шест. Ако са по-малко, повишенията стават редки и огромни; ако са повече, разликата между две нива е твърде малка, за да бъде описана. Този шаблон използва пет: Junior разработчик, Mid разработчик, Senior, Staff и Principal.

Трябва ли инженерите да станат мениджъри, за да се развиват?

Не. Това е стълбица за експертната пътека: Staff и Principal инженерите растат по обхват и влияние, без да управляват хора. Използвайте я заедно със стълбицата за Engineering Manager, така че преминаването към управление да е смяна на пътеката, а не повишение.

Как да използваме стълбицата при решенията за повишение?

Повишавайте хората, които вече работят постоянно на следващото ниво, а не тези, които биха могли. Помолете човека и неговия мениджър да съберат конкретни примери за всяка компетенция от целевото ниво и сравнявайте всеки случай със същата матрица, така че решенията да са последователни между екипите.

Как стълбицата се вписва в чек-ините и срещите 1:1?

Използвайте я като дневен ред на редовните чек-ини: човекът се оценява спрямо текущото си ниво, мениджърът прави същото, а разликите между двете оценки се превръщат в няколко конкретни задачи за развитие за следващите месеци.

Колко често трябва да обновяваме стълбицата?

Преглеждайте я веднъж или два пъти годишно и всеки път, когато структурата на компанията се промени — например когато създадете платформен екип или започнете да наемате Staff инженери. Пренапишете клетка винаги когато оценките постоянно се спъват в нея.

Изградете тази кариерна стълбица в LadderKit — безплатно

Настройте нивата и уменията ѝ за вашия екип, оценявайте хората спрямо тях в чек-ините и вземайте последователни решения за повишения.

Започнете безплатно Вижте демоверсията Без регистрация