Представьте себе такой разговор между CEO и scrum-мастером. CEO спрашивает, что он получит в следующем году, инвестируя 2 миллиона долларов в программное обеспечение. Scrum-мастер отвечает: «Пока точно не знаю, предстоят ежемесячные обновления ПО, а в конце проекта получим программное обеспечение стоимостью не менее 2 миллионов долларов». Ни один здравомыслящий CEO не одобрит такой проект. Почему?
Причина в том, что он не основан на реальных обязательствах. Обязательства – это обещание сделать что-либо к определенному сроку. Настоящее обязательство тесно связано с дополнительной ответственностью, что подразумевает возможность информировать членов команды и искать решения, если обещание невозможно выполнить.
Большинство из нас присутствовали на собраниях, где члены команды утверждали, что не «подписывались» под сроками выполнения работ, поэтому не несут за них никакой ответственности. В этом вина некоторых неопытных руководителей. Они ошибочно полагают, что, как только задача записана в план, команда получает непреодолимое стремление ее выполнять.
Обязывают не планы, а наши обещания. План – это просто удобный способ их фиксации. Обязательства даются людьми и документируются в планах проекта. А это не просто бумажка. Это зафиксированная информация, и все держат ее в голове.
В scrum-команде владелец продукта – это человек, который взял на себя выполнение обязательства. Он должен пообещать конкретные результаты, которые будут достигнуты в конце проекта. Владелец продукта – ключевое звено в реализации бизнес-цели, ради которой затевался проект.
Чем эффективнее на встрече с командой он сможет передать эти задачи и позволить ей осознать обязательства, тем лучше будет выполняться проект. Когда проект сталкивается с неизбежными трудностями (техническими проблемами, изменениями в бизнесе, увольнением сотрудников и т. д.), владелец продукта должен найти способ сохранить взаимопонимание в команде и поддерживать в ней чувство ответственности. Ежедневно он принимает решения, основанные на бизнес-изменениях, и встречается с командой, чтобы узнать, правильно ли она понимает бэклог и трансформировавшиеся задачи проекта.
Владелец продукта не ждет безучастно окончания спринта. Он обязан ориентироваться в происходящем. Его дело – расставлять приоритеты в бэклоге, чтобы быть голосом заказчика в команде разработки, помогать выявлять наиболее важные и ценные истории и задачи. Он должен быть уверен, что каждый член команды правильно понимает выражение фактически сделано в контексте бэклога задач. В процессе планирования спринта вся команда решает, какие функции из продуктового бэклога нужно переместить в спринт бэклога. Выбор делается на основании их значимости и расчетов трудозатрат на их выполнение. На этом его работа не заканчивается, затем владелец продукта руководит этим процессом.
Ежедневно владелец продукта принимает активное участие в проекте. Как и все успешные agile-команды, scrum-команды во многом зависят от личного общения, которое помогает правильно понимать, что они создают. Планирование спринта, проведенное в начале, дает каждому члену команды достаточно информации, чтобы начать работу, но владелец продукта не успевает сообщить всей команде подробности. Поэтому во время спринта владелец продукта каждый день занят. Он подробно отвечает на многочисленные вопросы членов команды, дает конкретные рекомендации, как вести разработку, и рассказывает, каким образом пользователи будут применять созданные функции, а также решает массу других вопросов, касающихся работы продукта.
Владелец продукта имеет право принимать такие решения. (Если он не занимается этим, значит, занимает чужое место. Scrum зависит от способности владельца продукта принимать решения от имени заказчика, в том числе выполненную работу.) Но он не располагает исчерпывающими сведениями. Обычно в проекте принимает участие много пользователей и заинтересованных сторон, владеющих ценной информацией, поэтому владелец продукта тратит много времени на общение с ними, чтобы получить ответы на вопросы разработчиков. Кроме того, он использует такое общение, чтобы отслеживать происходящие изменения и поддерживать актуальность продуктового бэклога, где отражаются последние изменения, в которых нуждается компания. Таким образом, если есть изменения в относительной ценности различных элементов продуктового бэклога, то владелец может изменить их очередность, подготавливая тем самым команду к следующей сессии по планированию спринта.
В scrum-командах любят рассказывать басню про свинью и курицу, чтобы разобраться в том, как работает принятие на себя обязательств.
Свинья и курица идут по дороге.
Курица говорит свинье: «Давай откроем ресторан!»
Свинья отвечает: «Хм, можно. А как мы его назовем?»
Курица отвечает: «Почему бы не назвать его “Яичница с беконом”?»
Свинья, немного подумав, говорит: «Нет, спасибо, ведь тогда мне придется посвятить себя проекту полностью, а ты будешь вовлечена лишь частично»[29].
Рис. 4.2. В истории про свинью и курицу роль первой значительно превышает вклад второй в готовый завтрак
Так и в scrum-проекте: кто-то вовлечен частично, как курица, а кто-то полностью, как свинья. Чем это отличается от неэффективного водопадного подхода? Все сводится к тому, как действуют члены команды, руководитель проекта и владелец продукта[30].
В scrum-командах часто говорят о ролях «свиней» и «куриц». Это упрощение введено для того, чтобы легче было определить человеку ту роль, которую он играет в проекте. Вспомните проекты, в которых вы участвовали: всегда ли вы действительно связывали собственные успехи или неудачи с успехом проекта?
Дело в том, что большинство людей считают себя «курами». Они готовы внести свой вклад в проект, но не хотят рисковать, ведь проверки, повышения, достижение будущих карьерных целей, сохранение рабочего места – все зависит от успеха проекта. Также легко забыть, что люди работают за деньги. Почему люди выполняют свою работу? Что на самом деле их мотивирует? Это не обязательно успех в текущем проекте.
Всех членов эффективной agile-команды можно считать «свиньями». Они искренне считают, что их личный успех зависит от успешности проекта. Но даже очень опытная scrum-команда легко возвращается к менталитету «курицы».
Бывало так, что вы как разработчик выбирали технологию для проекта лишь потому, что хотели изучить ее? Или в качестве руководителя проекта предпочитали agile-методологии, потому что они делают вас более востребованным? Скорее всего, да. Мы все хотя бы раз прошли через это. Каждый целеустремленный человек поступал подобным образом, и это важно признать. Но есть одно обстоятельство, предусмотренное правилами Scrum: выполнение задач спринта важнее всех прочих профессиональных целей[31], которые у вас есть. Иными словами, пока ты в scrum-команде – оставайся «свиньей».
Когда все члены команды – «свиньи», значит, каждый взял на себя обязательства и будет делать все, что необходимо для их выполнения.
Вот пример, помогающий понять, что значит брать на себя обязательства. Допустим, вы CEO компании и у вас есть обязательства перед проектом. И выясняется, что члены проектной команды устали и нуждаются в кофе. Если все заняты и не могут прерваться прямо сейчас, то несмотря на занимаемую должность вы пойдете за кофе для команды, потому что действительно имеете обязательства и убеждены: именно на это нужно потратить свое время.
В то же время в каждом проекте программного обеспечения должны быть и «куры». Например, каждый пользователь – это потенциальная «курица». Сколько раз вы были разочарованы возможностями браузера, текстовым редактором или почтовым клиентом? Вы когда-нибудь оставляли свои отзывы на сайте или отправляли их по электронной почте команде поддержки? Это один из способов превратить себя в «курицу». Раз команда прислушивается к вашему мнению и решает проблему, значит, вы помогли повысить ценность продукта. И чем активнее «курица», тем более высокую ценность она может привнести.
Если в scrum-проекте вы играете роль «курицы», то ваше мнение важно. Вы заинтересованы в результатах, и команде интересны ваши мысли. Но ваша работа напрямую не связана с проектом, у вас другие цели (например, продажа продукта, его поддержка или управление компанией). Все это имеет значение, но не связано с разработкой конкретных функций.
Вот почему scrum-команды – и особенно владелец продукта – налаживают отношения со своими «курами». Один из самых эффективных способов, помогающий в этом, – обеспечить пользователей новыми версиями работающего ПО на регулярной основе и с предсказуемым графиком. Это поддерживает вовлеченность «кур» и помогает им видеть свое влияние на проект.
Когда член команды бесстрастно выполняет задачи, возложенные на него руководителем проекта, не беспокоясь о возникновении каких-либо проблем, он ведет себя как «курица». Он не чувствует своей ответственности за этот проект, впрочем, как и ответственности других членов команды. Но если этот член команды искренне заинтересован в создании правильного плана и наиболее ценного программного обеспечения для клиента и своей компании, то он ведет себя как «свинья».
К сожалению, многие компании ожидают от членов команды действий, характерных для «кур», а не для «свиней». Программисты нередко обнаруживают, что их попытки принять участие в планировании заканчиваются ничем, потому что планирование и принятие решений – это привилегия менеджеров. («Уж не возомнил ли ты себя менеджером? Отправляйся на свое рабочее место, жалкий программист!») Если такое видение характерно для команды, то ей трудно эффективно применять Scrum.