🈴 Как разработать и внедрить систему грейдов не умерев по пути. Часть 1 из 2 🈴

 Публичный пост
13 апреля 2022  1263

5 направлений разработки (Frontend/Java/C#/Mobile Native/RIA), 500+ инженеров, 30+ команд, 1 система грейдов, сделанная и внедренная через боль и слезы. Поделюсь тем как мы разработали- протестировали-исправили (повторить N раз) и выкатили ее в этих условиях, о собранных граблях и усвоенных уроках.

Материала получилось много, поэтому будет 2 части - в первой опишу цели/проблемы/обшепринятые подходы в разрезе грейдов и то как я пробовал внедрить их в рамках одного направления (фронтэнд разработка на 60-70 человек).
Во второй - про объединение системы с другими направлениями разработки и о внедрении в масштабах всей компании.

📝 Краткое содержание первой части:

  1. ГРЕЙДЫ НЕ НУЖНЫ
  2. Системы грейдов которые есть
  3. Стартуем во фронтэнде - описание
  4. Стартуем во фронтэнде - тестирование
  5. Итоги первой части

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

⛔ ГРЕЙДЫ НЕ НУЖНЫ

Часто при рассказе о каком-то подходе/системе менеджмента/практике и тд слышны возгласы "Все хуйня, автор пидор, так не работает ".

Проблема заключаетя в том, что работающие (не хорошие, не правильные, а именно работающие) подходы/системы/whatever для команд в 5/50/500 инженеров ОЧЕНЬ СИЛЬНО ОТЛИЧАЮТСЯ. Также важно понимать контекст и задачи бизнеса , знать место от села до гугла и тд.

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

Мое мнение про грейды - для лампового стартапа в 5 человек делать подобную систему - примерно как ставить дорогие спортивные колодки на ВАЗ 2109 - потратите много денег, понтанетесь перед пацанами, но практической пользы будет мало.
Конечно никто не мешает вам потихоньку делать систему оценки с самого старта жизни компании. Оптимальная точка старта (имхо) 30-50 инженеров. Мы начали внедрение чуть-чуть позже (с 500). Но лучше конечно раньше.
Допустим вы все же решили что грейды таки нужны, но уважаемые люди из разработки резонно говорят:

ЗАЧЕМ НУЖНЫ ЭТИ ВАШИ ГРЕЙДЫ НОРМАЛЬНО ЖИЛИ БЕЗ НИХ!1!

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

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

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

⛰️ 🆚 🍆 Какие есть подходы есть к грейдам?

Условно говоря можно выделить 2 основных школы грейдов:

⚙️ Хардскилловая ака Объективная

По ощущениям чаще встречается на просторах РФ. Основные признаки: сеньор тот кто больше/глубже всех знает. Отсюда вытекает структура - хочешь уровень Х+1 - учи матчасть (иногда в свободное время) и сдавай экзамен. Из плюсов - довольно четкие критерии повышения. Минусы - не всегда связано с рабочими задачами (крудошлепишь на проекте, а чтобы получить +1 нужно учить алгоритмы, вопрос зачем это все бизнесу остается открытым), траты времени принимающих экзамен.
В качестве примера можно посмотреть компанию Metalamp, это одна из первых систем которую я пытался взять за образец и прикрутить к нашему фронтэнду (спойлер - не взял).
Тут видео с рассказом от автора:


И опенсорсная репа с подробным описанием

ЗЫ ребята в Металамп растят действительно сильных инженеров, за это им респект и уважуха

И еще пример платформы (ходят слухи что ЕПАМа) по обучению, основная часть грейдов - про знания в конкретной области.

Сейчас платформа недоступна, причину выяснить не удалось
Сейчас платформа недоступна, причину выяснить не удалось

🍦Софтскилловая ака субъективная

Будь клиентоориентированным проактивным коммуникабельным вовлеченным ламповым котиком и получишь апгрейд. Распространен в кровавом западном энтерпрайзе где cultural fit > engineering skill (сплевывает через зубы в сторону). Из плюсов - больше заточена под нужды бизнеса, комплексно подходит к оценке человека. Минусы - чтобы понять как апнуться нужна пояснительная бригада, оставляет простор для широкого трактования.
Яркий пример - Dropbox

Очень интересно, но че делать-то?
Очень интересно, но че делать-то?

🌌 Выбираем свой путь

А теперь о главном.
Как определить кто победит в этой битве двух якодзун когда речь зайдет о грейдах для вашей компании? Вам поможет народная мудрость:

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

Для аутстаффа важен скилл прохождения интервью: так уж сложилось что на интервью дрючат по техчасти. Ну и делайте систему которая будет помогать пройти интервью - вопросы про 0.1 + 0.2, event loop и тд.
Для огромного продукта умение работать в команде, cultural fit и прочие diversity чаще выглядит приоритетней глубоких знаний.
Для стартапа важна скорость доставки на прод, тестирование гипотез и тд, а грейды нахуй не нужны. А если думаете что нужны - делайте, стартап-то ваш.

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

🚍 Стартуем во фронте - разработка

📨 Вводные

В каких условиях я начинал работу над системой грейдов (про важность контекста помните же, правда?):

  • 5 направлений разработки (Frontend/Java/Net/Mobile Native/RIA);
  • 500+ инженеров всего, 60+ фронтэнд разработчиков, 30+ команд;
  • продуктово-аутсорсная компания. Да, так бывает. Мы делаем свои торговые платформы (акции, валюта, фьючерсы и тд), ставим и дорабатываем их, пилим с нуля то чего нет в продукте (например выпуск и торговлю NFT)
  • у каждого инженера есть должность формата младший/старший/ведущий/просто разработчик что похоже на грейд;
  • иногда происходят ротации и команда be like "Сенбор которого вы мне дали у нас даже стажеру кофе носить не годится, заберите";
  • миддлом можно быть очень долго, миддлы очень разные;
  • есть процесс перфоманс ревью и внутренняя ЕРП система где хранятися его артефакты;

📒 Струтура и наполнение

С чего же начать когда уже впитал мудрость систем грейдов других компаний и готов строить свой космолет?
Я начал с формулирования сути - как одним предложением охарактеризовать джуна/миддла если ты не Хэмингуэй?

У меня получились следующие критерии для первичного определения грейда:

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

Примерно так выглядит апгрейд
Примерно так выглядит апгрейд

Вокруг этих концепций в итоге и строили всю дальнейшую работу.
Следующим шагом добавил вторичные парметры:

  • харды . Что должен знать разработчик на каждом из уровней, пока в 2х словах;
  • софты. Команды большие, общаться и понимать коллег надо кто бы что ни говорил;
  • анти-паттерны. Сенбор называет всех тупыми мудаками на ревью? Джун ленится зайти в документацию перед тем как задать вопрос? Миддл выдает непредсказуемый результат?
  • аддоны. Сюда попали nice-to-have вещи вроде написания статей, выступления на митапах, опенсорс и другие годные активности

Первая версия структуры грейда
Первая версия структуры грейда

Со структурой каждого грейда определились, а сколько их будет?

Все текущие уровни кроме миддла особых сомнений не вызывали (отсутствие описания и критериев мы в расчет не берем), я решил упростить жизнь и немного подрихтовать то что есть, дополнительно разделив уровень миддла на 3. Зачем это делать? Понятие миддла настолько растяжимое что туда записывают всех поголовно, начиная от вчерашнего джуна до без пяти минут сеньора. В итоге получаем огромный разброс полезности/скилловости на одном и том же уровне.
Забегая вперед скажу что все уровни оказались в финальной версии кроме самого последнего, восьмого. Ибо это штучные экземпляры с лютым опытом.

Грейды TL:DR версия
Грейды TL:DR версия

У нас есть число уровней, структура каждого, теперь наполним каждый из уровней содержательной частью - чего собственно говоря ожидаем от человека грейда N.

Люблю майндмапы
Люблю майндмапы

Это упражнение занимает прилично времени, но пропустить его конечно не получится.

И тут можно было бы начинать тестировать систему, но Остапа понесло и я приделал к системе грейдов еще ценности...

Ценное
Ценное

и перки

Кросивое
Кросивое

Впрочем, в итоговую систему они не вошли, оно и правильно - чем проще тем лучше. Помните об этом когда соберетесь строить свою сверкающую систему грейдов.

Все готово, можно в прод?
И тут кроется самая главная сложность подобных систем. Для себя я сформулировал ее следующим образом:

Главной проблемой для сложной системы является ее внедрение, а не разработка

У нас есть описание каждого уровня, но что делать дальше? Как оценить софты? В каких единицах? Как часто можно просить повышение грейда? Кто и как оценивает? Можно ли оспорить решение? Где смотреть результаты менеджеру оценивающего? Что получится на выходе? Зачем мы здесь?
Над этими вопросами в идеальном мире задумываться с самого начала. Те идти путем от обратного. Подробней об этом методе можно почитать в книге Working Backwards: Insights, Stories, and Secrets from Inside Amazon. Рекомендую ознакомиться, смотреть на вещи под другим углом бывает полезно.
Но раз уж мы зашли так далеко - начинаем думать как приложить уже сделанную систему к нашей реальности.

🪜 Процесс оценки

Начнем с базовых правил исходя из наших целей и ограничений которые я определил:

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

Одного этого конечно же мало, и тут мы подходим к пожалуй самой сложной части процесса - разработке формы оценки. В каких единицах будем производить измерения того что заявлено в грейде? Самый простой подход - проставить 0/1 каждому пункту описания. Добавим оценку в процентах от 0 до 100 более сложным концепциям (например, соотвествие уровню сложности выполняемых задач) и кажется можно проводить первые тесты.

Понятно (не очень)
Понятно (не очень)

Ну и последним штрихом определимся с процессом:
Пробовали 2 подхода:

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

Добавим часть про принятие решений:

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

Поздравляю, все готово к тестированию на живых людях!

🧪 Стартуем во фронте - тестирование

Систему до этого момента я разрабатывал почти в одно лицо, периодически синхронизируясь по некоторым ее частям с лидами фронтэнда. Так лучше не делать и вот почему:

Эффективность системы = Принятие командой * Качество решения. Каждый множитель колеблется от 0 до 1. Обнуление любой из частей справа приводит к провалу. Принятие команды для систем в разработке которых она участвовала на порядок выше

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

первый вариант презентации
первый вариант презентации

Стало лучше, но отклика все еще не много.
Скорее всего люди которым надо будет работать с системой поймут ее и дадут детальный фидбэк не раньше чем опробуют ее на своей шкуре (то есть проведут грейдирование кого-то из своих разработчиков).

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

Итак, что показали 2 пробных прогона системы:

  • неудобно оценивать в процентах - непонятно как этот самый процент считать, получаем большой разброс оценок;
  • софт-скиллы тяжело оценивать в формат 0/1. Нет никаких полутонов - ты либо коммуникабельный, проактивный и тд либо нет. В реальности все гораздо сложнее. Туда же антипаттерны - например непредсказуемый результат. Если это случается раз в месяц - это 0 или 1? а если раз в неделю? в квартал?;
  • аналогично чекбоксы плохо работают с хард-скиллами - надо либо очень подробно расписывать все пункты в формате вопроса на который есть однозначный ответ или менять подход к оценке.

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

⏳ Итоги первой части

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

К каким выводам я пришел после первой части разработки и тестирования системы грейдов:

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

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

13 комментариев 👇
Захар Кириллов , Амбассадор ЕРАМ в Клубе 13 апреля в 20:52

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

Плюс (вернее, минус) GROW был в том, что как минимум на 80% она была построена вокруг прокачки хард-скиллов. Это была монструозная система со встроенными формами, таск-менеджером, напоминалками сотруднику и его менеджерам по линии подчинения и кучей других свистелок-перделок.

Но в GROW не было главного: никаких чётких указаний на то, что именно качать и как. Ну типа — вот Вася с Машей разивались вот так и достигли вот чего, а Лена с Петей пошли другим путём (вот каким именно) — и они уже там, а не тут.

То есть система должна быть с обратной связью, а не императивно диктующая какие-то там прописанные топ-менеждментом истины.

Потому у нас теперь (скоро? никогда? :) будет новая система. Я пока сам не пробовал, work in progress.

  Развернуть 1 комментарий

@zahhar, спасибо за дополнение, интересно будет узнать какой в итоге получилась новая система. В старой действительно очень не хватало хотя бы базового гайда. Из плюсов - достаточно исчерпывающий список технологий с разбиением на подразделы и система оценивания в формате novice/beginner/intermediate/advanced, за это лайк

  Развернуть 1 комментарий

@amaz1n, какой получилось — расскажу, когда сам получу практический опыт.

Называться она будет LevelUp. В её основе — всё та же система грейдов (при всём её несовершенстве и склонности к девальвации, особенно в ЕРАМ, где изначально система грейдов очень "мелкая" — у нас не придумали мидлов на 3 категории разделять, хотя ты в статье хорошо объяснил почему это имеет смысл).

Но в отличие от прежней, новая система показывает мне "меню" — несколько опций, куда я могу расти. Не только тупо следующий уровень в иерархии (вертикальный рост) но и возможность движения горизонтально или даже по диагонали (вверх, но в другую дисциплину). Также показывает наиболее популярную опцию, которую выбирали большинство коллег моего грейда (смотри скриншот дашборда).

Тут же будут рекомендации: менторов, коллег кто недавно прошел ассесмент, а также описания "вакансий" (assignments, ролей в проектах), для которых требуется новая роль — чтобы я сразу мог прикинуть, чем мне предстоит заниматься, если я получу ту лычку. Может ну её — не нужен мне тот геморрой?

Короче, родмап там огромный, идей море.

  Развернуть 1 комментарий

@zahhar, выглядит круто, главное донести все до прода и не потерять по пути

  Развернуть 1 комментарий
Skrypnikov Stanislav , Product manager (DM иногда) 18 апреля в 14:56

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

(Если шо, делал то же самое для отдела проджект манагеров, опыт имеется 🤭😁😭)

  Развернуть 1 комментарий

@Stas-Lemmy, это справедливое наблюдение, но однобокое. Оно валидно для сотрудников, да и то только для тех, которые не видят пользы в части про развитие и рост.

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

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

  1. Дадут понять менее опытным сотрудникам в какую стороны и какими инструментами прокачиваться.
  2. Обозначат в каком направление твоего развития заинтересована компания.

Ну а дальше уже вопрос реализации и внедрения системы, если их запороть, то будет как вы описали выше, просто способ обоснования не повышения зарплаты.

  Развернуть 1 комментарий

Классная статья, спасибо!

Вот ты написал "определитесь с задачами которые решаете, а еще лучше запишите их". Можешь рассказать какие конкретно цели ваша команда решала и решила ли?

  Развернуть 1 комментарий

@edbond, спасибо за вопрос! Цели и задачи которые решали мы я случайно перечислил уже в первом общем разделе, стоило бы конечно перенести в начало рассказа про личный опыт.
Если кратко, то это:

  • дать человеку понимание где он сейчас и как попасть на следущий уровень. Результат увидим через время, раскатка только началась. Пока скорее плюс
  • упростить процесс составления планов развития тимлидам. Однозначно плюс, стало гораздо проще и не обязательно изобретать велосипед каждый раз.
  • выровнять формальный и фактический уровень разработчиков. Увидим через продолжительное время, пока скорее минус
  • точнее оценивать уровень кандидатов на техническом интервью. Пока минус, но будем над этим работать
  • привлекать релевантных кандидатов. Если человек уделит перед интервью немного своего времени и посмотрит по каким принципам и критериям наша компания оценивает разработчиков он заранее сможет понять подходит ли ему такая история или нет (кому-то не подойдет и это норм). Сложно оценить, но пока скорее плюс
  Развернуть 1 комментарий

@amaz1n, честно говоря прям очень интересно было бы узнать почему что-то не получилось достичь. Может в конце второй статьи :)

  Развернуть 1 комментарий
