Рубрика: Драйверы мотивации · Блок: ДНК организации
Мотивация программистов: что работает, кроме денег
Мотивация программистов строится на тех же законах, что и мотивация других специалистов, но с поправкой на характер работы: сложные задачи, требующие сосредоточенности, быстрое устаревание знаний и высокий спрос на рынке. Деньги важны как основа, а удерживают и вовлекают интересные задачи, рост мастерства, автономия, понятный смысл работы и учёт личных мотивов.
Чем особенна мотивация программистов
Программисты — такие же сотрудники, как все, и универсальных «особых законов» для них нет. Но у работы разработчика есть черты, которые влияют на мотивацию. Задачи требуют долгой сосредоточенности: частые отвлечения разрушают продуктивность сильнее, чем в других профессиях. Знания быстро устаревают, и человек, который год не учился новому, ощущает, что отстаёт. Спрос на хороших специалистов высок, и у них почти всегда есть альтернатива.
Из этого следуют практические выводы. Разработчика демотивирует то, что мешает сосредоточиться и расти, а удерживает то, что даёт интересные задачи и развитие. При этом внутри профессии люди очень разные: одного вдохновляет архитектура сложной системы, другого — продукт, которым пользуются тысячи людей, третьего — команда и обмен знаниями.
Какую роль играют деньги
Зарплата важна, но работает она как фундамент, а не как главный двигатель. Если доход заметно ниже рынка, разработчик начнёт искать работу, и никакие интересные задачи этого не изменят. Если доход на уровне рынка, дополнительные деньги перестают быть решающим аргументом: человек выбирает между предложениями по задачам, команде, руководителю и перспективам.
Даниэль Пинк в книге «Драйв» (2009) описал три источника внутренней мотивации для работы, требующей творческого мышления: автономию, мастерство и цель. Работа программиста хорошо подходит под это описание. Поэтому разумная стратегия — держать оплату на рыночном уровне, чтобы деньги не были поводом уйти, и вкладываться в то, что действительно вовлекает.
Что мотивирует разработчиков кроме зарплаты
| Фактор | Как проявляется | Что может сделать компания |
|---|---|---|
| Интересные задачи | Сложность, новизна, нетривиальные решения | Распределять задачи с учётом интересов, чередовать рутину и вызов |
| Рост мастерства | Изучение технологий, развитие экспертизы | Время на обучение, конференции, внутренние разборы |
| Автономия | Свобода в выборе решений и организации работы | Договариваться о результате, а не о способе |
| Смысл продукта | Понимание, кому и зачем нужна работа | Рассказывать о пользователях и результатах |
| Сосредоточенность | Время без отвлечений | Беречь «тихие» часы, сокращать лишние встречи |
| Признание коллег | Уважение за качество решений | Код-ревью как обучение, внутренние выступления |
| Понятная перспектива | Видно, куда расти | Экспертный и управленческий треки |
Не все факторы одинаково важны для каждого. Как раз здесь и нужна индивидуальная работа руководителя.
Что демотивирует программистов
- Постоянная срочность. Переделки из-за меняющихся требований и плохого планирования.
- Отвлечения. День, разорванный встречами и сообщениями, не оставляет времени на сложную работу.
- Технический застой. Работа годами на устаревших технологиях без возможности что-то улучшить.
- Микроменеджмент. Контроль каждого шага вместо договорённости о результате.
- Бессмысленные метрики. Оценка по количеству строк кода или закрытых задач.
- Решения без участия. Технические решения спускаются сверху без объяснения и обсуждения.
- Отсутствие роста. Единственный путь вверх — в руководители, а управлять людьми человек не хочет.
Почему одинаковые программы мотивации не работают
Компании часто пытаются мотивировать ИТ-команду одинаково для всех: общий бонус, общие корпоративные мероприятия, общая программа обучения. Часть команды это ценит, часть остаётся равнодушной. Причина — разные мотивы.
Модель 12 движущих сил (DF) описывает шесть категорий мотивов: Знания, Польза, Эстетика, Люди, Власть и Порядок, в каждой — два противоположных полюса. Разработчика с ведущей силой в категории Знания заряжают сложные задачи и изучение нового. С ведущим полюсом «Практичный» — видимый результат и понятная связь вклада с вознаграждением. С ведущей силой в категории Эстетика — красивые, элегантные решения и качество кода. С ведущей силой в категории Люди — помощь коллегам и пользователям, работа в команде. С ведущей силой в категории Порядок — понятные процессы и стандарты. Профиль команды показывает, как распределить задачи и признание, чтобы мотивировать каждого; пример — в статье «Разбор команды по 12 движущим силам».
Как учесть стиль поведения разработчика
Мотивы отвечают на вопрос «ради чего», стиль поведения — «как человеку удобно работать». Профиль DISC — Доминирование, Влияние, Постоянство, Соответствие — помогает подобрать формат задач и обратной связи.
Разработчику с выраженным Доминированием важны самостоятельность и ответственность за результат; детальный контроль его раздражает. Разработчику с высоким Влиянием нужно общение: парная работа, обсуждения, выступления на внутренних встречах. Разработчику с выраженным Постоянством комфортнее стабильный ритм и понятный план; частая смена приоритетов его выматывает. Разработчику с высоким Соответствием важны ясные требования, время на качественное решение и уважение к деталям. О том, как оценивать технических специалистов с учётом этих особенностей, — на странице об оценке ИТ-специалистов.
Что может сделать руководитель ИТ-команды
- Регулярно говорить один на один. Не только о задачах, но и о том, что человеку интересно, что мешает, куда он хочет расти.
- Беречь время на сосредоточенную работу. Сокращать лишние встречи, договориться о «тихих» часах.
- Распределять задачи с учётом интересов. Чередовать рутину и задачи с вызовом, давать возможность пробовать новое.
- Строить два трека роста. Экспертный — для тех, кто хочет расти в сложности задач, и управленческий — для тех, кого тянет к людям. Эксперт, ставший руководителем против желания, часто теряет и мотивацию, и эффективность; об этой ловушке — в статье «Эксперт, ставший боссом».
- Объяснять смысл. Кому нужен продукт, какие результаты дала работа команды.
- Признавать качество. Не только скорость и объём, но и хорошие решения, помощь коллегам, улучшение кода.
- Учитывать формат работы. Для распределённых команд у мотивации свои особенности — о них в статье «Управление удалённой командой».
Как удержать сильного разработчика
Сильного разработчика редко удерживают одной мерой. Обычно работает сочетание: рыночная оплата, интересные задачи, понятная перспектива и руководитель, который замечает человека. Важнее всего вовремя видеть сигналы того, что мотивация падает.
Тревожные признаки знакомы большинству руководителей ИТ-команд: разработчик перестаёт предлагать улучшения, берёт только обязательные задачи, реже участвует в обсуждениях, начинает говорить о технологиях, которые используют «в других компаниях». Иногда человек прямо говорит, что устал от однообразия, но чаще молчит до заявления об уходе.
Регулярная встреча один на один — самый надёжный способ заметить это заранее. На ней полезно спрашивать не только о текущих задачах, но и о том, что человеку интересно в последнее время, чему он хотел бы научиться, что раздражает в процессах. Ответы подсказывают конкретные шаги: новый проект, смена технологии, роль наставника для младших коллег, участие в архитектурных решениях. Контрпредложение после заявления об уходе обычно запаздывает: решение к этому моменту уже принято. О том, как работать с риском ухода в целом, — на странице об удержании сотрудников.
Частые вопросы
Как мотивировать программистов, кроме денег?
Давать интересные и понятные задачи, возможность расти в мастерстве и изучать новое, автономию в выборе решений, время на сосредоточенную работу без постоянных отвлечений, понятный смысл продукта и признание результата коллегами. Что из этого важнее, зависит от конкретного человека.
Почему программисты уходят из компании?
Частые причины — застой в задачах и технологиях, слабый руководитель, постоянные срочные переделки из-за плохого планирования, отсутствие роста, непонятный смысл работы и зарплата заметно ниже рынка. Обычно уход складывается из нескольких причин.
Работают ли бонусы и KPI для разработчиков?
Как часть системы — да, если показатели понятны и разработчик может на них влиять. Жёсткие KPI по объёму кода или количеству задач обычно вредят: люди начинают оптимизировать показатель, а не результат.
Как понять, что мотивирует конкретного разработчика?
Спросить на встрече один на один, понаблюдать, какие задачи он берёт охотно, и использовать диагностику: профиль 12 движущих сил (DF) показывает ведущие мотивы, а профиль DISC — как человеку удобнее работать и получать обратную связь.
Нужно ли продвигать сильного программиста в руководители?
Только если он сам этого хочет и у него есть предпосылки к управлению. Многим сильным разработчикам ближе экспертный трек: рост в сложности задач и влиянии на технические решения без управления людьми.
Нужны ли программистам корпоративные мероприятия?
Зависит от людей. Одним важны неформальное общение и командные события, другим ближе профессиональные форматы: внутренние доклады, хакатоны, разборы сложных задач. Лучше спросить команду, чем устраивать мероприятие, на которое половина придёт из вежливости.