Шаблон кар’єрної драбини

Грейди розробника: шаблон кар’єрної драбини

П’ять рівнів від Junior до Principal і шість компетенцій — від розробки й випуску до розвитку команди.

Безкоштовний тариф · Банківська картка не потрібна

Цю кар’єрну драбину написано для продуктових компаній приблизно на 20–200 людей: розробники самі доводять фічі від задуму до продакшену, команди невеликі, а окремого HR, який вибудував би систему грейдів, немає. Вона описує п’ять рівнів — від людини на початку кар’єри до того, хто визначає технічний напрям усієї компанії. Найвищий рівень, Principal-інженер, належить до експертного треку, а управління розробниками описує окрема кар’єрна драбина керівника розробки.

Кожен рівень описано через те, що людина робить, а не через стаж. Читайте рядок матриці компетенцій зліва направо, щоб побачити, як зростає одне очікування, або розділ рівня — щоб побачити все, що на ньому очікується. З її допомогою зручно пояснювати, що означає наступний рівень, проводити самооцінку й чек-іни та порівнювати кандидатів на підвищення між командами.

Сприймайте її як відправну точку. Перейменуйте рівні відповідно до своїх посад, об’єднайте або приберіть компетенції, які вам не підходять, і перепишіть очікування своїми словами, перш ніж публікувати драбину для команди.

Рівні коротко

Junior-розробник
Опановує кодову базу й виконує чітко поставлені завдання з підтримкою колег.
Масштаб
Окремі завдання в одній частині продукту, які зазвичай декомпозує хтось досвідченіший.
Middle-розробник
Самостійно робить фічі й є надійним учасником команди.
Масштаб
Невеликі й середні фічі в зоні однієї команди — від короткого дизайн-документа до продакшену.
Senior-розробник
Веде великі частини роботи й піднімає планку для всієї команди.
Масштаб
Проєкти, що охоплюють кілька сервісів або кількох людей, і технічні рішення однієї команди.
Staff-інженер
Розв’язує проблеми на стику команд і впливає на технічні рішення за межами своєї.
Масштаб
Кілька команд або цілий продуктовий напрям, зокрема проблеми, що не належать жодній команді.
Principal-інженер
Визначає технічний напрям компанії й відповідає за її довгострокове технічне здоров’я.
Масштаб
Уся інженерна організація й технічна стратегія компанії на кілька років уперед.

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

Рядки — компетенції, стовпці — рівні. Читайте рядок зліва направо, щоб побачити, як зростають очікування.

Що означає кожна компетенція

Розробка та випуск: Перетворювати вимоги на робоче, підтримуване програмне забезпечення й доводити його до користувачів.
Проєктування систем: Обирати структури, інтерфейси й компроміси, які витримають зростання продукту.
Якість і надійність: Підтримувати продукт коректним, спостережуваним і доступним та вчитися на збоях.
Співпраця та комунікація: Ефективно працювати з іншими інженерами, продуктом, дизайном і рештою компанії.
Відповідальність і вплив на продукт: Розуміти, навіщо потрібна робота, і відповідати за результат, а не лише за завдання.
Менторство та розвиток команди: Допомагати іншим зростати й робити команду сильнішою за будь-кого з її учасників.

