Как понять, насколько правильно ты оценен, насколько верно оценены люди в твоей команде, соответствует ли оценка приносимой пользе и багажу их знаний и навыков? Стоит ли платить больше за знания, которые в данный момент не применяются и могут никогда не задействоваться? Как правильно оценить опыт? Как не обидеть коллег оценками и сподвигнуть их к саморазвитию, а не переходу в другую компанию? И как не раздуть ФОТ до бесконечности, когда люди открывают охоту за грейдами?

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

Когда-то давным-давно, в 2019 году, когда бюджеты были резиновые, а скорость зарплат в IT росла как на дрожжах, зарплата разработчика зависела частенько от того, насколько хорошо он умеет договариваться со своим лидером. Один делал сложные крутые штуки, но не мог донести до лидера их ценность и получал, грубо говоря, 10 рублей. А второй красил одну и ту же кнопку по 10 раз подряд и очень красиво объяснял лидеру сложность и необходимость ее перекраски — и получал 30 рублей. При этом на рынке эти ребята могли стоить обратно пропорционально. Немножко несправедливо, не правда ли? 

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

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

Глядя на эти проблемы, мы поняли, что всех надо как-то «померить» — и дальше уже что-то с этим делать.

Тогда инициативный разработчик и приглашенный внешний специалист по решению таких задач собрались…

И создали ГРЕЙДЫ

Пилотный проект запустили на фронтендерах пять лет назад, поскольку инициативный разработчик был как раз фронтендер. Грейдов было девять, по каждому — своя вилка для зарплаты. У каждого свои теоретические вопросы и практические задания. Очень похоже на собеседование, только дольше. Прогнали всех разработчиков через процедуру грейдирования, в результате стал понятен уровень хард-скиллов разработчиков в компании и зарплата стала иметь четкую взаимосвязь с хардами. Особо подробно на этом пилоте останавливаться не буду, потому что буквально через полгода интернет-банк начал переезд на React с AngularJS, и появилась острая необходимость в знании другой технологии. Соответственно, вопросы надо было менять, а кроме того, девять уровней было сложно отделить друг от друга, поэтому девять грейдов схлопнули до трех, а еще чуть позже расширили до пяти — джун, мидл, мидл+, сеньор, сеньор+ — и пересмотрели вопросы, сделав уклон на реакт и объединив их в общие темы.

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

Вторая версия системы оценки

Было сформировано около пятнадцати тем для разговора по каждому стеку. Например, знание языка, знание определенных технологий, паттерны разработки и т. п. Для каждого грейда требовался определенный уровень знания темы по пятибалльной шкале — назовем это картой грейда. 

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

Теперь опишу сам процесс грейдирования.

Сначала человек проходит этап самооценки, где выставляет себе оценки от А до Е по каждой теме. 

А — нет практики, только теоретические знания.

B — поддерживал существующее.

C — делал и поддерживал полностью сам.

D — делал много раз самостоятельно.

E — может обучать и передавать знания.

Далее проходит встреча. Всего из большого списка выбирается шесть тем, три выбирает грейдируемый, три — грейдирующие. По каждой теме происходит разговор по 20–30 минут (иногда растягивалось и сильно дольше), после чего выставляется оценка от А до Е. Дальше калькулятор с хитрой системой расчета указывает совпадение уровня кандидата исходя из самооценки и грейдов. Грейдирующие смотрят на калькулятор и в спорных случаях (около 70% соответствия) на свои ощущения и присваивают или не присваивают определенный грейд.

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

Промежуточные итоги и возникшие проблемы

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

1. ЗП разработчика коррелировала с рынком. То есть за определенный набор хардов на рынке платили столько же.

2. Стало нельзя получить больше только за умение договориться со своим руководителем.

3. Стал понятен уровень хард-скиллов разработчиков и тестировщиков в компании.

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

И в целом, казалось бы, справедливость восторжествовала… 

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

И пришел тогда бизнес к лидерам развития и разработки, и принес свои боли из-за грейдов...

В общем, в этой системе обнаружились новые проблемы:

1. Необходимость учить кучу технологий, которые не использовались в работе и благополучно забывались, а в основной работе были другие задачи (обычно намного проще, но иногда и сложнее, просто не затронутые в грейдах).

