10 правил создания полезных грейдов для разработчиков. Кейс Kolesa Group

О редакции Подписывайтесь на нас в Google News!
Дата публикации: 01.06.2023, 11:31
Николай Киндяков

«За 5 лет мы меняли систему грейдов (у нас их 9) для backend-разработчиков 9 раз. Это помогло выстроить оптимальные процессы. Пересматриваем уровни не чаще, чем раз в полгода. Поднимаем сразу не больше, чем на один. Защищают грейды не сотрудники, а тимлиды. В среднем за квартал на повышение идет 4-5 человек. Процент отказов – 8,5», – рассказывает директор по разработке Kolesa Group Николай Киндяков.

О том, как создать полноценную систему грейдирования, он поделился на Kolesa TeamLead Day

1. Задайте себе вопрос: «Зачем мне нужны грейды?»

Грейды – не «серебряная пуля». Они не решат всех проблем. Лучше выбрать самую критичную в данный момент. Затем держать на ней фокус в процессе построение грейдовой системы. 

Мы в Kolesa Group определили для себя, что хотим упростить найм. Раньше не было четкого понимания о том, что собой представляет каждый специалист и кому сколько платить.

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

2. Не изобретайте велосипед, когда в этом нет необходимости

Если вы только собираетесь вводить грейдирование, то лучше начать с базовой линейки: джун, мидл, сеньор. Не нужно сходу упарываться и придумывать штуки вроде джун-3, мидл-7 и сеньор-10. К такому делению обычно приходят осознанно, спустя время.

Николай Киндяков

Николай Киндяков

Уловить момент, когда необходимо вводить новые уровни, несложно. Поручайте сотрудникам различные задачи и смотрите, как  они с ними справляются. Если, условно, у одного все получается, а у другого – нет, хотя они оба в вашем понимании джуны, то начните пристально следить за всей командой. В случае массовости подобной истории есть смысл делить грейды на несколько частей.

3. Придумайте измеримые требования для повышения грейда

Традиционно специалиста оценивают по хард и софт скиллам. Человек знает PHP, Redis и MySQL – харды хорошие. А если он не падает в обморок при слове scrum, умеет в коммуникацию и не токсичит в коллективе, то и софты отличные.

Когда мы начинали историю с грейдами, сделали все по-другому. У нас была таблица с огромным количеством разных требований. Однако тогда мы не понимали, что есть вещи, которые никак нельзя измерить: знания, умения, понимание процессов.

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

4. Сделайте все процессы простыми, подвижными и справедливыми

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

Лучше сместить фокус специалистов на выполнение задач и достижение результатов. А в это время ответственные за рост люди (например, тимлиды) будут следить за успехами каждого сотрудника. Когда ребята увидят, что их работа всегда под контролем, а достижения ценятся, то процесс повышения станет прозрачнее.

Kolesa TeamLead Day

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

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

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

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

5. Добейтесь максимальной прозрачности

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

Николай Киндяков

Мы с такой проблемой сталкивались. Выходом стало создание комиссии, в которой участвуют все тимлиды и руководители. На нее приходит тимлид, который предлагает для повышения своего сотрудника и рассказывает, почему тот готов к переходу на новый уровень.
У всех членов комиссии есть право вето. Любой из них может сказать: «Нет, твой разработчик еще не сеньор, по таким-то причинам». В таком случае человеку отказывается в повышении, но дают список для улучшений.

6. Давайте сотрудникам регулярные фидбеки

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

7. Грейды должны иметь ценность

Речь, в первую очередь, о нематериальной ценности. Если все заворачивать только в сторону денег, то в какой-то момент вы упретесь во внешний потолок. Начнете переплачивать и получится так, что бекендеры будут зарабатывать в компании больше всех остальных вместе взятых.

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

Kolesa TeamLead Day

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

8. Распределяйте зарплаты грамотно

Материальная компенсация – важная штука. И она не выглядит такой очевидной, как некоторые привыкли думать. Мол, если чувак стал сильнее, то нужно платить на 100 тысяч тенге больше. Это так не работает.

Между джунами, мидлами и сеньорами пропасти. Джуны – не самостоятельная единица, которую нужно постоянно держать за руку. Горизонт планирования их ответственности – небольшая задачка, которую они сделали и счастливы.

Мидлы – основная боевая единица в команде. На них больше всего ответственности за типичные задачи и тренинг джунов. Это совершенно другой уровень.

Сеньоры имеют еще больше влияния на департаменты, компанию и технологии, вокруг которых и строится работа.

Николай Киндяков

Эти факторы нужно отражать в зарплатной линейке, чтобы это было заметно и подчеркивало важность сотрудника.

9. Сохраняйте актуальность грейдов

Грейды – это не та вещь, в которую вы впрягаетесь только один раз, а потом она просто существует. Нельзя сегодня разделить всех на мидлов и джунов, а завтра сказать сотрудникам: «Ребят, вы все равны, мы передумали…».

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

10. Сделайте их публичными и доступными для всех

Мы в 2021-м году сделали свою систему грейдирования публичной. Поступили так по двум причинам.

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

Kolesa TeamLead Day

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

Итог

Грейды – история про справедливость, которой так мало вокруг нас, но вы можете создавать ее в компании. Это тот самый редкий кейс, когда есть возможность построить маленький справедливый мир для работников. И от того, как вы будете к этому относиться, зависит очень многое в жизни компании.