Мотивация ИТ-специалистов – настоящая «головная боль» работодателей. Высокими зарплатами айтишников не удержать – в любой компании им заплатят столько же, сколько в предыдущей, или даже больше. Вдохновляющие речи на них не действуют, – программистами движет логика, а не эмоции.
Как мотивировать работников ИТ-сферы? Разбираемся с этим вопросом.
Творческая самореализация
Программист не просто «умеет кодить» – он решает сложные задачи, придумывает методы, создает собственный продукт, которым гордится. Это творческий человек, который стремится реализовать свой потенциал.
Если программисту долго не давать интересной работы, он задумается об уходе в другую компанию. Поэтому исправление «багов» и доработку программ за коллегами лучше распределять между сотрудниками отдела, чтобы никого не «перегружать» рутиной.
Компетентное руководство
Программистам важно, чтобы руководитель правильно оценивал их достижения, не отдавал распоряжения свысока, был последовательным и спрашивал их мнение.
Им также нужна некоторая автономность. Вместо указаний, что и как делать, дайте айтишнику задачу, время и необходимые инструменты. Он проанализирует ситуацию, рассмотрит возможные решения и найдет лучшее из них.
И ни в коем случае не ставьте над ним «мелкого» начальника, который будет «присматривать» за ходом работ. Это порождает чувство недоверия и вскоре может стать причиной увольнения по собственному желанию.
Обучение и карьерный рост
ИТ-специалисты ориентированы на развитие – этого требует сама специфика отрасли. Предоставьте им возможности для роста: обучающие курсы за счет компании, билеты на конференции программистов.
Если увидели у сотрудника задатки управленца – поддержите его. Например, предоставьте ему возможность встать во главе команды разработчиков, если он закроет собственные задачи по текущему проекту вовремя и качественно.
Гибкий график
Программисты не любят ограничения. Если вы заставите его работать строго с 9 до 18 – ему станет некомфортно. Если можете, проявите гибкость по отношению к сотруднику: разрешите работать по свободному графику или частично из дома.
Сегодня у программиста может быть творческий кризис, а завтра он закроет задачу за три часа. К нему может прийти гениальная идея в два часа ночи. В конце концов, главное – это результат.
Финансы
Для всех финансы являются одним из аспектов мотивации. Дайте компетентному программисту хорошую зарплату и возможность расти финансово, и для него это станет одним из стимулов для качественной работы.
Все эти пункты основаны на нашем опыте работы с IT-компаниями. Но мы будем рады услышать ваше мнение и ваше видение, чтобы прокачать свои скилы! Делитесь в комментариях своей мотивацией.
Комментарии (5)
Measurer01
05.07.2022 13:26+1Сегодня у программиста может быть творческий кризис, а завтра он закроет задачу за три часа.
А если не закроет? Как-то ведь надо оценивать эффективность и работоспособность программиста.
Хорошо, закрыл он задачу не вчера, а сегодня - молодец! А Вася из соседнего отдела не успел что-то сделать.
Творчество-творчеством, но рабочий порядок должен быть.
Sklott
05.07.2022 15:21+1Естественно порядок должен быть всегда. Иначе программисты могут разбаловаться и забить на работу, или уйти "по дорожке из хлебных крошек" в такие дебри, которые текущему проекту не нужны. Это понятно.
Но статья как бы не про это...
Если для вас, как руководителя, порядок - это быть на работе ровно в 9:00 как штык, и проваливай с работы в 18:00. То я не думаю что у вас будут задерживаться хорошие программисты. Хотя напрмер в той-же Финляндии именно так практически все и работают (правда я не знаю точно, это там такие традиции или требование начальства), для России это уже давно не так.
AllKnowerHou
06.07.2022 09:44Самый хороший мотиватор - это оказаться на улице безработным и бездомным
AYamangulov
В принципе, как будто, все правильно. Но уж слишком обзорно все описано, было бы неплохо, если бы автор добавил конкретные примеры и раскрыл пункты поподробнее. Ну вот для примера приведу образец плохих условий для самореализации. Каким бы ни был интересным проект, для каждого конкретного разработчика он всегда подходит к стадии "исчерпания" (при том, что для другого разработчика тот же проект может оказаться в тот же самый момент очень интересным). Причина очень проста - разработчик осваивает проект, выполняет все основные сложные задачи по рефакторингу или развитию, затем наступает момент, когда в проекте остаются только сравнительно несложные задачи по поддержке и доработке, все базовые технологии в стеке проекта освоены, изменения и сильное развитие не предвидятся. По опыту могу сказать, что сравнительно сложный проект в энтерпрайзе входит в эту стадию по истечениии срока от 11 месяцев до полутора лет. Далее работодателя обычно вполне устраивает вялотекущая жизнь проекта "на поддержке", заказчик платит, разработчики как будто бы загружены, никаких проблем. Тимлид не замечает, что разработчики "заскучали" и бывает очень удивлен, когда примерно в одно и то же время участники проекта один за другим приносят заявления на увольнения. Решение проблемы на самом деле существует только одно - тимлид "держит руку на пульсе", постоянно интересуясь мнением команды, и заблаговременно подбирает кандидатов на обновление команды проекта. Это должны быть разработчики, для которых этот проект является новым, интересным, стек проекта достаточно сложен для них, в нем им есть что осваивать, и даже задачи техподдержки проекта для них достаточно сложны и интересны. Старой команде предлагается совершить то, что называют "горизонтальным шифтингом" - им предлагаются новые проекты в той же фирме, которые их заинтересуют, предварительно в разумных пределах поучаствовав в обучении и передаче старого проекта новой команде. Особо подчеркну, что такое решение проблемы доступно только в достаточно больших фирмах, где есть много проектов и направлений развития. В малых командах, которые кормятся с одного-двух-трех постоянных заказчиков, как правило, это недостижимо - тут решения пробемы в приниципе нет, и разработчику нужно уходить в другую фирму, а работодателю - просто отнестись к этому философски, как к данности, и искать новых людей на стороне.
Вот хотелось бы, чтобы автор по каждому из своих общих пунктов привел какие-то похожие "примеры из жизни". И тогда статья действительно стала бы намного интересенее и полезнее.
Sklott
Да. Очень хорошая рекомендация. Только не надо её, впрочем как и всё остальное, доводить до абсурда. А то я знаком с очень крупной зарубежной компанией, где раз в N месяцев ВСЕ команды переходят на другие проекты... Это я скажу вам тот ещё аттракцион...