Всем привет!
Меня зовут Константин Щеглов, я – CIO SuperJob. Сегодня я расскажу о нашей системе грейдов, которую мы применяем для ежеквартальной оценки наших разработчиков. Мы поговорим о старой системе и проблемах, с ней связанных, а после этого я расскажу об изменениях, которые мы провели.
![unsplash.com unsplash.com](https://habrastorage.org/getpro/habr/upload_files/d43/d33/761/d43d33761d07e3d66614b837b5f3a4b7.png)
Историческая ретроспектива
На момент начала преобразований наша система грейдов представляла из себя вполне стандартную схему, состоящую из должностей разработчика, старшего разработчика, ведущего разработчика, что соответствовало общепринятым в сфере разработки грейдам junior, middle и senior-разработчика, а пересмотр должностей и зарплат был привязан к нашим ежеквартальным перформанс ревью. Исходная система, в целом, удовлетворяла нашим потребностям и была достаточно гибкой для того, чтобы максимально индивидуально подходить к развитию сотрудников. Но за последний год команда выросла на 50%, поэтому к персональному подходу требовалось приложить системность – мы решили изменить нашу систему грейдов, устранив некоторые недостатки.
Итак, одна из проблем – сотрудники на стартовых позициях могли получать больше денег, чем их коллеги на более высоких грейдах на старте. Да, такая разница возможна, потому что мы не можем при найме нового человека сразу всем менять зарплаты. Понятно, что это случается в моменте и зарплата старшего коллеги увеличится после ближайшего перфоманс ревью, но тем не менее, с такой суровой реальностью сталкивается плюс-минус любая команда. Еще это было связано с тем, что наша система грейдов никак не была привязана к механизмам пересмотра и индексации зарплат. Например, к нам вышел мидл, который активно перформил, мы прибавили ему зарплату, а должность осталась прежней. При этом терялся контроль, на какой грейд мы берем новых сотрудников, что приводило к усугублению предыдущей проблемы.
Кроме того, у нас отсутствовала единая линейка связок «грейд – зарплата» для каждого из направлений разработки. Здесь имеется в виду отдельная система грейдов для бэкенда, отдельная – для фронта, своя – для тестировщиков, другая – для мобильной разработки и т.д. Да, какие-то зарплатные вилки у нас, конечно же, были, но они корректировались на основе рынка и здравого смысла, при заведении новых вакансий. При этом, эти вилки пересекались между собой, что не добавляло стройности нашей системе. Это приводило к тому, что мы использовали пресловутую разбежку «от … до …», что не очень здорово с точки зрения нашего законодательства в части, что люди на одной позиции получают разные зарплаты. Так быть не должно.
Ко всему прочему, прибавки зарплат осуществлялись без учета грейдов и соответствующего изменения должностей.
Итого, все эти проблемы приводили к отсутствию прозрачности для всех участников процесса – как для сотрудников, так и для тимлидов и хэдов направлений, да и для всей компании в целом. И в середине 2021 года мы решили добавить немного упорядоченности к нашей кадровой политике, разработав новую систему грейдов, которая была призвана решить все выше обозначенные проблемы.
Аудит старой системы грейдов
Как театр начинается с вешалки, так и у нас любые изменения начинаются с аудита.
В дополнение к проблемам, упомянутом в предыдущем разделе, беглый аудит существующей системы выявил следующие интересные моменты:
На семь групп бэкенд-разработки у нас приходится три разные системы грейдов, то есть, например, зарплатная вилка ведущего разработчика в одной группе может отличаться от зарплатной вилки такого же ведущего разработчика в другой группе.
У всех групп фронтенд-разработки грейды совпадали, что не могло не радовать. Кроме того, сквозные грейды получились у QA, мобильной разработки и DevOps-команды в силу их малочисленности.
Отсутствовал какой-то единый шаг увеличения зарплат: кто-то получал зарплату, кратную 10 т.р., кто-то – пяти тысяч, а у кого-то сумма зарплаты была, скажем так, своеобразная, например, 200 543 рубля. Что, конечно, ни на какую систему грейдов не ложилось.
Наблюдался некоторый рассинхрон должностей и зарплатных вилок.
И со всем этим нужно было что-то придумать, притом так, чтобы никого не демотивировать и не обидеть. Задача, скажем так, нетривиальная.
Изменение системы грейдов
Дорога покорится идущему, поэтому за несколько итераций удалось выстроить систему, которая бы решила большинство наших проблем. Кроме того, мы разработали план, как из точки «А» прийти в точку «Б», никому не навредив.
Первым делом были зафиксированы базовые грейды, которые мы взяли из уже существующей системы, сохранив тем самым преемственность:
Разработчик.
Старший разработчик.
Ведущий разработчик.
Эксперт.
В некоторых направлениях перед грейдом «Разработчик» мы добавили ещё один грейд «Стажёр», что позволило увеличить разбежку и добавить позиции для сотрудников без опыта работы. Например, в направлении QA, где мы набирали новые кадры под обучение с нуля.
![](https://habrastorage.org/getpro/habr/upload_files/260/1f7/e82/2601f7e82d29daa041b4346fa5003aaa.png)
В направлениях, не связанных с разработкой, грейд «Разработчик» назывался «Специалист», либо «Инженер». Далее не буду проводить между ними различий – буду пользоваться термином «Разработчик».
Следующим шагом нам нужно было решить проблему «Один грейд – одна зарплата», чтобы увеличить нашу маневренность на рынке труда и при этом минимизировать ресурсы для найма и развития сотрудников. Мы остановились на разбивке каждого грейда на пять категорий, где каждой связке «грейд – категория» соответствует одна единственная зарплата. То есть нам удалось полностью избавиться от разбежки зарплаты «от … до …». Правда, категориями мы не перегружаем интерфейсы, например, не указываем их на нашем корпоративном портале. Они служат только для внутренней калибровки.
![](https://habrastorage.org/getpro/habr/upload_files/7c0/77a/da8/7c077ada88cb82f43b52adbdf639386a.png)
Шаг зарплаты между категориями грейда был выбран кратным 10 т.р., что позволило упростить расчеты и получить красивую лесенку не только грейдов, но и зарплат.
К этому моменту нам уже удалось решить одну важную задачу – у нас получилась единая система грейдов, которую мы могли использовать для найма новых сотрудников. Мы пришли к пониманию, какую зарплату человек может получать на определенной должности, тем самым облегчили коммуникацию между рекрутером и нанимающим менеджером. И если выстроить найм в соответствии с полученной схемой, то в долгосрочной перспективе мы бы уже могли перейти на новую схему просто за счет естественной ротации кадров. Но ждать 5-10 лет нам не хотелось, поэтому пришлось решать задачу распределения сотрудников по новым грейдам.
Начальную разметку грейдов мы сделали по текущим зарплатам сотрудников, устранив явные несоответствия как по должностям, так и по зарплатам. Это позволило выполнить первую итерацию задачи, не проводя массовое тестирование сотрудников на соответствие грейда и многочисленные переводы с одной должности на другую. Остальные переводы и индексации зарплат мы делаем постепенно, обозначив себе ориентир завершить переход на новые грейды в течение года.
И если с изменением должностей в сторону повышения не возникло никаких проблем, то в случае с понижением в должности пришлось действовать очень деликатно, применяя индивидуальный подход к сотрудникам. В большинстве случаев нам удалось достигнуть договоренностей, которые устраивали и сотрудников, и компанию. И да, зарплаты мы сделали кратными 10 т.р., с небольшим округлением в большую сторону – тут уж точно никто возражать не стал.
Для сложных случаев мы предусмотрели такой лайфхак: можно создать дополнительный грейд с другим названием (например, «инженер-программист»), что позволяет получить параллельный грейд со своей линейкой зарплат. Такой прием поможет обработать исключения из правил, пока мы приводим штатное расписание к новому виду.
При этом, чтобы избежать формулировки критериев получения той или иной категории, мы ограничились таким правилом – если сотрудник обладает 20% навыков для соответствующего грейда, то он получает пятую категорию, если 40% – четвертую категорию и т.д. Первую категорию грейда разработчик получает за обладанием всем набором навыков соответствующего грейда.
Итого, нам удалось получить более прозрачную систему грейдов, устранив явные недочеты старой системы. Это, в свою очередь, послужило основой, на которой мы в дальнейшем построили матрицы компетенций и индивидуальные планы развития сотрудников, но это тема для отдельной статьи.
На сегодня это всё, чем я хотел с вами поделиться, надеюсь, что наш опыт будет полезен. Спасибо, что дочитали до конца!