![](https://habrastorage.org/getpro/habr/upload_files/3ba/c80/9ec/3bac809ec494b0c7363c6e5a81c2c9a0.png)
Всем привет! В этой статье я расскажу, как у нас в «Рексофт» происходит повышение грейдов, почему именно так, и как мы к этому пришли.
К сожалению, начать придется издалека, и воображаемая машина времени отправляет нас в прошлое. Пристегните ремни, постараемся двигаться быстро. И, пожалуйста, наденьте спасательные жилеты: без «воды» никуда.
Темные времена
Первая остановка — эпоха раздоров и смуты. В эти темные времена не было четкого понимания, кому за что отвечать и кому что оценивать. Случалось даже, что должности выдавались по принципу рулетки. Ну, почти.
Идеология была такая: справился — значит, мидл, быстро и хорошо справился — значит, сеньор. А потом тебя просят на проекте, где кто-то когда-то справился «быстро и хорошо», поправить пару мелочей. Пару мелочей в React Class Component, где только state и render на 3000 строк. SetState внутри render, но в «ифе», чтобы, значит, в бесконечный loop не уйти. Если вы не знакомы с React, не проблема, у меня есть аналогия. Представьте гавайскую пиццу. Только вместо ананасов там репа, а вместо курицы — мясо чайки. Ну и мука прогорклая. Вкуснотища… В общем, веселье да и только.
Но давайте опустим обсуждение моих детских психологических травм и попробуем рассмотреть проблему системно.
Как это было
Разработчик какое-то время трудился на проекте, и в один прекрасный день к нему приходило осознание. Осознание собственной силы. Разработчик отправлялся к руководству и говорил:
— Я уже совсем не тот, что был раньше. Я достоин большего.
Руководство запрашивало фидбек у текущего руководителя проекта и на основании его отзыва принимало решение. Все. Стоит еще отметить, что вариантов, куда мог пойти разработчик со своей просьбой, была масса: руководитель проекта, руководитель практики, руководитель офиса, директор департамента, HR. Напоминает квест.
Но проекты меняются, руководители проектов, соответственно, тоже, и в конце мы получаем render на 3000 строк. Простите, не мог не вспомнить.
При таком подходе наверх зачастую продвигаются те, кто чаще бывает на виду и мелькает на митингах в положительном контексте. Обычно, если мы постоянно слышим о ком-то в позитивном ключе, то с большей долей вероятности будем лояльны к пожеланиям этого человека.
Да, да! Именно так и работает реклама. Я не спорю, умение пропиарить себя — это классный и порой очень нужный скилл, но это уже другая история, и мы расскажем ее как-нибудь в другой раз.
Итак, какие проблемы у нас были:
Оценка навыков разработчика технически неподкованными людьми.
Как вывод из предыдущего пункта — больше оценивались софт-скиллы, чем технические.
Выше вероятность продвинутся, если ты умеешь себя продавать.
Отсутствие понимания, как вообще должен изменяться грейд и компенсации.
И мы задумали создать беспристрастную систему оценки компетенций наших сотрудников, чтобы должность получил и тот, кто на виду, и парень рядом, который просто тихо пишет код и в гробу видел саморекламу.
Что ж, машина времени переносит нас дальше.
Делай «раз», или Первый блин комом
Мы оставили отзыв руководителя проекта как один из коэффициентов и добавили обязательную оценку сотрудника технически подкованным человеком. В итоге, мы получили оценку софт-скиллов плюс оценку технических скиллов.
На данном этапе оценка технического уровня легла на плечи руководителя практики. Руководитель практики, в нашем случае — это человек, который занимается развитием всего отдела (Frontend, Java, QA и т.д.). Следовательно, он должен был знать вообще все.
Дальше буду говорит про Frontend, мне так проще. У нас есть проекты на Angular и на React. То есть руководитель практики должен был очень хорошо знать оба этих фреймворка, чтобы прособеседовать мидла на сеньора. Звучит не очень, да? А еще проекты на Vue, NodeJS и т.д. Один человек не в состоянии обладать такими обширными знаниями, да еще и на уровне, позволяющем экзаменовать коллег. И это стало проблемой.
Кроме того, добавилась еще одна сложность: разработчик мог счесть свою оценку необъективной и предвзятой. В принципе, логичный ход мыслей. Далеко не все могут абстрагироваться и оценивать исключительно технический уровень. Возникают мысли вида: «Вот он с Петей кофе пить ходит, и поэтому Петя — сеньор, а я с ним кофе не пью, поэтому я джун». Очень часто в своих неудачах люди могут винить звезды, числа, скамейки, судьбу-злодейку и тем более — других людей. Порой сложно сказать самому себе: «Я облажался!»
В свою очередь, и у руководителя практики возникают мысли: «Вот как я буду собеседовать Петю? Я с ним кофе хожу пить. Я и так в курсе, что он знает и чего не знает, и собеседование будет фарсом». Да, мы в любом случае рекомендуем тех или иных людей, в любом случае к нашим словам прислушиваются. И работать в компании друзей всяко приятнее. Но стремиться мы должны к объективности.
Возможно, у кого-то возникнет закономерный вопрос: «Почему не лид команды?»
Да, это может быть хорошим вариантом, но нас он не устроил по следующим причинам:
Не во всех командах бывает лид фронта. Часто есть лид проекта, и как правило это бэкенд-разработчик. По понятным причинам объективно оценить технический уровень фронтенд-разработчика для него затруднительно.
Замыливается взгляд и пропадает объективность. Так или иначе устанавливаются социальные связи, формируется личностное отношение. Все это мешает оценивать другого человека.
Некоторые люди очень хорошо могут играть разные роли. Роль подчиненного или роль руководителя — по ситуации.
На последнем пункте я остановлюсь чуть подробнее. Некоторые люди могут очень хорошо играть отведенные им роли. Мы занимаем разные позиции и применяем разные стратегии в зависимости от окружения. И бывает так, что сеньор-лид, попадая в новую команду на роль линейного разработчика, не тянет одеяло на себя: не лезет с умными советами, а просто делает таски. Да, делает хорошо и правильно. Его мердж-реквесты проходят ревью с первого раза. Но! Есть одно маленькое «но». Он же не первый день замужем. Он знает, что у всех свое видение правильной архитектуры и у всех свои заморочки. Прежде чем делать задачу, которую можно решить несколькими способами, он позвонит лиду проекта и спросит: «А как именно это надо сделать?»
Что же мы получим в итоге, когда запросим фидбек на этого разработчика? А фидбек будет примерно такой:
«Уверенный мидл или стронг-мидл. Глупых вопросов не задает. Задачи делает в срок. До сеньора пока не дорос: не может самостоятельно принимать архитектурные решения и т.д.».
Проблема заключается в хорошем отыгрыше отведенной ему роли. На проектах, где он лид, не пройдет ни одно решение, которое его бы не устроило. И вообще он кошмарит всю команду. Но кошмарит в хорошем смысле слова, разумеется. Мы в «Рексофт» против буллинга, токсичного ревью и всего вот этого вот непотребства.
Что ж, пожалуй, хватит про людей, их роли и способность играть на разных позицияx. Это уже совсем другая история, и мы вернемся к ней в другой раз.
Итак, убрав одну из проблем, мы создали новые:
Отсутствие объективности. Ну или подозрение на необъективность.
Слишком большой спектр знаний, который должен покрывать руководитель практики.
И машина времени приближает нас к настоящему.
Делай «два», или Незнакомцы в поезде
Вводим кросс-интервью. Теперь, согласно регламенту, собеседование на повышение грейда проводится незаинтересованным человеком, в нашем случае — разработчиком, который работает в другом офисе, в другом городе и, разумеется, на другом проекте. Если он живет на Марсе, вообще замечательно. Желательно, чтобы до собеседования пересечений вообще не было. Собеседуют на изменение грейда исключительно сеньоры. Собеседующий подбирается наиболее близко по стеку, с которым работает собеседуемый. Angular? Значит берем сеньора со знанием Angular. React? Ну вы поняли, да?
Итак, что мы имеем теперь:
Собеседующий максимально объективен и абстрагирован.
Нет смысла иметь лишь один эталон для оценки уровня разработчиков.
Меньше мыслей типа «меня просто не любят и поэтому не повышают грейд».
Разумеется, некоторые люди в любом случае, даже тут, будут придумывать теории заговора и думать, что их завалили специально. Но мы то знаем, в чем истинная причина.
Звучит красиво и, наверное, даже правильно. Мы тоже так думали. Недолго, правда. Пожалуй, проще верблюду пролезть в игольное ушко, чем объективно оценить разработчика.
Получился гигантский разброс в оценках. Каждый спрашивает по-своему, и понимание сеньорности у каждого свое. Не верстал под IE6? Да какой же ты сеньор?! Никогда не делал кастомную очередь задач на генераторах? Куда ты лезешь тогда?! И все такое прочее.
Я как-то писал комментарий для одного интернет-издания о том, что такое грейды. Так вот, сферический грейд в вакууме — весьма сложный топологический объект. И точно определить, кто есть кто, не всегда возможно. Все зависит от конкретной компании-работодателя. Я видел, как загорались и гасли звезды, как джуны, меняя работу, становились сразу стронг-мидлами, а сеньоры превращались в мидлов.
У каждого из нас свои оценки, свои градации и свои триггеры. Мы стараемся быть объективными, но, когда нет единиц измерения и единой шкалы, прийти к общему знаменателю почти невозможно. Один жмет от груди 140 кг и на вес в 50 кг снисходительно скажет, что это всего лишь вес для разминки, а другой ведь и его поднять не сможет.
Здесь, пожалуй, мы сделаем остановку. Продолжение нашего путешествия к станции выработки единой системы оценки в «Рексофт» будет в следующей статье.