ет разрушить с трудом заработанное доверие между командой, пользователями и стейкхолдерами.
Подумайте, что вас мотивирует, когда вы работаете. Как часто мысли, подобные перечисленным ниже, приходят вам в голову?
• «Опыт работы с этой технологией украсит мое резюме» (если вы разработчик).
• «Если я проявлю себя в этом проекте, то могу получить в команде более высокую должность» (если вы руководитель проекта).
• «Выполнение такой сложной задачи точно в срок прославит меня» (если вы менеджер проекта).
• «Если мне удастся удовлетворить такого крупного клиента, то я получу огромный бонус» (если вы менеджер по работе с клиентами, владелец продукта, стейкхолдер и т. д.).
Мы все так думаем. И это нормально.
У любого человека есть свои собственные интересы, и в этом нет ничего плохого. Но персональная мотивация не объединяет команду. Когда люди работают вместе над единой задачей, они могут достичь гораздо большего, чем каждый по отдельности. Так что, пока каждый из нас беспокоится только о том, что может дать ему работа, которую он выполняет, мы добиваемся намного меньшего, чем если бы все работали как одна команда.
Приведем пример, как личные интересы могут нанести ущерб проекту. Предположим, в команде есть человек, который может переложить неинтересные или раздражающие его задачи на другого, обычно ниже его по статусу. Большинство из нас сталкивались с такой ситуацией. Например, старшие разработчики настолько заняты созданием нового ПО, что сняли с себя обязанность исправлять ошибки. Ведь заниматься разработкой новых функций гораздо интереснее, тем более если есть возможность ознакомиться с новыми технологиями. К тому же обычно существует команда младших разработчиков (зачастую в другом городе, где меньше платят), готовая заняться исправлением ошибок. Вообще это довольно распространенная практика: набирается «команда» опытных разработчиков для создания новых функций и группа поддержки, куда входят менее опытные специалисты, которые исправляют ошибки и ставят «заплатки» в уже выпущенное программное обеспечение.
Это очень удобно для старшего разработчика, желающего «выстрелить и забыть». Ведь он уверен: допущенные им погрешности будут устранять другие люди, которых он и знать не желает. В краткосрочном плане это очень неплохой способ работы для одного человека, но с точки зрения команды и в долгосрочной перспективе это неэффективно. Без всякого сомнения, ошибки должен исправлять тот, кто их сделал. Он уже знает детали кода, потому что писал его и хорошо в нем разбирается. Чтобы исправлением занялся кто-то другой, нужно затратить усилия на коммуникацию. Правда, иногда достаточно отправить письмо по электронной почте, но порой необходимы дополнительные документы (например, отчет об ошибке и обновленная спецификация). Человеку, который займется исправлением, потребуется время, чтобы разобраться в коде. Программист, создавший его, исправит погрешность за несколько минут, а другим понадобятся часы или дни (особенно если это новички или недостаточно опытные разработчики).
В scrum-командах редко встречается ситуация, когда грязную работу спихивают на другого, потому что все сотрудники привержены общему делу. Командная культура предполагает, что более опытный разработчик сам делает грязную работу за несколько минут, а не передает ее младшему коллеге, который потратит часы. Это и есть один из источников гиперпроизводительности и «удивительных результатов» применения Scrum, которые, похоже, недоступны многим командам.
Любая (даже не гибкая) команда может стать высокопроизводительной, если введет правила, запрещающие своим старшим членам передавать «скучные» задачи младшим по должности. Но по-настоящему успешной scrum-команде не нужно создавать специальных правил для подобных ситуаций. Причина в том, что все ее участники наделены подлинным чувством ответственности за каждый аспект проекта. Поэтому старшим членам команды никогда не придет в голову желание «свалить» технические задачи на младших коллег. Они поступят разумно, выполнив ту работу, которая необходима прямо сейчас (вспомните CEO, который пошел за кофе для сотрудников)[38]. Исправление ошибок и другие задачи обслуживания просто добавляются в бэклог спринта, рассматриваются во время ежедневных scrum-митингов и выполняются надлежащими людьми в определенное время. (И последний ответственный момент для исправления ошибок, возможно, как раз именно сейчас, потому что разработчик еще ничего не забыл.)
В успешной scrum-команде все чувствуют свою сопричастность не только к коду, который создают, но и к бэклогу, и каждый старается делать все возможное, чтобы поставить работающее программное обеспечение. Бэклог спринта – это ответственность каждого, даже самый молодой разработчик ощущает, что именно он сделал для пользователей. Вот что подразумевает Кен Швабер под коллективной ответственностью в цитате, приведенной в начале этой главы: каждый член команды разделяет ответственность за бэклог и чувствует персональную ответственность за поставку наиболее ценного работающего программного обеспечения, необходимого пользователям, – включая все функции, а не только те, над которыми работает лично он.
Как же достичь такого чувства командной ответственности, чтобы каждый – от младшего разработчика, старшего технического руководителя, scrum-мастера и до владельца продукта – добровольно взял на себя решение неинтересных задач только потому, что заботится о проекте?
Вы когда-нибудь были волонтером? Содействовали проекту с открытым исходным кодом? Вступали в клуб, любительскую спортивную команду, рок-группу, церковный хор? Подумайте о том случае, когда вы присоединились к группе, не имеющей отношения к вашей работе или семье. Зачем вы это сделали?
Вы присоединились к группе и, вероятно, отдавали ей немало своего времени и сил, потому что вас интересовала главная цель ее существования. Если это был штаб избирательной кампании, то вас беспокоила явка людей на выборы. Если футбольная команда – то вас волновала победа (и качественная игра). Так почему же на работе должно быть по-другому?
Все мы стремимся к цели. По меньшей мере, работаем за деньги. Если работа перестает приносить доход, мы прекращаем ею заниматься. У нас есть счета, которые нужно оплачивать, и семьи, которые требуется кормить. Так что, когда нам платят и предоставляют комфортную, безопасную обстановку, в которой мы должны отработать положенные часы, предлагают другие элементарные блага, составляющие рабочую среду, – этого бывает достаточно, чтобы мы приходили в офис и выполняли свои служебные обязанности.
Но достаточно ли этого, чтобы нас по-настоящему волновало создание работающего программного обеспечения?
Если вам довелось работать в недостаточно мотивированной команде, то вы знаете, что ответ будет отрицательным. Дело в том, что многие из нас никогда не трудились в действительно мотивирующей обстановке. Но если вам с этим повезло, то, скорее всего, вы вспоминаете те времена с ностальгией. Когда каждый заботится о создании отличного программного продукта, все вокруг приносит удовольствие: люди больше общаются, меньше спорят (или делают это продуктивно) и, похоже, легче достигают результата.
Существует много способов мотивировать команду: дать возможность поработать с новой технологией или в области, которая интересна, помочь продвинуться по служебной лестнице, платить премии, предоставлять работу на дому. Возможна и негативная мотивация: руководитель будет злиться, кричать (меньше заплатит, уволит). Эти позитивные и негативные стимулы мотивируют отдельных людей, но неспособны объединить команду.
Действительно сплотить может только вдохновляющая цель. Стив Макконел, эксперт и автор работ на тему управления проектами, в 16-й главе своей книги Beautiful Teams дал такое определение вдохновляющей цели:
Если вы копаете канавы, это вас не очень возвышает и вдохновляет. Но если вы копаете канавы, чтобы защитить свой город от врага, то это вдохновляет гораздо сильнее, хотя вы делаете то же самое. Поэтому задача лидера – представить работу таким образом, чтобы люди могли понять, в чем ее ценность.
Почти все программное обеспечение создано командой, а не отдельными людьми. Чтобы команда работала эффективно, нужно мотивировать всех сотрудников. Лучше всего вдохновляет и объединяет высокая цель, не оставляющая никого равнодушным.
Поставка ценности может быть очень эффективной вдохновляющей целью, мотивирующей всю команду. Когда у нее есть эта цель, она искренне верит в нее и готова самостоятельно решать, как ее достичь (и имеет возможность рисковать), команда будет усердно работать, используя имеющиеся инструменты, чтобы устранить любые препятствия на пути к этой цели.
Вдохновляющие цели направлены на ценность, но термин «ценность» может показаться абстрактным или оторванным от реальности. Для agile-команды ценность имеет вполне конкретный смысл: программное обеспечение ценное, если делает жизнь пользователей лучше. Что произойдет, если старший вице-президент сообщит команде: «Мы увеличили ваш доход в третьем квартале на 0,024 %, потому что вы напряженно работали. Отлично, молодцы!» Это не особенно мотивирует большинство разработчиков, даже если среди них есть те, кто оплатил опционы на акции.
Другое дело, если этот же человек придет и скажет: «Обычно я тратил три часа только на то, чтобы разобраться в этих цифрах. А ваше программное обеспечение настолько просто в использовании и так хорошо работает, что теперь я могу сделать все за десять минут. Спасибо!» Это гораздо сильнее мотивирует большинство разработчиков.
Разработчиков – а таковыми можно считать всех членов agile-команды, даже тех, кто не пишет код, – очень воодушевляет гордость мастера.