В новом выпуске подкаста «Релиз в пятницу» Миша Шпаков, Кира Айрапетова, Олег Филимошин обсудили грейды: когда, кому, зачем они нужны и как эффективно их использовать.
Если коротко, вот что я выделила для себя:
- Грейд — структура, позволяющая привязать зарплаты в компании к навыкам и задачам сотрудников.
- Грейды нужны не всем компаниям.
- Грейды не только про hard-skills.
- Грейды обоюдно удобны, если позволяют тем, кто больше вкладывает в развитие компании, получать больше.
- Грейды могут быть вертикальные и горизонтальные.
- Круто, когда человека сам решает, куда он хочет развиваться, и компания идет ему навстречу.
Под катом подробнее — текстом для тех, кому удобнее почитать, и ссылочка на видео для тех, кто предпочитает слушать.
Промотать к видео
1:47 — что такое грейды
3:16 — для чего внедрять систему грейдов?
4:25 — о разных оценках специалистов в разных компаниях
6:07 — рост сотрудника и грейды: как это связано?
8:53 — hard и soft skills в системе оценки
11:30 — что не так с оценкой «джун, мидл, сениор»
13:46 — когда грейды не подходят? о ролях и их критериях
14:49 — сениор не всегда ментор
15:33 — когда и почему грейды = стресс?
18:57 — о том, как грейды помогают
21:05 — кто устанавливает грейды в it-компании?
22:03 — эффективные грейды — это как?
26:07 — когда пора внедрять грейды в компании
27:40 — как и куда расти сениорам? идти в менеджеры — обязательный путь?
30:30 — об открытости информации о грейдах
32:20 — как лучше проводить оценку сотрудников? о процессе и инструментах
35:48 — как оценивать и мотивировать без грейдов
37:25 — частота perfomance review
Миша Шпаков — 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 месяца.
МШ: Я для себя узнал очень много сегодня и очень интересно было с вами пообщаться.
В итоге, что грейд — это очень крутая штука, если использовать правильно. Они нужны не всем компаниям, компания сама должна понять что ей нужно — грейды или что-то другое.
Грейд строится не только на технических навыках, а также на массу навыков, также хорошо, когда они включают в себя какие-то роли и задачи.
Круто, когда человек сам говорит, куда он хочет развиваться и компания идет ему навстречу. Спасибо за разговор, было интересно в этом разобраться.
Комментарии (13)
f000
21.09.2021 18:55+1Посмотрел еще вчера перед скрытием статьи.
Может я уже слишком стар, но чувствую себя ВикторСегреичем из одноименного скетча "приклеить или прибить".
Areso
21.09.2021 20:29+3А почему придумали в конце ХХ века? Не согласен с таким утверждением. У нас вот была система, называлась штатное расписание. А совместно с должностными инструкциями, в которых были и требования к кандидату, вполне можно было понять, джун (младший инженер), разраб (инженер 3,2,1 категорий), старший инженер (синьор), ведущий инженер (тимлид).
Все новое - хорошо забытое старое. Ну а кто-то может в силу возраста не застал...
geher
21.09.2021 23:15+1Вот-вот. Обозвали старое новыми словами. Только младшего инженера вроде не было (по крайней мере не встречал никогда). Вместо него был инженер без категории и техники (оба варианта примерно соответствовали джунам, но с различиями по требованиям к уровню образования и/или подготовки). Да и старшего вроде не припоминаю.
И на ведущего не всегда и не везде возлагались обязанности тимлида. Иногда он выполнял совсем другие роли (прожект менеджеры всякие и т.п.).
А еще были главные инженеры.
Хотя в разных организациях названия должностей в штатном расписании и должностные обязанности вполне могли отличаться.
Кстати, слышал, что эти порядки в некоторых организациях до сих пор почти без изменений существуют (разве только с некоторыми изменениями в оплате труда).
Areso
21.09.2021 23:21Главный инженер это как CTO, куда там простому инженеру...
И да, до сих пор живо - заводы там, КБ, МУПы, ФГУПы, и тому подобные организации.
Ares_ekb
22.09.2021 09:02+3Ха-ха, на мой взгляд, это квинтэссенция подкаста https://youtu.be/5-8rnwvZv7A?t=1907
Немного перефразируя: "Если одного устраивает одна зп, его прет от работы и т.п. А у другого ипотека, он пришел в компанию на 3 месяца позже, и мы готовы ему платить в 2 раза больше чем первому, то это нормально. Единственное, потом может вскрыться, что тим лид на проекте получает в 2 раза меньше, чем джун (рил ток), как-раз по этим самым причинам. И у первого немного снизится мотивация, поэтому лучше держать эту информацию в тайне."
Я с таким подходом сталкивался неоднократно и ощущение, что это считается нормой. Если у человека низкая самооценка, он просто скромный или ему очень хочется заниматься этим проектом, то зачем ему платить много? Буквально дословно неоднократно слышал фразу: "ну, он сам попросил такую зп, мы ему даже немного накинули, по-моему его всё должно устраивать, че он молчал". При этом люди с более низкой мотивацией, а часто и с более низкой квалификацией получают больше.
Я, например, на проекте совершенно четко вижу кто как работает, у кого какие компетенции. Меня ночью разбуди и я отвечу кто по вкладу стоит на 1-ом месте, кто на 2-ом, ..., кто на 7-ом и т.д. Кому какие задачи можно давать, кто сделает их за полдня, кто за неделю, кто вообще не сделает. И, главное, почему, я по нескольким критериям это легко обосную. Для этого мне не нужно проводить performance review раз в полгода. Но проблема в том, что это вижу не только я, но и другие сотрудники, а ещё они видят штатные должности коллег, по которым косвенно понимают уровень зарплаты. Когда они соотносят две переменные X (вклад сотрудника) и Y (должность, зп, а значит и оценка сотрудника руководством), то возникает естественный вопрос: может лучше меньше работать, потому что зп и так будут платить, или поискать другое место работы, где усилия будут оценены адекватно.
Какой смысл вообще в грейдах, если они не особо влияют на зп? Если зп определяется тем, сколько денег человек попросил, на сколько он мотивирован? Грейды не влияют также и на должностные обязанности сотрудника. Видел ситуации, когда мидл по факту менторит архитектора. Очевидно, что единственный смысл в грейдах - это просто пряник, нематериальная мотивация сотрудника, чтобы у него было ощущение, что он куда-то развивается. Либо это кнут, чтобы он понимал, что через полгода ему могут не повысить зп, если он будет плохо работать.
Короче, всё тлен, с этим ничего не поделать. Хорошим сотрудникам всегда будут платить меньше, потому что они и так мотивированы, потому что такой рынок, ...
Хотя наверное грейды - это не только корпоративный булшит, возможно в них есть и смысл. Если реально есть дерево компетенций, не высосанных из пальца, если на постоянной основе проводится обучение сотрудников для роста этих компетенций, то такая система позволит людям реально развиваться, повышать свою самооценку и либо на текущей работе просить повышение, либо на рынке труда быть более востребованным. Наверное грейды, сопряженные с системой обучения, это не такой уж отстой.
Ещё история из жизни (сорян, мне лень писать статьи, хоть в комментариях утолю жажду графоманства :). У меня на одной из работ ввели систему грейдов, и для меня это было одной из причин увольнения из компании, потому что глядя на этот перечень компетенций я совершенно четко осознал, что мне некуда развиваться ни по основной специальности, ни по смежным, и какой смысл дальше там работать. Т.е. грейды хорошо демонстрируют так же и профиль компании.
Бесплатная идея для стартапаможно публиковать на сайте компании дерево компетенций, чтобы люди понимали в какую компанию они идут и что им это даст. Или на сайтах с вакансиями компании могут выкладывать такие деревья для отдельной должности или объединенное дерево по всем должностям. Это куда интереснее, чем просто стандартный перечень требуемых компетенций: ответственность, мотивированность и т.п., по ним сложно понять какие перспективы на этой должности.Че-то похоже во мне проснулся не только графоман, но и стартапер:можно помайнить вакансии и резюме на предмет того какие компетенции уже есть в компаниях и какие требуются, аналогично для сотрудников: что они умеют уже сейчас и чему хотели бы научиться. Конечно, на сайтах вакансий есть ключевые слова, но много где требуется, например, Java, но по этому ключевому слову непонятно на сколько интересен будет этот проект, как ты будешь развиваться как специалист. Хочется из тысяч вакансий сразу найти подходящую. Ещё идея. Если дерево компетенций отражает профиль компании, то можно компании разбить на кластеры, чтобы в целом видеть чем вообще занимаются на рынке и где интереснее.APXEOLOG
22.09.2021 09:25Короче, всё тлен, с этим ничего не поделать. Хорошим сотрудникам всегда будут платить меньше, потому что они и так мотивированы, потому что такой рынок, ...
Это очень сомнительное утверждение. Размер ЗП человека зависит от многих условий, но в основном он зависит именно от самого человека, а не от "хоршевизны" сотрудника.
Можно привести аналогию - есть люди, которые в магазине берут товары не глядя на срок годности и иногда жалуются, что купили просроченный товар. Другие люди всегда смотрят на срок и у них нет таких проблем. А третий тип людей не только смотрит на срок, но еще и все магазины в округе мониторит и покупает качественные продукты дешевле, чем первые две группы. Да - такой рынок. Но в конечном счете все зависит от человека.
Ares_ekb
22.09.2021 10:48+3Да, я об этом и говорю. Если человек просит небольшую зп, то ему её и будут платить. В подкасте архитектор это прямо и сказал. Я часто слышал такую позицию и от других людей тоже.
Просто есть hard-скилы, есть soft-скилы. Далеко не у всех они одинаково хорошо развиты. А то о чем вы говорите, это уже какие-то trade-скилы, которые к уровню специалиста никакого отношения не имеют. И, на мой взгляд, людей у которых хорошо развиты все эти 3 типа скилов совсем мало. Если человек активно ходит по рынку труда, ему в принципе не так важно где работать, лишь бы работать меньше, но получать больше. То есть вопросы на сколько хороший он специалист, на сколько он мотивирован чем-то кроме денег, например, брать какие-то сложные задачи, обучать других сотрудников. Если он и так мотивирован, то зачем ему платить больше?
Наверное есть такие гении, у которых хорошо развиты все скилы...
HellWalk
22.09.2021 09:51Какой смысл вообще в грейдах, если они не особо влияют на зп?
Чтобы человек развивался так, как нужно компании. А не так, как нужно ему (чтобы у него самого такой мысли вообще не возникло - а какое развитие я хочу?)
Хорошим сотрудникам всегда будут платить меньше, потому что они и так мотивированы
Видел программистов, которые получали сильно меньше их реального уровня. Обычно они очень пассивны в плане работы - т.е. у них много других приоритетов в жизни, а работа - есть и ладно.
Ares_ekb
22.09.2021 10:36+2А как они достигли этого уровня, если они очень пассивны в плане работы? Может быть они пассивны в плане поиска работы? У человека могут быть отличные hard-скилы, могут быть отличные soft-скилы (он обучает других сотрудников, легко общается с коллегами по рабочим вопросам, предлагает идеи). При этом работа у него может быть на первом месте или нет.
Но то о чем вы говорите, это скорее trade-скилы, нужно адекватно оценивать свои способности, адекватно оценивать работодателей. Пробежаться по рынку, посмотреть где дороже, где дешевле, где нужно больше работать, где меньше, где нужно поторговаться. И ни к уровню специалиста, ни к его активности в работе всё это никакого отношения не имеет.
Пример из жизни. Два сотрудника устраиваются на работу примерно в одно и то же время. Один прямо активно работает, постоянно проявляет инициативу, ему дают сложные задачи, тим лид ему делегирует всё больше своих задач. И другой сотрудник ну просто что-то с чем-то, за полгода делает самостоятельно ровно 0 задач, сначала он обучался, потом ему дают задачи на день работы, он делает их по две недели. Причем не так, что он исчез на эти две недели и про него забыли, а активно отвлекает от работы других сотрудников, ему нужно полностью разжевать саму задачу, полностью разжевать решение задачи, но он всё равно сделает её неправильно, нужно будет всё повторить снова. Тим лид периодически пытается ему как-то помочь с задачей, направить его в нужную сторону, хотя за потраченное время он мог бы сделать 10 таких задач. Потом выясняется, что опять что-то нужно доделывать по этой задаче. Но люди тратят на всё это время из расчета, что человек обучится и дальше начнет нормально самостоятельно работать. Но к сожалению он не обучается, по итогам испытательного срока ему не повышают зп, при этом не увольняют и не понижают зп, но дают какие-то совсем простые задачи, даже не на разработку, больше на ручное тестирование. Но чел очень расстраивается из-за того, что ему не повысили зп и сваливает. А потом эти два человека общаются между собой и выясняется, что второй чел получал в 1,5 раза больше чем первый, а сейчас на новой работе получает ещё больше. Конечно ситуация комичная, я желаю удачи его новым работодателям. Но, ок, допустим, у второго чела недостаток hard-скилов, но у него и с soft-скилами всё ещё хуже. Сказать, что в работе он проявлял какую-то активность я тоже не могу. По всем пунктам он уступает первому челу, он не тянет даже на джуна. Но видимо активность в поиске работы всё это перевешивает.
HellWalk
22.09.2021 16:44+2А как они достигли этого уровня, если они очень пассивны в плане работы?
Профильное образование
Математический склад ума
Ну и просто большой ~15 лет опыт работы. За столько лет, хочешь не хочешь - прокачаешься
Это если говорить о том, что видел со стороны.
Ну и делайте скидку на субъективное мнение. Для меня, человека у которого в 35 лет кроме программирования нет ничего - 99% окружающих программистов - очень пассивны в плане работы/программирования. Тратят время на каких-то девушек, посиделки-гулянки, в общем фигней страдают :)
chernish2
А как можно подписаться на подкаст?
tw_community
Добрый вечер)
Подписаться и смотреть можно здесь: https://www.youtube.com/channel/UCTSnrzx_YKQOzTR1Y6OxxSQ
Подписаться на любой удобной аудио площадке и слушать можно здесь: https://friday-release.mave.digital/ep-3