Управление командой программистов: как и чем их правильно мотивировать? Часть первая

Эпиграф:
Муж, глядя на чумазых детей, говорит жене: ну, что, этих отмоем или новых нарожаем?

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

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

Рассмотрим основные факторы мотивации программистов (команды программистов), используя пирамиду Маслоу для наглядности и структурирования изложения. Если вдруг вы не слышали о пирамиде Маслоу — это не бесспорная, но весьма популярная и наглядная теория американского психолога Абрахама Харольда Маслоу, который предложил теорию мотивации личности на основе иерархии потребностей человека (см.картинку ниже).

Маслоу расположил потребности личности в иерархическом порядке, от физиологических потребностей — до потребности в раскрытии потенциала и самоактуализации. Ключевое предположение в теории Маслоу: «человек не может испытывать потребности более высокого уровня, пока не удовлетворены его потребности более низкого уровня». К примеру, личность не может быть движима потребностью в познании или эстетическими потребностями, если при этом эта личность трое суток не спала или не ела.

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

Итак, теперь пройдёмся по пирамиде Маслоу и рассмотрим её уровни в применении к управлению командой программистов.

I: Физиологические, биологические потребности:

Говоря о мотивации, многие, в первую очередь, часто думают о зарплате. Под зарплатой в этом случае я понимаю постоянную часть пакета компенсации, которая никак не зависит от результатов. Это не относится к бонусам, премиям и акциям компании. Именно зарплату я бы отнёс к уровню «физиологических потребностей» в нашем случае. Бонусы, премии по результатам работы, опционы и акции компании – все это я бы отнёс уже к другим уровням.

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

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

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

II. Потребность в безопасности, комфорт, постоянство условий жизни:

70 лет назад наличие печки в автомобиле могло быть мотивирующим фактором при выборе машины, тогда это было выше нормы, было признаком luxury. Сейчас даже отсутствие кондиционера — это нонсенс, и его наличие мотивирующим фактором при выборе автомобиля, разумеется, не будет. Так еще 10-15 лет назад удобный офис, хорошее железо, вкусный кофе, фитнес, гибкий график, и т.д. могли быть хорошими мотивирующими факторами, сейчас же это скорее норма для работы хорошего программиста. В то же время их отсутствие, опять же, будет демотивировать.

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

Стоимость времени программиста сейчас заметно выше, чем стоимость железа, на котором он работает. Два-три монитора, мощные компьютеры, удобное рабочее место для каждого разработчика — должны быть нормой в любой компании. Эта тема хорошо раскрыта в одной из статей Джоэла Спольски “The Joel Test: 12 steps to better code”.

Физическая составляющая комфорта — самая базовая и простая, поговорим теперь об остальных.

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

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

В описании этого уровня потребностей упоминается также свобода от тревоги и страха, отсутствие хаоса, потребность в структуре и порядке. Это тоже крайне важные моменты, которые сильно влияют на атмосферу в команде.

Во-первых, отсутствие хаоса, структура и порядок — команда должна понимать, кто за что отвечает, как распределены роли, что предстоит делать, кому, когда, какие требования лежат в основе продукта, каковы ожидания начальства и заказчика… Большая часть из этого должна быть формально описана, всё должно периодически обсуждаться. Без обсуждения и периодического использования описания не работают. Хорошей практикой является их периодическое обсуждение и обновление по результатам postmortem анализа после релиза.

Во-вторых, спокойная и дружеская атмосфера. Все мы проводим на работе большую часть времени, и хотим делать это без стресса, конфликтов, страха. Команда разработки и так обычно работает под давлением расписания и заказчиков. Добавочный стресс со стороны коллег и начальства никому не нужен. Атмосфера в команде, вообще сам факт того, что группа разработчиков может называться и быть «командой» — прямая и важная ответственность менеджера, одна из самых главных среднесрочных и долгосрочных задач. Поэтому менеджеру важно работать, в частности, с конфликтами в команде, не пускать их развитие на самотёк. Управление конфликтами — отдельная тема, заслуживающая отдельного изучения.

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

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

Команды разработки часто называют R&D (research and development), при этом research составляет значимую часть работы. Это та часть, которую обычно трудно запрограммировать и запланировать, иначе это не был бы research. Важно, чтобы команда имела право на ошибку, на инициативу, на опробование разных вариантов, которые могут закончиться удачей, а могут и не закончиться. Ошибки — нормальная часть работы, их нельзя избежать, но можно изучать, анализировать, извлекать из них уроки на будущее и двигаться дальше. Принципе 5 why’s, зародившийся в Toyota, хорошо помогает добраться до исходной причины проблемы. Наказывать за ошибки – это отличный способ создать атмосферу страха и неуверенности. Единственное исключение — когда по результатам разбора оказывается, что ошибка вызвана непрофессиональным отношением к работе, в таком случае, возможно, нужно будет принимать кадровые решения.

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

В сложной ситуации наехать с ходу просто, очень просто, но вот отъехать назад потом тяжело, и осадок остаётся надолго. Приведу простой пример из недавнего опыта. Одному из менеджеров команды срочно нужны были комментарии по поводу какой-то проблемы у заказчика от менеджера из смежной команды из другой страны. Он пинганул коллегу в мессенджере, подождал минут 15, пинганул еще раз, потом минут через 15 пошёл в большой чат, в котором были и остальные менеджеры, и слегка наехал на коллегу, с формулировкой вроде: “раз уж ты мне не соблаговолишь отвечать, может, и вопрос не такой уж срочный?”. В итоге оказалось, что наш корпоративный мессенджер слегка затупил, и коллега вопроса вообще не видел. Пришлось извиняться. В общем, лучше исходить из хорошего. Ошибиться в плохую сторону и наехать позже всегда получится, проблем с этим нет (хотя делать этого не стоит). Вообще, за более чем 20 лет работы в нашей индустрии я встречал реально злонамеренного коллегу всего один (!) раз. К счастью, мы довольно быстро расстались. Исходить из того, что коллеги хотят как лучше, в меру своего видения контекста, оказывается правильным в подавляющем большинстве случаев.

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

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

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

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

Еще важный момент, который стоит отнести к потребности наличия порядка и отсутствия хаоса — возможность концентрации на задаче, отсутствие частых переключений контекста. Работа программиста требует времени и сосредоточенности. Программисты очень не любят срочно бросать одну задачу и переключаться на другую. Необходимой частью работы программиста обычно бывает не только непосредственно разработка кода, но и баг фиксинг, и помощь с обработкой обращений от заказчиков. Стоит планировать такие вещи заранее, таким образом, чтобы дать возможность программисту спокойно и полностью завершить работу над одной задачей перед переключением на другую. Лучший вариант — дать возможность планировать свою работу самостоятельно, обозначив приоритеты и предстоящие задачи заранее, выделив длинное, продолжительное время для работы над одним типом задач. Эта тема хорошо описана в книге “Google — Site Reliability Engineering”, в которой хорошо описаны подходы к планированию работы команд, обеспечивающих эксплуатацию и развитие больших, высоконагруженных отказоустойчивых систем, а также инженеров, которые по роду деятельности совмещают разработку программного обеспечения и его поддержку.

Продолжение следует…

Источник: habr.com