Pull to refresh

Как сделать, чтобы они не уходили

Reading time3 min
Views25K
Вопрос удержания IT специалистов занимает умы не одного ИТ и HR менеджера. ИТ специалисты, особенно девелоперы, очень избалованы предложениями о работе, как внутри страны, так и за её пределами. Найти нового девелопера на замену ушедшему — задача не одного дня (иногда и не одного месяца, если это senior или lead developer). Как же их удержать? Начну с того, что это нормально, когда человек уходит из компании через 3-4-5 лет работы. Если люди начинают уходить более часто — это уже проблема.

image


Хороший руководитель знает о планируемом уходе своего сотрудника заранее. Отмечу, что у хорошего руководителя никогда не бывает не запланированных уходов сотрудников. Поэтому он даёт задание HR службе заранее и у него, к моменту ухода специалиста, уже есть несколько претендентов на освобождающееся место.

Рекомендация первая. Поддерживайте контакт со своими сотрудниками.

image

Как: Варианты разные. Регулярно проводить тимбилдинги внутри отдела (да именно так называет ИТ менеджер эту статью в бюджете, когда думает о походе в паб со своими сотрудниками (шутка, хотя...)). Вы ведь выбили деньги на такую статью бюджета? Тимбилдингом может быть неформальный выезд на шашлыки, велопрогулка, поход, прохождение квест-комнаты или игра в лазер-таг. Ключевое слово — регулярно. Обязательно надо периодически общаться с глазу на глаз с каждым сотрудником. Периодичность зависит от размера команды, но не реже чем раз в квартал. Во время этой встречи сначала узнайте у сотрудника о существующих проблемах и вопросах, и только потом дайте обратную связь и оценку его работы (про правило «бутерброда», я вам не буду напоминать).

Рекомендация вторая. Справедливая оценка труда.

image

Как: Подразумевается, во-первых, соблюдение ТК РФ (т.е. никаких оплат в конвертах и попыток надурить с начислениями). Во-вторых, чёткие и понятные должностные обязанности. ИТ-шники очень не любят, когда их постоянно заставляют делать не свойственную им работу. Разово допустимо привлечь к переезду офиса или генеральной уборке, но не более того. Регулярные испытания на самого сильного программиста приведут к уходу человека. В-третьих, если вы используете KPI, то не забывайте о том, чтобы они соответствовали SMART (конкретные, измеримые, достижимые, актуальные, ограниченные во времени). Также учтите, что системные администраторы, разработчики и ИТ аналитики очень не глупые люди. Они умеют хорошо считать, поэтому не надо играть в игры с такими людьми, пытаясь манипулировать цифрами и условиями, для подведения к невозможности достичь планируемых показателей. Эти люди сначала обидятся, а потом найдут место где их не обманывают (поверьте, такие места есть, даже в кризис!). Ещё — KPI не догма, то есть надо на регулярной основе делать анализ насколько они актуальны и соответствуют вашим нуждам и нуждам компании.

Рекомендация третья. Развитие и профессиональный рост.

image

Как: Без перспектив развития ваши люди разбегутся, даже если вы будете им платить хорошую зарплату. Точнее так — разбегутся профи, а останется шлак, готовый сидеть от звонка до звонка. Поэтому стоит задуматься о создании системы обучения персонала, если у вас её ещё нет. Если у вас грамотная служба HR в организации, то система обучения у вас должна уже быть. Но даже если она и есть, вам в любом случае придётся поработать. Необходимо продумать систему грейдирования. Это отражение уровней компетенции сотрудника. Примеры: инженер 2 категории — инженер 1 категории — ведущий инженер — главный инженер или junior developer — middle developer — senior developer — tech lead. Мало продумать грейды, вам надо продумать матрицу компетенций для каждого уровня (skills matrix). Это описание технологий, инструментов, качеств сотрудника и т.п., которые должны быть проявлены на данном уровне. Часто ещё применяют градацию проявления каждого качества (пример — читает со словарём до владеет в совершенстве). И это ещё не всё, надо продумать какие то бонусы, как материальные так и не материальные, которые будет получать сотрудник при переходе из грейда в грейд. Продумать процедуры оценки и формальные критерии. Составить для своих сотрудников PDP (персональный план развития). Продумать возможность выделения бюджетов под обучение своих сотрудников. Так же не стоит забывать, что надо постоянно им доверять всё более и более важные проекты. В общем, есть чем заняться.

Рекомендация четвёртая и последняя. Если люди подобраны правильно, они не нуждаются в мотивации. Всё, что нужно — это обеспечить отсутствие демотивирующих факторов © Джим Коллинз

P.S. Не забывайте про картинку в заголовке поста — просто не будьте м… и и не работайте с такими людьми. Прежде чем внедрять что-то новое в мотивации и оплате труда примерьте новшество на самого себя, поставьте себя на место вашего девелопера или системного администратора. Вам комфортно? Ваш доход не стал меньше? Вы можете достичь показателей, которые приведут вас к получению премии? И вас будут любить ваши сотрудники, и вы постигните дзэн и переродитесь в следующий жизни на какой-то другой планете, где этих(из книжки) нет вообще — в принципе.
Tags:
Hubs:
Total votes 47: ↑26 and ↓21+5
Comments100

Articles