Сколько в компании разработчиков, столько примерно и мнений. Например, где именно проходит граница между мидлом и синьором? Нам нужен был справедливый инструмент оценки, который помогает понять, не получает ли наш специалист зарплату меньше, чем должен был бы. И, самое главное, что нужно делать для того, чтобы развиваться.
В итоге мы сделали опросник из 14 пунктов, по которому за несколько минут можно оценить себя. То же самое делает про вас тимлид, и если оценки совпадают, то всё отлично, есть грейд и зарплата в нём (у нас по три уровня внутри каждого грейда, например, джун-джун, опытный джун и джун 80-го уровня). Если оценки не совпадают — начинается процесс переговоров с приведением примеров для синхронизации по части оценки и ожиданий, чтобы потом на следующей итерации они всё-таки совпали.
Пока мы попробовали этот подход на 120 разработчиках. Выглядит многообещающе. Но я хотел бы показать вам сам опросник, детали системы и обсудить, насколько прозрачной получилась такая система. Дальше в посте — предпосылки её создания, разбор каждого из параметров и ссылка на форму, которая показывает результат по нашей системе грейдов.
Почему мы не грейдируем только по хардам
Итак, основной смысл грейдирования — платить больше тем, кто приносит больше пользы компании. Многие компании предпринимают попытку грейдировать только по хард скиллам. При этом польза, приносимая сотрудником, имеет зависимость от уровня хардов, но на деле нужно смотреть шире. Например, мы ожидаем от синьора не только архитектурных решений и высокого качества кода, но и понимания, что же требуется бизнесу.
Подготовку опросника для проведения грейдирования я начал с того, что опубликовал опрос на всю разработку, чтобы понять, кто для нас синьор и чем, собственно, он отличается от мидла. Мне нужно было собрать общую массу мнений самих разработчиков, чтобы выделить наиболее часто упоминаемые качества.
Из опроса удалось получить большой список факторов, которые влияют на уровень именно с точки зрения разработчиков.
Основное, в чём сходились почти все опрошенные, — это то, что мы позже назвали «самоходность», то есть умение решить задачу самостоятельно. Или, если точнее, целиком и полностью реализовать задачу с достаточным качеством в разумные сроки и при этом понимать, что в задаче важно бизнесу и почему, на какие метрики будут смотреть продакты и какие технические метрики важно собирать. Второй наиболее часто упоминаемый фактор — это «технический кругозор», под которым мы понимаем владение текущим техническим стеком. Мы решили, что без двух этих качеств разработчик в принципе не может быть синьором. А позднее к ним добавились ещё «понимание бизнес-проблемы» и «умение действовать в условиях неопределённости».
Что убрали из оценки
Следующий шаг — я посмотрел на значимость каждого критерия, которые получились в результате опроса, а потом постарался выкинуть то, что не влияет на успешность решения задач в описанном выше ключе, чтобы сделать опросник простым и справедливым.
Как это ни странно, ушла из списка коммуникация с коллегами и заказчиком. Да, коммуникация с коллегами очень важна, но мы не можем на её основании определить грейд. Плюс у нас есть достаточно общие вопросы, которые косвенно включают в себя это проявление. Важно помнить, что грейд — это про уровень решения задач, про результативность. Если синьор токсичный, то это не значит, что он не может классно решить задачу. Это значит, что, возможно, мы просто не будем готовы с ним работать, но это не повод снижать грейд.
Также вылетели из списка клиентоориентированность, регулярность поставки изменений (это скорее про декомпозицию крупных задач) и многое другое.
В общем и целом осталось только то, что характеризует именно компетенцию. Получилось 14 базовых критериев, они представлены ниже.
Давайте их и разберём.
Опросник
Первая версия опросника, естественно, была собрана в гугл-документах, чтобы начать собирать данные и получать быструю обратную связь. На этой форме мы прожили более полугода, прежде чем начали переход в другой интерфейс.
Тут всё просто: самоходность — показатель автономности в решении задач в рамках своей компетенции. Конечно, мы не ожидаем, что разработчик сам придумает продукт, нарисует дизайн и займётся продажами. Мы ожидаем, что разработчик задаст необходимые вопросы продакту по проблеме и решению, спроектирует задачу, а дальше сможет оценить её, разложить по спринтам и проконтролировать её путь от начала разработки до успешной выкладки в прод. И всё это — в адекватные сроки. Мидлов в такой парадигме нужно контролировать от спринта к спринту, а джунов — регулярно в течение спринта. Синьоры могут прекрасно самостоятельно справляться с задачами, но это не означает, что они не могут и не должны поднимать какие-то вопросы и приходить за консультациями.
Один из важных аспектов контроля — это понимать, что разработчик не тратит много времени на реализацию какой-то известной библиотечной функции, не изобретает велосипед и не городит костыль там, где есть нормальное решение. Думаю, вы сталкивались с тем, что бывает, когда какой-то вопрос, который у опытного разработчика занимает полчаса, джун тихо и упорно решает пару недель.
Как и в следующих пунктах, тут нет какой-то объективной оценки вроде подсчёта частоты задаваемых вопросов, вполне хватает субъективной самооценки тимлида, и она по тестам оказывается довольно точна.
Это второй определяющий критерий для синьора в наших условиях. Если нет умения решать задачу в ситуации неопределённости, то перед нами — исполнитель, работающий преимущественно по ТЗ. А синьор — это тот, кто может выяснить и решить, как надо делать. Кто-то может справедливо отметить, что это может делать PM, но не стоит забывать, что критерии отличаются от компании к компании исходя из внутренней культуры.
Простую типовую задачу «под ключ» может решить и джуниор, а вот в случае, когда бизнес приходит и говорит «хотим сделать, чтобы вот так», часто надо придумать решение, которое не только «сделает вот так», но и выбрать архитектуру, понять, кого это может задеть внутри компании и на что ещё может повлиять, договориться с инфраструктурой, смежными командами и так далее, а потом уже сказать, какие есть варианты и чем они отличаются. Это похоже на аналитику задачи, но включает в себя умение искать оптимальное решение в локальной ситуации.
Ещё один пример неопределённости — это когда нужно что-то поправить, а никто не знает, где вообще эти правки вносить.
Понимание проблемы — это ответ на вопрос, зачем, собственно, решается эта задача. Разница принципиальна: если просто реализовывать ТЗ, то может быть выбрана не та архитектура. Или вообще может выясниться, что задачу в таком виде решать не надо, потому что есть другой путь. И опытный специалист должен его показать.
Конечно, бывают разные проектные менеджеры. Для некоторых важно, чтобы то, что они сказали, было сделано именно так, как они хотят. Но мы считаем, что такое слепое следование ТЗ обычно говорит о недостаточном понимании бизнес-задачи и имеет больше негативных последствий. Очень часто нужно делать не прямо по хотелкам, а чуть больше, чуть иначе и вообще обсуждать эти решения и их последствия. Но аргументированно.
А это уже навык аргументированного обсуждения, дополняющий прошлый пункт. И смысл не в том, чтобы порождать бессмысленные споры на ровном месте, а в том, чтобы видеть, предлагать и доносить разумные альтернативы.
Зачастую лучше чего-то не делать, чем реализовывать сомнительное решение либо делать по-другому.
Стратегическое — это черта сильного специалиста с богатым кругозором и насмотренностью. Синьор будет проектировать решение, которое закрывает среднесрочные и долгосрочные цели бизнеса без дополнительных крупных затрат. Конечно, не всегда так получается, но пытаться важно. Хорошо, если специалист об этом думает и регулярно проявляет эту черту.
Очень часто бывает, что приходит бизнес, говорит: «А покрасьте вот эту кнопку в красный». Джун возьмёт и покрасит через костыль. Мидл сделает отдельный класс красных кнопок и позволит ставить их там, где надо бизнесу. Синьор спросит, как часто нужно красить кнопки, зачем, какие ещё есть цвета, и, возможно, даст возможность бизнесу самому выбирать цвет кнопки без того, чтобы ходить в разработку.
Межкомандная работа — это наша специфика и временами боль, поэтому этот критерий попал в опросник. У нас много команд и много пересекающегося функционала. Охотно верю, что в других компаниях не так, но мы ждём от своих синьоров умения организовывать работу над межкомандными задачами. Чтобы они брали ответственность на себя, собирали тех, кто нужен для решения, раскручивали цепочку, как решать, и решали, а не просто оставляли задачу болтаться, «потому что непонятно, кто у них там должен».
То есть по факту у нас нельзя стать синьором, не имея хоть одной задачи, решённой на стыке команд.
В данном пункте нам интересно, как проявляется реакция на ошибку на проде. Думаю, что по формулировке пунктов опросника понятно, где для нас проходит разница. В отличие от предыдущего пункта не обязательно иметь опыт крупного падения в своей биографии: вполне может оказаться, что ошибок на проде специалист просто не допускал, как правило, в командах это видно сразу.
Это, пожалуй, самая субъективная оценка нашего опросника, потому что измеряется исключительно по ощущениям руководителя. Здесь мы оцениваем, насколько эффективно сотрудник выполняет задачи, с учётом скорости, количества решённых задач и качества их исполнения. Понятно, что в идеале надо сводить метрики по всей компании и сравнивать всех со всеми.
Сразу уточню, что перформинг на разных проектах и в разных командах может сильно отличаться. В нашей системе нет понижения грейдов, то есть если разработчик однажды показал хороший результат в одном из критериев (стабильно на протяжении нескольких месяцев), то вниз мы его не переоцениваем. Поэтому, если перформинг упал, мы думаем о том, что могло пойти не так в команде, руководстве или процессе.
Для оценки перформинга можно смотреть на количество закрытых задач, суммарное затраченное время, среднюю погрешность оценки и медиану погрешности оценки.
Этот пункт — про внимательность и ответственность за состояние задачи на момент её передачи в тестирование. Если разработчик считает, что его задача — «код писать, а не тестить» и передаёт её QA без проверки, то увеличивается нагрузка на тестировщика, а жизненный цикл задачи растягивается, так как она возвращается на доработку.
Пока для простоты оценки выбрали метрику «кол-во возвратов задачи после тестирования», но, как уже подсвечивали коллеги из некоторых команд, такая метрика не всегда объективна. Например, у QA могут быть проблемы с инфраструктурой, а не кодом. Поэтому как альтернатива метрике — это дойти до QA и узнать, насколько качественно сделаны задачи, передаваемые в тестирование.
На старте нового проекта или реализации большой задачи опытный разработчик закладывает архитектуру, которая долгое время позволяет гибко реагировать на запросы бизнеса. Этот критерий дополняет «стратегическое мышление», но там больше про потребности бизнеса и риски, а тут — про реализацию.
Тут, думаю, всё понятно.
У нас есть процесс технического ревью — это когда команда обсуждает и планирует конкретное техническое решение задачи. В разных компаниях данный процесс называется по-разному, но, как правило, суть одна.
Опытный разработчик уделяет много внимания этапу подготовки и планирования задачи, так как в этот момент даже крупные изменения будут значительно дешевле, чем на более поздних этапах.
Code Review — устоявшаяся практика в разработке, поэтому она тоже попала в оценку.
Знание стека — это суммарная оценка хардов по каждой части используемого стека, она проводится отдельно и просто заносится в опросник как один из пунктов. Важно, что нельзя стать синьором, не обладая глубоким пониманием технологий и умением применять их на практике.
Недостатки
Первая особенность в том, что у начинающего тимлида в команде по итогам оценки может оказаться больше синьоров, чем у опытного, поскольку его будет легче убедить в наличии отсутствующего навыка из-за субъективности оценки. В таких случаях рекомендуется проводить опросник в формате 270 градусов (самооценка, оценка руководителя, оценка коллеги или той роли, которая может оценить).
Вторая особенность — не все навыки объективно могут проявиться в конкретной команде. Например, у нас достаточно команд, которые работают полностью автономно без взаимодействия с кем-то ещё, и там нельзя показать ту же компетенцию межкомандного взаимодействия. Мы предполагаем, что разработчик, который поймёт, что хочет расти дальше, сможет при необходимости перейти в команду, где такая практика есть, просто чтобы получить нужный опыт. Либо сможет затащить какие-то проекты на уровне юнита или компании, находясь в своей команде.
Третья особенность — сами критерии достаточно субъективны: сразу стало заметно, что пункты начинают трактоваться по-разному. Сейчас выравниваем эту трактовку через добавление примеров.
Если оценка после очередного цикла снижается, то мы не меняем грейд и оплату, но говорим, где просадка, и просим подтянуть эти показатели. Это защита от субъективных колебаний и влияния атмосферы разных команд на разных проектах. В идеале синьор в одной команде будет синьором и в другой. Но никто не застрахован, что в другой команде он будет непродуктивен. Это либо изменение условий, либо конфликты в команде, либо некорректная предыдущая оценка. В любом случае это решается за пределами системы грейдов.
В итоге у нас есть рабочая модель, которая проверена на 120 разработчиках. Для них это справедливое ранжирование по деньгам, для компании — ещё и возможность прогнозировать бюджет. Для тимлидов — возможность показать сотруднику, в чём лучше развиваться внутри команды, и синхронизировать ожидания от роли.
Безусловно, не все приняли систему оценки с распростёртыми объятиями, был и ярко выраженный негативный фидбэк. Важно понимать, что оценка — процесс меняющийся, и требуется регулярно его обновлять и корректировать исходя из ситуации. Поэтому мы периодически собираем обратную связь и вносим коррективы.
Вот здесь за пять минут можно пройти опросник и оценить, какой грейд был бы у вас в Skyeng.
Автор: Дмитрий Кузнецов
