Рубрика «грейды»
Ваши ставки, господа…
2026-01-27 в 7:16, admin, рубрики: грейды, маржинальность, роли, ставки, тарификация, тендер, тендеры и закупкиЭволюция .NET-разработчика: взгляд рынка на грейды и компетенции (анализ 700+ вакансий)
2026-01-17 в 6:30, admin, рубрики: C#, c#.net, data science, junior, middle, senior, грейды, исследованиеВсе мы знаем стандартную лестницу: Junior, Middle, Senior. Но где на самом деле проходит граница? Почему в одном стартапе «сеньор» — это тот, кто вчера узнал про LINQ, а в кровавом энтерпрайзе от «мидла» требуют проектировать распределенные системы под нагрузкой в миллион RPS?
Я задалась вопросом оценки собственного грейда, когда уходила со своего первого места работы. Кто я для рынка? Почему мои знания на собесе в одной компании соответствуют чуть ли не уровню Senior, а в другой – покрывают максимум вакансию Junior’a?
IT БЕЗ ГРЕЙДОВ – КАК МЫ ОЦЕНИВАЕМ ЭФФЕКТИВНОСТЬ РАЗРАБОТЧИКА И КОМАНДЫ
2025-06-11 в 12:50, admin, рубрики: грейды, компетенции, метрики качества, метрики кода, мотивация в ИТ, мотивация программистов, мотивация разработчиков, разработчики, система оценки персонала, эффективность трудаПочти 6 лет мы в WPP.DIGITAL использовали классические грейды, чтобы оценивать квалификацию наших разработчиков. За это время пережили многое: проводили многочасовые интервью, шлифовали матрицу компетенций, убеждали сеньоров не скромничать, а джунов – не быть слишком уверенными в себе. Но вопросы все равно оставались: что делать, когда разработчик крут в одном стеке, но новичок в другом? Какой у него грейд? И главное – отражают ли оценки реальную эффективность специалиста?
Матрица soft skills: как вырасти от стажера до синьора
2024-11-29 в 11:49, admin, рубрики: грейды, карьера ИТ-специалиста, карьера программиста, навыки, развитие, разработка, разработка сайтов
Как организовать систему оплаты в компаниях, занимающихся разработкой
2024-02-05 в 13:00, admin, рубрики: ruvds_переводы, грейды, должности, должностные обязанности, зарплата, карьера
Любая программная компания рано или поздно сталкивается с проблемой должностей. Некоторые организации довольствуются «плоской» системой, но в отсутствие системы должностей возникают теневые иерархии, что на самом деле хуже. Должности дают чёткую демаркацию ожиданий от конкретного сотрудника. Например, гораздо проще возложить на ведущего разработчика ответственность за техническое руководство, если эта роль чётко определена. Без определений должностей наверх будут подниматься самые громкие, а тихие и вдумчивые останутся незамеченными.
Сложность чёткого определения должностей заключается в том, что люди пытаются обмануть систему (всегда заявляя, что они заслуживают новой должности/повышения зарплаты). Я наблюдал, как для борьбы с этим организации создают всё более длинные определения, позволяющие избегать пограничных случаев. Постепенно определения начинают занимать несколько страниц и перестают умещаться в головах. В процессе сложности системы соблюдение её правил ослабевает, а потом люди просто перестают им следовать. Я считаю, что есть более правильный путь, поэтому предлагаю следующее:
Не платите за то, сколько людей под руководством или сколько строк кода они написали. Платите им за генерируемые результаты.
Эта философия сильна и наделяет свободой. Неважно, если вы сотрудник, вносящий индивидуальный вклад (individual contributor, IC), занимаетесь техническим руководством или управлением командой. Важно то, насколько ваш вклад влияет на прибыль бизнеса.
В этом посте предлагается многоуровневая система, которую можно применять к IC, техническим руководителям и руководителям команд.
Читать полностью »
Где именно лежит граница между зарплатными грейдами: как это устроено у нас
2022-05-26 в 7:01, admin, рубрики: skyeng, Блог компании Skyeng, грейды, Карьера в IT-индустрии, команда, компетенция, опрос, разработчик, софт скилс, тимлид, управление персоналом, управление проектами, хард скилс
Сколько в компании разработчиков, столько примерно и мнений. Например, где именно проходит граница между мидлом и синьором? Нам нужен был справедливый инструмент оценки, который помогает понять, не получает ли наш специалист зарплату меньше, чем должен был бы. И, самое главное, что нужно делать для того, чтобы развиваться.
В итоге мы сделали опросник из 14 пунктов, по которому за несколько минут можно оценить себя. То же самое делает про вас тимлид, и если оценки совпадают, то всё отлично, есть грейд и зарплата в нём (у нас по три уровня внутри каждого грейда, например, джун-джун, опытный джун и джун 80-го уровня). Если оценки не совпадают — начинается процесс переговоров с приведением примеров для синхронизации по части оценки и ожиданий, чтобы потом на следующей итерации они всё-таки совпали.
Пока мы попробовали этот подход на 120 разработчиках. Выглядит многообещающе. Но я хотел бы показать вам сам опросник, детали системы и обсудить, насколько прозрачной получилась такая система. Дальше в посте — предпосылки её создания, разбор каждого из параметров и ссылка на форму, которая показывает результат по нашей системе грейдов.
Читать полностью »