Организации, стремящиеся стать гибкими, должны также обратить внимание и на формирование новой системы бонусов и стимулов, нацеленных на обеспечение и поддержку Agile-подходов. Независимо от того, насколько хорошо был спроектирован и осуществлён переход на новые методы работы, если будут продолжать действовать стимулы из “прошлой жизни”, способствующие прежнему же поведению, то сотрудники организации будут склонны вести себя “по-старому”.
Автор заметки, Майк Кон (Mike Cohn), один из соавторов и основателей Scrum и Scrum Alliance, называет это организационной гравитацией. Если культура организации не изменится в достаточной степени, чтобы стать другой – гибкой – организационная гравитация вернёт её в то состояние, в котором она пребывала до трансформации. Неправильно выстроенная система стимулов и бонусов является одной из самых мощных источников организационной гравитации.
Стимулы и бонусы бывают разные. Прежде чем рассматривать, как можно создавать надлежащие бонусы и стимулы, нужно прояснить разницу между ними.
Стимул – это вознаграждение, получаемое человеком или командой за достижение поставленной цели. Стимул известен заранее и предназначен для мотивации поведения предсказуемым способом. Например, у вас есть ребёнок, и вы говорите ему, что если он уберётся в своей комнате к трем часам дня, то вы вместе пойдёте в кино. Это – стимул.
Бонус, напротив, не известен заранее. Он выдаётся в тот момент, когда успешно выполняется какая-то задача. Вновь используя пример с ребёнком: он вернулся из школы с отличной оценкой, и вы знали, что он усердно готовился. В момент возвращения вы говорите, что сейчас же отпразднуете это достижение, купив мороженое. Это – бонус.
Бонусы и стимулы могут работать против Agile-целей. Например, звания, которые выделяют отдельных исполнителей на фоне всей команды, препятствуют созданию командного духа. Можно увидеть их в форме “программист года”, “лучший член команды”, “самый ценный соавтор” и т.д.
Некоторые виды поощряют подстраивающееся поведение, неоптимальное с точки зрения достижения целей. Примеры с тестировщиками, KPI которых выражается в количестве найденных ошибок, знакомы многим. Иногда это приводит к совершенно гротескным формам. Майк приводит в пример тестировщика, зарегистрировавшего более 200 записей для одной ошибки.
Ошибка заключалась в том, что значение неправильно вычислялось и отображалось на экране. Сам продукт работал на четырех операционных системах (текущие и предыдущие версии Windows и Mac OS X), восьми различных браузерах (текущие и предыдущие версии четырех браузеров) и поддерживался на семи разных языках. Запись об одной одной и той же ошибке была зарегистрирована для связки Firefox v59 / Windows 8.1 на французском языке. Аналогичная запись была создана для случая Safari 6.2 / MacOS 10.8 на английском языке и так далее.
Разбор отчётов из подобных “ошибок” занимает много времени, отнимает его у всех, кто с ним затем будет вынужден работать. Но, однако же, этот тестировщик, определённо, выглядел очень эффектно в конкурсе “лучший баг-хантер месяца”.
Что по поводу денег? Финансовые вознаграждения почти всегда так себе идея, считает Майк. Обычно они планируются из самых лучших побуждений теми руководителями, которые хотят, чтобы команда уложилась в особо сжатые сроки. Руководитель организует премии всем сотрудникам команды, если они выполнят задачу в поставленные сроки.
Вроде бы, неплохо. Но проблемы возникают в следующем проекте. Команда может начать его по плану, но, поскольку у её членов уже есть опыт, что если они немного отстают (или даже если они просто сообщат, что, возможно, уже немного отстают), то руководитель предложит им премии, чтобы проект был выполнен в срок. И подобная тенденция в поведении команды уже становится настораживающей.
Кроме того, финансовое вознаграждение не влияет на внутреннюю мотивацию людей. В таком вознаграждении нет ничего плохого. Большинство из нас и не появлялись бы на работе, если бы там не платили зарплату. Однако, нам хотелось бы использовать более глубокие мотивы, чем только финансовые.
Майк многому научился у команды, которой много лет назад выделил было большую денежную премию. Это были две команды из 12 разработчиков, премия – 75 000 долларов. На каждого приходилось более 6000 долларов, если бы бонус был бы разделён между ними равномерно.
В этом-то и была беда. Когда пришло время решать, в каком виде отдать премию команде, Майк не смог принять решение…
- выдать одинаковую сумму каждому члену команды? Это казалось несправедливым по отношению к тем, кто получал высокую зарплату, и чрезмерно щедрым по отношению к другим;
- выдать сумму, пропорциональную зарплате каждого человека? Выглядит противоположно пункту выше;
- по суммарному количеству трудочасов, затраченным на задачи? Вроде бы, несправедливо давать одинаковую сумму премии разработчику, который присоединился к проекту лишь месяц назад, и тем, кто работал над ним уже шесть месяцев кряду;
- а вознаграждать ли тех разработчиков, которые работали над проектом, но были переведены затем на другой? С одной стороны несправедливо оставлять их без внимания, но если их не было в самый тяжелый период работы, заслужили ли они это вознаграждение?
В общем, Майк так и не смог принять решение. Честно сказал об этом команде и предложил им самим разделить выделенную в качестве поощрения денежную премию. Через неделю они снова встретились. Разработчики сказали, что не могут найти способ распределить деньги между собой. Они долго спорили о том, как это сделать. И они почувствовали, что деньги могут разрушить те прочные связи, которые они выстроили внутри команды. В конце-концов, разработчики вернули большую часть премии, потратив часть её на две замечательные совместные загородные поездки. А для Майка это была последняя денежная премия, которую он предложил в качестве финансового вознаграждения.
Как же поощрять Agile-команды? Майк считает, что наиболее важной установкой является то, что вознаграждение должно поощрять командную работу, а не индивидуальную. Награды должны выдаваться всей команде. Это не означает, что нет места для индивидуальных поощрений. Но индивидуальные награды должны быть меньше по отношению к командным наградам – не “затмевать” последние. Записка от руки может творить чудеса эпоху электронной почты и мессенджеров. Уделяйте время, чтобы составлять такие записки, поблагодарив члена команды за что-то особенное и конкретное, что он сделал. Это станет предметом его гордости за вклад в общее дело.
Одна из главных и любимых наград Майка для команды – время. Это то, чего всем постоянно не хватает. Например, вы можете предложить команде недельный отпуск, если они выполнят крупный блок работ в срок. Если полная неделя отдыха – это слишком много, предложите команде провести неделю (или спринт) так, где каждый выберет то, чем заняться. Кто-то может делать рефакторинг старого кода, кто-то экспериментировать с новыми технологиями, кто-то может наверстать упущенное в чтении, если захочет.
Другой вариант – дать команде знания. Если они достигнут поставленной цели, можно отправить всех на конференцию. Также можно выделить каждому бюджет на покупку книг (да, это финансовое вознаграждение, но немного другое – целевое). Или бюджет для онлайн-обучения…
В Agile-командах стимулы и бонусы должны быть тщательно разработаны так, чтобы был явный акцент на работу в команде. Такой структурированный набор принесёт пользу как команде, так и всей организации.
Так же, как и не agile-команды, наверно: общественное признание, повышение степени свободы, время (отдых или перемена деятельности, в том числе на развитие), деньги (или другие ресурсы). Баланс групповой и индивидуальной мотивации также важен не только для agile-команд.