Воскресное развлекательное: тред о том, как мы изобретали грейды.
1 этап: «разделим фичи языка по грейдам».
Где-то в 2017 сели мы думать, как решить, кто из приходящих на собеседование мидл, кто джун, а за сеньоров браться страшно. Решили, что наверняка, это связано с знанием JS
Расписали табличку какие методы и термины из языка (и верстки) должен знать джун, а какие уже мидл. Ну, вроде, замыкания должен знать джун, а если он еще и про регулярки знает, то уже мидл.
Не так буквально, но похоже.
Посмотрели на получившуюся табличку, сказали «фигня какая-то» и выкинули результаты.
И пришли к выводу, что хотя есть вещи, которые статистически люди знают хуже или реже, но они примерно никак не связаны с грейдом человека.
Если смотреть на моих учащихся, то, например, из методов массива почти никто не знает про reduceRight и мало кто вспоминает про some и every (хотя встречая в коде могут легко догадаться). Потому что редко ими пользуются (мне всегда обидно за some и every).
Генераторы, Map и Set — все из той же оперы. Мало кто ими пользуется достаточно часто, чтобы легко вспомнить про них в обычном обсуждении задачи.
Тут мне обиднее всего за Set, я его нежно люблю, но понимаю, что чаще всего им пользуюсь, когда решаю всякие контесты.
2 этап: программисты создают матрицу компетенций.
Где-то через год после начала первого этапа, родилась новая движуха — давайте делать матрицу компетенций для всех программистов компании.Программисты, которым доверяют другие, взялись формулировать, каким должен быть программист
Вначале придумали крупные критерии этой матрицы:
Техника/Мастерство
Продуктивность
Критическое мышление
Работа с процессами
Коммуникации
Результативность и управление проектами
Применение архитектурного контекста
Применение продуктового контекста
Потом пошли описывать индикаторы, которые доказывают наличие критерия и назначать их разным грейдам.
Идея была такая: в каждом критерии есть сколько-то индикаторов. Каждый индикатор бинарный и либо проявляется, либо нет. И формулировки такие, чтобы точно можно было проверить
Соответственно, у каждого индикатора указан грейд, на котором мы ожидаем его закрытия. Если закрыто 80% индикаторов текущего грейда, то разработчик переходит в следующий.
А чтобы точнее проверять индикаторы, предлагалось приводить примеры проявлений, там, где это уместно.
Индикаторов получилось в сумме больше 100. Заполнение их раз в полгода на пересмотр отнимало больше целого дня у разработчиков (предполагалось, что каждый заполняет за себя и то, что может, заполняет коллегам, а потом обсуждает результаты с тимлидом, менеджером или кем-то еще).
Еще есть индикаторы, которые мы написали за сеньорские и которые стабильно отмечали выполняющимися большинство джунов. Например, индикатор «Использует глубокие знания технологии для более качественного решения задач». И даже примеры проявлений не спасают
Ну, и самая главная проблема — перфекционизм, который заставляет разработчиков хотеть закрыть все индикаторы, но не все из них возможно было закрыть без смены команды.
Например, индикатор «При необходимости выполняет смежную с разработкой роль (аналитик, тестировщик, devops)»
Индикаторы были сделаны так, чтобы, если человек помимо всего прочего делает сверх того, что должен, то должна быть возможность отметить, что он молодец и мы это ценим. Но это создавало ощущение, что «если у меня хорошая команда, то я не смогу закрыть 100% индикаторов!»
В общем, боль и страдание принесли нам эти сотни индикаторов. Хотя стало немного прозрачнее за счет того, что компания явно опубликовала, что она считает важным и для кого-то это стало понятным маршрутом для роста.
Этап 3: замена матрицы небольшим количеством критериев.
В какой-то момент решили попробовать сделать немного критериев, вместо сотни индикаторов. У критериев особенность, что нужно учитывать их дух, а не букву, потому что они описательные, а не строго бинарные были.
Собрали рабочие группы, которые состояли не только из разработчиков, но и менеджеров, предложили описать кто по их мнению джун, кто мидл, кто сеньор, кто лид. потом обобщили о обнаружилось, что это вполне себе обобщается до небольшого количества пунктов
На картинке один из 5 критериев для перехода из джуны в мидлы.
Показывать все критерии я пока не хочу, потому что они еще дорабатываются — формулировки местами оказались спорными и сложными, поэтому сейчас делаем их безопаснее.
Самая сложная идея была такая — до уровня мидл, разработчик может дорасти в любой команде. А дальше — совсем не факт. Потому что есть продукты, которые находятся на поддержке, в них нет большого количества переделок, сложных задач и чего-то такого.
И очень больно было некоторым менеджерам осознавать это. Они говорили: вот вы там придумали всякое, как мне растить разработчика в ведущего (по факту, в лида), если у меня задач больше нескольких часов не бывает, в команде 3 человека и расти мы не планируем. Критерии мне мешают!
Отдельно, параллельно с изобретением критериев, развернулась история с тем, что трех грейдов не хватает. Обычно, типичный джун, которого мы берем в компанию, за примерно год вырастает в мидла, а до следующего качественного перехода, который у нас был — ведущий инженер-программист
(от ведущих мы ждали лидерских качеств, это тимлиды, техлиды и прочие лиды) — до этого грейда можно расти лет 5 или больше, или никогда не дорасти. И это, конечно, демотивирует многих.
И как такового у нас не было грейда «сеньор», то есть «старший» разработчик.
Вот сейчас занимаемся причесыванием грейдов и есть описательное видение, какие они примерно получатся:
— интерн: знает язык, умеет программировать, нет промышленного опыта
— джун: это как интерн, только уже с каким-то реальным опытом
— мидл: это разработчик, который может делать типичные задачи самостоятельно, за ним не нужен присмотр
— мидл+: разработчик, который может сделать почти все задачи из бэклога команды, но не может планировать крупные рефакторинги
или принимать значительные архитектурные решения
— сеньор: разработчик, который кроме собственно деланья задач, умеет брать ответственность или за людей, или за архитектурные решения, или выполняет роль менеджера на крупных фичах. Либо умеет делать какие-то сверхсложные задачи
— Лид: это сеньор, который успешно и неоднократно доказал свои лидерские качества. Может быть тимлидом, техлидом, фичалидом или разработчиком rocket science задач.
Ну, и у лидов тоже есть усиленный грейд лид+, который про масштаб проявленй — еще крупнее, еще больше, чем у лида.