Нематериальные способы мотивации: советы менеджерам от разработчика

Повышение зарплаты и выплата бонусов — самый распространенный способ мотивации и удержания разработчиков. Но не единственный. Существует набор инструментов, которые не требуют материальных затрат и при этом эффективно влияют на лояльность и продуктивность разработчика, служат профилактикой выгорания. О них резиденты Клуба говорили 8 февраля на онлайн-встрече с Павлом Вейником.

Павел Вейник
Founding Teacher at Hard & Soft Skills

О спикере:

Стоит у основания различных сообществ ИТ-специалистов, включая: ByChange, Free IT. Сотрудничал с крупными корпорациями и продуктовыми компаниями (Miro, EPAM, AmadoAd Ltd., LeoHome Inc. и др). Делился экспертизой на более чем 100 митапах и конференциях. Обучил более 1K разработчиков и более 100 архитекторов.

План статьи:

• Что роднит разработчика с художником?
• Базовые инструменты нефинансовой мотивации разработчика.
• Что такое обратные связи и как они влияют на эффективность разработчиков?
• Как оценить работу разработчика?
• Вопросы и ответы.

Что роднит разработчика с художником?

Разработка — это творчество. Попробуйте сравнить то, как ведут себя художник в процессе написания картины и инженер в процессе реализации рабочих задач. Для обоих характерна увлеченность: им необходимы время для концентрации, для созревания концепции, идеи, подхода. В каждый момент времени задача требует какого-то творческого элемента. Сильное влияние на выполнение задачи оказывают настроение и обстановка.

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

Как правило, для разработчика, инженера хорошо сделанная работа уже является наградой. Так же как для художника та картина, которой он доволен. И понимание этого позволит вам раскручивать мотивацию по этой аналогии. Ведь отсюда вытекает, что один из главных нематериальных способов мотивации — это дать человеку работать, не трогая лишний раз.

Это не так просто, как кажется, потому что трогать его все же приходится: ему нужно ставить задачу, ему необходимо взаимодействовать с коллегами, отчитываться и так далее. Факторы, создающие для разработчика комфортную среду, связаны и с процессными, и с техническими моментами.

Базовые инструменты нефинансовой мотивации разработчика

Такие инструменты эффективны и не требуют больших затрат со стороны компании.

Формат 1-1

Один из самых эффективных инструментов нематериальной мотивации — формат обратной связи 1-1. Это встречи, как правило, проводит менеджер, чтобы понять настроение разработчика, быстро реагировать и не доводить до критических ситуаций, не разрывать взаимодействие между руководителями и подчиненными.

Существует множество правил, по которым проводятся встречи 1-1. Но главное среди этих правил следующее: менеджер должен быть на стороне разработчика. Такие встречи должны строиться не вокруг текущей работы, а вокруг роста разработчика.

Рост разработчика — это второе, что ему действительно интересно. Это то, к чему он стремится, то благодаря чему он может делать еще более крутые вещи и зарабатывать деньги.

Если строить 1-1 наполовину про текущую ситуацию и наполовину про цели и развитие разработчика, это дает менеджеру и разработчику инструменты взаимодействия, увеличивает лояльность.

Регулярность такой коммуникации уже является опорой, которая важна для разработчика. У него есть некая точка отсчета — раз в неделю, раз в месяц, — когда он может получить поддержку, ответы на волнующие вопросы.

Формат 1-1 не требует много затрат, а по эффективности сравним с премиями и бонусами.

Развитие разработчика

Разработчику сложно анализировать, как ему расти. Он хочет road map своего роста, а менеджер способен показать этот путь, в интересах компании в том числе. Если на проекте нет задач, которые интересуют разработчика, и они не предвидятся, то грамотнее сказать об этом сразу и предложить альтернативы: ротацию, обучение или что-то еще.

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

Частые ошибки:

• в компании отсутствует понятие профессионального роста;
• в качестве мотивации сотрудника рассматриваются только технические аспекты (внедрение нового инструмента, переход на новые версии стека, оптимизация).

Еще один эффективный и не затратный инструмент развития — шеринг знаний. Для этого можно завести практику внутренних вебинаров, канал в Slack для интересных тем для обсуждения. Помимо повышения экспертизы сотрудников, расширяется их круг общения, взаимодействие улучшает рабочие процессы, повышается вовлеченность в работу.

Стоит знать, что человек будет вовлекаться при двух условиях:

• когда он чувствует себя в безопасности, а для этого нужно завоевать его доверие (чему очень способствуют встречи 1-1);
• у него есть интерес к людям.

История про нематериальную мотивацию — это история про доверие, про soft-вещи, которые зависят от коммуникации.

Что такое обратные связи и как они влияют на эффективность разработчиков?

Давайте поговорим про проект как таковой. Что на что влияет в проекте? В 1980-х годах на сайте Массачусетского технологического университета была опубликована книга «Факторы влияния на график проектов». В ней хорошо отражены некоторые связи в проекте.

