DigitableCourses
Карьера

Карта карьеры

Карьера в разработке не одна лестница. Наверху она разветвляется, и ветки — это не «выше и ниже», а другая работа: у менеджера, архитектора и staff-инженера разные предметы ответственности и разные метрики успеха. Ходят по ней во все стороны, включая обратно, и обратный ход — не провал.

Ниже — решётка ролей портала со связями между ними и список компетенций-ориентиров для каждой пары «роль × уровень». Каждая компетенция ведёт в трек каталога, где эту тему разбирают.

Развилки карьеры Что такое грейды

Роли и переходы между ними

10 ролей в 4 группах и 35 переходов. Лестница здесь не одна: часть переходов ведёт вбок — из аналитика в продукт, из бэкенда в SRE, — а часть обратно, и обратный ход портал считает нормальным ходом, а не провалом.

Кто пишет продукт

Разработка под конкретную поверхность: сервер, браузер, телефон.

  • Бэкенд-разработчик

    Серверная часть: данные, API, интеграции, надёжность под нагрузкой.

    Как это называют: В вакансиях встречается как «backend», «серверная разработка», «fullstack с уклоном в бэк». Смотрите не на слово в заголовке, а на список задач.

    Куда отсюда ходят
    • SRE и платформенная инженерия вбок — другая профессия, не повышение Клиентами становятся свои же разработчики. Меняется предмет: не фича, а надёжность и инструменты.
    • Данные и машинное обучение вбок — другая профессия, не повышение Ближе всего через данные и очереди. Придётся добрать статистику, а не только инженерию.
    • Архитектор вглубь — тот же инженерный трек, больший масштаб Не повышение: горизонт растёт до нескольких систем, писать код вы будете меньше.
    • Тимлид, техлид, engineering manager вбок — другая профессия, не повышение Другая профессия с другими метриками успеха. Примерно каждый третий возвращается обратно, и это нормально.
    Компетенции-ориентиры: 4 уровня, 19 пунктов
    Junior

    Ждут не готовых решений, а скорости обучения и качества вопросов.

    • Пишу и запускаю код на рабочем языке без подсказки по синтаксису Могу с нуля собрать маленький сервис: зависимости, запуск, форматирование, линтер. Go
    • Понимаю, что происходит между запросом браузера и ответом сервиса Могу объяснить, почему запрос вернул 502, а не «сервер сломался». Компьютерные сети
    • Пишу SQL-запросы и понимаю, что такое транзакция Собираю выборку с джойном и группировкой без гугла, знаю, чем отличается транзакция от отдельных запросов. Базы данных
    • Работаю в общей ветке, не ломая историю остальным Развожу конфликт, делаю осмысленный pull request, восстанавливаю потерянный коммит. Git и командная работа
    • Локализую ошибку по логам и стектрейсу, а не перебором Формулирую гипотезу, проверяю её, а не меняю строчки наугад. Программирование с нуля
    Middle

    Держит весь путь фичи: от неполных требований до работы в проде.

    • Довожу фичу целиком: требования, код, тесты, выкладка, наблюдение После моего релиза не остаётся хвостов, которые доделывает кто-то другой. Как делают софт и карьера
    • Пишу тесты, которые ловят регрессии, а не повторяют код Могу объяснить, что именно проверяет каждый тест и почему его не жалко удалить. Тестирование ПО
    • Читаю план запроса и чиню медленную выборку Вижу seq scan там, где должен быть индекс, и понимаю, чем платит вставка за каждый лишний индекс. Базы данных
    • Проектирую API, который переживёт следующую версию Умею добавить поле, не сломав старых клиентов, и понимаю цену выбранного стиля API. Архитектурные паттерны
    • Работаю в чужом и старом коде, не переписывая его целиком Могу внести изменение в модуль, автор которого уволился, и объяснить, почему не стал рефакторить всё. Принципы разработки
    Senior

    Платят не за скорость набора кода, а за снятый риск.

    • Выбираю решение по последствиям, а не по моде, и записываю выбор У решений есть ADR: что рассматривали, чем пожертвовали, при каких условиях пересмотрим. Архитектурные паттерны
    • Проектирую с учётом отказов: ретраи, идемпотентность, согласованность Знаю, что произойдёт с данными при обрыве сети посередине операции, и заранее это учёл. Распределённые системы
    • Веду инцидент и пишу разбор без поиска виноватых После разбора остаётся изменение в системе или процессе, а не строчка «быть внимательнее». CI/CD, инфраструктура и облака
    • Ревьюю так, что после ревью человек становится сильнее В комментариях есть «почему», а не только «переделай»; у команды есть общий стандарт. Принципы разработки
    • Вижу в своей фиче поверхность атаки Разбираюсь с авторизацией и секретами до релиза, а не после отчёта пентеста. Безопасность приложений
    Дальше: ветвление, а не ступень

    После сеньора лестница расходится. Остановиться здесь — полноценный выбор, а не потолок.

    • Беру задачи, которые не помещаются в одну команду Довёл до конца работу, у которой не было ни владельца, ни чёткой постановки. Как делают софт и карьера
    • Меняю практики без формальных полномочий Мою идею внедрили команды, которые мне не подчиняются. Как делают софт и карьера
    • Оптимизирую по измерению, а не по ощущению Начинаю с профиля и нагрузочного теста, а заканчиваю числом «стало быстрее на столько». Производительность систем
    • Считаю деньги системы, а не только её архитектуру Могу сказать, во что обходится сервис в месяц и какой из вариантов дешевле при росте вдвое. CI/CD, инфраструктура и облака

  • Фронтенд-разработчик

    Интерфейс в браузере: разметка, состояние, производительность, доступность.

    Как это называют: «Фронтенд» в одной компании — вёрстка по макетам, в другой — целая клиентская архитектура с собственным бэкендом для фронтенда. Уточняйте на собеседовании.

    Куда отсюда ходят
    • Мобильный разработчик вбок — другая профессия, не повышение Похожие задачи состояния и навигации, другой рантайм и другой цикл релизов через сторы.
    • Бэкенд-разработчик вбок — другая профессия, не повышение Через BFF и API. Придётся всерьёз добрать данные и надёжность.
    • Продакт-менеджер вбок — другая профессия, не повышение Частая траектория: близость к пользователю помогает, но метрики успеха меняются полностью.
    • Тимлид, техлид, engineering manager вбок — другая профессия, не повышение Другая работа: у вас больше нет своей задачи, у вас есть чужие.
    Компетенции-ориентиры: 4 уровня, 19 пунктов
    Junior

    Базовая платформа важнее фреймворка: фреймворки меняются, браузер остаётся.

    • Понимаю, что делает браузер между загрузкой и первым кадром Могу объяснить, почему страница мигает, и где в этом виноват мой код. Frontend-разработка
    • Пишу разметку, которая работает без стилей и с клавиатуры Форма отправляется по Enter, кнопка — это button, а не div с обработчиком. Доступность (a11y)
    • Собираю раскладку, которая не разъезжается на телефоне Понимаю, что такое поток, флекс и грид, и не чиню всё абсолютным позиционированием. Frontend-разработка
    • Пишу компоненты и понимаю, откуда в них приходит состояние Отличаю состояние компонента от состояния приложения и не дублирую источник правды. Frontend-разработка
    • Разбираюсь со сборкой проекта, а не только с npm run dev Понимаю, что происходит между исходником и бандлом, и умею починить упавшую сборку. Frontend-разработка
    Middle

    Отвечает за поведение экрана целиком, включая ошибки и пустые состояния.

    • Выбираю способ хранения состояния под задачу, а не по привычке Могу объяснить, почему здесь хватает useState, а там нужен кеш серверных данных. Frontend-разработка
    • Делаю формы, которые честно ведут себя при ошибках сети и валидации Двойной клик не создаёт две записи, а ошибка сервера не стирает введённое. Frontend-разработка
    • Пользуюсь типами как инструментом проектирования, а не как формальностью Невалидное состояние в моих типах невыразимо, а не проверяется в рантайме. TypeScript
    • Тестирую поведение интерфейса, а не детали реализации Тест не ломается от переименования класса, но ломается от сломанного сценария. Тестирование ПО
    • Проверяю доступность до релиза, а не по жалобе Прохожу свой экран клавиатурой и скринридером и знаю, где в нём aria действительно нужна. Доступность (a11y)
    Senior

    Отвечает за клиентскую часть как за систему, а не как за набор экранов.

    • Держу архитектуру клиента: границы модулей, общие контракты, чужой код Новый разработчик добавляет экран, не спрашивая, куда положить файл. Frontend-разработка
    • Улучшаю метрики загрузки по измерению у реальных пользователей Работаю от полевых данных, а не от лабораторного прогона на своём ноутбуке. Производительность систем
    • Осознанно выбираю модель рендеринга и понимаю её цену Могу объяснить, что мы выиграли и что потеряли, уйдя на серверный рендеринг. Frontend-разработка
    • Понимаю клиентские классы атак и не полагаюсь на проверки в браузере Знаю, зачем нужен CSP, и не считаю валидацию на клиенте защитой. Безопасность приложений
    • Разговариваю с дизайном на одном языке и спорю по существу Могу сказать, что в макете дорого и чем это заменить, а не просто «так нельзя». UX и проектирование интерфейсов
    Дальше: ветвление, а не ступень

    Платформа, продукт, менеджмент — это разные работы, а не разные высоты.

    • Делаю инструменты для других команд и отвечаю за их удобство У моей библиотеки есть версионирование, миграции и живые пользователи внутри компании. Frontend-разработка
    • Ставлю практику качества на весь фронтенд компании Правила живут в CI, а не в переписке. CI/CD, инфраструктура и облака
    • Тяну задачи, у которых нет владельца Взял размытую проблему, разложил её и довёл до решения. Как делают софт и карьера
    • Поднимаю уровень команды, а не только свой У меня есть люди, которые выросли рядом со мной и могут это подтвердить. Как делают софт и карьера

  • Мобильный разработчик

    Приложения под iOS и Android: платформа, офлайн, фон, релизы через сторы.

    Как это называют: Под «мобильным разработчиком» понимают и нативную разработку под одну платформу, и кроссплатформенную на Flutter или React Native. Это очень разные наборы навыков.

    Куда отсюда ходят
    • Фронтенд-разработчик вбок — другая профессия, не повышение Ближайший сосед по задачам состояния и навигации; цикл релизов станет намного быстрее.
    • Бэкенд-разработчик вбок — другая профессия, не повышение Через API и синхронизацию. Придётся добрать данные, транзакции и нагрузку.
    • Тимлид, техлид, engineering manager вбок — другая профессия, не повышение Другая профессия. В мобильных командах особенно заметно: релизный цикл начинает управлять вами, а не вы им.
    Компетенции-ориентиры: 3 уровня, 12 пунктов
    Junior

    Сначала платформа и её ограничения, потом фреймворки.

    • Понимаю жизненный цикл экрана и приложения на своей платформе Знаю, что произойдёт с моим экраном при повороте, звонке и убийстве процесса. Мобильная разработка
    • Собираю экраны и навигацию по макету Раскладка выживает на маленьком экране, крупном шрифте и длинном тексте. Мобильная разработка
    • Хожу в сеть и обрабатываю ошибки, а не только счастливый путь Приложение не падает в метро и внятно объясняет, что связи нет. Компьютерные сети
    • Работаю в общей ветке и понимаю релизный цикл команды Знаю, куда мержится моя ветка и что попадёт в ближайший билд. Git и командная работа
    Middle

    Отвечает за фичу целиком, включая офлайн, фон и выкладку в стор.

    • Раскладываю приложение по слоям, а не по экранам Логику можно протестировать без запуска UI. Мобильная разработка
    • Делаю офлайн и синхронизацию, зная, что конфликты будут У меня есть правило разрешения конфликтов, а не надежда, что их не случится. Мобильная разработка
    • Работаю с фоновыми задачами и пушами в рамках ограничений платформы Понимаю, почему система убивает мою фоновую работу, и не борюсь с ней хаками. Мобильная разработка
    • Провожу релиз через стор и умею откатиться Знаю, что делать с багом в проде, когда ревью в сторе занимает сутки. Мобильная разработка
    Senior

    Отвечает за приложение как за продукт с миллионом установленных копий разных версий.

    • Держу запуск, память и батарею в пределах, которые сам измерил У меня есть цифры до и после, снятые на реальном слабом устройстве. Производительность систем
    • Защищаю данные на устройстве, которое мне не принадлежит Не храню секреты в приложении и знаю, что клиент всегда можно вскрыть. Безопасность приложений
    • Строю тестирование, которое переживает зоопарк устройств Знаю, что мы автоматизируем, а что осознанно проверяем руками, и почему. Тестирование ПО
    • Осознанно выбираю нативное или кроссплатформенное решение Могу назвать цену выбора для конкретной команды, а не спорить о фреймворках вообще. Мобильная разработка

