Мотивация разработчиков и других людей творческих профессий — руководство для компаний

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

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

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

Платите достаточно, чтобы зарплата не становилась проблемой

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

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

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

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

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

Широко цитируемое исследование Даниела Канемана показывает, что счастье и удовлетворенность (коррелирующие с производительностью и мотивацией) достигают плато в пределах разумной зарплаты. Некоторых людей продолжает мотивировать компенсация, но желание создать мотивирующую рабочую среду при помощи повышения зарплат не является выигрышной долгосрочной стратегией.

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

Управляйте процессом, а не людьми

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

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

Этой свободы требуют профессионалы почти в каждой области. И неудивительно, что активное управление людьми снижает производительность.

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

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

Мотивация разработчиков: Дайте им высказаться

Многие разработчики не любят, когда их кормят заданиями с ложечки. Но они не хотят решать задачи без контекста.

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

Не каждый проект будет захватывающим и интересным. Не каждый продукт будет новым модным инструментом на рынке. Но, как знает любой предприниматель, решение проблемы может стать важным и увлекательным, если именно проблема стоит на первом месте.

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

Сократите дурацкие метрики

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

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

Это действительно плохой способ измерить работу творческих профессий, потому что она часто требует больше “свободного” времени, потраченного на инкубирование идей, тестирование и новый старт в случае неудачи, чем времени, действительно потраченного на “работу”. Да, вы можете написать определенную часть кода за час. Но чтобы добраться до этой точки, у вас может уйти пять часов или пять дней.

Бывший SVP по разработке Box (теперь VP по разработке Google) Сэм Шиллейс предложил интересный взгляд на эту тему. Он объяснил, как в Box была введена специальная метрика производительности, основанная на разнообразных ценностях. Эти ценности зависели от позиции человека. Вместо того, чтобы вводить количественные критерии того, что нельзя оценить таким образом, они нашли способ сделать оценку качественной, специфичной и детальной.

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

Мотивация разработчиков: Создайте пространство для роста

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

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

Разработчик в Microsoft Скотт Хансельман объясняет эту модель созданием собственной версии пирамиды Маслоу, выделяя факторы, которые имеют значение на каждом уровне иерархии.

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

Мотивация разработчиков: Измеряйте удовлетворенность, затем улучшайте её

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

Redfin, технологичная компания по работе с недвижимостью, измеряет счастье своих разработчиков. Компания применяет показатель NPS (Net Promoter Score — индекс лояльности), который обычно применяют для измерения удовлетворенности клиента.

«Мы достигли фантастических результатов, измеряя уровень удовлетворенности клиента с NPS, поэтому мы решили применять его для наших сотрудников, задавая один вопрос: “С какой вероятностью вы посоветуете работать в Redfin?”»

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

Смена точки зрения

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

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

Источник