Рисунок 1 — схема обратных связей в проекте.

Частное следствие общеизвестно: «добавление новых программистов в опаздывающий проект увеличивает срок задержки». Есть и другие следствия: «чем больше людей в проекте, тем больше времени на него необходимо», «чем больше давления со стороны менеджмента/бизнеса/продукта, тем медленнее происходит разработка», «чем больше митингов, тем медленнее проект», «наличие оценки меняет срок проекта».

На этой схеме можно наглядно проследить связи в проекте: прогресс влияет на эстимации, оценки проекта; эстимация влияет на найм/увольнение; найм/увольнение влияют на онбординг, который влияет на продуктивность. И это все цикличные и достаточно сложные связи. Каждый проект уникален по комбинации этих связей. Сбалансировать их — ближе к искусству, чем к науке.

Рисунок 2 — эмпирически выявленная зависимость между коэффициентом, на который менеджер умножает оценку разработчиков, и реальным временем разработки.

Большая оценка расслабляет. Реальная оценка расслабляет. Жесткая оценка напрягает. И все это ведет к замедлению разработки.

Есть связь между так называемым «ефрейторским зазором», который менеджер добавляет к оценке, чтобы отчитаться о планировании, и реалистичным выполнением проекта. Выполнение проекта всегда запаздывает, и чем больше менеджер добавляет своего «ефрейторского зазора», тем позже завершается проект.

Примеры работы связей:

• Появление нового сотрудника снижает мотивацию других, если менеджер не находит способа реализации пункта развития разработчиков через обучение и менторинг.
• Если разработчик вкладывался в проект, а его задачу отменили, то мотивация сильно падает.

Важно следовать всем менеджерским подходам, ― строить диаграмму Ганта и прочие, ― но помнить, что в первую очередь это все делают люди, причем люди творческие, и делают из особенного материала под названием «мысль». Ошибиться в ту или другую сторону достаточно просто.

Здоровое отношение к срыву сроков

Когда отдельный разработчик срывает сроки по своей задаче? Он дает оценку задачи, закладывая свои риски на основании того, как он ее понял. Задача менеджера или тимлида убедиться, что человек понял задачу прежде, чем что-то с ней делать.

Как обычно происходит? Если сроки реально важны, то разработчик не делает задачу, а уменьшает отклонение реального срока от запланированного. Он может уменьшить объем задачи, чтобы успеть в срок. Если не укладывается, что будет подгонять реальный срок под запланированный. Если разработчик спешит, то он делает меньше тестов, меньше продумывает нюансы, увеличивая количество багов, которые еще больше замедляют проект.

Один из важнейших способов нематериальной мотивации — это здоровое отношение с срыву сроков. Это не повод лишить бонусов, а повод чему-то научиться.

Если разработчик всегда укладывается в сроки, значит, он их выставляет слишком большими. Если человек ставит срок, срывает, ставит новый, то он учиться правильно выставлять сроки. Это и есть здоровое отношение к этому явлению. Только очень опытный разработчик может достаточно точно оценить задачу. Это бывает редко.

Иногда менеджеры не совсем понимают природу работы разработчика. Добавляют новых людей — увеличивается срок проекта. Проводят тренинги по проекту, что также увеличивает срок реализации. Митинги, найм и увольнение людей тоже влияют на сроки.

Как оценить работу разработчика?

До сих пор не нашли способа правильно измерить работу разработчика. Измерять строками кода ― глупость, потому что все будут делать большой код и будут большими молодцами.

Когда разработчик понимает цель проекта, то он принимает более эффективные решения.

Пример. В системе долго генерировались отчеты, некоторые вовсе слетали. Было принято решение создать для пользователей список запущенных отчетов: сколько отчетов сгенерированы, какие еще в процессе. Опытный разработчик за три дня разработал решение, как ускорить работу с отчетом с нескольких часов до нескольких секунд. Как оценить такую работу? Кодом? Это история не про код, а про понимание и пользу.

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

Таким образом, удовлетворение разработчика зависит от:

• внешних факторов, которые подвластны менеджеру;
• внутренних факторов, которые подвластны самому разработчику.

Мотивация ― это всегда личная история. Компания большая, у нее есть свои правила, но разработчик ― это отдельный человек. И с компанией в лице менеджеров, рекрутеров, коллег он выстраивает личные отношения, а не формальные. Если добавить систему менторинга, то эта связь между сотрудником и компанией укрепится еще больше.

Вопрос ― ответ

Правильно ли я понимаю, что главное лицо от компании в общении и развитии разработчика ― это менеджер проекта?

Не во всех компаниях есть менеджер проекта. Там, где матричная структура в аутсорсе, это может быть ресурсный менеджер, а может быть проектный менеджер. Проектному нужно, чтобы разработчик выполнял задачу, ресурсному нужно, чтобы он оставался в компании и был доступен для распределения на проекты. В такой ситуации ресурсный менеджер остается тем, кто заинтересован. Если это продуктовая компания, то это линейный менеджер над этими разработчиками, Engineering Manager или тимлид. Нужно делать так, чтобы такое лицо было, и разработчик мог к нему обратиться при возникновении вопросов и быть уверенным, что получит человечный ответ. И это же лицо должно проводить встречи 1-1.