Кто отвечает за качество и прод

Работа, где ценность — не написанный код, а то, что система не падает и не врёт.

  • QA-инженер

    Качество как отдельная работа: тест-дизайн, автоматизация, обратная связь процессу.

    Как это называют: Портал различает мануального QA, автоматизатора и SDET. В вакансиях эти три слова часто перепутаны — уточняйте, что именно будет вашим предметом.

    Куда отсюда ходят
    • Бэкенд-разработчик вбок — другая профессия, не повышение Обычная траектория через SDET. Придётся всерьёз добрать проектирование, а не только автоматизацию.
    • SRE и платформенная инженерия вбок — другая профессия, не повышение Через тесты в CI и наблюдаемость: предмет тот же — доверие к системе.
    • Системный и бизнес-аналитик вбок — другая профессия, не повышение QA часто первым замечает противоречия в требованиях — это половина работы аналитика.
    Компетенции-ориентиры: 3 уровня, 12 пунктов
    Junior

    Главный навык — не «уметь кликать», а описывать наблюдаемое так, чтобы это можно было воспроизвести.

    • Пользуюсь терминологией тестирования одинаково с командой Не путаю дефект, отказ и ошибку и не спорю о словах на разборе бага. Тестирование ПО
    • Проектирую проверки, а не перебираю варианты вслепую Использую классы эквивалентности и границы и могу объяснить, почему этих проверок достаточно. Тестирование ПО
    • Пишу баг-репорт, по которому дефект воспроизводится с первого раза Разработчик не приходит с вопросом «а как это повторить». Тестирование ПО
    • Проверяю API напрямую, не только через интерфейс Умею отправить запрос руками и понять, на чьей стороне проблема. Тестирование ПО
    Middle

    Отвечает за то, чтобы автоматизация экономила время, а не съедала его.

    • Пишу автотесты, которые не мигают У набора нет «иногда красных» тестов, которые все привыкли перезапускать. Тестирование ПО
    • Встраиваю тесты в конвейер так, чтобы их результату верили Красный билд останавливает выкладку, и никто не воспринимает это как помеху. CI/CD, инфраструктура и облака
    • Программирую на уровне, достаточном для поддержки тестового кода Мой тестовый проект не хуже продуктового: он тоже читается и рефакторится. Python
    • Проверяю не только функциональность Умею поставить нагрузочный прогон и проверить базовые вещи по безопасности. Тестирование ПО
    Senior

    Предмет работы — не тесты, а то, насколько команде можно доверять своему релизу.

    • Строю стратегию тестирования под риски продукта, а не по шаблону пирамиды Могу объяснить, почему здесь мало юнит-тестов, и это осознанное решение. Тестирование ПО
    • Ловлю дефект на этапе требований, а не в проде Мои вопросы к постановке меняют постановку до начала разработки. Системный и бизнес-анализ
    • Меряю качество процесса, а не количество написанных тестов Смотрю на время до восстановления и долю неудачных релизов, а не на покрытие ради покрытия. Project Management
    • Понимаю развилки внутри качества и выбираю свою осознанно Могу объяснить разницу между SDET, инженером по качеству процесса и аналитиком рисков. Тестирование ПО

  • SRE и платформенная инженерия

    Надёжность и инструменты для других команд: инфраструктура как код, наблюдаемость, дежурства.

    Как это называют: DevOps-инженер, SRE и platform engineer — три разных набора обязанностей под тремя перепутанными названиями. Иногда за этими словами скрывается «эникейщик с ямлом».

    Куда отсюда ходят
    • Бэкенд-разработчик обратно — портал не считает это провалом Обратный переход обычен и не считается провалом: опыт эксплуатации делает инженера дороже.
    • Архитектор вглубь — тот же инженерный трек, больший масштаб Кто держал прод, лучше видит нефункциональные требования — это половина работы архитектора.
    • Данные и машинное обучение вбок — другая профессия, не повышение Через конвейеры и хранилища. Инфраструктурная часть знакома, статистика — нет.
    • Тимлид, техлид, engineering manager вбок — другая профессия, не повышение Другая профессия. Отдельный риск: в дежурной команде менеджер быстро становится диспетчером инцидентов.
    Компетенции-ориентиры: 3 уровня, 15 пунктов
    Вход

    Сюда почти не приходят с нуля: нужен опыт либо разработки, либо администрирования.

    • Уверенно живу в Linux без графического интерфейса Могу найти, что съело диск и процессор, не устанавливая ничего лишнего. Операционные системы
    • Разбираю сетевую проблему по слоям, а не перезагрузкой Умею дойти от «не работает» до конкретного места: DNS, маршрут, TLS, балансировщик. Компьютерные сети
    • Собираю и запускаю контейнеры осознанно Понимаю, чем контейнер отличается от виртуалки и почему мой образ весит гигабайт. CI/CD, инфраструктура и облака
    • Строю конвейер сборки и выкладки У проекта есть повторяемая сборка, которую можно запустить не с моего ноутбука. CI/CD, инфраструктура и облака
    • Пишу код, а не только конфиги Мои скрипты лежат в репозитории, проходят ревью и имеют тесты. Python
    Основной уровень

    Отвечает за платформу, которой пользуются другие команды.

    • Держу инфраструктуру в коде, а не в кликах по консоли Окружение поднимается заново из репозитория, и мы это проверяли. CI/CD, инфраструктура и облака
    • Эксплуатирую оркестратор, а не только пишу манифесты Понимаю, почему под не поднимается, и умею читать события кластера. CI/CD, инфраструктура и облака
    • Строю наблюдаемость, по которой можно вести расследование По дашборду видно, что сломалось, а не только что «что-то красное». CI/CD, инфраструктура и облака
    • Выкладываю без простоя и умею откатиться Канареечный или сине-зелёный релиз у нас работает, а не описан в вики. CI/CD, инфраструктура и облака
    • Не храню секреты в репозитории и умею их менять Ротация секрета — обычная операция, а не спецоперация. Безопасность приложений
    Senior и дальше

    Предмет работы — не серверы, а надёжность как договорённость с продуктом.

    • Формулирую цели надёжности вместе с продуктом и живу по ним У сервиса есть согласованный уровень доступности, и он влияет на решения о релизах. Распределённые системы
    • Проектирую систему под отказы, которые обязательно случатся Знаю модель отказов своей системы и что произойдёт при разделении сети. Распределённые системы
    • Управляю стоимостью инфраструктуры как инженерной задачей Могу назвать, что стоит дороже всего, и предложить размен без потери надёжности. CI/CD, инфраструктура и облака
    • Строю дежурство, которое не выжигает людей Ночные срабатывания разбираются и уменьшаются, а не считаются нормой профессии. Тайм-менеджмент для инженера
    • Отношусь к своей платформе как к продукту для внутренних клиентов У платформы есть документация, обратная связь и понятный путь миграции. Product Management

