Управление командой программистов: как и чем их правильно мотивировать? Часть вторая
Эпиграф:
Муж, глядя на чумазых детей, говорит жене: ну, что, этих отмоем или новых нарожаем?
Под катом вторая часть статьи нашего тимлида, а также директора по развитию продукта RAS — Игоря Марната об особенностях мотивации программистов. С первой частью статьи можно ознакомиться здесь — habr.com/ru/company/parallels/blog/452598
В первой части статьи я коснулся двух нижних уровней по пирамиде Маслоу: физиологических потребностей, потребностей в безопасности, комфорте и постоянстве и перехожу к следующему, третьему уровню, а именно:
III — Потребность в принадлежности и любви
Я знал, что итальянская мафия называется «Cosa Nostra», но я был сильно впечатлён, когда узнал, как переводится «Cosa Nostra». «Cosa Nostra» в переводе с итальянского — «Наше дело». Очень удачный для мотивации выбор названия (оставим в стороне род занятий, в данном случае нас интересует только мотивация). Человек обычно хочет быть частью команды, делать какое-то большое, общее, наше дело.
Большое значение удовлетворению потребности в принадлежности и любви уделяют в армии, на флоте, в любых больших военизированных формированиях. И, как мы видим, в мафии. Это объяснимо, ведь нужно заставить людей, у которых мало общего, которые изначально не составляют команду единомышленников, собраны вместе по призыву (не добровольно), имеют разные уровни образования, разные личностные ценности, посвятить буквально свою жизнь, со смертельным риском, некоему общему делу, доверить жизнь товарищу по оружию.
Это очень сильная мотивация, для большинства людей крайне важно ощущать принадлежность к чему-то большему, знать, что ты часть семьи, страны, команды. В армии этим целям служат форма, различные ритуалы, парады, марши, знамёна, и так далее. Примерно те же факторы важны для любой команды. Важны символы, корпоративный бренд и корпоративные цвета, атрибутика и сувениры.
Важно, чтобы значимые события имели своё зримое воплощение, с которым они могли бы ассоциироваться. Сейчас для компании иметь свою атрибутику, куртки, футболки, и пр. — скорее норма. Но важно также выделять команду внутри компании. Мы часто выпускаем футболки по результатам релиза, которые выдаются всем тем, кто к этому релизу причастен. Какие-то события, совместные отмечания или мероприятия всей командой — еще один важный фактор мотивации.
Помимо внешних атрибутов, на ощущение принадлежности к команде влияют еще несколько моментов.
Во-первых, наличие общей цели, которую все понимают, разделяют оценку её важности. Программисты обычно хотят понимать, что они делают крутую штуку, и эту крутую штуку они делают вместе, всей командой.
Во-вторых, у команды должно быть пространство для коммуникаций, в котором есть вся команда, и которое принадлежит только ей (к примеру, чатик в мессенджере, периодические командные синкапы). Помимо рабочих вопросов, неформальное общение, иногда обсуждение внешних событий, лёгкий offtop — всё это формирует ощущение общности и команды.
В третьих, я бы выделил внедрение внутри команды хороших инженерных практик, стремление к повышению стандартов, по сравнению с теми, которые приняты в компании. Внедрение лучших подходов, принятых в индустрии, сначала в команде, а потом и в компании в целом, даёт команде возможность почувствовать, что она в чём-то опережает других, идёт во главе, это создаёт чувство принадлежности к крутой команде.
На ощущение принадлежности также влияет участие команды в планировании и управлении. Когда члены команды вовлечены в обсуждение целей проекта, плана работ, стандартов и инженерных практик команды, собеседование новых сотрудников, у них возникает ощущение участия, совместного владения, влияния на работу. Люди намного более охотно выполняют решения, принятые и озвученные ими самими, чем предложенные со стороны, даже если они практически созвучны.
Дни рождения, юбилеи, значимые события в жизни коллег — совместная пицца, небольшой подарок от команды дарят тёплое чувство причастности и признательности. В некоторых компаниях принято дарить небольшие памятные знаки на 5, 10, 15 лет работы в компании. С одной стороны, не думаю, что это так уж сильно мотивирует на новые свершения. Но, очевидно, почти любому будет приятно, что про него не забыли. Это один из тех случаев, когда скорее отсутствие факта демотивирует, чем его наличие мотивирует. Согласитесь, может быть довольно обидно, если linkedin с утра напомнил и поздравил вас с 10-летним юбилеем на месте работы, а из компании ни один коллега не поздравил и не вспомнил.
Безусловно, значимым моментом является изменение состава команды. Понятно, что даже если о приходе или уходе кого-то из команды будет объявлено заранее (например, в рассылке по компании или команде, или на командном митинге), это никого особенно не мотивирует на новые свершения. Но если в один прекрасный день вы увидите рядом с собой нового человека, или не увидите старого, это может стать сюрпризом, и в случае ухода — прямо-таки неприятным. Люди не должны исчезать втихую. Особенно в распределённой команде. Особенно, если Ваша работа зависит от коллеги из другого офиса, который вдруг взял и внезапно исчез. Такие моменты однозначно стоят отдельного информирования внутри команды заранее.
Важный фактор, который по английски называется ownership (буквальный перевод «владение» не полностью отражает его смысл). Это не чувство обладания, а, скорее, чувство ответственности за свой проект, то чувство, когда ты эмоционально ассоциируешь себя с продуктом и продукт с собой. Это примерно соответствует молитве морпеха из фильма «Цельнометаллическая оболочка»:»Это моя винтовка. Таких винтовок много, но эта — моя. Моя винтовка — мой лучший друг. Она — моя жизнь. Я должен научиться владеть ею так же, как я владею своей жизнью. Без меня моя винтовка бесполезна. Без моей винтовки бесполезен я. Я должен стрелять из моей винтовки метко. Я должен стрелять точнее чем враг, который пытается убить меня. Я должен застрелить его прежде, чем он застрелит меня. Да будет так… ».
Когда человек работает над продуктом долго, имеет возможность нести полную ответственность за его создание и развитие, видеть, как из «ничего» возникает работающая вещь, как люди ей пользуются, возникает это мощное чувство. Продуктовые команды, которые долго работают вместе над одним проектом, обычно более мотивированы и сплочены, чем команды, собранные на короткий срок и работающие в режиме конвеера с переключением с одного проекта над другой, не имея полной ответственности за продукт целиком, от начала до конца.
IV. Потребность в признании
Доброе слово и кошке приятно. Каждого мотивирует признание важности сделанной им работы, её положительная оценка. Разговаривайте с программистами, давайте им периодический фидбек, отмечайте хорошо сделанную работу. Если у вас большая и распределенная команда, для этого отлично подойдут периодические встречи (то, что называется one to one), если команда совсем небольшая и работает вместе локально, такая возможность обычно предоставляется и без специальных встреч по календарю (хотя периодический one to one все равно нужен, просто можно проводить его реже). Эта тема хорошо раскрыта в подкастах для менеджеров на сайте manager-tools.com.
При этом, стоит держать в уме культурные различия. Некоторые подходы, привычные для американских коллег, не всегда будут работать с российскими. Уровень вежливости, принятый в ежедневном общении в командах в западных странах, поначалу кажется избыточным программистам из России. Некоторая прямолинейность, свойственная российским коллегам, может восприниматься как грубость их коллегами из других стран. Это очень важно в общении в межнациональной команде, на эту тему много написано, менеджеру такой команды обязательно нужно об этом помнить.
Демонстрация фич, на которых программисты показывают разработанные за спринт фичи — хорошая практика для реализации этой потребности. Помимо того, что это отличная возможность прочистить коммуникационные каналы между командами, познакомить продакт менеджеров и тестировщиков с новыми фичами, это ещё и хорошая возможность для разработчиков показать результаты своей работы, обозначить своё авторство. Ну и отполировать навыки публичного выступления, конечно, что всегда не вредно.
Хорошей идеей будет отмечать заметный вклад особо отличившихся коллег грамотами, памятными знаками (хотя бы добрым словом) на совместных тусовках команды. Такие грамоты и памятные знаки люди обычно очень ценят, возят с собой при переездах, и вообще всячески берегут.
Чтобы отметить более значимый, длительный вклад в работу команды, накопленный опыт и экспертизу, часто используют систему грейдов (снова можно провести аналог с системой воинских званий в армии, которая, помимо обеспечения субординации, служит и для этой цели). Часто молодые разработчики вкалывают с удвоенной силой, чтобы получить новые звёздочки на погоны (i.e. перейти со ступеньки младшего разработчика на штатного разработчика, и т.д.).
Крайне важно знать ожидания ваших людей. Кого-то скорее мотивирует высокий грейд, возможность именоваться, скажем, архитектором, а кто-то, наоборот, равнодушен к грейдам и званиям и будет считать признаком признания со стороны компании повышение зарплаты. Общайтесь с людьми, чтобы понимать, чего они хотят, каковы их ожидания.
Демонстрацией признания, проявлением более высокого уровня доверия со стороны команды может служить предоставление большей свободы действий или вовлечения в новые области работы. К примеру, при накоплении определенного опыта, достижении определенных результатов, программист помимо имплементации своих фич в соответствии со спецификацией может работать над архитектурой новых вещей. Или привлекаться к работе над новыми областями, возможно, непосредственно не связанными с разработкой — автоматизация тестирования, внедрение лучших инженерных практик, помощь в управлении релизами, выступления на конференциях, и т.д.
V. Потребность в познании и самоактуализации.
Многие программисты ориентированы на разных этапах своей жизни на разные виды деятельности в программировании. Кому-то нравится заниматься машинным обучением, разрабатывать новые модели данных, при этом читать для работы много научной литературы, создавать новое с нуля. Другому ближе отладка и поддержка существующего приложения, при котором нужно глубоко закапываться в существующий код, днями и неделями изучать логи, стектрейсы и сетевые капчи, и нового кода почти не писать.
Оба процесса требуют больших интеллектуальных усилий, но практический выход у них разный. Считается, что программисты неохотно занимаются поддержкой существующих решений, они скорее мотивированы на разработку новых. В этом есть здравое зерно. С другой стороны, самая мотивированная и сплочённая команда, с которой я когда-либо работал, занималась именно поддержкой существующего продукта, поиском и устранением багов после обращения команды поддержки. Ребята буквально жили этой работой, были готовы выходить по субботам и воскресеньям. Мы как-то раз охотно разбирались с очередной срочной и сложной проблемой то ли вечером 31 декабря, то ли днём 1 января.
На такую высокую мотивацию повлияли несколько факторов. Во-первых, это была компания с громким именем в индустрии, команда ассоциировала себя с ней (см. «Потребность в принадлежности»). Во-вторых, они были последним рубежом, за ними никого не было, продуктовой команды уже не было на тот момент. Между ними и заказчиками было два уровня поддержки, но, если уж проблема доходила до них — отступать некуда, позади никого, вся корпорация на них (четыре молодых программиста). В третьих, у этой большой компании были очень большие заказчики (правительства стран, автомобильные и авиационные концерны, и т.д.) и очень масштабные инсталляции, на несколько стран. Как следствие, всегда сложные и интересные проблемы, простые проблемы решались поддержкой предыдущих уровней. В четвёртых, на мотивацию команды очень сильно влиял профессиональный уровень команды поддержки, с которыми они взаимодействовали (там были очень опытные и технически крутые инженеры), и мы были всегда уверены в качестве подготовленных ими данных, проведённого анализа, и т.д. В пятых, и, думаю, это самый важный момент — команда была очень молодая, все ребята были в начале своей карьеры. Им было интересно изучать большой и сложный продукт, решать новые для них серьёзные проблемы в новом для них окружении, они стремились профессионально соответствовать уровню окружающих команд, проблем, и заказчиков. Проект оказался отличной школой, все потом сделали хорошую карьеру в компании и стали техническими лидерами и старшими менеджерами, один из ребят сейчас технический менеджер в Amazon Web Services, другой со временем перешёл в Google, и этот проект все из них до сих пор вспоминают с теплотой.
Если бы эта команда состояла из программистов с 15–20 летним опытом за спиной, мотивация была бы другой. Возраст и опыт не являются, конечно, 100% определяющими факторами, всё зависит от структуры мотивации. В этом конкретном случае стремление к познанию и росту молодых программистов дало отличный результат.
В общем, как мы уже неоднократно упоминали, вы должны знать ожидания своих программистов, понимать, кто из них хотел бы расширить или сменить сферу деятельности и учитывать эти ожидания.
Вне пирамиды Маслоу: видимость результата, геймификация и соревновательность, no bullshit
Есть ещё три важных момента относительно мотивации программистов, о которых обязательно нужно упомянуть, но притягивать их к модели потребностей Маслоу было бы слишком искусственным.
Первое — видимость и близость результата.
Разработка софта — это обычно марафон. Результаты усилий в R&D становятся видны через месяцы, иногда годы. Трудно идти к цели, которая находится далеко за горизонтом, количество работы ужасает, цель далеко, не ясна и не видна, «ночь темна и полна ужасов». Лучше разбить дорогу к ней на части, проложить путь к ближайшему дереву, которое видно, достижимо, очертания ясны, и оно недалеко от нас — и идти к этой близкой цели. Мы хотим сделать усилие длиной в несколько дней или недель, получить и оценить результат, потом двигаться дальше. Поэтому работу стоит разбивать на маленькие части (этой цели хорошо служат спринты в agile). Выполнили часть работы — зафиксировали, выдохнули, обсудили, наказали виновных, наградили непричастных — можно начинать следующий цикл.
Такая мотивация до какой-то степени аналогична той, что испытывают игроки при прохождении компьютерных игр: они периодически получают медали, очки, бонусы при прохождении каждого уровня, это можно назвать «дофаминовой мотивацией».
При этом видимость результата важна буквально. Закрытая фича в списке должна стать зелёной. Если код написан, протестирован, смёржен, но видимого для программиста изменения в визуальном статусе нет — он будет чувствовать незаконченность, не будет чувства завершённости. В одной из команд в нашей системе контроля версий каждый патч проходил три последовательных стадии — билд собрался и тесты прошли, патч прошёл код ревью, патч смёржен. Каждая стадия визуально отмечалась зелёной галочкой или красным крестиком. Как-то один из разработчиков пожаловался, что код ревью длится слишком долго, коллегам надо ускориться, патчи висят по несколько дней. Я спросил, что это, в сущности, для него меняет? Ведь когда код написан, билд собрался и тесты прошли, ему не нужно обращать внимания на отправленный патч, если не будет замечаний. Коллеги сами сделают ревью и смёржат (если, опять же, нет замечаний). Он ответил — «Игорь, я хочу поскорее получить свои три зелёные галочки».
Второй момент — геймификация и соревновательность.
При разработке одного из продуктов перед нашей инженерной командой стояла цель занять заметную позицию в сообществе одного из продуктов с открытым исходным кодом, войти в top-3. На тот момент объективного способа оценивать чью-либо заметность в сообществе не было, каждая из крупных участвующих компаний могла заявлять (и периодически заявляла), что она контрибьютор номер один, но не было никакого реального способа сравнить вклад участников между собой, оценить его динамику во времени. Соответственно, не было и способа поставить перед командой цель, которую можно было бы измерить в неких попугаях, оценить степень её достижения, и т.д. Для решения этой проблемы наша команда разработала инструмент измерения и визуализации вклада компаний и индивидуальных контрибуторов www.stackalytics.com. С точки зрения мотивации, это оказалось просто бомбой. Не только инженеры и команды постоянно следили за своим прогрессом и прогрессом коллег и конкурентов. Топ-менеджмент нашей компании и всех крупных конкурентов тоже начинал свой день со stackalytics. Всё стало очень прозрачно и наглядно, каждый мог внимательно отслеживал свой прогресс, сравнивал с коллегами, и т.д. Стало удобно и просто ставить цели инженерам, менеджерам и командам.
Важный момент, который возникает при внедрении любой системы количественных метрик — как только вы их внедрили, система автоматически стремится поставить во главу угла достижение этих количественных метрик, в ущерб качественным. К примеру, в качестве одной из метрик используется количество выполненных ревью кода. Очевидно, код ревью можно делать по-разному, можно потратить несколько часов на тщательное ревью и проверку сложного патча с проверкой тестов, прогоном на своём стенде, сверкой с документацией, и получить плюс одно ревью в карму, либо вслепую за пару минут прокликать пару десятков патчей, поставить каждому +1 и получить в карму плюс двадцать. Были комичные случаи, когда инженеры прокликивали патчи настолько быстро, что ставили +1 автоматическим патчам от CI системы. Как мы потом шутили, «go, go, jenkins». В случае с коммитами тоже было много деятелей, которые проходили по коду инструментами форматирования кода, редактировали комментарии, меняли точки на запятые и таким образом прокачивали себе карму. Бороться с этим достаточно просто: включаем здравый смысл и кроме количественных метрик используем также сущностные, качественные. Степень использования результатов работы команды, количество внешних контрибюторов, уровень покрытия тестами, стабильность модулей и всего продукта, результаты scale и performance тестирования, количество инженеров, получивших погоны core reviewer, факт принятие проектов в состав core projects коммьюнити, соблюдение критериев разных этапов инженерного процесса — все эти и многие другие факторы подлежат оценке наряду с простыми количественными метриками.
И наконец, третий момент — No bullshit.
Разработчики — люди весьма умные, и по роду деятельности экстремально логичные. Они по 8–10 часов в день строят длинные и сложные логические цепочки, поэтому на лету видят уязвимости в них. Делая что-то, они, как и все, хотят понимать, зачем они это делают, что изменится в лучшую сторону. Мегаважно, чтобы цели, которые вы ставите перед командой, были честными и реальными. Попытаться продать плохую идею команде программистов — плохая идея. Идея плоха, если вы не верите в неё сами, либо, в крайнем случае, у вас нет внутреннего состояния disagree and commit (я не согласен, но я сделаю). Мы как-то внедряли систему мотивации в компании, одним из элементов которой была электронная система для предоставления фидбека. Вложили кучу денег, свозили людей на тренинги в Америку, в общем, вложились по полной. Как-то в разговоре после тренинга один из менеджеров сказал своим подчинённым: «Идея неплохая, вроде, будет работать. Я сам вам давать электронный фидбек не буду, но вы своим людям давайте, и с них требуйте». Всё, дальше можно было уже ничего не внедрять. Затея, разумеется, закончилась ничем.