2. Гейминг с темами и самооценкой (помните про хитрый калькулятор? так вот разработчики оказались хитрее). Фишка была в том, что если занизить изначально свои оценки, а потом сдать несколько выбранных тем значительно лучше самооценки, то все остальные не затронутые на грейдах темы (поскольку пройти по всем хардовым темам за два часа было нереально) пересчитываются на уровень-два выше. 

3. Люди брали отпуска (в лучшем случае, в худшем — выделяли рабочее время) на подготовку к грейдам, как к экзамену.

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

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

6. Из предыдущего пункта вытекает финансовая непрогнозируемость ФОТа. В этой системе крайне сложно управлять бюджетом на ФОТ, и он разрастается неуправляемо.

7. Субъективность в принятии решения разными грейдирующими, которые задают разные вопросы и оценивают уровень по-разному.

8. Многие вопросы устарели и стали неважны.

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

10. Не учитывается, какую пользу еще разработчик приносит команде, помимо кодинга (да-да, не забываем что разработчик !== кодер).

11. Самое главное — вопросы теоретические и ответы теоретические, которые не факт что приносят реальную пользу Точке. А есть большое желание, чтоб люди и приносили пользу, и развивались, и получали удовольствие от работы, а уровень зарплаты мягко и приятно на это ложился.

Как обычно в IT, в одном месте починил — в другом сломалось. Получается, надо что-то придумать, чтобы создать новое, при этом не сломать старое.

Первым делом, конечно, надо было решить проблему с деньгами и неконтролируемым ФОТ (бизнесу все-таки надо как-то планировать бюджеты). Для этого отменили автоматическое поднятие зарплаты при получении грейда — решение принимает лидер команды, вилка грейда это потенциал разработчика, а реальная зарплата зависит от вклада. Зато вилки сделали внахлест: теперь, даже не повышая грейд, можно получать больше. На картинке это можно изобразить так:

Переход к портрету разработчика

С деньгами разобрались, теперь можно думать дальше, за что их, собственно, платить. Ну конечно, за эффективность в текущей роли и за пользу компании! Осталось разобраться, что такое эффективность и польза и сколько их мы ожидаем от каждого грейда.

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

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

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

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

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

Так выглядит новая карта грейдов для фронтендера Middle+. Оценку в софтовых темах сделали бинарной (проявляется — не проявляется), в хардах оставили пятибалльной.

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

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

Внедрение и предварительные итоги

Сначала мы выложили описанный выше портрет разработчика, чтобы все (в том числе и бизнес) могли с ним ознакомиться. После всеобщего одобрения провели несколько тестовых грейдов для проверки адекватности всего, что мы напридумывали. Обратная связь по формату и объективности была положительной, оценка по новой системе соответствовала нашим внутренним ощущениям, каких-то сильных перекосов не было. Но анкета оказалась довольно длинной, ее немного сократили и еще чуть-чуть пересмотрели вопросы и оценки. Также по ходу обкатки сформировали некоторый алгоритм приема, договорились о порядке вопросов, промежуточных синхронизациях и фасилитации встреч, чтобы не выбиваться из тайминга.

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

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

В общем, с 2024 года систему официально запустили!

Осталась одна небольшая проблемка: придумывало новую систему по 1–2 человека от стека, при этом принимающих грейды примерно в пять раз больше, а желающих сдать грейд примерно в 50 раз больше. Соответственно, необходимо обучение грейдирующих, чтобы всю суть концепции не потерять. Для этого грейды сначала принимали авторы концепции с постепенным контролируемым подключением новых грейдирующих для понимания критериев оценки.

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

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

2. Время уходит на заполнение анкеты, причем достаточно много (в основном от четырех часов до целого дня), но благодаря ей человек может вспомнить все, что сделал или не сделал. Это может быть дневник тщеславия, а может быть — наоборот, но в этом случае можно заранее оценить свои (не)достижения и не тратить время на прохождение грейдов.

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

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

5. Обучение грейдирующих действительно снизило различия в оценках.

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

Но, конечно, минусы тоже есть.

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

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

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

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

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

Возможно, через пару лет напишу и об этом ) В любом случае, это наш путь и он еще не пройден до конца.