Кто работает со смыслом и данными

Роли, в которых главный вопрос — «что и зачем», а не «как».

  • Данные и машинное обучение

    Конвейеры данных, модели, вывод моделей в прод и честная оценка их качества.

    Как это называют: Дата-инженер, дата-сайентист, ML-инженер и «AI-инженер» — разные профессии. Часть вакансий с ИИ в названии — это переименованный бэкенд, надо смотреть содержание.

    Куда отсюда ходят
    • Бэкенд-разработчик вбок — другая профессия, не повышение Инженерная часть переносится почти целиком; уходит статистика, добавляется нагрузка.
    • Системный и бизнес-аналитик вбок — другая профессия, не повышение Общий предмет — данные, но у аналитика заказчик внутри бизнеса, а не модель.
    • Продакт-менеджер вбок — другая профессия, не повышение Обычный переход для тех, кто устал доказывать ценность модели и хочет решать, что вообще строить.
    • SRE и платформенная инженерия вбок — другая профессия, не повышение Через MLOps: те же конвейеры и наблюдаемость, только предмет — не сервис, а модель.
    Компетенции-ориентиры: 3 уровня, 15 пунктов
    Вход

    База здесь двойная: инженерия и математика. Без второй половины получается копирование ноутбуков.

    • Пользуюсь вероятностью и статистикой, а не только средним значением Понимаю, чем распределение отличается от среднего, и почему выборка бывает нерепрезентативной. Математика для программиста
    • Достаю данные сам и понимаю, откуда они взялись Пишу нетривиальный SQL и знаю, какие поля в источнике врут. Базы данных
    • Пишу воспроизводимый код анализа, а не одноразовый ноутбук Мой результат повторяется на другой машине и через месяц. Python
    • Готовлю признаки и понимаю, что данные грязные всегда Проверяю пропуски, выбросы и утечку целевой переменной до обучения. Машинное обучение
    • Начинаю с простой модели и сравниваю всё с ней У меня есть базовое решение, которое надо было превзойти, а не только нейросеть. Машинное обучение
    Основной уровень

    Отвечает за то, чтобы модель приносила пользу за пределами ноутбука.

    • Оцениваю модель честно, включая то, где она ошибается Выбираю метрику под задачу, а не ту, которая красивее, и знаю цену ошибок каждого рода. Машинное обучение
    • Строю конвейеры данных, которые переживают сбой источника Пересчёт за вчерашний день — обычная операция, а не ручная починка. Data Engineering и ETL
    • Отвечаю за качество данных, а не только за код, который их читает У витрины есть проверки, и они срабатывают раньше, чем это заметит бизнес. Data Engineering и ETL
    • Довожу модель до прода и слежу за ней после запуска Знаю, когда модель протухла, и у меня есть план переобучения. Машинное обучение
    • Работаю с языковыми моделями инженерно, а не подбором промптов наугад У моего решения есть оценка качества и оценка стоимости запроса. ИИ-агенты и prompt engineering
    Senior и дальше

    Предмет работы — решение бизнес-задачи, а не показатель на отложенной выборке.

    • Перевожу задачу бизнеса в задачу обучения — или честно говорю, что модель здесь не нужна У меня есть проекты, которые я предложил закрыть, потому что хватало правила из трёх условий. Product Management
    • Ставлю эксперимент так, чтобы его результату можно было верить Считаю мощность заранее и знаю, что такое подглядывание в промежуточные результаты. Product Management
    • Держу нагрузку и стоимость вывода модели Знаю, во что обходится один запрос, и умею уменьшить это число. Производительность систем
    • Вижу риски модели: данные, приватность, вред от ошибки Могу назвать, кому и как навредит ошибка моей модели, и что мы с этим сделали. Безопасность приложений
    • Объясняю результат людям, которые не читают графиков После моего доклада принимают решение, а не просят «прислать презентацию». Логика и ошибки мышления

  • Системный и бизнес-аналитик

    Превращает размытое «надо сделать» в требования, по которым можно построить и проверить систему.

    Как это называют: Бизнес-аналитик и системный аналитик — разные роли, а в маленьких компаниях это один человек, который заодно и продакт, и техписатель.

    Куда отсюда ходят
    • Продакт-менеджер вбок — другая профессия, не повышение Одна из самых частых траекторий. Меняется вопрос: не «как правильно записать», а «стоит ли это делать».
    • Бэкенд-разработчик вбок — другая профессия, не повышение Возможен, если добрать инженерию всерьёз. Понимание предметной области при этом остаётся преимуществом.
    • Данные и машинное обучение вбок — другая профессия, не повышение Через аналитику данных. Придётся добрать статистику и инженерию конвейеров.
    • QA-инженер вбок — другая профессия, не повышение Смежная работа: критерии приёмки — общий предмет обеих ролей.
    Компетенции-ориентиры: 3 уровня, 12 пунктов
    Junior

    Главное умение — задавать вопросы, а не оформлять документы.

    • Вытаскиваю требования из людей, которые не умеют их формулировать После моей встречи остаётся не пересказ, а список решений и открытых вопросов. Системный и бизнес-анализ
    • Различаю виды требований и не путаю их между собой Не смешиваю бизнес-цель, пользовательский сценарий и техническое ограничение в одном пункте. Системный и бизнес-анализ
    • Пишу документ, который читают и по которому работают Разработчик не приходит с вопросом «а что здесь имелось в виду». Системный и бизнес-анализ
    • Рисую схемы в общепринятой нотации, а не произвольными квадратиками Мою диаграмму понимает человек, который не был на встрече. Системный и бизнес-анализ
    Middle

    Отвечает за то, чтобы построенное соответствовало задуманному.

    • Проектирую модель данных вместе с разработкой Понимаю, во что превратится моя сущность в базе и почему это важно. Системный и бизнес-анализ
    • Описываю интеграции и контракты между системами Мой контракт содержит поведение при ошибках, а не только счастливый путь. Системный и бизнес-анализ
    • Формулирую нефункциональные требования числами Вместо «должно быть быстро» у меня написано, при какой нагрузке и с каким временем ответа. Системный и бизнес-анализ
    • Пишу критерии приёмки, по которым можно проверить результат По моим критериям можно написать тест, не спрашивая меня. Системный и бизнес-анализ
    Senior и дальше

    Предмет работы — не документ, а согласие сторон, которые друг друга не понимают.

    • Работаю с предметной областью, а не только с формулировками Могу оспорить требование заказчика, потому что понимаю его бизнес лучше, чем он рассказал. Domain-Driven Design
    • Веду анализ внутри итераций, а не большим документом заранее Требования уточняются по ходу, и это не считается провалом планирования. Системный и бизнес-анализ
    • Свожу конфликтующие требования разных сторон к решению Умею вывести спор из «кто главнее» в «чем мы платим за каждый вариант». Логика и ошибки мышления
    • Понимаю архитектурные последствия своих требований Знаю, какое требование только что сделало систему распределённой. Архитектурные паттерны

  • Продакт-менеджер

    Решает, что и зачем строить, и отвечает за результат, а не за объём выпущенного.

    Как это называют: Product manager и product owner в разных компаниях означают то одно и то же, то принципиально разное. В стартапе продакт часто ещё и аналитик, и маркетолог.

    Куда отсюда ходят
    • Системный и бизнес-аналитик обратно — портал не считает это провалом Возврат в анализ — нормальный ход, особенно если не хочется отвечать за коммерческий результат.
    • Тимлид, техлид, engineering manager вбок — другая профессия, не повышение Смежная работа с людьми, но предмет другой: не команда, а ценность для пользователя.
    • Данные и машинное обучение вбок — другая профессия, не повышение Через продуктовую аналитику. Придётся перестать заказывать цифры и начать их считать.
    Компетенции-ориентиры: 3 уровня, 12 пунктов
    Вход

    Сюда обычно приходят из разработки, анализа или поддержки, а не с нуля.

    • Разговариваю с пользователями и не подсказываю им ответы Из интервью выношу описание проблемы, а не подтверждение своей идеи. Product Management
    • Выбираю метрику, которую нельзя накрутить, не сделав продукт лучше Могу объяснить, как моя метрика связана с деньгами и где её можно обмануть. Product Management
    • Приоритизирую так, что решение можно объяснить команде У отказа есть причина, а не «так решили наверху». Product Management
    • Формулирую задачу так, чтобы её можно было построить Команда не приходит с вопросом «а что делать, если сервис недоступен». Системный и бизнес-анализ
    Основной уровень

    Отвечает за направление, а не за список задач в спринте.

    • Проверяю гипотезы экспериментом, а не совещанием У гипотезы заранее написано, какой результат её опровергнет. Product Management
    • Держу стратегию и умею сказать «нет» хорошей идее У роадмапа есть логика, а не только список пожеланий стейкхолдеров. Product Management
    • Считаю юнит-экономику своего продукта Знаю, сколько стоит привлечение и сколько приносит пользователь, а не только DAU. Бизнес для инженера
    • Работаю с командой разработки, не превращаясь в диспетчера задач Команда знает, зачем делает фичу, и может предложить более дешёвое решение той же проблемы. Project Management
    Senior и дальше

    Предмет работы — портфель ставок, часть из которых обязана не сыграть.

    • Управляю ставками, а не задачами У меня есть закрытые направления, и я могу объяснить, чему они нас научили. Product Management
    • Отличаю данные от их интерпретации Не путаю корреляцию с причиной и вижу выжившую выборку в чужом отчёте. Логика и ошибки мышления
    • Веду переговоры со стейкхолдерами, у которых противоположные цели Договорённость держится дольше одного совещания. Как делают софт и карьера
    • Понимаю техническую цену своих решений Могу обсуждать техдолг как продуктовое решение, а не как каприз разработки. Как делают софт и карьера

