Джун, мидл и сеньор — стандартные грейды в IT и общая система, которая часто при переходе из компании в компанию перестаёт работать. Вчерашний сеньор получает оффер на мидла, а человек, которого несколько лет никто не повышал, спокойно тянет на тимлида.

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

Из-за этого грейд описывает роль, а не уровень человека. Собеседование в большинстве случаев работает как проверка соответствия конкретной вакансии: нанимающему важно, закроет ли кандидат ту работу, под которую открыта позиция, а решение принимают по задачам, которые он показывает на интервью.

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

• какие задачи закреплены за грейдом, на который вас зовут, и чем они отличаются от задач следующей ступени;
• кто и по каким признакам решает, что человек до этой ступени дотянул;
• есть ли письменное описание требований или всё держится на устной договорённости с руководителем;
• что произойдёт с грейдом, если вы захотите сменить направление внутри компании.

Матрица появляется в тот момент, когда трёх грейдов перестаёт хватать. Разработчик пилит свои фичи, сам же их и тестит, наполовину закрывает работу продакта, а заодно общается с заказчиком напрямую. В системе оценки при этом он всё ещё просто мидл, и непонятно, как учесть половину того, что он реально делает. Поэтому оценку разносят по нескольким направлениям и смотрят на человека сразу вертикально (уровень требуемых компетенций) и горизонтально (количество смежных компетенций).

В вертикаль входит основной стек: язык, фреймворк, качество кода, умение проектировать решения. В горизонталь идёт всё остальное, что помогает довозить задачи, от баз данных и инфры до понимания, зачем бизнесу эта фича. Деньги в такой модели считаются на основе уровня базовых скиллов (вертикаль) и количества дополнительных (горизонталь), поэтому крепкий мидл по стеку с прокачанной продуктовой частью вполне может стоить дороже технаря с одним языком программирования.

С софтами история более понятная: для разработчика они работают как гигиенический минимум — достаточно нормально обсуждать задачи и не превращать ревью в мясорубку, чтобы претендовать на любой технический грейд. Планка поднимается, когда появляется ответственность за людей и процессы, потому что там договариваться приходится постоянно.

Сама матрица грейдов никого не оценивает, оценивают разработчика на ревью. Раз в полгода команда проверяет, что человек закрыл, где вырос и куда двигается дальше. Но у такого процесса есть цена и она достаточно высокая: оценка 20 человек забирает у лида около 40 часов, а при команде побольше он выпадает из работы на месяц. Отсюда растёт соблазн перевести ревью на раз в год, но почти всегда это бьёт по мотивации сильнее, чем экономит время. Оптимальный компромисс: оставить полугодовой цикл и добавить возможность досрочного пересмотра для тех, кто вложился в большую цель и закрыл её раньше срока.

Основной стресс от ревью у разработчика возникает по другой причине. Полгода человек живёт в информационном вакууме, а потом узнаёт о себе много нового за одну встречу. Ситуация становится хуже, когда оценивают только по закрытым тикетам, потому что инициатива, разбор чужих проблем в трекер не попадают.

Что с этим делать разработчику:

• узнать, кто входит в оценивающую группу и по каким критериям она работает, до начала цикла;
• вести свой лог задач и не рассчитывать, что лид вспомнит всё за полгода;
• просить промежуточный фидбэк раз в пару месяцев, чтобы ревью не приносило сюрпризов;
• сверять самооценку с матрицей заранее и приходить с готовыми аргументами;
• спрашивать про досрочный пересмотр, если закрыли что-то крупное вне плана.

Работающая схема почти всегда запускается снизу: разработчик сам приходит и говорит, что готов брать больше. Ждать, пока лид заметит и предложит, можно долго, потому что у него полсотни задач и своя команда, а хорошо закрытые спринты выглядят как норма, а не как заявка на рост.

После разговора обычно дают около трёх месяцев и заранее согласовывают список задач, по которым потом будут оценивать. Формулировки фиксируют до старта, чтобы через квартал никто не спорил о критериях. Задача чаще всего звучит как «возьми процесс, с которым ты раньше не пересекался, и почини его»: разобраться, как он устроен сейчас, собрать данные, предложить решение и в идеале довести его до продакшена.

