
Нет, разумеется, хотят. И многие даже соглашаются. Правда потом возвращаются обратно в разработку, но соглашаются же.
Так что правильнее сказать «почему то, что им предлагают, вообще называется повышением».

Нет, разумеется, хотят. И многие даже соглашаются. Правда потом возвращаются обратно в разработку, но соглашаются же.
Так что правильнее сказать «почему то, что им предлагают, вообще называется повышением».
Меня зовут Кирилл, я IT-директор в Ви.Tech, IT-дочке ВсеИнструменты.ру. Недавно мы записали подкаст с Сергеем Щербининым, CEO консалтинговой компании fcon tech, бывшим CTO/CIO, и по ходу разговора снова уткнулись в performance review. Тема вроде не новая, но каждый раз в ней всплывает один и тот же сюжет: компании очень хотят собрать процесс, который сразу решит все, и именно в этот момент обычно начинаются проблемы.
Все мы знаем стандартную лестницу: Junior, Middle, Senior. Но где на самом деле проходит граница? Почему в одном стартапе «сеньор» — это тот, кто вчера узнал про LINQ, а в кровавом энтерпрайзе от «мидла» требуют проектировать распределенные системы под нагрузкой в миллион RPS?
Я задалась вопросом оценки собственного грейда, когда уходила со своего первого места работы. Кто я для рынка? Почему мои знания на собесе в одной компании соответствуют чуть ли не уровню Senior, а в другой – покрывают максимум вакансию Junior’a?
Почти 6 лет мы в WPP.DIGITAL использовали классические грейды, чтобы оценивать квалификацию наших разработчиков. За это время пережили многое: проводили многочасовые интервью, шлифовали матрицу компетенций, убеждали сеньоров не скромничать, а джунов – не быть слишком уверенными в себе. Но вопросы все равно оставались: что делать, когда разработчик крут в одном стеке, но новичок в другом? Какой у него грейд? И главное – отражают ли оценки реальную эффективность специалиста?

Сложность чёткого определения должностей заключается в том, что люди пытаются обмануть систему (всегда заявляя, что они заслуживают новой должности/повышения зарплаты). Я наблюдал, как для борьбы с этим организации создают всё более длинные определения, позволяющие избегать пограничных случаев. Постепенно определения начинают занимать несколько страниц и перестают умещаться в головах. В процессе сложности системы соблюдение её правил ослабевает, а потом люди просто перестают им следовать. Я считаю, что есть более правильный путь, поэтому предлагаю следующее:
Не платите за то, сколько людей под руководством или сколько строк кода они написали. Платите им за генерируемые результаты.
Эта философия сильна и наделяет свободой. Неважно, если вы сотрудник, вносящий индивидуальный вклад (individual contributor, IC), занимаетесь техническим руководством или управлением командой. Важно то, насколько ваш вклад влияет на прибыль бизнеса.
В этом посте предлагается многоуровневая система, которую можно применять к IC, техническим руководителям и руководителям команд.
Читать полностью »
Сколько в компании разработчиков, столько примерно и мнений. Например, где именно проходит граница между мидлом и синьором? Нам нужен был справедливый инструмент оценки, который помогает понять, не получает ли наш специалист зарплату меньше, чем должен был бы. И, самое главное, что нужно делать для того, чтобы развиваться.
В итоге мы сделали опросник из 14 пунктов, по которому за несколько минут можно оценить себя. То же самое делает про вас тимлид, и если оценки совпадают, то всё отлично, есть грейд и зарплата в нём (у нас по три уровня внутри каждого грейда, например, джун-джун, опытный джун и джун 80-го уровня). Если оценки не совпадают — начинается процесс переговоров с приведением примеров для синхронизации по части оценки и ожиданий, чтобы потом на следующей итерации они всё-таки совпали.
Пока мы попробовали этот подход на 120 разработчиках. Выглядит многообещающе. Но я хотел бы показать вам сам опросник, детали системы и обсудить, насколько прозрачной получилась такая система. Дальше в посте — предпосылки её создания, разбор каждого из параметров и ссылка на форму, которая показывает результат по нашей системе грейдов.
Читать полностью »