Какая роль HR? Может ли он проводить встречи 1-1?

HR не будет обладать достаточным доверием. Разработчик будет более заинтересован в том, кто может понять технические моменты. HR может проводить 1-1, если он погружен в разработку, а такого не бывает.

Кейс от резидента BICC. Команда проекта менторится после каждой итерации. Отдельно раз в 2-3 месяца лид, который в курсе всех ситуаций, объясняет, что было не так. При этом за командой дополнительно закреплен ресурсный менеджер, к которому человек может прийти и сказать то, что он не может сказать напрямую менеджеру. Ресурсный менеджер привлечен не из эйчаров, потому что у разработчика не будет доверия к этому человеку. У нас это менеджеры, у которых хватает soft-скиллов, чтобы понимать и уметь слушать.

Как еще можно измерять эффективность разработчиков, кроме сроков и дедлайнов?

Смотреть, насколько разработчик полезен бизнесу заказчика и аутсорс-компании. Разработчик, который приносит много пользы, мало хлопот ― лучше. И это не всегда на 100% коррелирует с его техническими скиллами. Поэтому должен быть менеджер, который знает, что делает разработчик, какие у него проблемы и как он их решает.

Проблема потери разработчиков при аутсорсной модели. Они живут отдельной жизнью, как их интегрировать в компанию, а не потерять на проекте клиента?

Первый шаг ― 1-1. Второй ― внутренний менторинг для других сотрудников: специалист менторит или его менторят. Показать тот путь развития, который сотрудник хочет. А иногда выгоднее договориться закончить проект и расстаться, чем долго пытаться держать разными путями. Он может повышать токсичность на проекте и снижать работоспособность всей команды.

Как распознать, что из нематериального вознаграждения будет для разработчика лучше всего?

В любых отношениях нужно говорить. Отношения человека и компании ― это тоже личные отношения, в которых нужно говорить. Нужен человек, который умеет слушать и слышать, говорить с разработчиком.

Что делать с выгоранием разработчика, который решил покинуть компанию и открыть свой бизнес?

Попрощаться с ним и оставить возможность вернуться. Уходить, чтобы открыть свой бизнес ― совершенно иной уровень мотивации и ответственности за свою жизнь.

ИТ-компания не готова обучать за свои деньги, чтобы растить мидлов и сеньоров. Растить джунов? Какие советы можете дать?

Растить джунов надо всем, другой вопрос ― есть ли на это деньги? Старайтесь организовать взаимодействие так, чтобы сотрудники обучали друг друга, менторили, устраивали внутренние митапы, вебинары, обмен опытом. Для этого необходимо создать безопасную атмосферу, стимулировать научиться говорить перед публикой. Чем сеньористее ребята, тем больше пользы от обмена опытом и тем сложнее этот обмен организовать. Сложно что-то сделать, если нет внутренней мотивации обмениваться опытом. Выращивать мидлов и сеньоров можно естественным путем, выстраивая их траекторию развития правильными задачами и менторингом.

Какие тулы и структуры вы используете для перформанс-ревью?

Таблички с закрытым доступом в Confluence мне хватало, когда я проводил 1-1 в качестве менеджера. Перформанс-ревью я никогда не проводил, потому что считаю, что человека нужно продвигать, когда он готов, иначе с ним будут проблемы.

Проводите ли вы опросы на лояльность?

Есть механики типа 360 ревью, которые достаточно дорого выстраивать. Они позволяют получить какой-то анонимный средневзвешенный результат. Я бы не стал такие механики прямо привязывать к перфоманс-ревью, потому что всё бывает у всех. Они скорее для измерения «средней температуры» сотрудника и компании в целом.

Видеозапись встречи:

План записи:

01:03 ― Приветственное слово спикера.
04:35 ― Что роднит разработчика с художником?
08:11 ― Базовые инструменты нефинансовой мотивации разработчика.
17:28 ― Что такое обратные связи и как они влияют на эффективность разработчиков?
29:10 ― Как оценить работу разработчика?
36:50 ― Вопросы и ответы.

Другие публикации по теме:

• Как мотивировать sales-менеджеров в сервисной ИТ-компании?
• Совет Директоров: рост зарплат и дефицит кадров в ИТ-отрасли
• Обучение английскому в компании. Штатный учитель, ИП, языковая школа — плюсы и минусы

Belarus IT Companies Club объединяет экспортные ИТ-компании Беларуси для сотрудничества, обмена опытом и важной информацией.

BICC — это:

• закрытое сообщество из 200+ владельцев и руководителей,
• обмен лидами и бенчем в Bench_Exchange,
• консультации для ваших бухгалтеров и юристов,
• регулярные встречи и отраслевые исследования.