Кто отвечает за масштаб

Другая профессия, а не следующая ступень: предмет работы меняется с кода на людей и системы.

  • Тимлид, техлид, engineering manager

    Работа про людей и поток задач. Не следующий уровень разработчика, а другая профессия.

    Как это называют: Слово «тимлид» покрывает три разных набора ответственности: техлид отвечает за техническое направление, тимлид — за поток работы, engineering manager — за людей и их развитие. Уточняйте, что имеют в виду именно здесь.

    Куда отсюда ходят
    • Бэкенд-разработчик обратно — портал не считает это провалом Примерно каждый третий возвращается в инженеры, и это хорошая новость. Человек после года в менеджменте стоит дороже, чем был.
    • Продакт-менеджер вбок — другая профессия, не повышение Смежная работа. Меняется предмет ответственности: не команда, а результат для пользователя.
    • Архитектор вбок — другая профессия, не повышение Обратно в техническую ветку, но с сохранением масштаба: несколько систем вместо одной команды.
    Компетенции-ориентиры: 3 уровня, 13 пунктов
    Tech lead

    Предмет — техническое направление команды. Код ещё пишет, но меньше.

    • Задаю техническое направление и объясняю его команде Решения записаны, и по ним можно спорить без меня. Архитектурные паттерны
    • Держу планку качества, не становясь узким местом Ревью не ждёт меня сутки, а стандарт живёт в линтере и CI. Принципы разработки
    • Управляю техдолгом как планом, а не как жалобой У долга есть список, оценка последствий и место в расписании. Как делают софт и карьера
    • Развиваю людей через задачи, а не через советы Даю задачу на вырост и остаюсь рядом, а не забираю её обратно на второй день. Как делают софт и карьера
    Team lead и engineering manager

    Предмет — люди и поток работы. Своей работы больше нет, есть чужая.

    • Веду регулярные встречи один на один, на которых говорят правду Люди приносят проблемы до того, как пишут заявление. Как делают софт и карьера
    • Даю обратную связь, включая неприятную, вовремя На ревью результатов не бывает сюрпризов. Как делают софт и карьера
    • Делегирую вместе с полномочиями, а не только с ответственностью Задача уходит целиком, и я не переделываю её ночью. Управление: базовые материалы
    • Смотрю на поток работы, а не на занятость людей Меряю время прохождения задачи, а не количество закрытых тикетов. Project Management
    • Нанимаю и провожу собеседования, за которые не стыдно Мои интервью проверяют работу, а не эрудицию, и кандидат получает ответ в срок. Как делают софт и карьера
    Head of и выше

    Предмет — несколько команд и правила, по которым они работают.

    • Проектирую границы команд, а не только их состав Понимаю, какие зависимости между командами создала выбранная нарезка. Как делают софт и карьера
    • Ставлю процесс под контекст, а не внедряю фреймворк целиком Могу объяснить, какую конкретную проблему решает каждый элемент процесса. Project Management
    • Разговариваю с бизнесом на языке денег и сроков Мой бюджет и мои обещания сходятся с реальностью чаще, чем расходятся. Бизнес для инженера
    • Держу нагрузку команды на уровне, который можно выдерживать годами У нас нет героизма как нормы и переработок как планового ресурса. Тайм-менеджмент для инженера

  • Архитектор

    Отвечает за решения, цена ошибки в которых — годы, а не спринт.

    Как это называют: Самое запутанное слово в отрасли: software architect, solution architect и enterprise architect — три разные должности. На собеседовании обязательно уточняйте, какую именно имеют в виду.

    Куда отсюда ходят
    • Бэкенд-разработчик обратно — портал не считает это провалом Возврат в разработку нормален: архитектор, оторвавшийся от кода на два года, начинает проектировать вслепую.
    • Тимлид, техлид, engineering manager вбок — другая профессия, не повышение Другая профессия с тем же масштабом: там предмет — люди, здесь — системы.
    • SRE и платформенная инженерия вбок — другая профессия, не повышение Смежная работа: нефункциональные требования и отказоустойчивость — общий предмет.
    Компетенции-ориентиры: 3 уровня, 12 пунктов
    Software architect

    Архитектура одной системы. Ближе всего к коду из трёх вариантов.

    • Выбираю архитектурный стиль под задачу и знаю его цену Могу объяснить, почему здесь модульный монолит, а не микросервисы. Архитектурные паттерны
    • Записываю решения так, чтобы их можно было пересмотреть У каждого крупного выбора есть ADR с контекстом и условиями пересмотра. Архитектурные паттерны
    • Провожу границы по предметной области, а не по слоям кода Мои модули совпадают с тем, как бизнес думает о своей работе. Domain-Driven Design
    • Понимаю, что делает распределённость с данными Знаю, где у нас согласованность в конечном счёте, и что видит пользователь в этот момент. Распределённые системы
    Solution architect

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

    • Проектирую интеграции между системами разных владельцев Контракт переживает то, что вторая сторона изменит свою систему без предупреждения. Архитектурные паттерны
    • Перевожу «надёжно и быстро» в конкретные числа и проверяю их У решения есть нагрузочный расчёт, а не только схема на слайде. Производительность систем
    • Закладываю безопасность в архитектуру, а не навешиваю после Модель угроз обсуждается до реализации и влияет на выбор решения. Безопасность приложений
    • Планирую миграцию, которую можно остановить на середине У перехода есть промежуточные состояния, в каждом из которых система работает. Базы данных
    Enterprise architect

    Ландшафт всей компании. Кода здесь почти нет, зато есть политика и деньги.

    • Вижу ландшафт систем компании и знаю, что с чем связано Могу сказать, какие системы упадут, если выключить эту. Как делают софт и карьера
    • Ввожу правила, которые команды соблюдают без надзирателя Стандарт удобнее нарушения, поэтому его не обходят. Как делают софт и карьера
    • Обосновываю архитектурные решения деньгами и рисками Разговариваю с финансовым директором на его языке, а не показываю схемы. Бизнес для инженера
    • Учитываю требования регуляторов до проектирования, а не после проверки Знаю, где у нас персональные данные и что с ними по закону можно делать. Безопасность приложений

Самооценка: разметить себя и увидеть пробелы

Три состояния на пункт — «делаю», «делаю с поддержкой», «не делаю» — взяты из материала «Как расти: план развития и обратная связь». Результат самооценки — карта пробелов, а не уровень. Портал не назовёт вас джуном, мидлом или сеньором: у него нет для этого данных, а у слов нет общего значения между компаниями.

Отметки хранятся только в этом браузере (localStorage, ключи digitable:career:*). Регистрация не нужна, никуда ничего не отправляется, кнопка «Сбросить» удаляет их целиком.

Самооценка требует JavaScript: она считает карту пробелов прямо в браузере и хранит отметки локально. Без него страница остаётся полезной — выше лежит вся решётка ролей и полный список компетенций со ссылками на треки.

Список компетенций — ориентир этого портала, а не отраслевой стандарт и не матрица вашего работодателя. Внешние матрицы, с которыми полезно сверяться, перечислены в материале про грейды; читать их стоит по два соседних уровня сразу — ценность в дельте между ними.