Розробник: очікування за компетенціями й рівнями
Компетенція	Junior-розробник	Middle-розробник	Senior-розробник	Staff-інженер	Principal-інженер
Розробка та випуск	Виконує чітко окреслені завдання читабельним кодом із тестами, просить допомоги, якщо застряг на кілька годин, а не днів, і відпрацьовує зауваження рев’ю до мержу.	Без постійної опіки доводить фічу від короткого дизайн-документа до продакшену, розбиває її на зручні для рев’ю пул-реквести й реалістично оцінює знайому роботу.	Веде проєкти, що охоплюють кілька сервісів або учасників, вибудовує порядок робіт так, щоб щось корисне виходило якомога раніше, і знімає ризики до того, як вони заблокують команду.	Розблоковує випуск там, де команди залежать одна від одної: розплутує спільні залежності, створює інструменти або проводить міграції, потрібні кільком командам, і тримає міжкомандні проєкти в графіку.	Визначає, як випускає софт уся організація, — практики релізів, вибір платформ, інструменти збирання й деплою, — щоб кожна команда випускала швидше й безпечніше.
Проєктування систем	Дотримується усталених у кодовій базі патернів і може пояснити, чому змінений ним код влаштовано саме так.	Проєктує компоненти всередині наявного сервісу, пише короткий дизайн-документ для нетривіальних змін і порівнює щонайменше два варіанти, перш ніж обрати.	Веде проєктування фіч, що зачіпають кілька сервісів, письмово фіксує компроміси для рев’ю та конструктивно рецензує дизайни інших інженерів.	Визначає архітектуру на стику команд — спільні моделі даних, контракти сервісів, рішення «робити чи купувати» — і передбачає, як система має змінитися в найближчі рік-два.	Відповідає за технічну стратегію компанії: на які технології робити ставку, від яких відмовлятися і як архітектура має розвиватися разом із бізнесом на кілька років уперед.
Якість і надійність	Пише тести на свої зміни, перевіряє роботу перед релізом і виправляє баги в коді, який зачіпав.	Додає моніторинг і алерти для своїх фіч, бере участь у чергуваннях і розбирає типові інциденти за ранбуком.	Керує реагуванням на інциденти в системах команди, пише постмортеми без пошуку винних і стежить, щоб дії за їхніми підсумками справді виконувалися.	Знаходить ризики надійності й безпеки на стику систем, задає стандарти — стратегію тестування, цільові рівні сервісу (SLO) — і доводить виправлення до кінця в кількох командах.	Визначає, що означають надійність, безпека і якість для компанії, разом із керівництвом балансує їх зі швидкістю і є останньою інстанцією в найскладніших інцидентах.
Співпраця та комунікація	Відкрито розповідає про прогрес і блокери та ставить чіткі запитання, якщо вимога незрозуміла.	Безпосередньо працює з продуктом і дизайном над уточненням вимог, пояснює технічні обмеження простою мовою і пише зрозумілі рев’юерам описи пул-реквестів.	Представляє команду на плануванні, домовляється з продуктом про обсяг і компроміси та пише документи, зрозумілі людям поза розробкою.	Узгоджує технічний план між кількома командами й функціями, розв’язує розбіжності між командами й пояснює технічні ризики керівництву.	Має вагу в рішеннях на рівні компанії, перекладає бізнес-стратегію в технічний напрям і навпаки та за потреби представляє розробку перед клієнтами, партнерами чи інвесторами.
Відповідальність і вплив на продукт	Розуміє мету своїх завдань, перевіряє, що випущене працює для користувачів, і доводить справу до кінця.	Відповідає за фічу й після запуску: стежить за використанням і помилками, виправляє те, що йде не так, і пропонує покращення за підсумками.	Відповідає за частину продукту від початку до кінця, ставить під сумнів вимоги, які не допомагають користувачам, і пропонує роботу, що просуває цілі команди.	Знаходить найвагоміші проблеми в усьому продуктовому напрямі — зокрема ті, за які не взялася жодна команда, — і домагається їх розв’язання.	Пов’язує інвестиції в розробку з результатами компанії та виступає за великі ставки чи проти них, зважаючи на їхній технічний і бізнесовий ефект.
Менторство та розвиток команди	Просить зворотний зв’язок і діє відповідно до нього, записує те, у чому розібрався, щоб наступному новачкові було легше.	Уважно робить код-рев’ю, допомагає з онбордингом нових колег і працює в парі з junior-розробниками над незнайомими частинами коду.	Цілеспрямовано менторить одного–двох розробників, дає зворотний зв’язок, який допомагає їм дорости до наступного рівня, і бере участь у співбесідах.	Вирощує senior-розробників у різних командах, впливає на процес найму та інженерні практики; до нього звертаються по пораду.	Вибудовує технічну культуру компанії — як ухвалюються рішення і як поширюються знання — і вирощує наступне покоління staff-інженерів.

Прокрутіть таблицю вбік, щоб побачити всі рівні.

Завантажити CSV Відкривається в Excel, Google Таблицях і Numbers.

Junior-розробник: що очікується

Опановує кодову базу й виконує чітко поставлені завдання з підтримкою колег. Окремі завдання в одній частині продукту, які зазвичай декомпозує хтось досвідченіший.