Сергей Дыниовский , Руковожу командой разработки 18 апреля в 13:32

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

Хочу уточнить один момент: вы привязываете грейды к зарплатной вилке? сотруднику в явной форме сообщается что для повышения зарплаты ему нужно перейти на новый грейд?

  Развернуть 1 комментарий

@sergeyd, привет, логичные вопросы, где про грейды там и про деньги так или иначе.
Повышение зарплаты возможно без перехода на следующий грейд. Переход на следующий грейд в 90% случаев означает повышение заработной платы.
Вилки есть, но пока они не прибиты гвоздями к каждому конкретному грейду + их нельзя назвать прозрачными. Есть вероятность что поменяем это в обозримом будущем

  Развернуть 1 комментарий

@amaz1n, понял, ну мне кажется что "Вилки есть, но пока они не прибиты гвоздями к каждому конкретному грейду" - это как раз оптимальный вариант, хотя у вас команда большая, возможно уже и стоит жестко фиксировать вилки.

С жесткой фиксацией две проблемы (обе, в принципе, решаемые):

  1. Что делать с сотрудниками на определенном грейде, но которые за рамками принятых вилок
  2. Что делать с ценными сотрудниками, которые хотят повышение, но не хотят перемещаться между грейдами по каким-то причинам
  Развернуть 1 комментарий

@sergeyd, имхо как ни крути, все корнер-кейсы не покроешь. Если процентов 10 от всех случаев будут выходить за рамки системы - имхо это нормально, если не противоречит здравому смыслу

  Развернуть 1 комментарий

😎

Автор поста открыл его для большого интернета, но комментирование и движухи доступны только участникам Клуба

Что вообще здесь происходит?


Войти  или  Вступить в Клуб