Эпиграф: Муж, глядя на чумазых детей, говорит жене: ну, вымоем этих или родим новых? Под катом — обсуждение нашего тимлида, а также директора по развитию продуктов РАН Игоря Марната об особенностях мотивации программистов.
Секрет успеха в создании крутых программных продуктов известен — возьмите команду крутых программистов, дайте команде крутую идею и не мешайте команде работать.
Крутые разработчики встречаются редко и востребованы.
Некоторые рекрутеры даже говорят, что у них сложилось впечатление, что проще выпустить крутого программиста, чем нанять его с рынка.
Помимо сложностей с наймом как таковым, опыт каждого конкретного разработчика, его знание существующего продукта и истории его развития зачастую незаменимы или трудно и трудоемки в восполнении.
Поэтому, если вам повезло и у вас уже есть крутая команда программистов, важно поработать над их мотивацией.
Нанимать, обучать новых разработчиков и собирать из них команду — почти так же сложно и долго, как рожать и воспитывать детей.
Рассмотрим основные факторы мотивации программистов (команд программистов), используя для наглядности и структурирования изложения пирамиду Маслоу.
Если вы не слышали о пирамиде Маслоу, то это не бесспорная, но очень популярная и показательная теория американского психолога Абрахама Гарольда Маслоу, который предложил теорию личной мотивации, основанную на иерархии человеческих потребностей (см.
картинку ниже).
Маслоу расположил потребности личности в иерархическом порядке: от физиологических потребностей до потребности в потенциальном развитии и самореализации.
Ключевое предположение теории Маслоу заключается в том, что «человек не может испытывать потребности более высокого уровня, пока не будут удовлетворены его потребности более низкого уровня».
Например, человеком не может двигать потребность в знаниях или эстетические потребности, если при этом он не спал и не ел в течение трех дней.
Прежде чем вдаваться в подробности, остановимся на очевидном факте – команда состоит из людей, все люди разные, у каждого своя структура мотивации.
Помимо того, что каждым человеком движут разные интересы, каждый человек еще и находится в разных условиях жизни.
Кто-то находится в начале карьеры и думает, как ее построить, кто-то собирается жениться, а кто-то хочет освоить новую предметную область.
То, что важно одному, совершенно неважно другому, и завтра все снова изменится.
Чтобы правильно понять этот контекст, есть простое средство – нужно над ним задуматься и поработать с ним.
Самое главное – это общение.
Обязательно разговаривайте с коллективом о чем-то помимо работы, выстраивайте неформальные отношения.
Итак, теперь давайте пройдемся по пирамиде Маслоу и рассмотрим ее уровни применительно к управлению командой программистов.
Я: Физиологические, биологические потребности: Говоря о мотивации, многие часто в первую очередь думают о зарплате.
В данном случае под зарплатой я подразумеваю постоянную часть компенсационного пакета, которая никак не зависит от результатов.
Это не касается бонусов, бонусов и акций компании.
Именно зарплату я бы в нашем случае отнес к уровню «физиологических потребностей».
Премии, бонусы по результатам работы, опционы и акции компании – я бы отнес все это к другим уровням.
На мой взгляд, как бы странно это ни звучало, зарплата скорее могла бы быть демотивирующий фактор, а не мотивирующий фактор.
Особенность работы с программистами в том, что все это люди, во-первых, очень умные (особенность профессии), во-вторых, глубоко и/или широко образованные.
Обычно программисты помимо своей профессии имеют глубокое понимание одной или нескольких предметных областей, для которых они создают продукты.
Кроме того, хорошие программисты интересуются и хорошо знают историю развития программирования, алгоритмы, стандарты и т. д. То же самое касается и их предметной области.
Для людей этого уровня зарплата обычно не является основным мотивирующим фактором.
При этом отсутствие достойной зарплаты у программистов, в их понимании, демотивирует, и демотивирует сильно.
Достойная зарплата – это норма.
Заработная плата значительно выше нормы (рыночной) – тоже, как ни странно, достаточно демотивирующий фактор.
Коллега как-то рассказал мне о команде программистов в одной из крупных американских анимационных компаний, которая в силу ряда обстоятельств получала зарплаты на уровне в два-три раза выше рынка.
По его словам, более скучающих, ленивых и демотивированных программистов он в жизни не видел.
Факт повышения зарплаты может мотивировать в краткосрочной перспективе, но через несколько месяцев новая зарплата становится нормой и перестает мотивировать.
В целом я бы сказал, что для программистов в начале карьеры фактор зарплаты более важен, по мере профессионального роста и развития его значимость снижается и начинают преобладать другие факторы.
Второй важный момент – наличие справедливого баланса в уровне зарплат в команде.
Если команда почувствует, что вклад одного участника заметно ниже, а уровень вознаграждения одинаковый, это демотивирует всю команду.
Иногда у руководителей возникает соблазн разжечь огонь деньгами — удержать выгоревшего или демотивированного человека, повысив ему зарплату выше нормы.
Обычно это создает проблемы только в долгосрочной перспективе — мотивация самого человека не сильно увеличится, либо повысится на пару месяцев, но мотивация остальной команды упадет. В таких ситуациях стоит искать другие подходы, если, конечно, это не уникальный специалист, которого нужно удержать любой ценой, даже на короткое время.
II. Потребность в безопасности, комфорте, постоянстве условий проживания: 70 лет назад наличие печки в автомобиле могло быть мотивирующим фактором при выборе автомобиля; тогда это было выше нормы и было признаком роскоши.
Сейчас даже отсутствие кондиционера – нонсенс, а его наличие, конечно, не будет мотивирующим фактором при выборе автомобиля.
Так 10-15 лет назад удобный офис, хорошее железо, вкусный кофе, фитнес, гибкий график и т. д. могли быть хорошими мотивирующими факторами, а сейчас это скорее норма работы хорошего программиста.
В то же время их отсутствие снова будет демотивировать.
Важным демотивирующим фактором является отсутствие способности концентрироваться и шумная рабочая обстановка.
Работа программиста требует тишины и концентрации.
Если офисное помещение не дает возможности предоставить разработчикам уединенное рабочее пространство, необходимо как минимум обеспечить комфортное сотрудничество коллег, не мешающих друг другу.
Энергичных и громких товарищей лучше объединять друг с другом, давая возможность сконцентрироваться тем, кто в этом нуждается.
Стоимость времени программиста сейчас существенно превышает стоимость оборудования, на котором он работает. Два-три монитора, мощные компьютеры, удобное рабочее место для каждого разработчика — должно быть нормой в любой компании.
«Эта тема хорошо освещена в одной из статей Джоэла Спольски».
Тест Джоэла: 12 шагов к улучшению кода».
Физический компонент комфорта – самый основной и простой; теперь поговорим об остальном.
Во многих компаниях для программистов нормой является гибкий график работы и отсутствие дресс-кода.
Это хорошо и правильно, если специфика работы команды это позволяет (например, нет встреч с клиентами, политиками или банкирами).
Важно иметь определенное время, в течение которого вся команда будет работать вместе на местном уровне, чтобы люди могли общаться и решать проблемы лицом к лицу.
Программист, по сути, не уходит с работы даже после работы.
Обычно рабочие моменты прокручиваются в его голове независимо от его присутствия в офисе, а хорошие решения часто приходят за пределами офиса.
Учитывая необходимость быть хорошими (о чем мы поговорим ниже), мелочный контроль вреден.
Это не только демотивирует, но и снижает производительность.
Как показывает практика, при отсутствии контроля мотивированная команда с большей вероятностью будет работать дольше, чем необходимо.
Если будет контроль, разработчики могут сидеть за клавиатурой с девяти до шести, но результат, думаю, будет хуже.
Как говорится, один человек может привести лошадь к водопою, но и сотня не заставит ее пить, если она этого не захочет. В описании этого уровня потребностей также упоминается свобода от тревоги и страха, отсутствие хаоса, потребность в структуре и порядке.
Это тоже крайне важные моменты, которые очень сильно влияют на атмосферу в коллективе.
Во-первых, отсутствие хаоса, структуры и порядка – команда должна понимать, кто за что отвечает, как распределяются роли, что нужно сделать, к кому, когда, какие требования лежат в основе продукта, каковы ожидания руководства и заказчик.
Большая часть этого должна быть формально описана, все должно периодически обсуждаться.
Без обсуждения и периодического использования описания не работают. Хорошей практикой является их периодическое обсуждение и обновление на основе результатов посмертного анализа после выпуска.
Во-вторых, спокойная и дружелюбная атмосфера.
Мы все проводим большую часть времени на работе и хотим делать это без стресса, конфликтов и страха.
Команда разработчиков обычно работает под давлением графиков и клиентов.
Никому не нужен дополнительный стресс со стороны коллег и начальства.
Атмосфера в коллективе, вообще сам факт того, что группу разработчиков можно назвать и быть «командой», — это прямая и важная обязанность руководителя, одна из важнейших средне- и долгосрочных задач.
Поэтому менеджеру важно работать, в частности, с конфликтами в коллективе, а не пускать их развитие на самотек.
Управление конфликтами – это отдельная тема, заслуживающая отдельного изучения.
Есть два основных способа повлиять на эмоциональное состояние коллектива и поведение коллег (если кто-то добавит в комментариях, было бы здорово).
Во-первых, это ваше собственное поведение.
Личный пример очень важен для руководителя и команды.
Как говорится, каков священник, таков и приход. Ведите себя так, как вы ожидаете от своих коллег.
Второе — поощрять правильное поведение и, так сказать, дестимулировать неправильное поведение.
Общайтесь с людьми, давайте им обратную связь, для этого есть много способов.
В общем, обратная связь — это тема для отдельного разговора; это большая и важная часть работы с мотивацией.
Еще одно замечание по поводу атмосферы, которая может показаться необычной, но на практике это важно.
Чаще всего в команде разработчиков девушек меньше, чем мужчин.
Часто группы полностью мужские.
В таких условиях, еще и под нагрузкой, в коллективе иногда начинает употребляться нецензурная лексика.
Практика показывает, что это отрицательно влияет на атмосферу; общение постепенно становится грубым.
Вам следует избегать его использования самостоятельно и препятствовать его использованию в своей команде.
Команды разработчиков часто называют R&D (исследования и разработки), причем исследования составляют значительную часть работы.
Это та часть, которую обычно сложно программировать и планировать, иначе это не было бы исследованием.
Важно, чтобы команда имела право ошибаться, проявлять инициативу, пробовать разные варианты, которые могут закончиться успехом, а могут и не закончиться.
Ошибки — нормальная часть работы, их невозможно избежать, но можно изучать, анализировать, учиться на них на будущее и двигаться дальше.
Принцип «5 почему», придуманный в Toyota, — хороший способ добраться до основной причины проблемы.
Наказание за ошибки — отличный способ создать атмосферу страха и неуверенности.
Исключение составляет лишь тот случай, когда по результатам анализа выяснится, что ошибка вызвана непрофессиональным отношением к работе, в этом случае может потребоваться принятие кадровых решений.
На атмосферу в коллективе большое влияние оказывают ваши ожидания и эмоциональное состояние перед началом разговора.
Прежде чем начать сложную дискуссию, какой-то разбор полетов или просто эмоциональный разговор, важно ваше настроение и отношение к человеку, с которым вы собираетесь поговорить.
Я всегда по умолчанию верю и действую исходя из того, что человек искренне старался сделать лучше всего.
Если с вашей позиции кажется, что это не так, вам нужно спокойно и подробно выяснить контекст и понять, что он сделал правильно, почему он считал это правильным и где наши ожидания расходятся.
Обычно оказывается, что они не то чтобы расходятся, просто у него видение контекста более полное или свежее, и есть что-то, чего вы не знали.
Или, наоборот, он чего-то не знал.
Особенно это важно в распределенной команде, когда люди реже общаются лично и используют электронную почту и мессенджеры.
Это еще более критично в команде, состоящей из программистов из разных стран и разбросанных по разным часовым поясам.
Именно здесь культурные различия начинают играть большую роль.
В сложной ситуации ехать с ходу легко, очень легко, но потом ехать назад сложно, и осадок остается надолго.
Позвольте мне привести вам простой пример из недавнего опыта.
Одному из менеджеров команды срочно понадобились комментарии по какой-то проблеме с клиентом от менеджера родственной команды в другой стране.
Он пинговал коллегу в мессенджере, подождал 15 минут, пинговал еще раз, потом через 15 минут зашел в большой чат, в котором были и другие менеджеры, и слегка напал на коллегу, с формулировкой типа: «так как ты не соизволите мне ответить, может быть, и вопрос не такой срочныйЭ» В итоге оказалось, что наш корпоративный мессенджер немного туповат, а коллега вообще не видит вопроса.
Мне пришлось извиниться.
В общем, лучше начать с хорошего.
Всегда можно совершить грубую ошибку и потом столкнуться с неприятностями; с этим проблем нет (хотя этого делать не следует).
В общем, за более чем 20 лет работы в нашей отрасли я встретил по-настоящему злостного коллегу лишь один раз (!).
К счастью, мы довольно быстро расстались.
В подавляющем большинстве случаев оказывается правильным предположить, что коллеги хотят лучшего, насколько они понимают контекст. Ваша задача как руководителя — обеспечить синхронизацию контекстов, общее понимание ожиданий, требований, сроков и стандартов, принятых в команде.
Это может показаться мелочами, но атмосфера в коллективе строится именно из таких мелочей.
С точки зрения распределенной команды, одной из важных задач является обеспечение периодического личного общения членов команды.
Я не раз слышал от программистов, что после того, как к ним, например, приходили инженеры из службы поддержки и работали вместе лично, они с радостью оставались на работе, чтобы помочь в сложном случае лично Паше, недавно пришедшему к ним, хотя раньше Паша был просто иконой в мессенджере, и ради иконы никто не задерживался.
Кстати, я начал говорить о команде поддержки и вспомнил каноничный для меня пример.
Однажды у одного из клиентов в Америке возникла проблема с продуктом, один из инженеров из команды поддержки, работавший над его внедрением (командированный из России), остался после работы, чтобы помочь, но проблема не решилась и не решается.
В общем, он задержался и просидел там почти до утра.
В это время менеджеры заказчика обострили проблему, определили ее критичность для них и вечером ушли с работы.
Процесс эскалации уже набирал обороты в другом часовом поясе, менеджеры службы поддержки в России начали пытаться помочь, из-за определённых сложностей со связью с офисом заказчика (VPN, проблемы со связью, сложности со звонками между странами,.
) они не знала, что парень уже сидит в офисе и решает вопрос, и попыталась его найти.
Нашли только утром (американское), когда вопрос уже был практически решен и продукт работал.
Сразу же начали говорить, что, черт возьми, у клиента такая эскалация, ничего не работает, где ты, мы тебя не можем найти и т. д. Надо ли говорить, что в результате такого поведения парень был сильно демотивирован.
Организация работы распределенной команды — отдельная большая тема, но важно помнить две вещи.
Во-первых, очень важны коммуникации и атмосфера, от этого зависит успех работы.
Во-вторых, это не работает само по себе; его необходимо рассматривать отдельно и углубленно.
Еще один важный момент, связанный с данным уровнем потребностей, – это опять же заработная плата.
Не размер зарплаты как таковой, а наличие определенного порядка ее изменения.
В компании должен быть подход к определению требований к должностям разного уровня.
Каждый разработчик должен иметь возможность обсуждать ожидания от своей работы с компанией, понимать, как и когда его усилия могут повлиять на его зарплату.
Этой цели служат периодические встречи с руководителем, полугодовые или ежегодные обзоры эффективности.
Это опять же один из тех моментов, наличие которых явно не мотивирует, а вот их отсутствие очень демотивирует. Из необходимости порядка и наличия правил вытекает необходимость соблюдать эти правила, следовать нормам, принятым в коллективе, как формальным, так и неформальным.
В целом я бы назвал это потребностью «быть хорошим».
Наличие этой потребности подтверждает, что микроменеджмент не нужен, а скорее вреден.
Достаточно обеспечить человека всем необходимым для работы, дать ему знание контекста, приоритетов, обеспечить свободу действий и принятия решений на его уровне.
В таких условиях он почувствует доверие, возможность самостоятельно принимать решения, брать на себя ответственность за них, сможет раскрыть свой потенциал.
Еще одним важным моментом, который следует отнести к необходимости порядка и отсутствию хаоса, является возможность сконцентрироваться на задаче, отсутствие частого переключения контекста.
Работа программистом требует времени и сосредоточенности.
Программисты очень не любят срочно отказываться от одной задачи и переключаться на другую.
Необходимой частью работы программиста обычно является не только собственно разработка кода, но и исправление ошибок и помощь в обработке запросов клиентов.
Планировать подобные вещи стоит заранее, таким образом, чтобы дать возможность программисту спокойно и полностью завершить работу над одной задачей, прежде чем переключиться на другую.
Лучший вариант — дать себе возможность самостоятельно планировать свою работу, заранее определяя приоритеты и предстоящие задачи, выделяя длительные, растянутые промежутки времени для работы над одним типом задач.
Эта тема хорошо описана в книге « Google – Проектирование надежности сайта », где хорошо описаны подходы к планированию работы коллективов, обеспечивающих эксплуатацию и разработку больших, высоконагруженных, отказоустойчивых систем, а также инженеров, чья профессия совмещает разработку программного обеспечения и его поддержку.
Продолжение следует. Теги: #Карьера в IT-индустрии #программирование #Читальный зал #Управление персоналом #HR-процесс #мотивация программиста
-
Нагрузочное Тестирование На Гатлинге
19 Oct, 24 -
0H H1 – Небольшая Логическая Игра
19 Oct, 24 -
Советы Удаленному Менеджеру
19 Oct, 24 -
Видео Под Арестом
19 Oct, 24 -
Cnews Awards Или It-Бизнес По-Русски
19 Oct, 24 -
Критический Анализ Игр Со Поиском Предметов
19 Oct, 24