Розробка та випуск: Виконує чітко окреслені завдання читабельним кодом із тестами, просить допомоги, якщо застряг на кілька годин, а не днів, і відпрацьовує зауваження рев’ю до мержу.
Проєктування систем: Дотримується усталених у кодовій базі патернів і може пояснити, чому змінений ним код влаштовано саме так.
Якість і надійність: Пише тести на свої зміни, перевіряє роботу перед релізом і виправляє баги в коді, який зачіпав.
Співпраця та комунікація: Відкрито розповідає про прогрес і блокери та ставить чіткі запитання, якщо вимога незрозуміла.
Відповідальність і вплив на продукт: Розуміє мету своїх завдань, перевіряє, що випущене працює для користувачів, і доводить справу до кінця.
Менторство та розвиток команди: Просить зворотний зв’язок і діє відповідно до нього, записує те, у чому розібрався, щоб наступному новачкові було легше.

Middle-розробник: що очікується

Самостійно робить фічі й є надійним учасником команди. Невеликі й середні фічі в зоні однієї команди — від короткого дизайн-документа до продакшену.

Розробка та випуск: Без постійної опіки доводить фічу від короткого дизайн-документа до продакшену, розбиває її на зручні для рев’ю пул-реквести й реалістично оцінює знайому роботу.
Проєктування систем: Проєктує компоненти всередині наявного сервісу, пише короткий дизайн-документ для нетривіальних змін і порівнює щонайменше два варіанти, перш ніж обрати.
Якість і надійність: Додає моніторинг і алерти для своїх фіч, бере участь у чергуваннях і розбирає типові інциденти за ранбуком.
Співпраця та комунікація: Безпосередньо працює з продуктом і дизайном над уточненням вимог, пояснює технічні обмеження простою мовою і пише зрозумілі рев’юерам описи пул-реквестів.
Відповідальність і вплив на продукт: Відповідає за фічу й після запуску: стежить за використанням і помилками, виправляє те, що йде не так, і пропонує покращення за підсумками.
Менторство та розвиток команди: Уважно робить код-рев’ю, допомагає з онбордингом нових колег і працює в парі з junior-розробниками над незнайомими частинами коду.

Senior-розробник: що очікується

Веде великі частини роботи й піднімає планку для всієї команди. Проєкти, що охоплюють кілька сервісів або кількох людей, і технічні рішення однієї команди.

Розробка та випуск: Веде проєкти, що охоплюють кілька сервісів або учасників, вибудовує порядок робіт так, щоб щось корисне виходило якомога раніше, і знімає ризики до того, як вони заблокують команду.
Проєктування систем: Веде проєктування фіч, що зачіпають кілька сервісів, письмово фіксує компроміси для рев’ю та конструктивно рецензує дизайни інших інженерів.
Якість і надійність: Керує реагуванням на інциденти в системах команди, пише постмортеми без пошуку винних і стежить, щоб дії за їхніми підсумками справді виконувалися.
Співпраця та комунікація: Представляє команду на плануванні, домовляється з продуктом про обсяг і компроміси та пише документи, зрозумілі людям поза розробкою.
Відповідальність і вплив на продукт: Відповідає за частину продукту від початку до кінця, ставить під сумнів вимоги, які не допомагають користувачам, і пропонує роботу, що просуває цілі команди.
Менторство та розвиток команди: Цілеспрямовано менторить одного–двох розробників, дає зворотний зв’язок, який допомагає їм дорости до наступного рівня, і бере участь у співбесідах.

Staff-інженер: що очікується

Розв’язує проблеми на стику команд і впливає на технічні рішення за межами своєї. Кілька команд або цілий продуктовий напрям, зокрема проблеми, що не належать жодній команді.

Розробка та випуск: Розблоковує випуск там, де команди залежать одна від одної: розплутує спільні залежності, створює інструменти або проводить міграції, потрібні кільком командам, і тримає міжкомандні проєкти в графіку.
Проєктування систем: Визначає архітектуру на стику команд — спільні моделі даних, контракти сервісів, рішення «робити чи купувати» — і передбачає, як система має змінитися в найближчі рік-два.
Якість і надійність: Знаходить ризики надійності й безпеки на стику систем, задає стандарти — стратегію тестування, цільові рівні сервісу (SLO) — і доводить виправлення до кінця в кількох командах.
Співпраця та комунікація: Узгоджує технічний план між кількома командами й функціями, розв’язує розбіжності між командами й пояснює технічні ризики керівництву.
Відповідальність і вплив на продукт: Знаходить найвагоміші проблеми в усьому продуктовому напрямі — зокрема ті, за які не взялася жодна команда, — і домагається їх розв’язання.
Менторство та розвиток команди: Вирощує senior-розробників у різних командах, впливає на процес найму та інженерні практики; до нього звертаються по пораду.

