В новом выпуске подкаста «Релиз в пятницу» Миша Шпаков, Кира Айрапетова, Олег Филимошин обсудили грейды: когда, кому, зачем они нужны и как эффективно их использовать.
Если коротко, вот что я выделила для себя:
- Грейд — структура, позволяющая привязать зарплаты в компании к навыкам и задачам сотрудников.
- Грейды нужны не всем компаниям.
- Грейды не только про hard-skills.
- Грейды обоюдно удобны, если позволяют тем, кто больше вкладывает в развитие компании, получать больше.
- Грейды могут быть вертикальные и горизонтальные.
Круто, когда человека сам решает, куда он хочет развиваться, и компания идет ему навстречу.
Под катом подробнее — текстом для тех, кому удобнее почитать, и ссылочка на видео для тех, кто предпочитает слушать.
Миша Шпаков — dev тимлид VDS.
Кира Айрапетова — руководитель HR в Timeweb.
Олег Филимошин — архитектор Timeweb Cloud.
Миша Шпаков (МШ): Всем привет, это подкаст «Релиз в пятницу» от компании Timeweb. Сегодня мы поговорим о грейдах в IT и не в IT-компаниях. Нужны ли они? Что это такое? И как с этим жить? Меня зовут Миша Шпаков, сегодня мне помогут Олег и Кира. Представьтесь, пожалуйста, и расскажите о себе.
Олег Филимошин (ОФ): Меня зовут Олег Филимошин, я работаю архитектором облака в Timeweb. Я застал много всяких вариаций того, как оценивать скилы разработчика, сам принимал участие в составлении программ и проектировании процесса оценки специалистов, поэтому я постараюсь чем-то поделиться.
Кира Айрапетова (КА): Меня зовут Кира Айрапетова, я работаю руководителем HR-отдела компании Timeweb. Я занималась в течение своей карьеры и доработкой грейдов, и разработкой грейдов, поэтому тоже хотела бы поделиться мыслями на этот счет.
МШ: Класс! А вообще, какое-то непонятное слово «грейд», что это такое?
КА: По сути, это структура для оценки снизу доверху. Началось это где-то в конце ХХ века, когда люди, которые управляли компаниями, поняли, что выдавать зарплаты из воздуха — это не очень удобно. Поэтому они придумали систему грейдирования. И мы все, особенно в IT, на ней едем по сей день.
МШ: Слушай, а вот джуниор, мидл, синьор — это оттуда?
КА: Да, но я думаю, что мы еще обсудим этот вопрос. Это тоже грейдирование, но не всегда оно правильное и не всегда хорошо используется.
МШ: Слушай, а вот ты начала говорить, что это используется для мотивации — только для мотивации или есть еще какие-то причины внедрения грейдов?
КА: Для введения грейдов существует несколько причин. Грейды полезны как бизнесу, так и разработчикам или другим сотрудникам, но мы IT-компания, так что будем говорить о разработке и о разработчиках.
Грейды нужны в компании, чтобы растить своих сотрудников в соответствии с потребностями бизнеса.
У нас есть грейд, скажем тот самый, не очень удачный «джуниор / мидл / синьор».
Чтобы в одной компании быть джуном, тебе достаточно знать язык «X» и набор технологий «Y» на каком-то, определенным компанией, уровне. Чтобы быть мидлом, тебе нужно знать всё это уровень выше, плюс уметь делать это самостоятельно. Чтобы быть синьором, знать технологии еще на уровень выше, и уметь обучать джуниоров, к примеру.
Какое-то общее понимание, что такое «джуниор / мидл / синьор», может быть похожим от места к месту.
Если мы говорим про конкретные грейды при оценке, то еще должны оцениваться конкретные скилы, знание технологий и так далее. «Джуниор/мидл /синьор», то нас в компании должны знать PHP, JS на одном уровне, а если человек приходит из другой компании или идет в другую компанию, там будут абсолютно другие требования.
Тот, кто в одном месте синьор, в другом может быть джуном, и наоборот. Бывают люди, которые говорят: «Я джун, я вообще ничего не знаю, меня не повышали 20 тысяч лет, я, наверное, совсем дурак» А потом он приходит и пилит архитектуру. Такое тоже бывает.
Грейды полезны для бизнеса, компания помогает человеку расти так, как полезно для компании. Человек должен оценивать себя здраво и должен понимать, что все компании работают по-разному. У человека должно быть объективное адекватное восприятие своих навыков и понимание того, где он эти навыки применит.
Еще существует бюрократическая история — карта компетенций, карта развития сотрудника. Это хорошо, но сложно. У разработчиков все немного проще: есть, допустим три грейда — что ты должен сделать, чтобы подняться на следующий, есть perfomance review, ты должен его пройти.
Конечно, я сейчас, все максимально упрощаю, так делать не очень правильно. Но если мы объясняем «на пальцах», это достаточно понятная схема развития для сотрудника. Компания показывает своему сотруднику, чего он должен добиться, чтобы поднять зарплату, скиллы и так далее.
Поэтому я за грейды, но за грейды, сделанные правильно. Очень часто компании совершают ошибки в их внедрении, потому что они не понимают, какую цель они преследуют. Более того, они даже не понимают, как это делать.
В итоге, отвечая на твой вопрос, да, это полезно, и бизнесу и сотрудникам, и грейды используют не только для мотивации.
ОФ: Я тоже хотел добавить. На самом деле, хорошо, если эти грейды прописаны.
А то приходишь в компанию, а там все на каком-то «подсознательном уровне» чувствуют, кто они есть и куда им двигаться. Потом осознанные люди начинают задавать вопрос «А куда я развиваюсь?» и всё рассыпается. Так что очень хотелось бы, чтобы грейды были прописаны. Хотя бы в Confluence.
КА: Мне кажется, документация нужна всегда и везде, хотя бы в минимальном количестве.
МШ: Олег, у тебя богатый опыт. Ты работал на разных позициях во многих компаниях. Можешь рассказать, что ты думаешь в целом о грейдах и о них, как о системе мотиваций?
ОФ: Сам по себе, в отрыве от других процессов, грейд — это не система мотиваций. Я хотел вкинуть мысль, которую нам следует обсудить — а только ли хард скиллы входят в грейды?
ИП: Нет. Я уже говорила, что джуна, мидла и синьора друг от друга отличает инициативность и самостоятельность. Это как раз про социальные навыки. Они везде почти одинаковые, но их тоже надо прописывать.
ОФ: Очень хорошо, если эйчар знает и умеет это использовать.
Раньше никто ничего не прописывал. В должностной инструкции написано что-то. Разработчики приходили, посидели, поработали как-то, деньги получили. Зарплата и «квалификация» пересматривались, когда разработчик приходил с офером из другой компании, и сообщал о том, что уходит. Если он был ценным сотрудником — руководство его тормозило, давало чуть больше денег, чем предложили в другом месте, и разработчик оставался.
Позже IT-отрасль в России стала развиваться и появлялись осознанность и осмысленность. Появились процессы по пересмотру уровня и зарплаты. Часто шел запрос на повышение уровня и з/п от разработчиков, так как они не развивались. Люди хотели не просто денег, но еще и расти в своей специальности.
В последнее время стали появляться компании, где все прописано. Часто в таких компаниях сильная команда HR-ов. Тебя знакомят с процессами, как только приходишь в компанию. В таких компаниях любой новичок знает, что через полгода будет ревью, он к нему готовится и прекрасно знает, что ему требуется сделать, чтобы повысить свою зарплату или квалификацию в рамках компании.
Мне доводилось участвовать и организовывать процесс работы с техническими специалистами, в него входила возможность оценить человека на входе в компанию по грейдам. И есть замечание, что очень плохо оценивать разработчиков тремя конечными грейдами.
Допустим, человек не развивался, был синьором, рынок поменялся. Новые сеньоры, приходящие в компанию, могут быть сильнее его по навыкам, иметь бОльшую з/п, и у человека возникнут вопросы к руководству.
Еще круто, когда компания может оценить кандидата на должность и дать ему обратную связь, если человек не подходит для компании, ему подскажут, что нужно подтянуть, чтобы ему были рады в этой компании.
КА: Да, есть люди, которые после нормально фидбэка возвращаются на собеседование, подтянув свои навыки.
ОФ: По той же системе можно оценить работника в период испытательного срока. Ожидания компании изложены письменно, можно пальцем аргументированно показать, что стоит подтянуть, а с чем человек круто справился.
Грейды — это инструмент, который не всегда подходит в контексте. Бывает контекст, когда у тебя кросс-функциональная команда, здесь неплохо подходит механизм с ролями.
Есть роль, у роли есть критерии и ты их можешь совмещать. Как дерево развития навыков в компьютерных играх. Это открывает глаза людям, что они могут не только в своей линейке раскачиваться. К примеру, прописав роли, компания может повысить количество фулстеков, если ей это выгодно. Или склонять больше людей в менеджерство.
Не все сеньоры могут менторить. Люди могут не уметь, не хотеть или не знать, что так можно. Поэтому мы ввели роль ментора. Это было формализовано, ты мог найти карточку сотрудника-ментора и узнать, с развитием каких компетенций он может помочь. У нас появилась внутренняя платформа для обучения (менторства). И появилась она благодаря тому, что мы это прописали, проговорили и рассказали остальным.
МШ: Вы назвали много плюсов, но у меня грейд ассоциируется с аутсорс-компаниями. Многие мои друзья работают в таких компаниях. Они рассказывают, что это очень стрессовая история, когда ты знаешь, что раз в полгода у тебя проверка, и ты боишься провалиться. А так как разработчики — часто интроверты, для них это нервирующая процедура, которая снижает продуктивность.
КА: Я думаю то, о чем говорят твои друзья — особенность их компаний. В крупных компаниях такие процессы действительно приносят стресс в жизнь, потому что требования не гибкие, они не про людей, а только для регламента. А то, что делается для регламента — всегда плохо.
Я за то, чтобы грейды были гибкие, многоуровневые, для сотрудников. И говорю о тех грейдах, которые работают в обе стороны. Иногда грейды вводятся, чтобы элементарно давать своим сотрудникам причину для НЕповышения зарплаты. Так бывает. Скорее всего, с этим связан негатив твоих знакомых.
Я за то, чтобы если сотрудник развивается, растет и тащит компанию вперед, то он получал больше. В идеале, грейды должны быть про это.
ОФ: У меня есть еще одна теория, почему для аутсорсеров грейды могут быть стрессом. При таких процессах, оценка тебя как сотрудника, происходит раз в полгода, а в остальное время ты не знаешь, что о тебе скажут.
КА: И более того, если мы говорим про грейды в крупных аутсорс- компаниях, оценка производится по хард скиллам. По каким-нибудь выполненным задачам из таск-трекера.
Ни твоя инициативность, ни твой бизнес-ориентированный подход, ни твое желание обучать джунов не влияют на это. Могут даже забыть посмотреть, что последний проект ты делал на PHP, который для этого ты и выучил, а до этого не знал. Это полная шиза, так использовать грейды.
Грейды — отличный инструмент, если его применять правильно. Если вводит грейды, которыми ты собираешься кошмарить людей, то получишь отток сотрудников. Грейды — это мотиватор, помощь компании и очень удобный инструмент оценки, чтобы двигать человека дальше, что выгодно обеим сторонам.
Я HR, не разработчик. Я могу оценить разработчика по софт-скилам, а что мне дальше делать с этой оценкой без грейдов — непонятно. Когда разработчики оценили хадр-скилы кандидата, я, зная должность, на которую мы ищем человека, могу понять, потянет он работать в проекте наравне со всеми, или это джун, которого стоит посадить писать запросы для базы данных, и пусть растет и проявляет инициативу.
ОФ: Также можно сравнить несколько кандидатов.
ОФ: Кто придумывает грейд в компании?
КА: В компании, если мы говорим о разработчиках, это должна быть смежная работа архитекторов, эйчаров и людей, которые оценивают и принимают решение, тимлидов, к примеру.
И грейды должны периодически пересматриваться, так как рынок очень подвижный. Следовать грейдам, которые написаны 2 года назад бесполезно. Это закладывают при разработке грейдов.
МШ: Давайте попробуем разобраться. У нас есть общепринятая практика на рынке. Есть три уровня специализации и кажется это очень мало.
КА: Что такое джун/мидл/синьор. Это три позиции, которые человек будто бы должен в своей жизни занимать. Есть еще тимлид. Хорошо, 4.
ОФ: Это странно, словно обязательно ты должен в тимлида вырастать.
КА: Ну да, будто менеджерская — это обязательно. На самом деле, нет. Если ты не хочешь заниматься менеджерством, это тоже допустимо. Джун/мидл/синьор — очень узко профилированная оценка, она не дает широты понимания всех навыков сотрудника.
Когда ты фулстачишь, выполняешь какие-то продуктовые задачи или частично проджект, тестируешь свой код, становится совсем непонятно. Ты джун чего? Или мидл чего? Будто бы ты делаешь все, но при этом непонятно, на каком уровне.
В идеале грейды должны быть многоуровневые, должны быть грейды в глубину и в ширину.
Допустим, сотрудник знает PHP на 10/10, JS на 5/10, еще знает базы данных, может работать с продуктами. Для грейда конечная цель — не только развитие, но и зарплата. Она должна складываться не только из того, что ты сеньор на PHP, но и из других навыков. Так, по моему мнению, должны выглядеть хорошие грейды.
Опять же, это система, к которой нужно прийти, она сложная, не все ее могут себе позволить, не у всех даже есть в этом потребность.
В рамках компании из 7 человек, какое-то интуитивное разделение джун-мидл-сеньор может быть нормально. Но не всегда понятно, что с ними и с компанией будет потом.
ОФ: Бывают еще очень редкие вещи, в которые никто не верит. Когда оценивается вся команда, команда полностью отвечает за свой результат и их зарплата зависит от их результата. Тогда грейды пропадают, они не нужны. Постарались хорошо — получите деньги, плохо — разберитесь внутри, в чем было дело.
КА: Это вопрос очень высокой самоответственности.
ОФ: И вопрос масштабирования. Для компании в 400-500 человек, это звучит почти нереально.
МШ: Как компании понять, что она готова к внедрению грейдов? Как это определить?
ОФ: Первое — у компании нет грейдов (смеется).
КА: Есть какие-то маркеры.
Стоит подумать о внедрении грейдов, когда начинается неразбериха в найме, неразбериха в мотивации сотрудников, когда не совсем понятно, что делать с зарплатами, потому что рынок не стабильный. Грейды — это в любом случае какая-то стабильность.
Когда эти маркеры начинают проявляться, стоит задуматься над введением структуры. Грейд — это структура. Структура нужна не всегда и не везде, я люблю творческих хаос, он классный, особенно если мы говорим про какой-то продуктовый подход. Но структура местами делает хорошие вещи гораздо лучше. Когда ты понимаешь, что у тебя происходит что-то непонятное, пора ввести структуру.
ОФ: Про маркеры. Самый важный маркет — когда приходят люди и говорят «Я не знаю, куда развиваться, я увольняюсь». Если все хорошо и все понимают, куда развиваться, и в бизнесе все хорошо — потребности в грейдах не возникает. Тогда нет проблем, пусть работает само.
МШ: Вы проговорили социальные навыки, роли, конкретные обязанности. Куда мне как специалисту расти, если я уже условно «сеньор», например?
КА: Можно в менеджеры. Это максимально про социальные навыки. Если ты хочешь управлять людьми, ты можешь — тогда ты это делаешь.
Если нет, то ничего нет плохого в том, чтобы развиваться как специалист. Хороший специалист, синьор, может отвечать только за техническую сторону разработки. Не за то, чтобы команда была мотивирована, а именно за то, как будет развиваться стек. То есть может расти и дальше в глубину. Технологии развиваются. Если ты синьор, и хочешь дальше оставаться синьором, ты все равно будешь расти за этими технологиями.
МШ: Но если я сеньор, то предполагается, что я уже на максимальном уровне и зарплаты и какого-то развития своей компании.
КА: Есть дополнительная мотивация, индексация за стаж, какие-то бонусы за участие и принесение пользы бизнесу. Есть способы мотивации сотрудников, которые не растут в менеджмент.
ОФ: Все зависит от компании. Если в твоей компании специалист видит, что у разработчиков зарплата n-я, а у всего менеджмента nx2, то разработчик рано или поздно догадается, куда идти.
Если в компании зарплаты уравнены, как на западе, где зарплата менеджмента ниже, чем у крутого специалиста, то сама компания тебя подталкивает развиваться больше в техническую сторону.
МШ: А как правильно показывать, какой у тебя грейд, надо ли делать его открытым? Чтобы я знал, допустим, что у Васи такой-то грейд, такой-то уровень и такая-то зарплата или это должно быть закрыто?
КА: К открытому грейду еще нужно прийти. Открытые зарплаты могут себе позволить не все компании в силу разных причин, это не только финансовый вопрос.
ОФ: Но все же это основная причина. Рынок труда сейчас — это биржа. Разработчики одного и того же уровня с разницей в 2-3 месяца взятые на работу, к сожалению, получат, скорее всего, разные зарплаты.
КА: Вопрос открытости — вопрос частный. От бизнеса к бизнесу. Кого-то это привлечет, а кого-то оттолкнет.
ОФ: Тут есть проблема. Разработчик может прийти за повышением зарплаты, так как у «соседа» другая зарплата. Он задается вопросом «чем я хуже?». Зарплата используется как инструмент оценки.
Но не всегда это оценка, часто бывает, что зарплата того или иногда специалиста сложилась из нужд. К примеру, у соседа х2, т.к. у него ипотека и трое детей, сейчас он просто не сможет нормально жить на меньшее. Но когда об этом узнает специалист со схожими обязанностями, у него будет ощущение, что его обделили, и меньше ценят. Это сложный вопрос.
МШ: Как правильно проводить скоринг специалиста?
ОФ: Я не уверен, что есть такое понятие «как правильно». Нельзя ответить, как правильно. Бывает как лучше, исходя из конкретных задач.
МШ: Допустим, мы в Timeweb вводим сетку грейдов, чтоб оценить своих сотрудников. Что я как тимлид должен сделать?
КА: Сначала эта сетка прописывается в зависимости от требований бизнеса, то есть надо понимать, что нужно бизнесу в данный момент. Ты оцениваешь, насколько твои сотрудники способны согласно грейдам эти задачи выполнять. Дальше можно сотрудников корректировать. Если ты понимаешь, что сотрудник хороший, слегка не дотянул, его можно обучить, его можно мотивировать. Но это в идеале, если компания не очень большая.
ОФ: Возможно Миша спрашивает про то, как этот процесс непосредственно организовать?
МШ: В том числе. На самом деле, есть несколько вопросов. Давай с этого начнем.
ОФ: Как минимум это психологически интересный момент. Человек сам себя может оценить по этой же системе. И можно потом свести с оценкой, проводимой компанией. Таким образом, человек может узнать, насколько адекватно он себя оценивает.
МШ: А если мы говорим об инструментах для оценки? Допустим, мы провели опрос 360. Это все равно нацелено на субъективную оценку тимлида, одного человека, который принимает решение. Или нет?
ОФ: А это как вы сделаете. Чаще всего собираются рабочие группы. Из кого их собирать, тоже от вас зависит. Либо это люди из твоей компетенции, либо это разносторонние люди, либо это представители бизнеса.
КА: Это люди принимающие решение, но у них должны быть компетенции на принятие этого решения.
ОФ: Хочу добавить, что обычно это стоит очень дорого. Раз в полгода какие-то ключевые лица от работы отстраняются, они занимаются ревью около месяца, в зависимости от размера компании. В итоге из полугода, человека занимается основными рабочими задачами только 4-5 месяцев. Это приводит к тому, что в какой-то момент начинают оценивать раз в год, качество ревью падает. Нужно искать баланс и выбирать такой процесс, чтобы это не затягивать, не превращать в дорогое бесполезное удовольствие.
МШ: Есть ли еще что-то помимо грейдов, что позволяет правильно работать с сотрудниками и мотивировать их?
ОФ: Лучший способ — это хорошая развитая обратная связь в команде.
Не нужно ждать, когда к тебе придет эйчар, скинет заранее подготовленную форму, и потребует заполнить. Эйчар может быть не в курсе, что вы друг с другом не работаете, хотя сидите рядом и кушать вместе ходите.
Так что, если у вас хорошо развита обратная связь, то скорее всего, как только встречается какая-то проблема в команде, сотруднику дадут обратную связь, он тут же продолжит развиваться дальше. Этот цикл петли обратной связи грейды обязывают проводить хотя бы раз в полгода. Если это развивать как часть культуры, то даже грейды не понадобятся.
КА: Это действительно вопрос хорошей коммуникации между руководителем и командой.
ОФ: Это вектор, куда стоит двигаться. Грейды — это способ прийти к нормальному фидбэку через формальный процесс.
МШ: Как часто надо устраивать performance review?
КА: Раз в полгода — это оптимальный промежуток времени, потому что дорого, во-первых, а во-вторых, полгода — это достаточный срок для человека, чтобы он помимо задач, которых обычно в работе много, мог как-то прокачаться.
Ты же не только на рабочих задачах развиваешься, ты что-то извне потребляешь. На это нужно время, нужно время, чтобы освоить, применить в работе.
ОФ: А еще раз в полгода, потому что в отпуска люди уходят, сезонность подбирается. Не обязательно развитие — это про какие-то хард-скилы, может нужно прочитать книгу, а может повысить уровень английского, чтобы техническую литературу свободно читать. Это нельзя сделать за месяц или за пару дней. Скорее всего это займет много времени.
Но, например, когда мы формировали процесс, мы заложили возможность досрочного пересмотра. Если человеку поставили большую цель и он справился за 2 месяца, то ему не нужно ждать еще 4 месяца.
МШ: Я для себя узнал очень много сегодня и очень интересно было с вами пообщаться.
В итоге, что грейд — это очень крутая штука, если использовать правильно. Они нужны не всем компаниям, компания сама должна понять что ей нужно — грейды или что-то другое.
Грейд строится не только на технических навыках, а также на массу навыков, также хорошо, когда они включают в себя какие-то роли и задачи.
Круто, когда человек сам говорит, куда он хочет развиваться и компания идет ему навстречу. Спасибо за разговор, было интересно в этом разобраться.
Источник: https://habr.com/ru/company/timeweb/blog/579204/