Такая задача одновременно измеряет и харды, и софты. Допустим, вам достался медленный код-ревью. Сначала придётся понять, где именно теряется время, потом сходить к бизнесу и выяснить, мешает ли им это, потом договориться с лидами соседних направлений. Если кейс не выгорел, спокойно разбирают причину. Иногда человек изначально понял задачу неправильно, иногда упёрся в то, что не смог договориться. Повторная попытка нормально заходит через полгода, когда есть что показать поверх работы над ошибками.

Отдельная засада ждёт тех, кто метит в лиды. Количество таких мест ограничено, и пока текущий лид на месте, вакансия не появится. Рабочих вариантов тут два: дождаться масштабирования, когда команда растёт и лидов реально становится больше, либо найти незанятую зону ответственности, которая важна бизнесу, и защитить её. Второй путь длиннее, зато он работает даже в статичной структуре.

Чтобы не приходить на повышение с пустыми руками, помогает несколько вещей:

• держать в своих годовых целях хотя бы одну, которую вы придумали сами и можете объяснить, зачем она компании;
• заранее спросить, какие задачи закреплены за следующим грейдом, и начать подтягивать их до первого разговора о повышении;
• фиксировать договорённости письменно, включая критерии успеха и сроки;
• показывать промежуточный результат, а не приносить всё разом в конце трёх месяцев.

Инициативу сверх плана компании обычно поощряют отдельно, от поездок на профильные конференции до внутренних конкурсов и премий. Штука приятная, но на грейд она влияет косвенно, поэтому рассчитывать стоит всё-таки на согласованный список задач.

К каждому грейду привязана вилка с минимумом, серединой и максимумом, а разброс между краями обычно составляет 30–40%. Внутри неё можно двигаться без всякого повышения: для этого есть ежегодный пересмотр, завязанный на цели и премию. Как только хочется заметно больше, вилка упирается в потолок, и единственный способ его пробить состоит в смене грейда.

Кадровая служба раз или два в год делает срез рынка и подтягивает границы, потому что рынок ведёт себя как биржа. Двух одинаковых по скиллам мидлов, нанятых с разницей в 2–3 месяца, может разделять большая сумма: за прежние деньги нового человека уже не находят, приходится платить больше. Те, кто давно работает в компании при этом остаются со старой зарплатой, а система грейдов начинает ломаться.

Для тех, кто не собирается в менеджмент, компании обычно держат отдельные способы добавить денег: индексацию за стаж и бонусы за конкретную пользу бизнесу. Работает это ровно настолько, насколько компания готова платить сильному технарю сопоставимо с управленцем. Когда у менеджмента вилки вдвое выше, разработчики довольно быстро делают выводы и уходят в лиды, включая тех, кому это противопоказано.

Всё, что описано выше, проверяется до подписания оффера за один разговор с нанимающим лидом. Вопросы стоит задавать так, чтобы человек не отвечал общими словами про заботу о развитии.

У нас в Centicore Group всё устроено примерно так же: требования по грейдам лежат в открытом доступе, а наставничество вынесено в отдельную роль, поэтому можно и ментора себе найти, и самому взять новичка. Статьи с докладами на конференциях у нас идут в зачёт роста наравне с задачами по проекту.

Грейд описывает роль, которая нужна компании прямо сейчас, поэтому одно и то же слово в двух офферах означает разную работу и разные деньги. Проверять имеет смысл содержание: какие задачи закреплены за уровнем, кто и по каким критериям оценивает, есть ли путь наверх для того, кто не хочет управлять людьми.

Со своей стороны стоит перестать ждать, пока рост заметят. Заявка на повышение почти всегда идёт снизу, дальше выдают 3 месяца и список задач, по которым будут судить, поэтому выгоднее прийти с готовым предложением, чем ждать полугодового ревью. Свой профиль по компетенциям полезно держать в актуальном состоянии независимо от того, есть ли в компании формальная система: он одинаково пригодится и на внутреннем ревью, и на собеседовании в другом месте.