Principal-інженер: що очікується

Визначає технічний напрям компанії й відповідає за її довгострокове технічне здоров’я. Уся інженерна організація й технічна стратегія компанії на кілька років уперед.

Розробка та випуск: Визначає, як випускає софт уся організація, — практики релізів, вибір платформ, інструменти збирання й деплою, — щоб кожна команда випускала швидше й безпечніше.
Проєктування систем: Відповідає за технічну стратегію компанії: на які технології робити ставку, від яких відмовлятися і як архітектура має розвиватися разом із бізнесом на кілька років уперед.
Якість і надійність: Визначає, що означають надійність, безпека і якість для компанії, разом із керівництвом балансує їх зі швидкістю і є останньою інстанцією в найскладніших інцидентах.
Співпраця та комунікація: Має вагу в рішеннях на рівні компанії, перекладає бізнес-стратегію в технічний напрям і навпаки та за потреби представляє розробку перед клієнтами, партнерами чи інвесторами.
Відповідальність і вплив на продукт: Пов’язує інвестиції в розробку з результатами компанії та виступає за великі ставки чи проти них, зважаючи на їхній технічний і бізнесовий ефект.
Менторство та розвиток команди: Вибудовує технічну культуру компанії — як ухвалюються рішення і як поширюються знання — і вирощує наступне покоління staff-інженерів.

Як адаптувати цю драбину

Зіставте рівні зі своїми посадами
Якщо у вас посади «Розробник I, II, III», перейменуйте рівні, але залиште по одному рівню на кожен реальний крок у масштабі роботи. Більшості компаній, де менше ніж 100 розробників, рівень Principal поки не потрібен — не запроваджуйте його, доки хтось справді не виконує цю роботу.
Залиште п’ять–сім компетенцій
Понад сім ніхто не читає, а якщо їх менше чотирьох, дуже різні люди виглядають однаково. Об’єднайте компетенції, які ви завжди оцінюєте разом, і додавайте нову, лише якщо вона змінить реальне рішення.
Переформулюйте очікування так, щоб їх було видно
Для кожної клітинки запитайте себе: чи зможе керівник навести приклад за останні пів року? Замініть слова на кшталт «сильний» чи «глибокий» тим, що людина насправді робить, — наприклад, «керує реагуванням на інциденти в сервісах команди».
Перевірте драбину на реальних людях до публікації
Попросіть двох–трьох керівників розставити своїх співробітників за чернеткою. Там, де їхні думки розходяться, формулювання неоднозначне: виправте його, опублікуйте драбину й домовтеся переглянути її через пів року.

Питання та відповіді

Питання про цю драбину

Скільки грейдів має бути в розробника?

Для компанії на 20–200 людей зазвичай достатньо чотирьох–шести. Якщо рівнів менше, підвищення стають рідкісними й величезними; якщо більше — різницю між сусідніми рівнями вже не описати. У цьому шаблоні їх п’ять: Junior, Middle, Senior, Staff і Principal.

Чи обов’язково розробникові ставати керівником, щоб зростати?

Ні. Це експертний трек: staff- і principal-інженери зростають у масштабі та впливі, не керуючи людьми. Використовуйте його разом із кар’єрною драбиною керівника розробки — тоді перехід у менеджмент буде зміною треку, а не підвищенням.

Як використовувати драбину для рішень про підвищення?

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

Як драбина допомагає на чек-інах і зустрічах один на один?

Використовуйте її як порядок денний регулярних чек-інів: співробітник оцінює себе за своїм поточним рівнем, керівник робить те саме, а розбіжності між оцінками перетворюються на кілька конкретних завдань з розвитку на найближчі місяці.

Як часто переглядати кар’єрну драбину?

Раз чи двічі на рік і щоразу, коли змінюється структура компанії, — наприклад, коли з’являється платформна команда або ви починаєте наймати staff-інженерів. Переписуйте клітинку, якщо на ній раз у раз спотикаються під час оцінювання.

Створіть цю кар’єрну драбину в LadderKit — безкоштовно

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

Почати безкоштовно Відкрити демоверсію Без реєстрації