Хабрахабр

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

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

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

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

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

image

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть