2013-11-19
Большинство людей не имеют ни малейшего представления о том, как мотивировать этот странный класс людей под названием «программисты». Большинство не понимает, что теннисные столы, бесплатные плюшки и велодорожка не способны прикрыть недостатки в управлении вроде низкой степени автономности, плохого инструментария, постоянных дедлайнов и бессмысленных проектов.
Что вообще важно в работе разработчика? Инструменты, способность справиться с проектом, навыки и опыт, талант, групповое взаимодействие и мотивация. Вот как раз на мотивацию менеджер проекта может повлиять самым прямым образом.
Ещё одна важная особенность деятельности разработчика состоит в том, что измерить индивидуальную производительность каждого участника группы разработки практически невозможно и экономически нецелесообразно. Знаете, почему?
Потому что те, кто способен оценить эту производительность, настолько ценны в проекте, что не стоит тратить их время на проведение подобной оценки. Если в команде есть опытные инженеры, лучше направить их ресурсы на обучение джуниоров, чем на проведение оценки деятельности этих же джуниоров.
Конечно, опытный программист может быстро прикинуть в уме, кто из молодых специалистов толков, способен, быстро схватывает, но это не облегчает оценку индивидуальной производительности. Самое сложное— это отделить факторы плохой организации труда от фактора неважных способностей работника. Поэтому HR-политика оценки индивидуального вклада каждого работника в проект — лишь шумовой фон и плодотворная почва для раздоров, поскольку их методы неточны.
Это всё к чему? К тому, что единственная эффективная стратегия управления программистами — это мотивация, поскольку любая попытка измерения их усилий и контроля над их производительностью приводит к обратным результатам.
Немного истории
Традиционная система менеджмента, основанная на принуждении, не работает в сфере технологий. Сравните труд в индустриальном обществе XIX в. и труд после технологической революции XXI в.
Для трудовых отношений в индустриальном обществе характерно ожидание определённого количества выпущенного количества продукции от преданного трудолюбивого работника средних возможностей: то, что называется стандартом. Допустим, что стандартный индекс производительности равен 100. Лучшие работники могут соответствовать индексу 150-200, но в среднем хороший работник обладает индексом 125. Если получается так, что работники без риска для здоровья достигают индекса 150, компания просто поднимает стандартный индекс. Индекс бракоделов и халтурщиков стремится к нулю. Один бракодел подставляет под удар производительность четырёх хороших работников, и вот тут вступает в игру менеджмент, основанный на системе наказаний. Такая система плохо отражается на хороших работниках и снижает их производительность, но отлично мотивирует бракоделов, что поднимает общую производительность. Принуждение в этом случае приносит больше прибыли, чем увольнение неэффективного работника.
В мире технологий всё иначе. Индекс производительности разработчиков может превышать 200, 500, 1 000, а иногда достигает и 5 000+. А их реакция на негативное окружение выливается не просто в спад производительности. Как правило, они просто уходят. Инженеры ничего не имеют против увольнения проблемных сотрудников, но типичная HR-культура (традиционная иерархия, угрозы увольнений, методики подбора персонала) вызывает у инженеров тошноту. Принуждение здесь не работает. Единственное, что работает в современном мире —это внутренняя мотивация.
Бонусы мало мотивируют типичного инженера. Особенно если бонусы выдаются в качестве компенсации за неадекватные рабочие процессы. Никакая прибавка, премия и оплата тренажёрного зала не покроет потраченные на недоорганизованный проект силы и нервы. Да, можно получить премию в 5 000 долларов за наконец реализованный и вымученный за месяцы бессонной работы проект, но эти деньги не снизят шанс скорого увольнения выгоревшей команды.
Инженеры ценят интересную работу. Плохо спланированный проект — это всегда риск для программиста. Риск потерять собственную мотивацию, риск потратить время зря, риск скатиться в пропасть низкокачественного кода. Ведь, как правило, программисты достигают пика своей карьеры в возрасте до 40 лет. К этому времени сам программист достигает понимания своих возможностей: какой он специалист, средний, высококвалифицированный, куда идти дальше…
Традиционные HR-механизмы в случае с разработчиками достигают совсем не той цели, которой должны бы. Бонусы не мотивируют на изменение рабочего процесса, а увольнение средних работников в качестве демонстрационной меры приводит к увольнению лучших работников.
И что же делать?
Я предлагаю подход, основанный на мотивации в течение разных временных отрезков. Сейчас поясню.
Рассмотрим потребность людей в отдыхе и перерывах. На работе человеку необходимо отдыхать, скажем, каждые 2 часа по 10 минут. Каждый день необходимо отдыхать по 2-4 часа. Каждую неделю — по 2-3 дня. Каждый год — по 4-6 недель (редко, правда, кто себе это позволяет). В идеале человеку нужно отдыхать по году раз в семь лет, либо хотя бы сменить деятельность на этот год. Эта схема очень согласуется с пирамидой потребностей по Маслоу: биологические потребности удовлетворяются короткими перерывами в течение дня; душевные — более длительными в течение длительных периодов времени.
Этот же подход можно распространить и на мотивацию, распределив потребность в мотивации по 6 различным временным отрезкам: минуты, часы, дни, недели, месяцы и годы.
Итак:
(минуты) Увлечённость
Увлечённость —это состояние интенсивной концентрации на решении интересной проблемы. В состоянии увлечения мы пишем, готовим, занимаемся спортом, программируем. Такое состояние может быть и деструктивным, если, например, возникает при азартных или видеоиграх, вызывая зависимость.
Программирование в принципе основано на состоянии вовлечённости в создание кода. Лучше всего программисты работают именно в таком состоянии. Однако, в среднем программисту удаётся работать в таком состоянии 15-120 минут в неделю. Остальное время тратится на собрания, перерывы, рефакторинг кода, переключение между задачами. Даже если программиста «на пару секундочек» отвлекли небольшим пустяковым вопросом, он теряет 30 минут сосредосточненной работы. Типичное офисное окружение явно вредит состоянию этой вовлечённости, необходимой для высококонцентрированной работы.
Для вовлечённости необходимо соответствующее окружение. Программисту нужна уверенность в том, что его не отвлекут менеджеры и коллеги. Что их инструменты будут стабильно работать и не будет внезапно меняться и ломаться.
Какие задачи вызывают вовлечённость в их выполнение? Да разные. Дебаггинг может показаться и отвлекающим занятием, а может приносить настоящее исследовательское удовольствие, пусть и редко. В плохом коде (а большинство корпоративного ПО написано из рук вон плохо) почти нет связи между внутренними частями, нет эстетики, поэтому достичь состояния вовлечённости достаточно сложно.
Чтение хорошего кода — это как чтение отлично написанной книги, поэтому этот процесс легко приносит удовольствие.
Кстати, сама суть разрабатываемого продукта никак не влияет на это воодушевлённое состояние. Просто оставьте программиста на некоторое время в покое — и он с удовольствием займётся написанием кода для наискучнейшего бизнес-приложения. А проект по обучению искусственного интеллекта может показаться сущим адом, если над ним приходится работать в атмосфере торговой биржи.
(часы) Отклик
Знаете, почему программисты так любят научно-исследовательские проекты? Потому что в таких проектах скорость и количество обратной связи очень высоки по сравнению с корпоративными проектами. Бизнес-проекты разрабатываются в одном мире месяцами, а выпускаются совсем в другом мире. После релиза программист этот проект в глаза не видит. В научных проектах программист получает отклик быстро и часто.
Обратная связь может быть и положительной, и отрицательной. Положительная поднимает настроение и дух, отрицательная помогает взглянуть на проделанную работу под другим углом.
Однако, если обратная связь происходит редко, как правило, она бывает отрицательной, и складывается ощущение, что не работает вообще ничего.
Это не значит, что менеджеры обязаны предоставлять обратную связь каждый час. Это невозможно. Обратная связь подразумевается и при возможности выполнить конкретную задачу. Не нужны частые ревью или микроменеджмент, нужно это ощущение завершённости: поработал, «открыл ачивку», можно двигаться дальше.
Многое здесь зависит от используемого языка. Например, высокопродуктивные языки вроде Python, Scala, Clojure позволяют получить первые результаты уже за считанные часы.
А, скажем, ситуация с C или Java сложнее.
(дни) Прогресс
Увлекательная работа и получаемый отклик —это прекрасно, но помимо этого нужно видеть и ежедневный прирост. Именно в течение дня программист хочет видеть произведённые улучшения. Если процесс настолько заторможенный, что разработчик в течение дня не может создать лог о сколько-нибудь значимом изменении (добавленная фича, пофиксенный баг), что-то идёт не так.
Именно на ежедневном отрезке менеджеры и программисты начинают понимать друг друга: обе стороны стремятся к прогрессу. Однако, менеджерам свойственна проблема Гейзенберга: наблюдающий мешает наблюдаемому. Всё возрастающая увлечённость Jira представляется абсолютно опасной, поскольку надзор за проблемами и задачами на любом уровне порождает тревожность. Практики Scrum и Agile тоже зачастую могут нанести вред по причине ежедневной отчётности и подробного описания проделанной работы. Чем больше отчётности — тем меньше времени для выполнения ежедневных задач. Здесь остаётся рассчитывать на адекватность менеджеров.
(недели) Поддержка
Программистам очень свойственно такое небольшое психическое расстройство, как депрессивный реализм. Что это такое?
Давайте возьмём в пример наших любимых руководителей. Руководители в своей деятельности дают указания своим подчинённым, подчинённые эти указания выполняют с разным успехом, руководители довольны. У программиста в качестве подчинённого – компьютер, который в любой момент может нам сказать: «Эй, чувак, я не могу это скомпилировать, сделай с этим что-нибудь». Неважно, в чьей зоне ответственности возникла эта проблема, и сколько месяцев назад на этом месте кода возник костыль, разбираться с этим сейчас тебе.
Приблизительно каждую неделю в работе программиста возникает преграда, мешающая производительности и требующая решения. Вот в такие моменты ему нужна поддержка со стороны менеджера, который снимет с него посторонние задачи и не будет винить его за задержки в написании нового кода.
(месяцы) Карьерное развитие
В большинстве сфер люди растут в карьерном смысле, вкладывая время, заставляя себя замечать, постепенно втираясь в доверие. При этом реальный рост навыков не настолько важен, важен опыт. Обычно опыт для очередного продвижения набирается в течение года-трёх. Для IT-специальностей это не совсем верно. Программист не может позволить себе тратить годы на то, чтобы повышать уровень лояльности к собственной персоне, ничего при этом не изучая. Программист ценится своими навыками и скоростью адаптации ко вновь возникающим технологиям. Для программиста немыслимо несколько лет работать над одним проектом: это для него прямое доказательство собственной некомпетентности. Поэтому важно предоставить ему возможность выбирать проекты, переключаться между ними, не усматривая в этом отсутствие преданности.
Пересматривать позицию программиста в среднем необходимо каждые два месяца.
(годы) Глобальные цели
Одни мечтают создать лучшую в мире видеоигру, другие — найти решение сложной математической проблемы, третьи – улучшить существующую технологию или создать новую. Некоторые ж хотят уйти на покой после построения собственного бизнеса.
Множество стартапов ставят перед собой именно такие привлекательные цели по захвату мира: мечтают, как их продукт будет объединять людей, покончит со злом, поможет бедным или решит проблемы ожирения. Это очень привлекательно для постановки долгосрочных целей. Единственная проблема стартапов состоит в том, что они забывают о целях ежедневных, заставляя разработчиков бесконечно переключаться на разные задачи, не давая им времени на концентрацию, ограничивая их во времени.
Только с годами становится понятно, куда идёт компания, какие внутри и вокруг неё собираются люди, куда направлен вектор её развития.
Рецепт для Epic Win
Все знают эту рекрутинговую истину о том, что нанимая лучших инженеров, вы поднимаете эффективность в 10 раз, а заработную плату — всего в два.
Это верно только при условии высокой мотивации инженера. Если вы дадите посредственную работёнку высококлассному специалисту, вы потеряете время и деньги.
Все хотят нанять звёзд, но ничего не делают, чтобы их удержать. Возможно, в краткосрочной перспективе такой подход себя оправдывает: ушёл один, наймём другого. В долгосрочной же политика удержания талантливых работников приведёт к экспоненциальному росту эффективности.
Давайте резюмируем вышенаписанные многобукв, и наконец выведем формулу удержания талантов. Точной формулы нет, но следующие правила действуют безотказно:
- Снизить уровень контроля, предоставить автономию для программистов;
- Предоставить свободные условия для выбора проекта или его части;
- Переходить от иерархии к атмосфере лидерства.
Звучит утопично, но это работает.
Перевод: Люся Ширшова. По материалам блога Michael O.Church.
Читайте также:
Что важнее в работе программиста: смысл или деньги?
18 вещей, которые нужно знать растущим специалистам
Бывает 11 типа программистов, или об источниках мотивации в IT
