Заметьте, «клиентом» может быть кто угодно: непосредственный заказчик проекта; массовый потребитель; крупный банк; кто-то из вашей семьи; люди, ожидающие вакцину от ротавирусной инфекции, – и от вас зависит, получит ли каждый то, в чем нуждается. Другими словами, клиент – это тот, кто получает пользу от вашей деятельности.

Хочу уточнить: я не искал управляющего. Мне нужен был человек, на кого группа будет во всем полагаться и кому сможет доверить расстановку приоритетов в бэклоге. Помню, что я тогда решил позвать на это место самого большого умника из отдела маркетинга программного продукта. Обратите внимание: не из отдела разработки, а из отдела маркетинга. Именно так Дон Роднер стал первым, кто взял на себя роль владельца продукта. Он знал программное обеспечение, над которым мы работали, – не с технической стороны, хотя он понимал достаточно для того, чтобы взаимодействовать с инженерами и программистами, – а с точки зрения клиента. Что понадобится людям от этого программного обеспечения, когда они начнут им пользоваться? Подбирая кандидата на роль владельца продукта, найдите того, кто сможет буквально залезть в мысли любого потребителя, который заинтересован в том, что вы делаете. По словам моего одного приятеля, его жена является идеальным владельцем продукта – она точно знает, чего хочет, а ему остается лишь исполнять ее желания.

Владелец продукта, в отличие от скрам-мастера, не только владеет более прочными и разнообразными профессиональными навыками, но и его деятельность носит принципиально другой характер. Скрам-мастер и команда отвечают за то, каков будет темп их труда и как быстро они закончат проект. Владелец продукта ответствен за то, чтобы результативная командная работа превратилась в результат, приносящий прибыль. Долгие годы я создавал функциональный портрет владельца продукта, из которого выбрал для вас самые существенные его обязанности, сгруппировав их в четыре группы.

1. Владелец продукта должен обладать всей полнотой знаний о том, что входит в круг его обязанностей. Подразумевается следующее: во-первых, он должен быть абсолютно компетентен во всем, что делается в процессе разработки, и уметь оценивать возможности команды – то есть с чем она справляется, а с чем не очень; во-вторых, довольно хорошо разбираться в сути продукта и понимать, как довести разработку проекта – а это может быть и компьютерная система ФБР, и метод обучения учащихся средних школ – до результата, имеющего действительную стоимость. Кроме того, владелец продукта должен великолепно знать рынок, чтобы уметь анализировать его состояние: какая продукция имеет значение сегодня и как может измениться ситуация завтра.

2. Владелец продукта должен быть наделен полномочиями для принятия решений. Дирекции компании не следует вмешиваться в действия владельца продукта (как она не вмешивается в действия и решения группы). Напротив, руководителям, отвечающим за проект, полагается оказывать ему всяческое содействие, когда он трудится над концепцией продукта и когда в процессе разработки выполняет свои обязанности, помогая команде добиваться нужной цели. Помощь со стороны управленческого аппарата – весьма ценный фактор, поскольку владелец продукта испытывает давление со стороны многочисленных заинтересованных групп, как внутренних, так и внешних. Перед лицом такого мощного натиска он не мог бы сдерживать удар без административной поддержки. Надо добавить, что владелец продукта несет ответственность за результат, отбирает и формулирует для команды все требования на текущий спринт, при этом он не вправе давать задания отдельным участникам и вмешиваться в решения команды.

3. Владелец продукта должен быть всегда доступен для команды, поскольку в любой момент может потребоваться его объяснение, почему то или иное задание нужно делать в первую очередь. По сути, владелец продукта несет полную ответственность за ведение бэклога, по этой причине необходим налаженный обмен мнениями между ним и командой. Бывает так, что участники группы в силу своего опыта и квалификации советуют владельцу продукта, какие требования наиболее важны в данный момент. Владелец продукта должен быть надежным, последовательным и доступным. Не имея возможности связаться с ним, команда может принять неверное решение. Участники группы целиком полагаются на владельца продукта: на его концепцию продукта и знание ситуации на рынке. Поэтому нужна постоянная взаимосвязь владельца продукта и команды, иначе весь рабочий процесс может развалиться. Кстати, это одна из причин, почему я редко рекомендую на роль владельца продукта руководящих работников, например генеральных директоров компаний, – у них просто нет столько времени посвящать себя нуждам команды.

4. Владелец продукта должен нести ответственность за полезность продукта. Если речь идет о бизнес-структуре, в рамках которой работает скрам-команда, – значит показателем полезности является прибыль. Таким образом, деятельность самого владельца продукта соответственно оценивается из расчета, сколько прибыли приносит один выполненный пункт из его списка требований. Например, когда команда за неделю справляется с сорока пунктами, я всегда требую, чтобы обязательно измеряли, сколько конкретно прибыли приносит каждое выполненное требование. Однако скрам-команды работают в самых разных областях деятельности, и необязательно это должна быть бизнес-среда. Поэтому критерием полезности может быть, например, объем удачно завершенных дел. Мне известна следственно-оперативная группа из правоохранительных органов, измеряющая принесенную обществу пользу количеством осуществленных за неделю арестов находящихся в розыске преступников. Я знаю несколько церковных приходов, применяющих методологию Scrum, которые выбрали собственное мерило ценности: они измеряют популярность среди людей с помощью подсчета своей паствы и контроля ее роста. Смысл в том, что каждая команда – над чем бы она ни работала – должна сама для себя определить критерий полезности и спрашивать результат с владельца продукта, поскольку именно он в ответе за то, чтобы ценность и стоимость продукта постоянно росли. Постулируемый в системе Scrum принцип прозрачности дает возможность легко отслеживать такого рода показатели.

Действительно огромная зона ответственности для одного человека, поэтому на больших проектах обычно работает бригада владельцев продукта, которая должна обслуживать все обязательные требования как скрам-команд, так и заказчиков. Несколько позже я вернусь к этой бригаде. Но сейчас мне хотелось бы проиллюстрировать все сказанное выше небольшой историей, а чтобы вы прочувствовали, чем должен заниматься человек, выполняющий обязанности владельца продукта, я предложил бы вам пересесть (исключительно в своем воображении) в кабину реактивного истребителя F-86 «Сейбр», которым управляет Бешеный Майор Джон Бойд.

В ходе Корейской войны воздушные бои в основном велись между американскими F-86 «Сейбр» и советскими МиГ-15. Истребитель МиГ-15 отличался высокой маневренностью, отличными разгонными характеристиками, высоким практическим потолком и большим оснащением вооружения; скорость была немногим лучше, но в принципе по всем параметрам он считался более совершенным самолетом. Теоретически МиГ-15 должны были бы полностью очистить небо от американских самолетов. Вместо этого соотношение потерь составляло десять к одному не в пользу советской авиации. Тактика действий американских истребителей в небе Кореи настолько поразила воображение военных теоретиков – как такое вообще было возможно, – что в дальнейшем именно она определила судьбу ведения будущих войн. Этот феномен имел переломное значение даже в дальнейшем развитии методологии Scrum.