Сразу скажем, что какая-то система, которая помогает оценивать уровень разработчиков и других специалистов — необходимость для любой компании, в которой работает больше 2 человек. Как-то же нужно определять, какие задачи кому поручить, чтобы повысить вероятность их быстрого и качественного выполнения.
Чаще всего в разговорах и описаниях вакансий встречаются такие «лычки» как Junior, Middle, Senior. Сотрудникам кадровых служб эти короткие и некогда модные, звучные слова, обозначающие грейд специалиста, должны дать понимание кто перед ними и какую компенсацию ему можно предложить. Носителю «звания» они также должны давать понимание на каком уровне развития он находится.
Вот только проблема в том, что такие грейды не решают ни одну из описанных задач. И вот почему.
Развитие не дискретно
Когда у нас есть всего три грейда — Junior, Middle, Senior — на весь карьерный путь, переход от одного к другому должен быть ощутим. Как перевод тумблера из одного положения в другое. Однако, к сожалению, на практике этого не происходит.
Оборачиваясь на проведенные в редакторе кода годы, я, например, не могу четко определить момент когда из джуна стал миддлом. Когда из миддла стал сениором, да и стал ли?
Решить эту проблему пытаются внедрив промежуточные грейды. Junior+, Middle-, Middle+ и тому подобные. Но бОльшая дискретизация лишь добавляет путаницы, заставляя внедрять дополнительные критерии оценки. Если они недостаточно четкие и понятные, то пища для синдрома самозванца. К тому же, забуксовать на одной из отметок и потерять интерес к развитию — очень легко. Сам не раз вытягивал себя из этого болота за волосы.
Нет единого стандарта
У нас есть примерные критерии, которыми можно объяснить разницу между грейдами. Чаще всего используется следующее различие. Если говорить простыми словами:
- Джуниор делает так, как сказали. Зона ответственности — задача
- Миддл делает так, как решил сам. Зона ответственности — модуль
- Сениор решает что и как делать. Зона ответственности — продукт, результат
Я работал в нескольких компаниях. И не только в каждой компании, но и в каждой проектной команде внутри одной организации есть своё понимание сениорности сотрудника. Просто уровень задач и требований к качеству их исполнения отличается очень сильно.
Если мы работаем над каким-нибудь публичным маркетинговым инструментом для бизнеса, наиболее важный критерий будет скорость поставки решения, чтобы не подводить согласовавших проекты и бюджеты маркетологов. Если мы работаем в банке, нам важнее стабильность кода, который попадает в продакшен. Ну а если мы пишем какой-то софт для блоков управления военных истребителей (надеюсь, не на JS), то мы захотим быстродействия и производительности. Но и ошибки, конечно допускать нельзя.
Представим что сотрудник из первой компании, научившись штамповать лендинги со скоростью гепарда, идет на собеседовение в последнюю. У себя он уважаемый Senior. Но в лучшем случае на собеседовании ему присвоят Middle-грейд. Не потому что он лентяй или плохой разработчик. Просто он никогда ранее не занимался быстродействием и производительностью.
Слишком упрощённая оценка
Что именно мы оцениваем, когда оцениваем человека как Junior, Middle или Senior? Если принять описанные выше различия грейдов за истину, то одним словом мы описываем сразу три качества, три ветки развития сотрудника
- техническую экспертизу
- самостоятельность, инициативность
- софт-скиллы
А что если условный Иван прекрасные технический эксперт, но совершенно не умеет общаться с людьми. Да, скорее всего он не нужен именно в вашей команде, но какой грейд мы ему присвоим?
А что если условный Алексей отлично ладит с коллегами, предлагает идеи по развитию проекта, но код может писать только при помощи ИИ?
Можно ещё долго играть в условные примеры. Суть в том, что оперируя лишь такими грейдами, каждый раз мы получаем огромные шансы ошибиться с оценкой уровня сотрудника и нанять не того человека не на те задачи.
Иллюзорный финиш
Может показаться, что добравшись до уровня Senior, мы пересекаем финишную ленту на гонке развития экспертности. Однако это очень далеко от правды. Внутри грейда есть те кто еле-еле пролез по меркам требований, есть те кто уже давно маринуется без понимания того что будет дальше. И перед каждым из сениоров стоят свои задачи по углублению экспертизы. Но к чему стремиться, если больше грейдов нет?
Да, может появиться желание как и в случае с дискретизацией грейдов придумать дополнительные ступеньки вроде Senior+. Однако это заведомо тупиковый путь. Возможности человеческого мозга настолько огромны, что мы устанем выдумывать. И все так же каждый последний грейд будет означать финиш. Иллюзорный финиш.
Что можно использовать вместо грейдов?
Есть несколько более продвинутых вариантов
Матрицы компетенций
Выделяют ряд направлений (например, «асинхронность», «typescript», «react», «безопасность», «архитектура» и др.) и для каждого выделить уровни. Каждый уровень — описание задачи, которую может решить сотрудник или знания, которое он может продемонстрировать. Разработать такую матрицу сложно, это требует времени. И даже после того как она будет написана, нужно периодически её актуализировать.
Грейдирование каждой ветки развития
Выше я писал, что грейд описывает сразу три качества сотрудника. Однако в карьерном плане их можно свести к двум веткам развития: исполнителя и менеджера. Выбирая этот вариант грейдирования, мы будем присваивать сотруднику сразу два уровня. По одному для каждой ветки развития. Однако это подходит только для больших корпораций, которые могут дать возможности прогрессирования по каждому из направлений.
Роли и зоны ответственности
Это радикальный подход с отказом от грейдов. Применяя его, вместо «Middle разработчик» мы будем говорить «Разработчик сервиса оплаты». Это описывает роль и зону ответственности. Для неё должны быть прописаны обязанности, зоны принятия решений и KPI. Например «Разработчик сервиса оплаты» будет отвечать за поддержку и развитие этого сервиса, а его KPI может быть, например, быстродействие форм оплаты. Такая система может быть интересна малым компаниям, в которых работают сотрудники примерно одного уровня. Однако она не дает ощущения вертикального роста. Скорее всего имеет смысл комбинировать её с какими-то другими системами.
Возникает вопрос, а можем ли мы отказаться от Junior, Middle, Senior грейдов? Мое мнение — вряд ли. Очень уж это очень быстро и удобно. Однако мы должны понимать все её недостатки и ограничения, не принимать её за истину последней инстанции и, самое главное, по возможности применять более совершенные модели когда от этой оценки будет хоть что-то зависеть.
