Как сделать, чтобы они не уходили
Хороший руководитель знает о планируемом уходе своего сотрудника заранее. Отмечу, что у хорошего руководителя никогда не бывает не запланированных уходов сотрудников. Поэтому он даёт задание HR службе заранее и у него, к моменту ухода специалиста, уже есть несколько претендентов на освобождающееся место.
Рекомендация первая. Поддерживайте контакт со своими сотрудниками.
Как: Варианты разные. Регулярно проводить тимбилдинги внутри отдела (да именно так называет ИТ менеджер эту статью в бюджете, когда думает о походе в паб со своими сотрудниками (шутка, хотя…)). Вы ведь выбили деньги на такую статью бюджета? Тимбилдингом может быть неформальный выезд на шашлыки, велопрогулка, поход, прохождение квест-комнаты или игра в лазер-таг. Ключевое слово — регулярно. Обязательно надо периодически общаться с глазу на глаз с каждым сотрудником. Периодичность зависит от размера команды, но не реже чем раз в квартал. Во время этой встречи сначала узнайте у сотрудника о существующих проблемах и вопросах, и только потом дайте обратную связь и оценку его работы (про правило «бутерброда», я вам не буду напоминать).
Рекомендация вторая. Справедливая оценка труда.
Как: Подразумевается, во-первых, соблюдение ТК РФ (т.е. никаких оплат в конвертах и попыток надурить с начислениями). Во-вторых, чёткие и понятные должностные обязанности. ИТ-шники очень не любят, когда их постоянно заставляют делать не свойственную им работу. Разово допустимо привлечь к переезду офиса или генеральной уборке, но не более того. Регулярные испытания на самого сильного программиста приведут к уходу человека. В-третьих, если вы используете KPI, то не забывайте о том, чтобы они соответствовали SMART (конкретные, измеримые, достижимые, актуальные, ограниченные во времени). Также учтите, что системные администраторы, разработчики и ИТ аналитики очень не глупые люди. Они умеют хорошо считать, поэтому не надо играть в игры с такими людьми, пытаясь манипулировать цифрами и условиями, для подведения к невозможности достичь планируемых показателей. Эти люди сначала обидятся, а потом найдут место где их не обманывают (поверьте, такие места есть, даже в кризис!). Ещё — KPI не догма, то есть надо на регулярной основе делать анализ насколько они актуальны и соответствуют вашим нуждам и нуждам компании.
Рекомендация третья. Развитие и профессиональный рост.
Как: Без перспектив развития ваши люди разбегутся, даже если вы будете им платить хорошую зарплату. Точнее так — разбегутся профи, а останется шлак, готовый сидеть от звонка до звонка. Поэтому стоит задуматься о создании системы обучения персонала, если у вас её ещё нет. Если у вас грамотная служба HR в организации, то система обучения у вас должна уже быть. Но даже если она и есть, вам в любом случае придётся поработать. Необходимо продумать систему грейдирования. Это отражение уровней компетенции сотрудника. Примеры: инженер 2 категории — инженер 1 категории — ведущий инженер — главный инженер или junior developer — middle developer — senior developer — tech lead. Мало продумать грейды, вам надо продумать матрицу компетенций для каждого уровня (skills matix). Это описание технологий, инструментов, качеств сотрудника и т.п., которые должны быть проявлены на данном уровне. Часто ещё применяют градацию проявления каждого качества (пример — читает со словарём до владеет в совершенстве). И это ещё не всё, надо продумать какие то бонусы, как материальные так и не материальные, которые будет получать сотрудник при переходе из грейда в грейд. Продумать процедуры оценки и формальные критерии. Составить для своих сотрудников PDP (персональный план развития). Продумать возможность выделения бюджетов под обучение своих сотрудников. Так же не стоит забывать, что надо постоянно им доверять всё более и более важные проекты. В общем, есть чем заняться.
Рекомендация четвёртая и последняя. Если люди подобраны правильно, они не нуждаются в мотивации. Всё, что нужно — это обеспечить отсутствие демотивирующих факторов © Джим Коллинз
P.S. Не забывайте про картинку в заголовке поста — просто не будьте м… и и не работайте с такими людьми. Прежде чем внедрять что-то новое в мотивации и оплате труда примерьте новшество на самого себя, поставьте себя на место вашего девелопера или системного администратора. Вам комфортно? Ваш доход не стал меньше? Вы можете достичь показателей, которые приведут вас к получению премии? И вас будут любить ваши сотрудники, и вы постигните дзэн и переродитесь в следующий жизни на какой-то другой планете, где этих (из книжки) нет вообще — в принципе.
Комментарии (5)
Arslanbekov
5 сентября 2016 в 16:53
+1↑
↓
Господи, неужели в IT компаниях еще не убивают за KPI? Зачем об этом вообще писать…
pan_KOST
5 сентября 2016 в 17:03
–1↑
↓
KPI могут быть разными.
Если мерить количество строк кода, это бред, а не KPI.
Нормальны KPI разработчика (команды) в обязательном порядке содержит взаимоотношения следующих параметров:- количество выполненных требований
- степень участия в проекте
- Количество багов разработчика
- Соответствие соблюдения сроков работ, заявленным самим разработчиком
Параметров много. Но бизнесу разработчики не нужны, которые вечно делают идеальный мир. Бизнесу нужны качественные результаты, помогающие дальнейшему развитию компании и решающие конкретные «боли» клиентов.
5 сентября 2016 в 17:18
0↑
↓
Убивают не за KPI, а за неадекватные KPI. У сотрудника должно быть понимание, что он получает некую «плюшку» за чёткий, достижимый и прозрачный показатель. Если премию дают или не дают в зависимости от настроения руководства, без всяких KPI/КПЭ/Целей/Вклада/Оценки, то вот за это можно начинать «убивать».
hmspns
5 сентября 2016 в 16:54 (комментарий был изменён)
+1↑
↓
P.S. Не забывайте про картинку в заголовке поста — просто не будьте м… и и не работайте с такими людьми.
Одна из немногих книг, которую я бросил, не дочитав. Сплошное нытьё автора и ничего дельного.5 сентября 2016 в 17:12
0↑
↓
Читать эту книгу, я тоже не советую. Вы абсолютно правы :-) Просто картинка была «в тему».
