Вы находитесь на странице: 1из 230

Эту книгу хорошо дополняют:

Scrum. Революционный метод управления


проектами
Джефф Сазерленд

Deadline
Том Демарко

От хорошего к великому
Джим Коллинз
Roman Pichler

Agile Product
Management
with Scrum
Creating Products that Customers Love

Addison-Wesley
2010
Роман Пихлер

Управление
продуктом
в Scrum
Agile-методы для вашего бизнеса

Перевод с английского
Александра Коробейникова

Москва
«Манн, Иванов и Фербер»
2017
УДК 658.5.012.1
ББК 65.291.217
П36

Издано с разрешения Pearson (Addison-Wesley Professional)


На русском языке публикуется впервые
Книга рекомендована к изданию
Лианой Мартиросян и Наталией Юлдашевой
Благодарим за помощь в подготовке издания компанию ScrumTrek
в лице Алексея Пименова, Дарьи Рыжковой, Василия Савунова
и Александра Тупикова

Пихлер, Роман
П36 Управление продуктом в Scrum. Agile-методы для вашего бизне-
са / Роман Пихлер ; пер. с англ. Александра Коробейникова. —
М. : Манн, Иванов и Фербер, 2017. — 240 с.

ISBN 978-5-00100-354-0

Ядро каждой успешной команды agile-разработки — дальновидный,


мотивированный и наделенный большими полномочиями владелец про-
дукта, способный быть не просто менеджером, а членом scrum-команды,
готовым к тесному и постоянному сотрудничеству.
Роман Пихлер, один из ведущих экспертов по Scrum и agile-управле-
нию продуктом, в своей книге рассматривает все компоненты этой роли,
необходимые, чтобы привести компанию к великолепным результатам.
Его книга о том, в чем заключается роль владельца продукта, с какими
типичными сложностями и подводными камнями он сталкивается в своей
работе, как их преодолеть, а также чем agile-управление продуктом, осно-
ванное на Scrum, отличается от традиционных подходов и как эффективно
применять scrum-техники на практике.

УДК 658.5.012.1
ББК 65.291.217
Все права защищены. Никакая часть данной
книги не может быть воспроизведена
в какой бы то ни было форме без письменного
разрешения владельцев авторских прав.

Authorized translation from the English language


edition, entitled Agile product management with
Scrum: creating products that customers love,
1st edition, ISBN 978-0-321-60578-8; published
by Pearson, publishing as Addison-Wesley
Professional.

ISBN 978-5-00100-354-0 © Roman Pichler, 2010


© Перевод на русский язык, издание
на русском языке, оформление.
ООО «Манн, Иванов и Фербер», 2017
Содержание

Предисловие Джеффа Сазерленда . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Предисловие Бретта Квинера . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Предисловие . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Чем отличается agile‑управление продуктом . . . . . . . . . . . . 23
Что предлагает эта книга и кто должен
ее прочесть . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

1. Кто такой владелец продукта? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27


Роль владельца продукта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Характеристики правильного владельца
продукта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Визионер и человек действия . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Лидер и командный игрок . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Пропагандист и переговорщик . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Наделенный полномочиями
и преданный делу . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Доступный и квалифицированный . . . . . . . . . . . . . . . . . . . . . 36
8 Содержание

Работа с командой . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Взаимодействие со scrum‑мастером . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Работа с клиентами, пользователями
и другими заинтересованными лицами . . . . . . . . . . . . . . . . . . . . . 41
Моделирование роли владельца продукта . . . . . . . . . . . . . . . . . 45
Главный владелец продукта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Иерархия владельцев продукта . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Как правильно выбрать владельцев
продукта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Распространенные ошибки . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Владелец продукта с недостаточными
полномочиями . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Перегруженность владельца продукта . . . . . . . . . . . . . . . 53
Частичный владелец продукта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Удаленный владелец продукта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Заместитель владельца продукта . . . . . . . . . . . . . . . . . . . . . . . . . 57
Комитет владельцев продукта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Вопросы для самоконтроля . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

2. Планирование концепции продукта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61


Видение продукта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Желаемые качества видения . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Общее и объединяющее . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Широкое и мотивирующее . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Краткое и приятное . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Содержание 9

Минимально функциональный продукт . . . . . . . . . . . . . . . . . . . . 68
Простота . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Бритва Оккама . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Чем меньше, тем лучше . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Простые пользовательские интерфейсы . . . . . . . . . . . . . 76
Потребности покупателя и свойства продукта . . . . . . . . . 78
Рождение видения продукта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Любимые проекты . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Использование Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Техники формирования видения . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Прототипирование и макетирование . . . . . . . . . . . . . . . . . 84
Персоны и сценарии . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Визуализация и обзор в отраслевом журнале . . . . 88
Модель Кано . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Формирование видения и дорожная карта
продукта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Минимальные продукты и варианты продукта . . . . . . . . 92
Распространенные ошибки . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Отсутствие видения . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Пророческое видение . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Аналитический паралич . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
«Мы-лучше-знаем-что-нужно-клиентам» . . . . . . . . . . . 97
«Большое — значит хорошее» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Вопросы для самоконтроля . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
10 Содержание

3. Работа с бэклогом продукта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101


Глубинные свойства бэклога продукта . . . . . . . . . . . . . . . . . . . . . 102
Достаточная степень детализации . . . . . . . . . . . . . . . . . . . . . 102
Оценка . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Развитие . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Приоритетность . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Работа над бэклогом продукта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Выявление и описание элементов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Выявление элементов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Описание элементов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Структурирование бэклога продукта . . . . . . . . . . . . . . . . . 111
Расстановка приоритетов в бэклоге продукта . . . . . . . . . 113
Ценность . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Знания, неопределенность и риск . . . . . . . . . . . . . . . . . . . . . . . 116
Возможность выпуска . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Взаимозависимости . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Подготовка к планированию спринта . . . . . . . . . . . . . . . . . . . . . . . 120
Выбор цели спринта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Когда нужно и ровно столько,
сколько нужно . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Декомпозиция элементов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Обеспечение четкости, проверяемости
и осуществимости . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Определение масштабов элементов . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Содержание 11

Очки историй . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130


Покерное планирование . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Работа с нефункциональными требованиями . . . . . . . . . 135
Описание нефункциональных требований . . . . . . 136
Управление нефункциональными
требованиями . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Бэклог продукта при масштабировании . . . . . . . . . . . . . . . . . . . 138
Использование единого бэклога продукта . . . . . . . 139
Расширьте горизонт груминга . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Создайте различные видения
бэклога продукта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Распространенные ошибки . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Замаскированная спецификация . . . . . . . . . . . . . . . . . . . . . . . . 141
Список просьб к Санта-Клаусу . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Навязывание требований . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Пренебрежение грумингом . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
Конкурирующие бэклоги продуктов . . . . . . . . . . . . . . . . . 144
Вопросы для самоконтроля . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

4. Планирование релиза . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147


Время, затраты и функциональность . . . . . . . . . . . . . . . . . . . . . . . . 148
Стабильность качества . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Быстрые и частые релизы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
Квартальные циклы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Скорость . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
12 Содержание

Диаграмма сгорания работ для релиза . . . . . . . . . . . . . . . . . . . . . 160


График сгорания работ для релиза . . . . . . . . . . . . . . . . . . . . . 161
Столбиковая диаграмма сгорания работ . . . . . . . . . . 164
План релиза . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Прогнозирование скорости . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Составление плана релиза . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
Планирование релизов в больших проектах . . . . . . . . . . . 173
Общие ориентиры для оценок . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Перспективное планирование . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Конвейерная работа . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
Распространенные ошибки . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
Отсутствие диаграммы сгорания работ
или плана релиза . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
Владелец продукта в кресле пассажира . . . . . . . . . . . . 178
Взрывной релиз . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
Работа в ущерб качеству . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
Вопросы для самоконтроля . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180

5. Совместная работа на совещаниях по спринту . . . . . . . . . . 182


Планирование спринта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
Критерии готовности . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
Ежедневный scrum-митинг . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Спринт-бэклог и диаграмма сгорания работ
для спринта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Обзор итогов спринта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
Содержание 13

Ретроспективный анализ спринта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193


Совещания по спринтам в крупных
проектах . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
Совместное планирование спринта . . . . . . . . . . . . . . . . . . . 195
Scrum-совещание по Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
Демонстрация результатов спринта . . . . . . . . . . . . . . . . . . 196
Совместная ретроспектива спринта . . . . . . . . . . . . . . . . . . 197
Распространенные ошибки . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
Владелец продукта — «чайка» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
Незаинтересованный владелец
продукта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
Нежизнеспособный темп . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
Стремление создать иллюзию . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
Включение в отчет диаграммы
сгорания задач спринта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
Вопросы для самоконтроля . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203

6. Превращение во владельца продукта . . . . . . . . . . . . . . . . . . . . . . . . . . 205


Как стать отличным владельцем продукта . . . . . . . . . . . . . . 206
Познайте себя . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
Развитие и рост . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
Найдите наставника . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
Убедитесь в поддержке на нужном
уровне . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
Вы еще не готовы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
14 Содержание

Как развивать владельцев продукта . . . . . . . . . . . . . . . . . . . . . . . . . . 211


Осознайте важность роли . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
Выбирайте правильного владельца
продукта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
Наделяйте владельцев продукта
полномочиями и поддерживайте их . . . . . . . . . . . . . . . . . . 213
Поддерживайте институт владельцев
продукта в компании . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
Вопросы для самоконтроля . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216

Библиография . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218

Благодарности . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226

Об авторе . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
Посвящается Мелиссе
Предисловие
Джеффа Сазерленда

Владелец продукта  — новая роль для большинства ком-


паний, и поэтому она нуждается в убедительной презен-
тации, которую и  дает эта книга. Когда избирался пер-
вый владелец продукта, я был вице-президентом Object
Technology и отвечал за разработку первого продукта, со-
зданного по Scrum. Этот продукт должен был стать опреде-
ляющим для компании, и мне отводилось шесть месяцев,
чтобы создать инструмент разработки, который изменит
рынок. Помимо работы вместе с  небольшой, тщательно
подобранной командой мне предстояло перестроить всю
компанию вокруг новой схемы деятельности. До поставки
продукта оставалось несколько месяцев, и было понятно,
что успех определит правильно сформированный набор
минимального функционала. Оказалось, мне не  хватает
времени на разговоры с клиентами и тщательный анализ
действий конкурентов, что помогло бы точно расставить
Предисловие Джеффа Сазерленда 17

приоритеты и разложить функционал на небольшие эле-


менты для команды.
Я уже делегировал свои инженерные обязанности
первому scrum-мастеру, Джону Скамниоталесу, но  мне
был необходим владелец продукта. У  меня имелся до-
ступ к  любым ресурсам компании, поэтому я избрал
на  нужную мне роль Дона Реднера, лучшего специалис-
та из  коман­ды менеджеров продукта. Дону как первому
владельцу продукта предстояло вести его, сформировав
в уме видение перспектив, бизнес-плана и выручки, пла-
нов развития и выпуска, а главное — тщательно разрабо-
тав бэклог* продукта с расставленными для всей коман-
ды приоритетами.
Дон половину времени проводил с  командой, а  дру-
гую половину  — с  клиентами. В  его задачи входило вы-
дать нужный продукт, в  то время как я вместе со  всей
компанией работал над неймингом и брендингом, марке-
тинговой стратегией и  коммуникациями, планировани-
ем продаж и обучением, продолжая каждый день ходить
на  scrum-митинги и  устранять все препятствия на  пути

* Бэклог (или журнал продукта) — список всех пожеланий к продук-


ту, составленный по принципу от наиболее к наименее важному.
При этом под важностью понимается совокупный показатель про-
гнозируемых трудозатрат на его реализацию. В бэклоге хранятся
элементы  — это могут быть пользовательские истории, техниче­
ский долг и  т.  д. Элементы бэклога декомпозируются на  задачи
(элементарные действия, которые может сделать один человек).
Прим. науч. ред.
18 Управление продуктом в Scrum

команды. Роль Дона была гораздо серьезнее, чем обычно


у  менеджера по  маркетингу продукта. Внезапно он ока-
зался владельцем нового направления бизнеса. В  то же
время ему приходилось глубоко вникать в работу инже-
неров, регулярно объясняя ситуацию и  мотивируя со-
трудников. Полное погружение одновременно и в рынок,
и в команду — это уникальный опыт.
Степень концентрации и мера ответственности хоро-
шего владельца продукта подробно описаны в этой книге,
однако редко наблюдаются в реальных компаниях по про-
изводству продукта и IT-командах. Нам необходимо опи-
сание образцового владельца продукта, а также того, как
он исполняет эту роль. Такое руководство и  подготовил
Роман Пихлер.
Джефф Сазерленд,
один из создателей Scrum
Предисловие
Бретта Квинера

Сегодня во  всей индустрии ПО набирает силу Agile. По­


следние двадцать лет многие клиенты, партнеры и  со-
трудники были разочарованы тем, как мы разрабатываем
корпоративные технологические решения. Они, к  сожа-
лению, часто оказывались низкокачественными, требо-
вали нескольких лет для вывода на рынок, в них нередко
отсутствовали инновации, необходимые для решения ре-
альных проблем бизнеса.
Salesforce.com стремится стать другой компанией,
ориентированной на  успех клиентов и  сотрудников. Мы
знали, что для организации нашего типа традиционные
методы разработки ПО неприменимы. Требовалось при-
думать иную модель и, смирив гордыню, найти лучший
вариант. Мы спросили себя: существует ли способ регу-
лярно и вовремя выдавать качественное ПО? Реально ли
часто и быстро создавать ценности для клиентов? Можно
20 Управление продуктом в Scrum

ли внедрять инновации с такой же скоростью, с какой рас-


тет компании? Оказалось — да, можно.
Мне как главному владельцу продукта в Salesforce.com
нужно было найти максимально динамичный способ, при
помощи которого менеджеры продуктов сумеют донести
желания и  потребности клиентов и  бизнеса до  команд
разработчиков, обеспечив к тому же обратную связь. Ис-
пользование Scrum позволяет возложить на  менеджеров
продукта ответственность за создание ценности для кли-
ента. Что, в свою очередь, дает возможность направлять
команду к разработке в первую очередь наиболее важных
для бизнеса функций, чтобы как можно быстрее передать
продукт в  руки покупателей. Scrum дает нужную гиб-
кость, чтобы быстро реагировать на меняющиеся условия
рынка и давление со стороны конкурентов или внедрять
новые идеи наших команд. Из  этой книги вы узнаете,
чем владелец продукта отличается от традиционного ме-
неджера продукта и  почему он наделен более высоким
уровнем ответственности за  успех продукта. Здесь ярко
выявлен контраст между поведением специалиста в тра-
диционной и agile-моделях.
Многие пытались объяснить роль владельца продук-
та, но  никому это не  удалось так, как Роману Пихлеру.
Он убедительно рассказывает о  теории и  практике гиб-
кого управления продуктом, которые помогают владель-
цам продукта, членам scrum-команд и  руководителям
Предисловие Бретта Квинера 21

внедрять­ инновации. Роман приводит множество приме-


ров из  деятельности таких конкурентоспособных инно-
ваторов, как Salesforce.com, а также доходчиво объясняет,
как создать и обеспечить надежную работу минимальной
функциональности при инновациях. Он обращает внима-
ние и  на  часто встречающиеся ошибки владельцев про-
дукта.
В современной динамичной и  конкурентной среде
требования клиентов высоки как никогда. Гибкий под-
ход, которого мы придерживаемся в  Salesforce.com, де-
монстрирует отличные результаты, наши владельцы про-
дукта выдают все больше инноваций и создают ценности
для покупателей. Если вы хотите добиться такого же ре-
зультата, то эта книга для вас. Проверенные инструмен-
ты, методы, ценные советы  — все это поможет на  пути
к успеху — вашему и ваших клиентов.
Бретт Квинер,
старший вице-президент
по продукту Salesforce.com
Предисловие

По гибкой разработке ПО и  управлению продуктом на-


писано много отличных книг. Однако до сих пор нет ис-
черпывающего описания того, как оно работает. Кажется,
что agile-адепты стараются ускользнуть от ответа на этот
вопрос, а специалисты по управлению продуктом до сих
пор силятся понять этот дивный agile-мир. Сейчас все
больше компаний берут на  вооружение Scrum, и  вопрос
о специфике управления продуктом в scrum-среде стано-
вится очень актуальным. В этой книге делается попытка
на него ответить.
В 1999 году я познакомился с agile- и деологи­ей, и ме­
ня поразило тесное сотрудничество между техниче­скими
и  бизнес-специалистами и  технарями. Я всегда считал,
что разработка ПО  — это то, что интересует гиков*,

* Гик  — человек, чрезвычайно интересующийся чем-либо, фанат.


Первоначально так называли людей, увлеченных высокими техно-
логиями (обычно компьютерами и гаджетами). Прим. ред.
Предисловие 23

но не бизнесменов­. Занимаясь коучингом своего первого


agile-проекта в 2001 году, я прежде всего старался помочь
менеджерам продукта перейти к  миру гибких методоло-
гий. С тех пор владение продуктом всегда оставалось са-
мым большим вызовом для компании и определяло успех
всего предприятия. Так было во всех компаниях, которые
я консультировал, и  это помогало не  только разрабаты-
вать успешный продукт, но и применять Scrum по назна-
чению. Можно повторить слова Криса Фрая и Стива Грина
(Fry, 2007; 139), которые консультировали Salesforce.com
по переходу к Agile:

В начале нашей работы мы постоянно слышали


от многих экспертов, что роль владельца продукта —
ключевая для успеха перехода к  Agile. Хотя интуи-
тивно это было понятно и нам, мы все же не до кон-
ца осознавали те значительные перемены, которые
ожидают владельцев продукта.

Чем отличается
agile‑управление продуктом
Agile, или гибкое управление продуктом, основанное
на Scrum, отличается от традиционных подходов во мно-
гих отношениях. В таблице 1 приведено резюме наиболее
важных различий.
24 Управление продуктом в Scrum

Таблица 1. Управление продуктом по-старому и по-новому

Старые методы Новые методы

Несколько ролей — напри- Один человек, владелец продукта,


мер, маркетолог продук- отвечает за продукт и возглавляет
та, менеджер продукта проект. Более подробно об этой
и менеджер проекта. новой роли можно прочитать в гла-
Между ними делится от- вах 1 и 6
ветственность за создание
продукта

Менеджеры команды отде- Владелец продукта — член scrum-


лены от команды разра- команды, он постоянно и тесно
ботчиков: разные процеду- сотрудничает со scrum-мастером
ры, отделы и мощности и всей командой. Подробнее об этом
читайте в главах 1, 3 и 5

Обширное исследование Минимальная предварительная


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

Предварительное иссле- Исследование продукта — это посто-


дование и определение янный процесс, требования возни-
продукта: разрабатывают- кают как его следствие. Отсутствует
ся и окончательно уста- фаза определенности и четкое
навливаются подробные указание требований к рынку или
требования продукту. Бэклог продукта динами-
чен, и его содержание варьируется
в зависимости от отзывов клиентов
и пользователей. Более подробно
об этом говорится в главе 3

Отзывы пользователей Максимально быстрые и частые


получаются на позднем релизы вместе с краткосрочными
этапе, в ходе рыночного обзорными совещаниями порождают
тестирования и после ценную обратную связь от пользо-
запуска продукта вателей и клиентов, что позволяет
создать продукт, который полюбят
клиенты. Это описано в главах 4 и 5
Предисловие 25

Agile-методы, в  том числе Scrum, придерживаются


старой как мир истины: постоянны только изменения.
«Если собственный анализ компании не  делает продукт
устаревшим, это сделает чей-то еще анализ»,  — писал
Теодор Левитт в своей знаменитой статье «Близорукость
маркетинга», опубликованной в  1960  году. Кристенсен
добавляет, что прорывные технологии со временем про-
исходят в  любой отрасли. Непонятно только, насколько
быстро и  часто это случается. Компании, неспособные
к  стремительной адаптации, сойдут с  дистанции, даже
если в данный момент с их доходами все в порядке. К счас-
тью, эмпирическая природа Scrum отлично приспособила
эту методологию к внедрению разных новшеств и инно-
ваций, действий в сложных ситуациях, где преобладают
текучесть и непредсказуемость. Если ваш бизнес характе-
ризуется переменами, в Scrum вы, скорее всего, найдете
мощного союзника.

Что предлагает эта книга


и кто должен ее прочесть
Эта книга для всех, кого интересует гибкое управление
продуктом, особенно для владельцев продукта. Она рас-
сказывает о роли владельца продукта и основных методах
управления. К  ним относятся визуализация продукта,
26 Управление продуктом в Scrum

разработка и совершенствование бэклога продукта, пла-


нирование и  отслеживание релиза продукта, использо-
вание scrum-собраний и переход к новой роли. Это прак-
тическое руководство позволит эффективно применить
scrum-техники управления продуктом. Особое внимание
уделяется продуктам, связанным с  ПО,  — от  простого
приложения до мобильных телефонов.
Но это не учебник для начинающего менеджера про-
дукта и не пособие по Scrum для новичков. Тем более не-
льзя считать книгу руководством на  все случаи жизни
в области управления продуктом. Многие аспекты управ-
ления продуктом здесь даже не  рассматриваются. Наи­
большее внимание уделяется идеям и  методам управле-
ния продуктом, специфичным для Scrum.
Эта книга предполагает, что вы знакомы со  Scrum
и  обладаете актуальными познаниями в  области управ-
ления продуктом.
Надеюсь, книга поможет вам создавать продукты,
которые полюбят потребители: они будут приносить по-
купателям пользу и разрабатываться разумно, с расчетом
на длительную перспективу.
1
Кто такой владелец
продукта?

Однажды я работал над продуктом в  области здраво­


охранения. Эта система должна была создавать больше
ценностей для потребителей и обеспечить существенное
преимущество над конкурентами. Через два с  лишним
года новый продукт был наконец запущен, на него возла-
гались большие надежды, но все обернулось провалом.
Что же произошло? Где-то по  дороге между идеей
и  запуском концепция заблудилась. Маркетологи про-
вели исследование рынка, сформулировали концепцию
продукта и передали ее менеджеру продукта. Он написал
спецификацию и вручил менеджеру проекта, который пе-
редал ее в разработку. Не нашлось никого, кто бы отвечал
за создание успешного продукта, не существовало общего
видения продукта и его функциональности. У всех были
собственные подходы, своя концепция.
28 Управление продуктом в Scrum

Как разрешить ситуацию? На всех этапах за продукт


должен отвечать один человек — владелец продукта. Эта
глава рассказывает о  его полномочиях и  обязанностях,
а также о том, как правильно вести себя в этой роли.

Роль владельца продукта


В Scrum Guide Кен Швабер пишет о владельце продукта:

Владелец продукта  — единственный человек, отве-


чающий за  список требований к  продукту и  ответ­
ственный за результат работы команды. Этот человек
составляет бэклог продукта и обеспечивает его до-
ступность для всех членов команды.

Определение звучит вполне безобидно, пока мы не на-


чнем оценивать его последствия. Владелец продукта воз-
главляет усилия разработчиков по  созданию продукта,
благодаря которому появляются желаемые преимущест-
ва. Это часто подразумевает формулирование концепции
продукта, работу с  бэклогом продукта, планирование
релиза, привлечение клиентов, пользователей и  дру-
гих заинтересованных лиц, управление бюджетом, под-
готовку запуска продукта, посещение scrum-митингов
и сотрудничество с командой. Владелец продукта играет
ключевую роль не  только в  создании новых продуктов­,
1. Кто такой владелец продукта? 29

но  и  в  поддержании­ жизненного цикла продукта. На-


значение одного человека ответственным за  релизы
обеспечивает их непрерывность и  снижает количество
передаточных звеньев, а  также поощряет долгосрочное
планирование. Исследование в SAP AG выявило и другие
преимущества: сотрудники, работающие владельцами
продукта, чувствовали себя уверенно, понимали степень
своего влияния и то, что они на виду, были наиболее орга-
низованными и мотивированными для новой роли.
Но владелец продукта — это прежде всего член scrum-
команды, он тесно сотрудничает с  коллегами. Scrum-
мастер­ и команда помогают владельцу продукта, совмес-
тно работая над бэклогом продукта, а владелец продукта
отвечает за успех необходимых мероприятий.
Велик соблазн сравнить роль владельца продукта
с  традиционными ролями  — менеджером продукта или
руководителем проекта. Но  любое сравнение будет не-
точным. Владелец продукта  — это новая многогранная
роль, которая объединяет власть и ответственность, тра-
диционно распределявшиеся в руках разных людей, в том
числе клиента, спонсора, менеджера продукта и руково-
дителя проекта.
Конкретные задачи владельца продукта зависят
от  контекста: в  частности, от  типа продукта, стадии его
жизненного цикла и  размера проекта. Например, вла-
дельцу продукта, который состоит из  программного
30 Управление продуктом в Scrum

обеспечения­, аппаратного обеспечения и  механических


устройств, потребуются совершенно иные компетенции,
чем человеку, возглавляющему работу по  созданию веб-
приложения. А владелец продукта, участвующий в боль-
шом scrum-проекте, должен иметь иные навыки, чем че-
ловек, сотрудничающий с одной-двумя командами.
В коммерческих проектах владелец продукта  —
обычно представитель клиента: менеджер продукта
или маркетолог. Сам клиент принимает на  себя эту
роль, если продукт разрабатывается для конкретной
организации. Например, это может быть внешний кли-
ент, которому необходимо новое решение для хранили-
ща данных, или внутренний клиент (в частности, отдел
маркетинга), запрашивающий обновление сайта. Мне
доводилось работать с клиентами, пользователями, ме-
неджерами бизнес-направлений, менеджерами продук-
тов, руководителями проектов, бизнес-аналитиками
и  архитекторами, которые хорошо подходили на  роль
владельца продукта в  конкретных обстоятельствах.
Владельцем продукта может стать даже CEO*. Напри-
мер, Ript  — визуальный планировщик, позволяющий
пользователям копировать и  вставлять изображения
и  тексты из  одного приложения в  другое,  — это плод

* От Chief Executive Officer (англ.) — высшая исполнительная долж-


ность в компании. В принятой в России иерархии аналог генераль-
ного директора. Прим. ред.
1. Кто такой владелец продукта? 31

усилий Джерри Лейборна, CEO компании­Oxygen Media,


который взял на себя роль владельца продукта для пер-
вого релиза программы.

Характеристики правильного
владельца продукта
Выбор правильного владельца продукта необходим
в  любом scrum-проекте. Успешные владельцы продук-
та, с  которыми я работал, обладали некоторыми общи-
ми чертами. Поскольку владелец продукта  — это новая
роль, людям часто требуются время и поддержка, чтобы
приспособиться к ней и приобрести необходимые навы-
ки. Основная проблема  — найти сотрудников с  прием-
лемым уровнем знаний и опыта, которые смогут хорошо
выполнить задачу. (Переход к  роли владельца продукта
и  самосовершенствование в  этой должности описаны
в главе 6.)

Визионер* и человек действия

Писатель Джонатан Свифт заметил: «Ви`­де­ние  — это ис-


кусство видеть невидимое». Владелец продукта  — это

* Визионер (от англ. vision — видение) — человек, обладающий стра-


тегическим мышлением. Прим. ред.
32 Управление продуктом в Scrum

визионер­, который может представить себе конечный про-


дукт и поделиться этим видением с другими. Но владелец
продукта — это и человек действия, способный оценить
трудоемкость всех этапов работы вплоть до  ее заверше-
ния. Он может описывать требования, тесно сотрудничать
с командой, принимать или отвергать рабочие результа-
ты и  руководить проектом, отслеживая и  предсказывая
его прогресс. Как предприниматель владелец продукта
поощряет творческое мышление и инновации, уверенно
чувствует себя в меняющихся условиях, обстановке неоп-
ределенности, спорах, конфликтах, он ценит и понимает
юмор, поощряет эксперимент и обдуманный риск.

Лидер и командный игрок

«Хорошие бизнес-лидеры создают концепцию, формули-


руют концепцию, страстно ее отстаивают и  неумолимо
ведут к  завершению»,  — говорит Джек Уэлч, бывший
председатель совета директоров и CEO компании General
Electric. Владелец продукта  — именно такой лидер. От-
вечая за  успех продукта, он обеспечивает руководство
всеми, кто занят разработкой, и  готов принимать слож-
ные решения. Например, укажет, отложить дату запуска
или ограничиться меньшей функциональностью. В  то
же время владелец продукта  — командный игрок, он
вступает в  тесное сотрудничество с  другими членами
1. Кто такой владелец продукта? 33

scrum‑команды­ и не  обладает формальной властью над


ними. Мы можем определить владельца продукта как
primus inter pares — первого среди равных в том, что ка-
сается продукта­.
Двойственная природа владельца продукта (как лиде-
ра и командного игрока) накладывает свои ограничения.
Он ни в коем случае не должен быть диктатором, но в то
же время не  может себе позволить нерешительности
и мягкотелости в управлении.
Владелец продукта — это своего рода пастырь инно-
вационного процесса, он направляет проект и стремится
к согласию с командой при принятии решений. Совмест­
ное принятие решений обеспечивает общую вовлечен-
ность, задействует знания и творческий импульс коман-
ды и  в  итоге дает лучшие результаты. Подобный метод
работы требует терпения, поскольку члены команды по-
началу часто спорят и лишь затем из различных идей фор-
мируется новое решение. Кейнер приводит в своей рабо-
те полезные сведения о коллективном принятии решений
и связанных с ним методах координации (Kaner, 1996).

Команда предпринимателей
Порой мы излишне концентрируемся на  знаменитых
предпринимателях и  лидерах  — Билле Гейтсе, Стиве
Джобсе и  других. На  самом деле лишь немногие ин-
новации — это действительно результат гениальности­
34 Управление продуктом в Scrum

одного человека. И  даже если владелец продукта  —


ходячая инновация, ему все равно требуется команда
для воплощения идеи в  жизнь. Ни один даже самый
выдающийся предприниматель не  сможет сам при-
нять все нужные решения. Нейробиологи доказали,
что даже сверхквалифицированный человек спосо-
бен ошибиться, пытаясь справиться со всем в одиноч-
ку. Поэтому рекомендуется использовать еще хотя бы
одного человека, чтобы было с кем проконсультиро-
ваться. Финкельштейн и его соавторы связывают это
с работой человеческого сознания (Finkelstein, 2009).
В команде множество партнеров, способных про-
верить ваши идеи и тем самым стимулировать приня-
тие верных решений. Эд Кэтмалл, президент Pixar,
утверждает:
…если дать хорошей команде посредственную
идею, она либо исправит ее, либо выбросит и приду-
мает взамен что-то получше.
Мудрость многих лучше, чем гений одного.

Пропагандист и переговорщик

Владелец продукта должен быть эффективным пропа-


гандистом и  переговорщиком. Этот человек общается
с  разными сторонами, объединяя клиентов, пользова-
телей, разработчиков, инженеров, маркетологов, со-
трудников отдела продаж, операционных сотрудников
и  руководство­. Владелец продукта  — это голос клиента,
1. Кто такой владелец продукта? 35

который доносит до  исполнителей требования потреби-


теля и заполняет лакуну между «пиджаками» и «технаря-
ми». Иногда от него требуется сказать «нет», а иногда —
найти компромисс.

Наделенный полномочиями
и преданный делу

У владельца продукта должно быть достаточно полномо-


чий, чтобы возглавить разработку и  объединить усилия
всех заинтересованных лиц. В mobile.de, самом большом
немецком онлайн-рынке автомобилей, высшее руковод­
ство избирает владельцев продуктов, обеспечивает им
поддержку и выступает в роли старшего партнера. Столь
тесное сотрудничество позволяет руководителям лучше
следить за ходом выполнения конкретных проектов и от-
казываться от бесперспективных на раннем этапе*.
Достаточные полномочия владельца продукта необ-
ходимы для руководства разработкой продукта. Владелец
продукта должен обладать полнотой власти для приня-
тия решений, касающихся любых аспектов  — подбора
подходящих членов команды, определения того, какая
функциональность будет входить в  тот или иной релиз,

* Личное сообщение Филиппа Мисслера, CTO компании mobile.de,


18 июня 2009 года.
36 Управление продуктом в Scrum

и  т.  д. Это человек, имеющий доступ к  бюджету и  спо-


собный создать рабочую среду, стимулирующую творче­
ский импульс и инновации. Он должен быть предан делу
разработки. Владелец продукта  — это уверенный в  себе
энергичный энтузиаст, достойный доверия.

Доступный и квалифицированный

Владелец продукта должен быть доступным и иметь нуж-


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

Владелец продукта в PatientKeeper


Джефф Сазерленд, один из  создателей Scrum
и  бывший технический директор компании Patient-
Keeper, ведущего производителя интегрированных
1. Кто такой владелец продукта? 37

информационных­ систем в  области здравоохране-


ния, разъясняет необходимую квалификацию и  пол-
номочия владельцев продукта в этой компании:
[Владелец продукта] должен быть экспертом
в своей отрасли, работать хотя бы пару дней в не-
делю как врач в  одной из  ведущих больниц Бос-
тона… техническим специалистом, уже написав-
шим несколько приложений… экспертом в анализе
пользовательских историй, сценариев использо-
вания и  программных спецификаций, особенно
в  области здравоохранения… уметь находить об-
щий язык с клиентами и отделом продаж, выяснять
требования и  набирать специалистов-медиков
для тестирования прототипов с  новой функцио-
нальностью… и при этом вести бизнес, заниматься
выручкой, отношениями с  клиентами и  специа-
листами по продажам в части, касающейся функ­
ционала, создавать пользовательские истории
и  все дополнительные спецификации продукта,
в  том числе анализировать ожидания клиента.
[Наши владельцы продукта] получают помощь
только от разработчиков и членов своей команды.
Первые два назначенных специалиста с  задачей
не  справились. Но  постоянное обучение, настав-
ничество и верно выбранный сотрудник дали нуж-
ные результаты*.

* Из письма Джеффа Сазерленда на рассылку scrum-тренеров Yahoo!


от 2 октября 2008 года и из личного сообщения Джеффа Сазерлен-
да от 16 декабря 2008 года.
38 Управление продуктом в Scrum

Работа с командой

Владелец продукта — это такой же член scrum-команды,


как и все остальные, он должен полагаться на сотрудни-
чество с  ней и  со scrum-мастером. Команда представля-
ет собой многофункциональную, самоорганизующую-
ся и  при этом небольшую группу специалистов. В  ней
должны быть представлены все роли, необходимые для
создания продукта. Члены scrum-команды работают в ат-
мосфере доверия и  сотрудничества, как равноправные
коллеги. Исключается разделение людей на  «мы и  они».
Должно присутствовать только понятие «мы».
Для создания атмосферы успешности в scrum-коман-
де сведите к минимуму изменения в ее составе в течение
релизов и  между ними. Чтобы группа людей преврати-
лась в сплоченную команду, потребуется время. Необхо-
димо создать тесно спаянный коллектив, члены которого
доверяют друг другу, эффективно работают вместе. Если
изменить состав команды, процесс построения начина-
ется заново и  в  результате снижаются продуктивность
и  самоорганизация. К  тому же нужно установить долго-
срочное партнерство между scrum-командой и ее продук-
том. Каждый продукт должен разрабатываться одной или
несколькими преданными ему командами. Это не только
облегчает обучение, но и упрощает распределение людей
и ресурсов.
1. Кто такой владелец продукта? 39

Поскольку владелец продукта, scrum-мастер и коман-


да должны постоянно и тесно сотрудничать, желательно
разместить всех членов scrum-команды в одном помеще-
нии. Рассмотрим пример mobile.de. То, что владельцы
продукта, scrum-мастер и  команда находились в  одном
помещении, повысило производительность и  боевой на-
строй команды*. Если владелец продукта не  имеет воз-
можности постоянно находиться вместе с  командой, он
должен регулярно встречаться с  ее членами. Владельцы
продукта, работающие удаленно, могут приходить в офис
и оставаться вместе с командой на протяжении несколь-
ких дней при каждом спринте. Если владельцы находятся
в  том же комплексе, но  располагаются далеко от  коман-
ды, я рекомендую им выполнять «правило одного часа»:
проводить как минимум час в день в помещении, где тру-
дится команда.
Атмосфера в помещении, где работает команда, долж-
на стимулировать творческий процесс, который включа-
ет взаимодействие и  ощущение радости от  работы, со-
держит ключевые маркеры информации (формулировку
концепции, наиболее приоритетные элементы бэклога
продукта, диаграмму архитектуры ПО, задания текуще-
го спринта, график хода релиза и спринта). Лучшие рабо-
чие помещения — те, где созданы условия для сочетания

* Личное сообщение Филиппа Мисслера, CTO компании mobile.de,


22 июня 2009 года.
40 Управление продуктом в Scrum

командной­ работы, личного пространства и  деятельнос-


ти небольших групп в комнатах отдыха.

Взаимодействие
со scrum‑мастером
Чтобы постоянно играть на  высшем уровне, спортивной
команде необходим тренер, а  scrum-команде  — scrum-
мастер*. Он оказывает поддержку владельцу продукта
и команде, защищает ее и процесс работы и при необхо-
димости вмешивается, чтобы удостовериться, справляет-
ся ли команда с задачей, сохраняет ли здоровую атмосфе-
ру и мотивацию и не создает ли технического долга**.
Роли владельца продукта и scrum-мастера дополняют
друг друга. Владелец продукта в первую очередь отвечает
за создание нужного продукта. Scrum-мастер в основном
несет ответственность за  то, «как» правильно использо-
вать практики Scrum. Эти два аспекта проиллюстриро-
ваны на  рисунке  1.1. Долгосрочный успех достигается,
когда правильный продукт создается правильными ме-
тодами.

* Например, у  профессиональных регбистов есть несколько тре-


неров: по  атакам, защите, схваткам, ударам, тренеры форвардов,
а также главный тренер.
** О техническом долге и оптимальном темпе работы подробно гово-
рится в главах 4 и 5.
1. Кто такой владелец продукта? 41

Правильный Быстрые, Продол-


продукт но недолго- жительный
вечные успехи успех

Неправильный Медленный Быстрый


продукт провал провал

Неправильно Правильно

Рисунок 1.1. Создание правильного продукта


правильными методами

Поскольку роли владельца продукта и scrum-мастера


призваны дополнять друг друга, выполнять их одному
человеку невозможно: это создает чрезмерную нагрузку.
Нельзя быть одновременно scrum-мастером и владельцем
продукта.

Работа с клиентами,
пользователями и другими
заинтересованными лицами
Клиент  — это тот, кто приобретает продукт, а  пользо-
ватель  — человек, применяющий продукт. Они опреде-
ляют его успех или неудачу. Продукт будет востребован
42 Управление продуктом в Scrum

на рынке­, только если достаточное количество клиентов


купят его, а  пользователи сочтут выгодным приобрете-
нием. Заметьте, что клиент и пользователь могут не сов-
падать, а  их потребности  — различаться. Рассмотрим
в качестве примера электронные таблицы. Пользователи
особенно ценят простоту их применения и высокую про-
изводительность. В свою очередь, компания, приобрета­
ющая продукт, заинтересована в разумной стоимости ис-
пользования и безопасности данных.
Для создания успешного продукта его владелец,
scrum-мастер и  команда призваны точно определить за-
просы клиента и  пользователя, а  также найти методы
наилучшего удовлетворения их потребностей. Для этого
нужно вовлечь в работу клиентов и пользователей на са-
мом раннем этапе.
Предоставляя клиентам отзывы о прототипах, пригла-
шая их представителей на  рабочие совещания во  время
спринтов, выпуская быстрые и частые релизы ПО, коман-
да сумеет многому научиться у клиентов. Продукт — это
всего лишь средство, конечная цель — помочь покупате-
лю и принести пользу компании-разработчику. Приведем
известное высказывание Теодора Левитта по этому пово-
ду: «Человеку, который покупает дрель, нужна не  сама
дрель, а  отверстия в  стене». Только сосредоточившись
на нуждах покупателя, можно разработать оптимальное
решение.
1. Кто такой владелец продукта? 43

Помимо клиентов и  пользователей производители


продукта должны привлекать и  других заинтересован-
ных лиц — например, представителей служб маркетинга,
продаж и клиентского обслуживания. Их с самого нача-
ла следует приглашать на  рабочие совещания во  время
спринтов. Эти встречи позволят заинтересованным ли-
цам увидеть, как создается продукт, наладить контакт
со  scrum-командой и  обменяться мнениями. Брайсон
(Bryson, 2004) предлагает обзор методов выявления за-
интересованных лиц, анализа их требований и  работы
с ними.

Менеджеры по продуктовому
маркетингу и менеджеры продукта
Некоторые компании разграничивают стратегиче­
ский и тактический продакт-менеджмент и выделяют
отдельные должности для каждого из них: менеджер
по продуктовому маркетингу и (технический) менед-
жер продукта. Деятельность менеджеров по продук-
товому маркетингу обычно направлена вовне: в  их
обязанности входит понимать рынок, управлять пла-
ном развития продукта и следить за общими дохода-
ми после релизов. А  менеджеры продукта смотрят
внутрь: их задача  — подробное описание функций,
расстановка приоритетов и сотрудничество с коман­
дой разработчиков. В  Scrum владелец продукта
совмещает все эти обязанности. По  стратегическим
вопросам управления продуктом владелец продукта
44 Управление продуктом в Scrum

может получить поддержку от  управляющего порт­


фелем, вице-президента и  даже CEO. Все зависит
от  размера компании и  важности проекта. Помощь
по ценообразованию и маркетинговым вопросам ему
окажут менеджер по продуктовому маркетингу и ру-
ководитель отдела продаж. С  точки зрения тактики
владелец продукта должен рассчитывать на  подде-
ржку scrum-мастера и своей команды. Объединение
обоих аспектов управления продуктом обеспечивает
сквозное руководство и общую ответственность. Мы
стараемся избегать появления лишних звеньев, необ-
ходимости ждать согласований и  отсрочек, а  также
проблем, связанных с  недопониманием одного ра-
ботника другим.

Вы, наверное, заметили, что не  упомянута роль


руководителя проекта в  scrum-команде. Причи-
на в  том, что обязанности по  управлению проектом
больше не  входят в  компетенцию одного человека.
Они распределены между членами scrum-команды.
Например, владелец продукта отвечает за  дату ре-
лиза, его объем, управление бюджетом, сообщения
о прогрессе и работу с заинтересованными лицами.
Команда определяет и оценивает задачи, а затем ра-
ботает над ними. Таким образом, роль руководителя
проекта становится избыточной. Это не  значит, что
люди, которые работают в  этой должности, больше
не  нужны. Очень часто они становятся успешными
scrum-мастерами. Встречались мне и  руководители
проекта, отлично выполнявшие роль владельца про-
дукта.
1. Кто такой владелец продукта? 45

Моделирование роли
владельца продукта
Прежде чем рассказать о методах работы владельца про-
дукта в  крупных scrum-проектах, хочу дать совет: избе-
гайте больших проектов! Начинайте с  малого и  быстро
разрабатывайте продукт с  минимальной функциональ-
ностью. Об этом пойдет речь в главе 2. Если приходится
заниматься крупным проектом, увеличивайте объемы
медленно. Пусть он растет естественным образом, при-
бавляя по  одной команде за  раз. Если работу начинает
слишком большое число людей, то проект может стать
чересчур сложным, так что последующие обновления по­
требуют массу времени и денег*.

Главный владелец продукта

В крупных scrum-проектах принимает участие несколь-


ко небольших команд. Каждой из них требуется владе-
лец продукта, но в одиночку он может заниматься лишь
ограниченным количеством команд. Сколько команд­

* Эта идея излагается в законе Конвея (Conway, 1968). Он гласит, что


структура организации, разрабатывающей продукт, часто влияет
на архитектуру самого продукта. Например, если в проекте участ-
вуют три команды, то архитектура нередко будет состоять из трех
основных подсистем.
46 Управление продуктом в Scrum

может­ быть доверено одному владельцу продукта без


сверхурочной работы и пренебрежения своими обязан-
ностями,  — зависит от  ряда факторов. Среди них но-
визна и  сложность продукта, а  также знание предмета
командами. Обычно владельцу продукта удается пло-
дотворно работать не  больше чем с  двумя командами.
Если их больше, то должны сотрудничать несколько
владельцев продукта. Возникает противоречие: вла-
делец продукта  — это один человек, но  для крупного
scrum-проекта их нужно несколько. Поэтому необхо-
димо назначить ответственного за  создание и  внед-
рение концепции продукта. Таким образом, вводится
иерархия сотрудничающих владельцев продукта, один
из  которых  — главный. Такая же система существует
в  ресторанах, где есть несколько шеф-поваров во главе
с главным шеф-поваром*.
Главный владелец продукта руководит остальны-
ми владельцами продукта. Он должен следить, чтобы
о потребностях постоянно информировались различные
команды, а  также за  оптимизацией прогресса проекта
в целом. В его задачи входит способствовать коллектив-
ному принятию решений, и  за  ним остается последнее

* Владелец продукта верхнего уровня не всегда именуется главным


владельцем продукта. Швабер использует термин владелец обще-
го продукта (Schwaber, 2007); Ларман и Водде называют главного
владельца продукта просто владельцем продукта (Larman & Vodde,
2009).
1. Кто такой владелец продукта? 47

слово, если компромисс не найден. Когда проект, начав-


шийся с  единственной команды, расширяется, первый
владелец продукта обычно становится его главным вла-
дельцем.

Иерархия владельцев продукта

Иерархия варьирует от  небольшой команды владельцев


продукта с  главным владельцем до  сложной структуры,
состоящей из нескольких уровней сотрудничающих вла-
дельцев продукта. Рассмотрим оба варианта, начав с наи­
более простого.
Организация проекта, изображенная на рисунке 1.2,
состоит из трех команд и трех владельцев продукта. Каж-
дый владелец продукта отвечает за свою команду. В свою
очередь, владельцы продукта тоже формируют команду,
и  владелец продукта  В выступает в  роли главного. Эта
иерар­х ия считается горизонтальной, несмотря на  нали-
чие главного владельца. Приведу пример, как можно при-
менить такую организацию проекта: клиент нанимает
коман­д у владельца продукта, отвечающую за веб-портал
и его приложения. Четыре владельца продукта и главный
владелец продукта тесно сотрудничают, при этом каждый
отвечает за конкретное предложение, а главный владелец
продукта — за весь продукт, включающий в себя все при-
ложения и портал.
48 Управление продуктом в Scrum

Команда владельцев продукта

Владелец Главный владелец Владелец


продукта А продукта и владелец продукта В
продукта Б

Команда А Команда Б Команда В

Рисунок 1.2. Простая иерархия владельцев продукта

На рисунке 1.3  представлен другой вариант, подхо-


дящий для больших scrum-проектов и  заимствованный
из книги Кена Швабера (Schwaber, 2007; 70–73).
Организация проекта, частично изображенная на ри-
сунке 1.3, состоит из четырех уровней и девяти владель-
цев продукта*. Каждый владелец продукта руководит
своими коллегами, располагающимися на  более низком
иерархическом уровне, и помогает им. Владелец продук-
та верхнего уровня является главным владельцем про-
дукта. Он отвечает за  всю разработку и  успех продукта.

* Кен Швабер (Schwaber, 2007; 71) предлагает каждому владельцу


продукта стать частью интегрированной scrum-команды, в  кото-
рую входят также scrum-мастер и команда. Каждая интегрирован-
ная scrum-команда поддерживает команды более низкого уровня.
Так, на рисунке 1.3 интегрированная scrum-команда «Игры» под-
держивает scrum-команды «Тетрис» и «Шахматы».
1. Кто такой владелец продукта? 49

В  данном­ случае владельцы продукта образуют непрос-


тую иерархию.

Главный владелец продукта


«Мобильный телефон»

Владелец про- Владелец про- Владелец про- Владелец


дукта «Развле- дукта «Комму- дукта «Фото продукта
чения» никации» и видео» «Органайзер­»

Владелец Владелец
продукта продукта
«МР3-плеер» «Игры»

Владелец Владелец
продукта продукта
«Тетрис» «Шахматы»

Рисунок 1.3. Сложная иерархия владельцев продукта

Сложная иерархия владельцев продукта предпо-


лагает специализацию деятельности каждого из  них.
50 Управление продуктом в Scrum

Главный­ владелец продукта возглавляет общую раз-


работку, координируя свою деятельность с  клиента-
ми и  другими заинтересованными лицами. Владельцы
продукта более низкого уровня сосредоточены на  сво-
их функциях или подсистемах и  тесно сотруднича-
ют с  коман­дами разработчиков. Швабер (Schwaber,
2007; 72) отмечает:

Владелец продукта планирует, расписывает, рас-


пределяет и  отслеживает работу со  своего уровня
вниз… Чем выше его уровень, тем сложнее работа.
Объем ответственности владельца продукта вы-
сшего уровня обычно предполагает, что им стано-
вится должностное лицо не  ниже вице-президента
или CEO.

Как правильно выбрать


владельцев продукта

Найти подходящего человека на  роль владельца про-


дукта непросто, даже когда нужен только один такой
кандидат. По  каким же критериям выбирать правиль-
ных владельцев продукта для больших проектов? Ответ
на этот вопрос дает понимание разных способов органи-
зации команд в большом проекте. Существует всего два
варианта: функциональные команды и  компонентные
1. Кто такой владелец продукта? 51

команды (Pichler, 2008; Larman and Vodde, 2009). Функ-


циональная команда внедряет сквозной набор требова-
ний — например, одну или несколько тем или функций.
В  результате появляется сквозной вертикальный срез,
который проходит через основные части программной
архитектуры. Компонентная команда выдает компонент
или подсистему­.
Эти два варианта ортогональны друг другу: функцио-
нальные команды организуются вокруг бэклога продук-
та, а компонентные — вокруг программной архитектуры.
У  обоих есть свои преимущества и  недостатки. Напри-
мер, компонентные команды обеспечивают целостность
архитектуры и  многократное использование кода. К  со-
жалению, они часто не могут воспользоваться бэклогом
продукта, оформленным в  виде пользовательских исто-
рий или сценариев использования, а  нуждаются в  де-
тально прописанных технических требованиях. Кроме
того, им приходится для создания обновления продукта
интегрировать результаты своей работы. Эти свойства
ведут к  непроизводительным издержкам. Напротив,
функциональные команды обычно могут работать па-
раллельно друг другу. У них меньше проблем с интегра-
цией, и им достаточно требований, указанных в обычном
списке. Однако обеспечение архитектурной целостности
и  многократное использование кода не  всегда возмож-
ны. Обычно организации применяют функциональные­
52 Управление продуктом в Scrum

команды­, а компонентные привлекают только при необ-


ходимости.
Поскольку владелец продукта компонентной команды
должен помогать переводить элементы бэклога продукта­
в  технические требования, то лучший кандидат на  эту
роль не  менеджер продукта, а  архитектор или старший
разработчик. Если проект состоит, например, из  трех
функциональных команд и  одной компонентной, то
на должности владельцев проекта стоит пригласить трех
менеджеров продукта и  одного архитектора. При этом
предполагается, что один из  владельцев продукта будет
главным владельцем продукта.

Распространенные ошибки
Введение роли владельца продукта для многих организа-
ций означает вход на новую для них территорию. И путь
к  эффективному использованию этой должности полон
опасностей и ловушек. Данный раздел поможет избежать
некоторых наиболее распространенных ошибок.

Владелец продукта с недостаточными


полномочиями

Проект, в котором владелец продукта не обладает доста-


точными полномочиями, похож на  автомобиль с  мало-
1. Кто такой владелец продукта? 53

мощным двигателем: он, конечно, едет, но с увеличением


скорости возникнут проблемы. Владельцу продукта с не-
достаточными полномочиями не хватает власти. Причин­
может быть несколько: ему мало внимания уделяет ру-
ководство, поддержка поступает не  с  того уровня или
не  от  того человека, руководитель не  до  конца доверяет
владельцу продукта или не может по каким-то причинам
делегировать ему полномочия по  принятию решений.
В  результате владелец продукта прикладывает для эф-
фективной работы — например, для объединения scrum-
команды, заинтересованных лиц и  клиентов или для
исключения требований из  релиза — слишком большие
усилия. Так, владелец продукта в проекте по разработке
одного нового продукта вынужден был при принятии
любого серьезного решения советоваться с  руководите-
лем бизнес-отдела. Неудивительно, что это приводило
к задержкам и подрывало веру команды в своего лидера.
Полномочия владельца продукта должны быть достаточ-
ными, к  тому же он должен пользоваться необходимой
поддержкой и доверием.

Перегруженность владельца продукта

Перегрузка на  работе пагубно отражается на  здоро-


вье и  моральном состоянии любого человека. А  пере-
груженные владельцы продукта часто оказываются
54 Управление продуктом в Scrum

слабым звеном, ограничивающим прогресс проекта.


Симптомы перегрузки владельца продукта  — это не-
достаточная работа над бэклогом продукта, пропуски
планирования спринтов или обзорных совещаний, не-
возможность задать им вопрос и  слишком длительное
время, требующееся для ответов. Перегруженные вла-
дельцы продукта не соответствуют идее agile-мани­феста
о  постоянном темпе. «Agile-процессы подразумевают
равномерное развитие. Заказчики, разработчики и поль-
зователи должны постоянно поддерживать один и тот же
темп» (Beck et al., 2001).
Перегруженность владельца продукта наступает
вследствие двух основных причин: нехватки времени
на  исполнение своих обязанностей и  недостатка подде-
ржки со  стороны команды. Доступность владельца про-
дукта оказывается под угрозой, если эта роль  — лишь
одна из  нескольких задач, которые он вынужден выпол-
нять, или если ему приходится следить за большим коли-
чеством продуктов и командами. Недостаток поддержки
со  стороны команды  — результат неправильного пони-
мания роли владельца продукта. Хотя он один, бо́ль­шая
часть его работы требует коллективного труда. Коман­
да и  scrum-мастер должны поддерживать владельца
продукта­.
Чтобы не  перегружать владельца продукта, по­
пробуйте для начала освободить этого человека от всех
1. Кто такой владелец продукта? 55

остальных обязанностей. Ведь он занимается постоян-


ной работой и  может отвечать только за  один продукт
и  одну команду. Кроме того, убедитесь, что команда
в  каждом спринте находит время для сотрудничества
с владельцем продукта. Scrum отводит для этого до 10%
действий команды (Schwaber, 2007). Такое сотрудни-
чество не  только позволяет более равномерно распре-
делить бремя нагрузки, но и дает возможность исполь-
зовать коллективное мышление и  творческий импульс
всей команды­.

Частичный владелец продукта

Некоторые организации распределяют роль истинного


владельца продукта между несколькими людьми  — на-
пример, менеджером продукта и  владельцем продукта.
Менеджер продукта занимается маркетингом и менедж-
ментом, создает концепцию, его деятельность направле-
на вовне, он контактирует с рынком. Владелец продукта
занимается внутренними вопросами, руководит сприн-
тами и  работает с  командой. В  подобном случае так на-
зываемый владелец продукта — это всего лишь техничес-
кий писатель. При данном подходе укрепляются прежние
барьеры, размываются ответственность и  полномочия,
появляются лишние звенья, задержки и другие неприят-
ности.
56 Управление продуктом в Scrum

Нужно не расщеплять роль владельца продукта, а пра-


вильно ее использовать. За тактические и стратегические
вопросы управления продуктом должен отвечать один че-
ловек. Это может потребовать перемен в организации —
например, адаптации служебных обязанностей и  путей
карьерного роста, увеличения спектра обязанностей от-
дельных сотрудников, о чем пойдет речь в главе 6.

Удаленный владелец продукта

Удаленный владелец продукта работает отдельно


от  коман­ды. Слово «удаленный», возможно, вызывает
представление, что владелец продукта находится на  од-
ном континенте, а команда — на другом. На самом деле
удаленность имеет самые разные формы и  степени. Так
называют и  ситуации, когда владелец продукта работа-
ет с командой в одном здании, но в разных помещениях,
и  случаи, когда они находятся на  разных континентах
и в различных часовых поясах (Simons, 2004). Проблемы,
связанные с  удаленными владельцами, повсюду одина-
ковы: недостаток доверия, недопонимание, отсутствие
единства и медленный темп работы. И причина понятна:
«Самый экономичный и  эффективный способ передачи
информации команде разработчиков — это личная бесе-
да» (Beck et al., 2001).
1. Кто такой владелец продукта? 57

Избегайте удаленных владельцев продукта, разме-


щайте всех членов scrum-команды рядом. Как уже гово-
рилось, компания mobile.de резко повысила производи-
тельность и  боевой настрой, когда владелец продукта,
scrum-мастер и команда стали работать в одном помеще-
нии. Если это невозможно, то владелец продукта должен
проводить как можно больше времени в том же помеще-
нии, что и остальная scrum-команда. Удаленным владель-
цам продукта нужно присутствовать хотя бы при пла-
нировании спринтов, на  обзорных и  ретроспективных
совещаниях. Переход от удаленного к присутствующему
владельцу продукта нередко требует времени. Иногда
это связано с  приемом на  работу и  обучением местного
владельца продукта. В некоторых случаях требуется даже
переосмысление стратегии продукта компании и измене-
ние места его производства.

Заместитель владельца продукта

Заместитель владельца продукта  — это человек, кото-


рый временно занимает место настоящего владельца.
Мне доводилось видеть, как работают заместители слиш-
ком загруженных, частичных или удаленных владельцев
продукта. Один вице-президент по  управлению продук-
том получил предложение занять должность владельца
58 Управление продуктом в Scrum

продукта­, критичного для развития бизнеса. Хотя он иде-


ально подходил для этой работы, ему с трудом удавалось
проводить достаточно времени с командой. В результате
бизнес-аналитику команды пришлось выступать в  роли
заместителя, когда настоящий владелец продукта не мог
присутствовать. Он делал бóльшую часть работы вла-
дельца, не  имея соответствующих полномочий. Сам же
владелец продукта принимал окончательные решения
о приоритетах в бэклоге продукта, при планировании ре-
лизов, приеме результатов работы. В  итоге увеличилось
количество конфликтов, решения принимались медлен-
нее, уменьшилась производительность и  упал команд-
ный дух.
Использование заместителя владельца продукта  —
это попытка искусственно вылечить системную пробле-
му. Вместо косметического ремонта организациям следу-
ет заняться причинами: например, освободить владельца
продукта от  других обязанностей, объединить его в  од-
ном помещении со scrum-мастером и командой или найти
нового владельца продукта.

Комитет владельцев продукта

Комитет владельцев продукта  — это группа владель-


цев продукта, в  которой никто персонально не  отвечает­
1. Кто такой владелец продукта? 59

за  общий­ продукт. Ни один из  них не  руководит этой


группой, не помогает выработать общую цель и принять
решение. Комитет владельцев продукта может выродить-
ся в бесконечные совещания по поводу конфликтующих
интересов и методов. Иногда это называют «смерть от ко-
митета». Никакого реального прогресса нет, сотрудники
перестают работать вместе и  начинают бороться друг
против друга. Поэтому обязательно нужен главный вла-
делец продукта, который руководит другими владель-
цами продукта, может помочь при принятии решений,
в  том числе по  вопросу приоритетов в  бэклоге продукта
и планированию релизов.

Вопросы для самоконтроля


Роль владельца продукта  — это краеугольный камень
успешного применения гибкого управления продуктом
в  Scrum. Времена одиноких менеджеров продукта, за-
пирающихся в  кабинете и  напрягающих мозги, чтобы
разработать идеальные требования, прошли. Владелец
продукта — это член scrum-команды, он готов к тесному
и постоянному сотрудничеству.
Следующие вопросы помогут успешно применить
роль владельца продукта.
60 Управление продуктом в Scrum

— Кто представляет клиентов и  пользователей в  ва-


шей компании?
—К
 то определяет и описывает потребности клиентов
и функциональность продукта?
—К
 то руководит выработкой концепции продукта
и  действиями по  претворению ее в  жизнь? Какую
роль играют командная работа и  совместное при-
нятие решений?
—Ч
 то потребуется для внедрения роли владельца
продукта в  той форме, которая описана в  данной
главе­?
2
Планирование
концепции продукта

В начале 1990‑х телефонные конференции были насто­


ящим испытанием. Участникам нередко приходилось от-
ворачиваться от стола и кричать в микрофон. Когда люди
говорили одновременно, их голосов не было слышно, так
что разговор напоминал какой-то гул. Компания Polycom
занималась телепрезентациями и  решениями по  пере­
даче видеокартинки, голоса и  контента. Там осознали,
что клиентам необходимы телефонные конференции, ко-
торые были бы больше похожи на личное общение, без ис-
кажений, эха и других помех. Поэтому Polycom заплани-
ровала концепцию продукта со следующими свойствами
(Lynn and Reilly, 2002; 63):
— Превосходное качество аудио, позволяющее гово-
рить нескольким людям одновременно без ущерба
для понимания.
62 Управление продуктом в Scrum

— Простота в использовании, без загадочных кнопок


и проводов.
— Привлекательный внешний вид, подходящий для
использования в конференц-зале руководства.
В итоге появился продукт под названием SoundStation,
который был запущен в 1992 году. Концепция стала важ-
ным фактором его успеха. В  этой главе рассказывается
о  методах планирования концепции продукта. Начнем
с содержания и свойств эффективной концепции.

Видение продукта
— Скажите, пожалуйста, куда мне отсюда идти?
— Это во многом зависит от того, куда ты хочешь
прийти, — ответил Кот.
— Да мне почти все равно, — начала Алиса.
— Тогда все равно, куда идти, — сказал Кот.
Льюис Кэрролл, «Алиса в Стране чудес»*

Способность представить себе то, как должен выглядеть


новый продукт или его новая версия, необходима для
того, чтобы куда-то прийти. Представления о  продукте
выливаются в видение — набросок будущего продукта**.

* Перевод Б. Заходера. Прим. перев.


** Хотя концепция продукта не  входит в  структуру Scrum, она упо-
минается у Швабера и Бидла (Schwaber and Beedle, 2002; 34). Кен
Швабер пишет: «Концепция описывает причины, по  которым за-
пускается проект, и его желаемый результат» (Schwaber, 2004; 68).
2. Планирование концепции продукта 63

Видение служит объединяющей целью, которая придает


энергию и направляет работу людей. В этой цели смысл
существования продукта. Как и в примере с Polycom, ви-
дение описывает продукт в самом общем виде, указывает
суть  — информацию, которая считается критичной для
разработки и запуска успешного продукта. Демонстрация
обновлений продукта клиентам и  пользователям на  об-
зорных совещаниях во время спринта и частые и быстрые
релизы ПО служат для подтверждения и уточнения кон-
цепции. Эффективное видение должно содержать ответы
на следующие вопросы:
— Кто будет покупать этот продукт? Кто его целевой
клиент? Кто будет использовать продукт? Кто его
целевые пользователи?
— Каким потребностям будет отвечать продукт? Ка-
кую ценность он создает?
— Какие свойства продукта жизненно необходимы
для удовлетворения избранных потребностей,
а  следовательно, и  для успеха продукта? Как
приблизительно продукт будет выглядеть и  ра-
ботать? В  каких аспектах он станет особенно
хорош­?
— Как он будет выглядеть на фоне других продуктов,
выпущенных конкурентами или самой компани-
ей? Каковы уникальные коммерческие аргументы
продукта? Какой станет его цена?
64 Управление продуктом в Scrum

— Как компания будет получать прибыль от  прода-


жи продукта? Каковы источники выручки за него
и как выглядит бизнес-модель?
— Осуществимо ли производство продукта? Сможет
ли компания его разработать и продавать?
Если вы планируете использовать новый продукт
как трамплин для изменения бизнес-модели, то эта
информация должна быть отражена в  концепции про­
дукта.
Возьмем в  качестве примера iPod и  iTunes компа-
нии Apple. Apple проложила дорогу к  доминированию
на цифровом музыкальном рынке, создав хороший про-
дукт, iPod, и  упаковав его в  отличную бизнес-модель.
Тесная интеграция iPod и iTunes, музыкального онлайн-
магазина компании, не только сделала удобной процесс
покупки музыки онлайн, но  и  замкнула покупателей
в  пространстве своих продуктов. Это позволило Apple
изменить правила игры  — продавать музыку онлайн
по сравнительно низким ценам. Доход компании от му-
зыки невелик, в отличие от огромной прибыли от прода-
жи MP3‑плееров.
Видение iPod должно было обязательно предусмат-
ривать безболезненную интеграцию с  iTunes, а  видение
iTunes — обращаться к бизнес-модели и дополнительной
выручке от продажи iPod.
2. Планирование концепции продукта 65

Желаемые качества видения


Видение должно кратко сообщать о  сути будущего про-
дукта и  описывать общую цель, которая дает направле-
ние для работы, но достаточно неопределенно, чтобы спо-
собствовать творчеству.

Общее и объединяющее

Все люди, связанные с  разработкой продукта, должны


разделять его видение: scrum-команда, руководство,
клиенты, пользователи и  другие заинтересованные
лица. Питер Сенге формулирует это так: «Концепция
действительно является общей, когда у нас с вами возни-
кает схожая картина и мы оба хотим, чтобы эта картина
возникала у  нас обоих, а не у каждого индивидуально»
(Senge, 2006; 192). Общее видение порождает единение
и  заряжает энергией всех, кто вовлечен в  процесс раз-
работки. Оно способствует эффективной командной
работе и облегчает обучение команды. «Когда люди дей­
ствительно разделяют одно видение, они связаны друг
с  другом общими надеждами» (Senge, 2006; 192). Если
же у  членов команды видение не  совпадает, они будут
двигаться в  разных направлениях, а  не  к  общей цели.
Отличный способ добиться общего видения — привлечь
66 Управление продуктом в Scrum

к  его разработке членов scrum-команды и  заинтересо-


ванных лиц.

Широкое и мотивирующее

Видение продукта должно в  общих чертах описывать


мотивирующую цель, которая будет направлять усилия
по  разработке, но  при этом оставит место для творчес-
тва, станет вдохновлять людей. Марисса Майер, вице-
­президент Google по  поисковым продуктам и  отноше-
ниям с  пользователями, описывает, как используется
продуктовое видение в Google:

Мы подбираем в  команду людей, которые действи-


тельно очень заинтересованы в  предмете. Считаю
полезным, что мы по-прежнему отказываемся от де-
тальных спецификаций продукта. Если вы пишете
документ объемом 70  страниц, в  котором подроб-
но рассказывается, какой продукт вы должны сде-
лать,  — вы убиваете творчество. А  так, например,
инженер приходит и  говорит: знаете, вы тут забыли
функцию, а я хочу ее добавить. Нельзя изгонять твор-
ческое начало из работы. Консенсусный подход, при
котором команда сообща вырабатывает концепцию
того, что они делают, и  оставляет достаточно про-
странства для творчества каждому члену команды,
2. Планирование концепции продукта 67

действительно­ способен вдохновлять и  нередко


приводит к наилучшим результатам*.

Нужно противостоять искушению перегружать про-


дукт деталями или спецификациями. Дополнительная
функциональность будет обнаружена и  отражена в  бэк-
логе продукта в ходе проекта.

Краткое и приятное

Если говорить о видении продукта, то оно должно быть


кратким и  сжатым, содержать только информацию, не-
обходимую для его успеха. Например, продукты-блок-
бастеры, как показало десятилетнее исследование Линна
и  Рейли, обладали всего шестью атрибутами (Lynn and
Reilly, 2002). Таким образом, видение продукта  — это
не  список функций и  оно не  должно содержать избы-
точные подробности. Специалист по  agile-управлению
проектами Джим Хайсмит поясняет: «Как оказалось,
описание пятнадцати-двадцати признаков или функ-
ций продукта  — задача довольно легкая. А  вот выбор
трех-­четырех из них, которые побудили бы человека этот

* “Inside Google’s New-Product Process”, BusinessWeek.com, June 30,


2006.
68 Управление продуктом в Scrum

продукт­ купить, — дело сложное­» (Highsmith, 2009; 97).


Специалист по  разработке продуктов Дональд Райнерт-
сен соглашается: «У  большинства успешных продуктов
есть четкое и  простое ценностное предложение. Поку-
патели обычно выбирают между конкурирующими про-
дуктами на  основе трех-четырех ключевых факторов»
(Reinertsen, 1997; 174–175).
Видение продукта обычно считается сжатым, если
может пройти лифтовый тест Мура. «Можете вы объяс­
нить, в  чем идея вашего продукта, за  то время, пока
едете в  лифте?» (Moore, 2006; 152). Если ответ отрица-
тельный, то видение, вероятно, слишком сложное или
запу­танное.

Минимально
функциональный продукт
Чтобы создать видение продукта, scrum-команда долж-
на заглянуть в  будущее и  сформулировать то, как, по  ее
мнению, будет выглядеть и  работать будущий продукт.
Конечно, для любого человека, не наделенного даром яс-
новидения, верное предсказание будущего  — дело чрез-
вычайно сложное. В конце концов, единственное, что мы
точно знаем о будущем, — это то, что оно неопределенное.
Не существует методики исследования рынка, способной
2. Планирование концепции продукта 69

выдавать абсолютно достоверные прогнозы. А полностью


безопасные инвестиции — это лишь иллюзия­. Так, Купер
утверждает, что вероятность неудачи для новых продук-
тов колеблется от 25 до 45% (Cooper, 2001; 10). В некоторых
исследованиях приводятся еще более высокие проценты.
Рынки развиваются самым неожиданным образом, реак-
цию клиентов предсказать трудно, что и  иллюстрирует
следующая история*.
Когда в 1999 году компания Expertcity выпустила ин-
терактивную систему технической поддержки, на  нее
возлагались большие надежды. Исследования рынка по-
казали, что новый продукт будет иметь большой успех.
К сожалению, продукт не оправдал ожиданий. Expertcity,
однако, отметила, что пользователи стали широко при-
менять одну из функций продукта — возможность поде-
литься экраном  — неожиданным образом. Они начали
с  ее помощью управлять удаленными компьютерами.
Компания тут же внесла изменения в продукт, превратив
его в средство удаленного контроля. Модифицированный
продукт получил название GoToMyPC. Он стал настолько­

* На  точность предсказания реакции рынка влияет его динамика


и  степень инновационности продукта. Для стабильных рынков
и  продуктов, переживающих постоянные или пошаговые инно-
вации, реакция рынка может быть просчитана довольно хорошо.
Для  других рынков и  продуктов это сложно или даже невозмож-
но  — например, в  случае прорывных инноваций. Кристенсен
(Christensen, 1997; 143) отмечает: «Нельзя анализировать рынки,
которые еще не существуют».
70 Управление продуктом в Scrum

успешен, что Citrix в  2003  году решила приобрести


Expertcity за  225  миллионов долларов. GoToMyPC сейчас
является частью пакета Citrix Online. Хотя исходное ви-
дение продукта Expertcity и оказалось неверным, способ-
ность компании к адаптации помогла ей превратить яв-
ный провал в неожиданный успех.
Поскольку наше умение предсказывать будущее ог-
раниченно, ориентируйтесь ради успеха на  минималь-
но функциональный продукт, имеющий небольшое ко-
личество функций, которые призваны удовлетворить
избранные потребности клиентов*. Вспомните iPhone,
выпущенный в  2007 году. Уникальное восприятие теле-
фона пользователем полностью затмило конкурентов.
Так был установлен новый стандарт для смартфонов.
Одним из  секретов успеха стал узкий набор потребнос-
тей клиента, которые были избраны Apple. Компания
избежала искушения попытаться разом удовлетворить
запросы многих потребителей, постаравшись скопиро-
вать все функции, которые предлагались конкурентами.
Вместо этого Apple решила по-новому взглянуть на  то,

* Термин «минимально функциональный продукт» отсылает нас


к работе Марка Денна и Джейн Клиленд-Хуан. В их книге Software
by Numbers (2004) предложен термин «минимальная коммерче­
ски ценная функциональность», который обозначает наименьшую
функциональность, способную все же создать ценность для поку-
пателя. Идея быстрого формирования небольшого набора функ-
ций и пошагового улучшения продукта восходит к методу эволю-
ционной разработки Тома Гилба (Gilb, 1988).
2. Планирование концепции продукта 71

как должны выглядеть смартфоны, и  сознательно отка-


залась от  некоторых функций. Первый iPhone поступил
в  продажу без множества функций, которые считались
к тому времени стандартом: копирования и вставки, воз-
можности отправлять текстовые сообщения нескольким
получателям и набора для разработки ПО. Однако эти ог-
раничения не сказались на общем успехе. Урезание функ-
циональности позволило Apple разработать и выпустить
продукт в конкурентоспособное время и дало компании
существенное преимущество над соперниками. Основы-
ваясь на успехе первой версии iPhone, Apple в 2008 году
запустила 3G-модель, расширив возможности телефо-
на как в  программном, так и  в  аппаратном отношении.
Она вышла и  на новый сегмент рынка, нацелившись
на бизнес-­к лиентов.
Сравните успех iPhone с  другим продуктом компа-
нии  — Apple Newton, вышедшим на  рынок в  1993  году
после пяти лет разработки. Помните объявления Apple,
которые обещали вам полноценный КПК, способный
делать самые невероятные вещи — например, распозна-
вать ваш почерк? Когда Newton наконец вышел на  ры-
нок, оказалось, что он чересчур громоздкий. Более того:
самая важная его функция  — распознавание почер-
ка — не работала должным образом. Продукт не оправ-
дал ожиданий, и  в  1998  году его выпуск прекратился.
Сейчас можно сказать, что планы Apple на Newton были
72 Управление продуктом в Scrum

чрезмерно амбициозными. Компания выпустила про-


дукт, который претендовал слишком на  многое, и  по-
терпела неудачу.
Создание минимального продукта дает ряд пре-
имуществ. Это отмечают Смит и Райнертсен (Smith and
Reinertsen, 1997) и  Денн и  Клиленд-Хуан (Denne and
Cleland-Huang, 2004)*. Продукт выходит быстрее, вре-
мя выхода на  рынок сокращается, функциональность
добавляется более своевременно. Снижается стоимость
разработки продукта и увеличивается скорость возвра-
та инвестиций. Быстрее можно выручить деньги за то-
вар, что ускоряет движение наличности, убыстряются
и  темпы обучения. Сократив время выхода на  рынок,
мы имеем возможность чаще воспринимать реакцию
рынка и  самостоятельно реагировать на  нее, а  не  пы-
таться ее предугадать. Быстрый выпуск минимально
функционального продукта снижает риски. Если про-
дукт оказывается неудачным и его приходится сразу же
отзывать с рынка, мы теряем меньше денег. Это позво-
ляет внедрить в стратегию возможность ошибки, таким
подходом активно пользуется Google. Марисса Майер
из  Google объясняет: «Мы понимаем, что многие про-
дукты придется просто выбросить, но  помнить будут­

* Смит и  Райнертсен (Smith and Reinertsen, 1997) называют метод


разбиения инновации на более мелкие и быстрые этапы пошаговой
инновацией.
2. Планирование концепции продукта 73

только значимые­ продукты, обладающие большим


пользовательским потенциалом»*.
Поскольку будущее неопределенно, концепция долж-
на распространяться только на следующую версию про-
дукта. Даже если долгосрочной мечтой Стива Джобса
было доминирование на  рынке мобильных телефонов,
это определенно не являлось целью первого iPhone. Боль-
шие амбиции лучше всего реализовывать пошагово. «Ва-
жен только один шаг — следующий» (Gilb, 1988; 97). Как
только появляется концепция, она превращается в  го-
товый продукт благодаря использованию пользователь-
ских и клиентских отзывов. Их собирают по результатам
демонстрации новых версий продукта на  обзорных со-
вещаниях во время спринтов, а также быстрых и частых
релизов продукта. Подобный метод работы позволяет
scrum-команде сразу же определить, действительно ли
они производят нужный продукт. Если же нет, то виде-
ние, вероятно, сформировано неверно, так что следует
внести коррективы.
Заметьте, что видение продукта может воплощать-
ся более чем в  одном релизе. Например, запуску первой

* “So Much Fanfare, So Few Hits”, BusinessWeek.com, July 10, 2006. По-
добный же подход отражен в  знаменитом изречении Арта Фрая
из 3М: «Чтобы найти принца, придется перецеловать много лягу-
шек». Заметьте, что прекрасный принц заплатит за  всех этих ля-
гушек. (Имеется в  виду сказка братьев Гримм «Принц-лягушка».
Прим. ред.)
74 Управление продуктом в Scrum

версии­ Google Chrome в  декабре 2008  года предшество-


вало множество непубличных релизов и публичная бета-
версия в сентябре 2008 года. Более долгосрочный взгляд
на  рост продукта можно воплотить в  плане развития,
о котором говорится ниже.

Простота
Простота облегчает создание удобного в  использовании
продукта с  минимальной функциональностью. Не  сто-
ит путать простоту с  упрощенностью. Еще Леонардо
да Винчи говорил: «Простота — это высшая степень слож­
ности».

Бритва Оккама

Простота как руководящий принцип — это давняя тради-


ция. Еще в  XIV  веке францисканский монах Уильям Ок-
кам, как считается, заявил, что при выборе между функ-
ционально эквивалентными решениями следует отдавать
предпочтение более простому (Lidwell, Holden, and Butler,
2003; 142). Эта идея известна как бритва Оккама.
Простота — это не только эстетика продукта. Это кон-
центрация на  его сути, когда создается только действи-
тельно необходимое и  есть возможность быстро и  легко
2. Планирование концепции продукта 75

изменять и расширять продукт. Простые, но адекватные


продукты удобны в  использовании  — например, Apple
или iPod. Основанный на  колесе прокрутки и  кнопках
на нем, iPod прост и минималистичен, но предлагает все
необходимые функции. Бек и  Эндрес пишут: «Проекты,
тяготеющие к  простоте, идут на  пользу и  человечеству,
и производительности» (Beck and Andres, 2005; 110).

Чем меньше, тем лучше

Здравый смысл предполагает: для выигрыша в конкурент­


ной борьбе требуется создать лучший и  более функцио­
нальный продукт. Мы часто полагаем, что чем больше
функций у продукта, тем он лучше и привлекательнее для
покупателей. Вовсе нет, утверждает 37Signals (37Signals,
2006), создающая удобные в  использовании веб-прило-
жения, удостоенные многочисленных призов. Компания
при разработке продуктов руководствуется принципом
простоты и сосредоточивается на их сути.

Чтобы опередить конкурентов, делайте меньше, чем


они… Возьмите свое видение продукта и  уменьши-
те его наполовину… Начните с экономичного умного
приложения и  дайте ему набрать обороты. На  пост-
роенном таким образом надежном основании можно
делать что угодно.
76 Управление продуктом в Scrum

Джон Маэда, специалист по простоте решений и про-


фессор Массачусетского технологического института, со-
гласен с этими положениями: «Легче всего достичь про-
стоты при помощи обдуманного исключения. Если вы
сомневаетесь в функции, исключите ее» (Maeda, 2006; 1).
Стиву Джобсу приписывают фразу: «Инновации  — это
не значит всегда и всему говорить “да”. Это значит гово-
рить “нет” всему, кроме самых важных функций». Agile-
манифест разделяет эту точку зрения, называя простоту
одним из  12  принципов и  определяя ее как «искусство
увеличения работы, которую вы не  делаете» (Beck et  al.,
2001). Каждый раз, когда у  вас появляется идея новой
функции или вы обнаруживаете новое требование, задай-
те себе вопрос, насколько эта функциональность значима
для успеха продукта. Если она не критична — откажитесь
от идеи. В результате получается простой и лаконичный
продукт, который предлагает только те функции, кото-
рые действительно нужны клиенту или пользователю.

Простые пользовательские интерфейсы

Google  — компания, которая открыто взяла на  воору-


жение принцип простоты как ключевой при взаимодей­
ствии с пользователем. «Google не ставит целью создавать
продукты с  богатой функциональностью: наши лучшие
продукты содержат только те функции, которые нужны
2. Планирование концепции продукта 77

людям для достижения своих целей. В  идеале даже те


продукты, которые требуют большого количества функ-
ций и сложного дизайна, должны быть столь же просты,
сколь и  эффективны… Мы стараемся не  просто добав-
лять новые функции, но  и  развивать продукты в  других
направлениях»*. Разработка простых пользовательских
интерфейсов, по утверждению Лидуэлла, Холдена и Бат-
лера, прекрасно оправдала себя в  Google: «В  то  время
как другие интернет-поисковики стремились добавлять
на свои сайты рекламные сервисы и применимые для кон-
кретных случаев функции, Google придерживалась свое-
го простого и эффективного дизайна. Результат — самый
производительный и  удобный в  использовании поиско-
вик в сети» (Lidwell, Holden, and Butler, 2003; 143). А Бер-
нар Жирар, автор книги The Google Way (Girard, 2009; 34),
считает, что именно благодаря простоте AdWords — рек-
ламная программа Google — стала такой успешной.

Подобно интуитивному Macintosh GUI, благодаря


которому продукты Apple выглядят такими друже-
любными и удобными в использовании, дизайн и на-
правленность на пользователя интерфейса AdWords
от  Google помогли ему победить. Любой рекламо-
датель сразу же понимает, как разместить объяв­
ление…

* “Ten principles that contribute to a Google user experience”.


www.google.com/corporate/ux.html.
78 Управление продуктом в Scrum

Потребности покупателя
и свойства продукта
Потребности покупателя и  свойства продукта лежат
в  основе любой концепции и  заслуживают самого при-
стального внимания. От  выбора важнейших потребнос-
тей покупателя зависит то, к  какому рынку или его сег-
менту мы собираемся обращаться. Сосредоточившись
на  по­т ребностях, мы рассматриваем продукт как средс-
тво достижения цели  — удовлетворения нужд клиента
или пользователя. В  то же время свойства продукта  —
критически важные параметры, которыми должен об-
ладать продукт для удовлетворения этих потребностей.
Например, сенсорный экран  — это свойство продукта.
Вероятно, потребность, обусловившая это свойство,  —
простота в  использовании. Свойства могут быть как
функ­циональными, так и нефункциональными. Функци-
ональные свойства — это конкретные функции или черты
продукта, например способность совершать и принимать
звонки. Нефункциональные свойства  — это производи-
тельность, выносливость, стиль, дизайн и удобство в ис-
пользовании. Нефункциональные атрибуты могут стать
важным дифференцирующим фактором  — воздейство-
вать на  пользовательский опыт, а  также на  расширяе-
мость продукта и  удобство его эксплуатации, которые,
2. Планирование концепции продукта 79

в  свою очередь, влияют на  общую стоимость владения


продуктом и его срок службы.
Свойства помогают команде двигаться вперед, огра-
ничивая пространство решений  — набор всех возмож-
ных вариантов. Декларируя потребности пользователя
и  детализируя минимальный набор свойств продукта,
мы связываем потребности с техническими решениями,
помещая клиента в центр наших усилий по разработке.
Разделение потребностей и  свойств позволяет исследо-
вать, почему возникла нужда в  продукте и  как он дол-
жен выглядеть и  работать. Возможно изучение разных
свойств с  целью установить наиболее подходящие. На-
пример, сенсорный экран  — это один из  способов обес-
печить удобство использования. Другие, более дешевые
альтернативы — это несколько больших кнопок или го-
лосовой контроль.
Определив свойства продукта, часто бывает полезно
расположить их в порядке приоритетности: свойства, ко-
торые удовлетворяют несколько потребностей, важнее
и  должны иметь более высокий приоритет. Расстанов-
ка приоритетов особенно помогает в  случае конфликта
свойств.
Рассмотрим два свойства  — сочетаемость с  другим
оборудованием и  удобство в  эксплуатации. Способ-
ность взаимодействовать с  разнообразными системами
80 Управление продуктом в Scrum

и  устройствами­ обычно требует определенного уровня


архитектурной сложности. Удобство в эксплуатации, на-
против, предполагает использование простой открытой
архитектуры. В  результате появляется напряжение: вла-
делец продукта, scrum-мастер и команда вынуждены при-
лагать усилия, чтобы примирить непримиримое и найти
наилучшее решение для удовлетворения потребностей
покупателя. Алистер Кокберн (Cockburn, 2005; 147) пред-
лагает при расстановке приоритетов для свойств продук-
та руководствоваться следующими факторами:
— Пожертвовать остальными ради этого.
— Попытаться сохранить.
— Пожертвовать этим ради остального.
Так, чтобы поставить удобство в эксплуатации выше
сочетаемости с  другим оборудованием, мы должны по-
жертвовать остальными свойствами ради удобства
в  эксплуатации. В  то же время мы должны попытаться
сохранить сочетаемость.
Полезное, простое и дешевое решение для записи по­
требностей и  свойств  — это набор бумажных карточек.
Карточки способствуют командной работе, на них легко
писать и  делать дополнения. Их можно группировать,
вешать на стенку и перемещать. Когда работа по форми-
рованию концепции закончена, мы можем наклеить кар-
точки на перекидную доску, повесить ее в рабочем поме-
щении и скопировать данные на вики-ресурс проекта.
2. Планирование концепции продукта 81

Рождение видения продукта


Первые дни жизни любого продукта окружены легенда-
ми и  мифами, не  существует четкой формулы порожде-
ния идей и развития их в видение. В данном разделе рас-
сказывается о  двух подходах к  формированию видения
нового продукта — это любимые проекты и Scrum. В лю-
бом случае концептуальная работа должна быть сведена
к минимуму — важно быстро выпустить первый вариант
продукта или демоверсию для клиентов и пользователей.
Прислушайтесь к  рецензиям, и  поймете, на  правильном
ли вы пути. Затем внесите изменения. Воздержитесь
от  излишних процедур и  мер контроля на  концептуаль-
ном этапе  — они сдерживают творчество и  инновации.
Вместо того чтобы придумывать инновации, ваши со-
трудники тратят время на заполнение бумажек.

Любимые проекты

В таких компаниях, как Google, разработчикам разреша-


ется тратить до 20% времени на «любимые проекты». Это
проекты, связанные с частными исследованиями, которые
приводят к новым идеям, реализуемым в прототипах. Ре-
зультаты оправдывают вложения Google: большая часть
всех продуктов, выпущенных за вторую половину 2005 го­
да, начиналась как «любимый проект» (Mayer,  2006).
82 Управление продуктом в Scrum

Разработчики­, выдвинувшие исходную идею, продолжа-


ют работать над проектом претворения ее в  жизнь, как
это было в случае с браузером Google Chrome. Бен Гуджер
и  Дарин Фишер, два инженера, предложивших прототип,
сыграли важную роль в проекте разработки Chrome (Levy,
2008)*. Кен Швабер (Schwaber, 2007; 80) приводит такие ар-
гументы в пользу этого подхода к развитию новых идей:

Я рекомендую отвести часть времени каждого со-


трудника на  деятельность, не  имеющую отношения
к  scrum-командам, в  которых он состоит на  данный
момент, но идущую на благо предприятия. Я советую
использовать на это примерно 20% их времени. Пусть
они соединяются в группы по интересам и работают
вместе. Какое-то время займет работа с  коллегами
по  поддержанию и  расширению функциональных
знаний, а какое-то — поиск и разработка прототипов
новых идей. Так были разработаны желтые клейкие
стикеры в 3M и почта Gmail в Google.

Использование Scrum

Если для разработки концепции необходимы более серь-


езные усилия, используйте для этого Scrum. Попросите
владельца продукта, scrum-мастера и  команду провести­

* Проект браузера Google возглавлял менеджер продукта Брайан


Раковски­(Levy, 2008).
2. Планирование концепции продукта 83

мероприятия по  выработке продуктового видения, воз-


главлять которые должен владелец продукта. Сначала
в бэклоге продукта будет фигурировать самое общее ви-
дение итогового продукта — например, «Доступны прото-
типы, исследующие варианты дизайна пользовательского
интерфейса» или «Проводятся собеседования с  клиента-
ми». В  процессе работы в  бэклоге продукта появляются
высокоуровневые свойства, описывающие будущий про-
дукт в  соответствии с  продуктовым видением. Каждый
визионерский спринт будет порождать обновление — шаг
навстречу видению продукта, что в итоге вырастет в ито-
говый продукт. (Если понадобится только один визио-
нерский спринт, то концепция продукта создается по его
результатам.) Например, Supermassive Games — британс-
кая студия по  разработке компьютерных игр  — исполь-
зует визионерские спринты для организации работы
на  раннем этапе, который часто именуется «предпроиз-
водством». Команда создает наброски и  прото­типы для
дальнейших итераций на  пути к  общей концепции ком-
пьютерной игры. Прототипы могут быть как моделями
Lego и набросками на бумаге, так и действу­ющими про-
граммами*.
Scrum-команда, вырабатывавшая видение продук-
та, должна в том же составе, за некоторыми ощутимыми

* Личные сообщения Харви Уитона, CEO Supermassive Games, 21 ок-


тября и 2 ноября 2009 года.
84 Управление продуктом в Scrum

исключениями­, проводить и разработку. В некоторых слу-


чаях команда может привлечь внешних специалистов —
например, дизайнера пользовательского интерфейса или
представителя службы поддержки — в команду, занима­
ющуюся визионерскими спринтами. После формирова-
ния видения специалист может покинуть команду, стано-
вясь просто заинтересованным лицом.

Техники формирования видения


В этом разделе приводится обзор техник, которые могут
оказаться полезными при формировании видения про-
дукта. Обзор не претендует на всеохватность и глубокое
описание методов. Он призван снабдить вас достаточным
количеством информации, чтобы можно было судить, на-
сколько эти техники применимы к вашему проекту. Здесь
рассматриваются прототипирование и  макетирование,
персоны и сценарии, варианты использования и пользо-
вательские истории, последовательности и раскадровки,
визуализации и обзоры, а также модель Кано.

Прототипирование и макетирование

В начале нового проекта мы часто не имеем представле-


ния о том, чего именно не знаем. Более того, наша целевая
2. Планирование концепции продукта 85

группа покупателей и основные пользователи находятся


в таком же положении, поэтому не могут сразу объяснить,
как должен выглядеть и работать наш продукт. Таким об-
разом, формирование видения лучше всего понимать как
процесс открытия, обретения знания и  обучения, кото-
рое требует экспериментов. В экспериментах исследуют-
ся причинно-следственные взаимоотношения, когда про-
цесс манипулирования причиной идет до  тех пор, пока
не будет получено желаемое следствие. Это одновременно
и поощрение открытого, исследовательского, живого ума,
и  следование строгим процедурам. Ключ к  эффективно-
му эксперименту состоит в быстром получении необходи-
мого знания посредством внедрения и тестирования про-
тотипов и макетов, которые служат средствами создания
знания и обучения. Они помогают понять, как должен вы-
глядеть и работать продукт, какая технология и архитек-
тура будут для него наиболее успешны, насколько вообще
осуществима идея. Прототипы — это обычно расходные
материалы, создаваемые быстро и  дешево. Порой даже
бумажных прототипов и  набросков достаточно для тес-
тирования идеи. Исполняемые прототипы, исследующие
конкретный вопрос, иногда называются спайками.
В одном телекоммуникационном проекте были пос-
тавлены довольно амбициозные требования по удобству
использования. Исследование рынка показало, что про-
дукты компании воспринимаются как менее удобные для
86 Управление продуктом в Scrum

пользователя, чем у  конкурентов. Поэтому команда по­


строила прототип, состоящий из макета устройства и од-
норазовой реализации самых важных элементов пользо-
вательского интерфейса на  Flash. Клиентов пригласили
протестировать прототип, и их отзывы сильно повлияли
на итоговый дизайн. В результате получился новый про-
дукт с прекрасным клиентским интерфейсом.

Планирование, выполнение,
проверка и воздействие
Организованный эксперимент проходит по четырех-
шаговой модели, известной также как цикл Деминга.
Сначала мы вырабатываем гипотезу (планирование).
Затем воплощаем ее (выполнение) и  анализируем
результаты (проверка). Если эксперимент оказал-
ся неудачным, мы вносим в  гипотезу изменения, где
необходимо, и  проводим следующий эксперимент  —
либо для достижения лучшего результата, либо что-
бы попробовать другой подход (воздействие). Томас
Эдисон, создатель первой коммерчески успешной
электрической лампочки, знал о неизбежности проб
и ошибок — необходимости многократно ошибиться,
чтобы воплотить в  жизнь полноценный продукт. Хо-
рошо известна его фраза:
«Если я обнаружил десять тысяч методов, кото-
рые не работают, это не ошибка. Я не обескуражен,
потому что исключение каждого неверного метода —
это шаг вперед».
2. Планирование концепции продукта 87

Персоны и сценарии

Персоны помогают нам выбрать целевых потребителей.


Сценарии позволяют понять, как продукт изменяет их
жизнь (Cooper, 1999). Персона — это «гипотетический архе-
тип», представляющий целевого клиента или пользовате­
ля.  Можно считать персону частным случаем носителя
пользовательского сценария или пользовательской роли.
В  их описания включается информация, важная для ис-
пользования продукта потребителями: например, долж-
ностные обязанности, навыки или интересы пользователя­.
Сформировав корректно персоны, мы можем иссле-
довать то, как продукт, который мы собираемся разра-
батывать, будет влиять на  их жизнь. Для этого создаем
сценарии, которые описывают, как персона достигает
своих целей без продукта и с ним. Формальный способ со-
здания таких сценариев — составление карты потребле-
ния: одна ее часть описывает деятельность, необходимую
для достижения конкретной цели без нашего продукта,
другая — деятельность, которая потребуется в будущем,
когда продукт будет доступен (Womack and Jones, 2005).
Использование сценариев и карт потребления позволяет
установить ценностное предложение продукта: необхо-
димы ли выбранные свойства? Создают ли они преиму-
щества для всех персон? Можно ли определить более важ-
ные свойства продукта?
88 Управление продуктом в Scrum

Визуализация и обзор
в отраслевом журнале

Два эффективных метода определения ценностных


и  коммерческих аргументов продукта  — это его визу-
ализация и  обзор в  отраслевом журнале. Визуализа-
ция — это макет упаковки, в которой может поставлять-
ся продукт. Для создания визуализации scrum-команда
придумывает название продукта, его графическое отоб-
ражение и  три важнейших коммерческих аргумента,
при помощи которых продукт будет продаваться. Ин-
формация размещается на  передней части упаковки.
На  оборотной части можно указать дополнительные
подробности (Highsmith, 2009; 96–97). Чтобы написать
обзор в отраслевом журнале, члены scrum-команды вы-
ясняют, что бы они хотели прочитать о продукте после
его запуска (Cohn, 2009; 232). Это упражнение сделать
быстро и легко. Его также можно использовать для про-
верки того, все ли одинаково понимают и  разделяют
концепцию продукта.

Модель Кано

Модель Кано помогает выбрать нужную функцио-


нальность для создания привлекательного продукта
(Kano, 1984). Она рассказывает, насколько может быть
2. Планирование концепции продукта 89

удовлетворен­ покупатель при внедрении определенно-


го свойства продукта. В модели разграничиваются три
типа функций: основные, производительные и привле-
кательные. Рассмотрим работу модели Кано на примере
мобильного телефона. Основные функции мобильного
телефона  — это его включение и  выключение, совер-
шение и прием звонков, создание, отправка, получение
и  чтение текстовых сообщений. Эти рудиментарные
функции необходимы, чтобы продать продукт, но удов-
летворенность покупателя ими быстро исчерпывается.
Например, если добавить еще одну кнопку для вклю-
чения и выключения телефона, это не создаст никакой
дополнительной ценности. Невозможность обеспечить
основные функции обычно делает продукт бесполез-
ным. Производительные функции, как правило, приво-
дят к прогрессивному повышению удовлетворения. Они
следуют принципу «чем больше, тем лучше». Например,
чем легче телефон и чем быстрее он включается, тем бо-
лее удовлетворенными, вероятнее всего, будут клиенты.
Они не могут насытиться требованиями производитель-
ности. Однако производительных функций недоста-
точно, чтобы продукт существенно отличался от  всего
остального на  рынке. Привлекательные функции, как
свидетельствует название, призваны привлекать и вос-
хищать покупателей. Интересный дизайн продукта
и  способность индивидуализировать телефон­  — это
90 Управление продуктом в Scrum

примеры привлекательных функций. Они могут удов-


летворять скрытые потребности клиентов, о которых те
могли и не догадываться. Именно эти функции продук-
та создают конкурентное преимущество и  уникальное
коммерческое предложение.
Проблема в том, что нужно сочетать основные, про-
изводительные и  привлекательные функции таким
образом, чтобы желаемые преимущества были макси-
мальными. Полезно бывает применить модель Кано
к  продуктовому видению или бэклогу продукта. Как
и  в  случае видения продукта SoundStation, с  которого
мы начали эту главу, продуктовое видение часто сосре-
доточивается на производительных и привлекательных
функциях и  редко включает основные, которые можно
найти в  бэклоге продукта. Заметьте, что модель Кано
способна делать интересное предсказание: со временем
привлекательные функции превращаются в производи-
тельные, а  производительные становятся основными.
Когда конкуренты начинают поставлять схожие продук-
ты, ваши продукты теряют свои преимущества. Чтобы
остаться лидерами, компаниям нужно регулярно обнов-
лять свой продукт, предлагая новые привлекательные
функции. Эта корреляция  — еще одна причина того,
чтобы быстро запустить исходный продукт и затем регу-
лярно его обновлять.
2. Планирование концепции продукта 91

Формирование видения
и дорожная карта продукта
До сих пор в  этой главе рассматривались вопросы со-
здания видения нового продукта, что особенно сложно.
По мере «взросления» продукта и выхода пошаговых об-
новлений визионерская деятельность обычно сокраща-
ется. Но  новым версиям продукта все еще нужны цели.
План развития продукта позволяет scrum-команде сфор-
мулировать цели будущих версий продукта. Пока виде-
ние заключается в  создании и  корректировке дорожной
карты продукта.
Дорожная карта продукта — это тип плана, который
показывает, как продукт должен развиваться в своих вер-
сиях, и облегчает диалог между scrum-командой и заин-
тересованными лицами. Дорожная карта продукта позво-
ляет организациям координировать разработку и запуск
смежных продуктов — например, линейки продуктов или
продуктового портфеля. Рекомендуется не  усложнять
план развития продукта, а  сосредоточиться на  самой
сути. План развития продукта должен содержать пример-
ную дату выхода следующей версии, указание целевых
потребителей и  их нужд и  три-пять основных функций.
Не  беспокойтесь о  деталях. Они появятся и  будут отра-
жены в бэклоге продукта. Заметьте, что дорожная карта
92 Управление продуктом в Scrum

продукта никогда не заменит тщательного анализа реак-


ции рынка и соответствующей корректировки продукта.
Он просто утверждает, как, по нашему мнению, продукт
должен развиваться на основе текущего понимания рын-
ка. Дорожные карты продукта  — это живые документы,
они эволюционируют.
Составьте дорожную карту сразу после того, как про-
дукт был успешно представлен на  рынке. (Появление
пятилетнего плана прежде, чем вышел релиз продукта,
имеет мало смысла. Такой план скорее отражает мечту,
чем предсказывает реальность.) В  составлении долж-
ны принимать участие все важные для продукта лица.
К  ним относятся scrum-команда, ответственный за  про-
дуктовый портфель, представители команд разработки
других продуктов и  заинтересованные лица. Убедитесь,
что дорожная карта продукта имеет реалистичные сроки.
В зависимости от рынка и стадии жизненного цикла про-
дукта ограничьтесь 6–12 месяцами и не пытайтесь делать
прогнозы на следующие два-три года.

Минимальные продукты
и варианты продукта
В процессе взросления продукт начинает отвечать все
большему числу потребностей покупателей: обслуживает
потребителей в разных сегментах и регионах. Поскольку­
2. Планирование концепции продукта 93

запросы становятся многочисленнее и  разнообразнее,


услож­н яется выпуск обновлений продукта с  минималь-
ной функциональностью. Требуется все больше функций
для поддержки постоянно растущего количества клиентов
и пользователей. Чтобы решить проблему, мы применяем
варианты продукта. Каждый вариант адресован конкрет-
ной группе пользователей и  сегменту рынка. Приведем
в  качестве примера популярную программу Visio для со-
здания диаграмм. Версия 2007 года доступна в двух вари-
антах: Office Visio Standard 2007 и Office Visio Professional
2007. Первый позиционируется как «базовое средство
визуализации», а профессиональная версия является рас-
ширением Visio Standard 2007  и  призвана «помочь биз-
нес- и IT-пользователям визуализировать, анализировать
и представлять комплексную информацию, сложные сис-
темы и процессы». Эти два варианта обслуживают различ-
ные сегменты рынка — домашних и коммерческих поль-
зователей с  ограниченной потребностью в  диаграммах
и  профессиональных пользователей, нуждающихся в  до-
полнительной диаграммной функциональности.
Хотя варианты продукта могут стать могущественны-
ми союзниками, слишком большое их количество ведет
к разбуханию продуктового портфеля, высокой стоимос-
ти поддержки и перегруженности клиентов. Представьте
себе, что было бы, если бы Microsoft предлагала четыре
версии Office Visio 2007: Essentials, Standard, Professional
94 Управление продуктом в Scrum

и Deluxe. Потребители затруднились бы с выбором, и им


было бы непросто принять решение о покупке*.
Есть и еще один недостаток: варианты продукта опас-
ны тем, что функциональность придется внедрять снова
и снова, что приведет к высоким издержкам на разработ-
ку и  техническую поддержку. Решить эту проблему мо-
жет создание набора шаблонов, общих для всех вариан-
тов. Эти шаблоны называются платформой. Например,
Apple использует общие компоненты для iPhone и  iPod
touch. Однако, осознав необходимость введения общих
компонентов, не  следует попадаться в  ловушку  — наде-
яться на создание идеальной мегаплатформы. Начинайте
с  малого. Платформа должна расти естественным путем
по мере увеличения необходимости в вариантах продук-
та. Тщательно сохраняйте ее функциональность. Этот
подход, возможно, приведет к  рефакторингу архитекту-
ры, но он исключает опасность чрезмерного усложнения
платформы.

Распространенные ошибки
Выработка продуктового видения  — это необходимый
шаг в  подготовке его к  запуску. Берегитесь следующих

* Кстати, Microsoft в  конце 1990‑х годов предлагала три варианта


Visio  — Standard, Pro и  Tech. Затем компания решила упростить
свой портфель.
2. Планирование концепции продукта 95

распространенных ошибок: отсутствия видения, про-


роческого видения, аналитического паралича, а  также
девизов «мы-лучше-знаем-что-нужно-клиентам» и «боль-
шое — значит хорошее».

Отсутствие видения

Очевидная, но, увы, распространенная ошибка — начать


разработку продукта без какого-либо видения. Это чаще
всего бывает, когда клиенты требуют внедрения в продукт
отдельных функций, не  понимая необходимости связи
между ними. Получающийся при этом продукт носит на-
звание функциональной сборной солянки (DeMarco  et  al.,
2008; 143–145). Избегайте этого: убедитесь, что вы име-
ете концепцию, четко указывающую на клиента, его из-
бранные потребности и  важнейшие свойства продукта.
Эта концепция затем позволит определить, какие функ-
ции следует внедрить, и поможет создать полезный и цен-
ный продукт.

Пророческое видение

Несмотря на  то что продуктовое видение рисует карти-


ну будущего продукта, это предсказанное будущее мо-
жет никогда не  наступить. Переработка видения в  про-
дукт — это предпринимательская деятельность, которая
96 Управление продуктом в Scrum

подразумевает­ риск. Как вы помните, видение Expertcity


вылилось в  продукт, который не  оправдал ожиданий.
То есть даже видение не страхует от неудачи. Однако, как
и в случае с Expertcity, провал может стать первым шагом
к успеху. Например, программа GoToMyPC стала результа-
том неудачного первого релиза. Чтобы свести к миниму-
му любые потенциальные убытки или ущерб от неточного
прогноза, выбирайте узкий набор потребностей клиента
и  почаще выпускайте обновления. Затем анализируйте
и вносите изменения.

Аналитический паралич

Как уже говорилось, не  стоит увлекаться предваритель-


ным исследованием рынка, иначе вы можете попасть
в  ловушку аналитического паралича, когда приходит-
ся проводить все новые и  новые изыскания, причем без
всякого прогресса. Чрезмерное исследование рынка гро-
зит не только потерей времени и денег, но и тем, что вы
не предъявите привлекательный продукт вовремя. Пони-
мание рынка и забота о клиентах очень важны, но ориен-
тация только на  клиентов, без собственного понимания
того, как должен выглядеть и работать продукт, вряд ли
приведет к успеху.
2. Планирование концепции продукта 97

Чаще всего причина аналитического паралича — из-


лишняя забота о безопасности инвестиций. Компании,
злоупотребляющие подобным поведением, часто не-
терпимы к неудачам и требуют всего и сразу. Руковод­
ство хочет получить точные прогнозы, в том числе кон-
кретную долю рынка и  доходы, и  только тогда готово
утвердить концепцию. Аналитический паралич можно
предотвратить, сведя концептуальную часть к  мини-
муму, как можно быстрее разработав продукт и опера-
тивно адаптировав его к рынку на основании реакции
клиентов­.

«Мы-лучше-знаем-что-нужно-клиентам»

Некоторые компании впадают в  другую крайность


и  совсем не  обращают внимания на  рынок. Они пола-
гаются исключительно на  интуицию руководства или
техническое совершенство разработчиков. Эти органи-
зации считают себя знатоками того, что нужно клиен-
там. Конечно, при этом возникает риск потратить время
и  деньги на  разработку никому не  нужного продукта.
Чтобы не  заниматься инновациями в  башне из  слоно-
вой кости, стоит включить в процесс разработки самих
клиентов и  пользователей, приглашая их на  обзорные
98 Управление продуктом в Scrum

совещания по спринтам, а также быстро и часто выпус-


кая ПО.

«Большое — значит хорошее»

Создание продуктов с  огромным количеством функций


может, как отмечают Престон Смит и  Дональд Райнерт-
сен, создать большую шумиху вокруг вашей компании
(Smith and Reinertsen, 1998; 67):

Всем нам нравятся истории успеха разработки,


достигнутого героическими стараниями. Команда
разработчиков берется за, казалось бы, невоз-
можный проект и  прилагает сверхчеловеческие
усилия… Эти проекты похожи на  длинные пере-
дачи, приводящие к  тачдауну* и  сводящие с  ума
болельщиков. Они гораздо интереснее, чем обыч-
ная игра,  в  которой за  один раз не  проходишь
и 10 метров­.

Но какими бы увлекательными ни были огромные


проекты, есть у  них и  недостатки: на  них уходит мас-
са денег и времени, при этом очень велик риск провала.

* Тачдаун  — один из  способов набрать очки в  американском и  ка-


надском футболе. Прим. ред.
2. Планирование концепции продукта 99

«Компании часто совершают ошибку — пытаются найти


идеальное решение, которое с первого же дня всех устро-
ит. Часто это выливается в  создание слишком сложных
дорогих продуктов, которые не  очень хорошо функцио-
нируют» (Anthony et al., 2008; 125). При этом в  больших
проектах очень сложно развивать продукт на основании
отзывов клиентов и  пользователей, поскольку многие
функции предопределены.
Этой ошибки можно избежать, начав с  работы над
продуктом, призванным удовлетворить узкий набор кли-
ентских требований и  предлагающим минимальную,
но  достаточную функциональность. Быстро запустите
его, изучите реакцию рынка и внесите соответствующие
изменения.

Вопросы для самоконтроля


Убедитесь, что вся scrum-команда разделяет видение бу-
дущего продукта. Это видение должно быть умеренным
и  ориентированным на  ближайшую версию продукта.
Думайте о  большом, но  начинайте с  малого. Проверьте
свое видение, приглашая на обзорные совещания во вре-
мя спринтов потребителей и клиентов и быстро выпуская
обновления продукта. Затем развивайте продукт на осно-
ве клиентских отзывов.
100 Управление продуктом в Scrum

Следующие вопросы помогут вам применить идеи


для концепции, обсуждавшиеся в этой главе.

— Преследуют ли ваши продукты общие цели?


— Как вырабатываются цели и кто их формулирует?
— Как выработать концепцию, обладающую описан-
ными в этой главе качествами?
—К
 ак такая концепция обогатит вашу инновационную
деятельность?
3
Работа с бэклогом
продукта

Немногие элементы Scrum могут похвастаться такой по-


пулярностью, как бэклог продукта. И на то есть причины.
Бэклог продукта хорош своей простотой: это всего лишь
сформированный по приоритетности список пока не вы-
полненных дел, необходимых для создания продукта.
Среди элементов бэклога могут быть исследование
потребностей покупателя или различных технических
вариантов, описание функциональных и нефункциональ-
ных требований, необходимых для запуска продукта дей­
ствий, а также другие компоненты — например, создание
рабочего окружения или устранение дефектов. Бэклог
продукта заменяет традиционные документы с  требова-
ниями, такие как спецификации рынка и продукта. Вла-
делец продукта отвечает за управление бэклогом продук-
та, в него также вносят свой вклад scrum-мастер, команда­
102 Управление продуктом в Scrum

и  заинтересованные лица. Вместе они открывают функ-


циональность продукта.
В этой главе рассказывается о бэклоге продукта и ме-
тодах эффективной работы с ним. Рассмотрим также не-
сколько более сложных его применений, в том числе ра-
боту с нефункциональными требованиями и расширение
бэклога продукта для больших проектов.

Глубинные свойства бэклога


продукта
Элементы бэклога продукта обладают четырьмя свой­
ствами: имеют достаточную степень детализации, оце-
нены, независимы и приоритизированы — в английском
языке получается удобная аббревиатура DEEP (от detailed,
estimated, emergent, prioritized)  — глубинный*. Рассмот-
рим эти свойства подробнее.

Достаточная степень детализации

Элементы бэклога продукта имеют достаточную степень


детализации, это показано на рисунке 3.1. Элементы с бо-
лее высоким приоритетом описаны подробнее, чем ме-
нее важные. «Чем ниже приоритет, тем меньше деталей,

* Аббревиатуру DEEP придумал Майк Кон.


3. Работа с бэклогом продукта 103

вплоть до полного минимума», — пишут Швабер и Бидл


(Schwaber and Beedle, 2002; 33). Следуя этому правилу,
вы сохраняете бэклог продукта минималистичным, а его
элементы — реализуемыми в течение спринта. В резуль-
тате требования выявляются, декомпозируются и  дета-
лизируются в течение всего проекта.

Очень подробно прописанные


Высокий Бэклог продукта элементы, готовые к внесению
в следующую итерацию, — например,
краткие пользовательские истории
Элементы со средней детализацией —
например, длинные пользовательские
Приоритет

истории

Обобщенные элементы, например


эпики

Низкий

Рисунок 3.1. Степень приоритетности элемента бэклога


продукта определяет уровень его детализации

Оценка

Элементы бэклога продукта оцениваются. Эта оценка


довольно приблизительная и  часто выражается в  очках
за  пользовательскую историю или в  идеальных днях.
Понимание объема элементов списка помогает в расста-
новке приоритетов и  планировании релиза. Детализи-
рованные оценки уровня задач даются на  совещаниях
104 Управление продуктом в Scrum

по планированию спринтов, задачи и их оценка фиксиру-


ются в спринт-бэклоге.

Развитие

Развитие бэклога продукта имеет естественный харак-


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

Приоритетность

Все элементы бэклога продукта расположены по приори-


тетности. Самые важные внедряются в  первую очередь.
Они находятся в верхней части бэклога продукта, как по-
казано на рисунке 3.1. После завершения работы над эле-
ментом он удаляется из бэклога.

Работа над бэклогом продукта


Если сад надолго оставить без ухода, он зарастет. Так
и  бэклог продукта  — когда им пренебрегают, он станет
3. Работа с бэклогом продукта 105

громоздким и  неудобным. Ему нужны забота и  внима-


ние, с  ним рекомендуется постоянно работать. Работа
над ним — это непрерывный процесс, состоящий из ука-
занных ниже шагов. Правда, они не всегда выполняются
именно в таком порядке.
— Выявляются и описываются новые элементы, а су-
ществующие при необходимости изменяются или
удаляются.
— Происходит расстановка приоритетов. Самые важ-
ные задачи помещаются в верхнюю часть.
— Высокоприоритетные элементы подготавлива-
ются к  ближайшему совещанию по  планирова-
нию спринта. Они декомпозируются и  детализи­
руются.
— Команда определяет масштаб элементов бэклога
продукта. Это необходимо ввиду внесения в него
новых элементов, изменения существующих и ис-
правления оценок.
Хотя владелец продукта отвечает за  хорошее состоя-
ние бэклога продукта, работа над ним — это командный
процесс. Выявляются и  описываются элементы, они вы-
страиваются по приоритету, декомпозируются и детали-
зируются всей scrum-командой. В Scrum выделяется на эту
деятельность до  10% командного времени (Schwaber,
2007). При необходимости в  процесс вовлекаются и  за-
интересованные лица. Требования больше не спускаются
106 Управление продуктом в Scrum

команде сверху, в их формулировании принимают учас-


тие все члены команды. Владелец продукта, scrum-мастер
и команда общаются не через документацию, а лично.
Совместная работа над бэклогом продукта интересна
и эффективна. Она порождает диалог как внутри scrum-
команды, так и  между командой и  заинтересованными
лицами. Она устраняет разделение на  «бизнесменов»
и «технарей», ликвидирует ненужные передаточные зве-
нья. Требования становятся более ясными, к  их разра-
ботке привлекаются коллективный опыт и  творческий
импульс всей scrum-команды, создается ощущение при-
частности к общему делу.
Некоторые команды предпочитают заниматься рабо-
той с бэклогом сразу после ежедневного scrum-митинга.
Другие работают еженедельно или проводят более длин-
ную рабочую сессию с ним ближе к окончанию спринта.
Работа с  бэклогом продукта происходит и  на  обзорных
совещаниях по  спринтам, когда scrum-команда и  заин-
тересованные лица обсуждают дальнейшую разработку:
выявляются новые элементы бэклога и  удаляются уста-
ревшие. Не забудьте включить в свои планы работу с бэк-
логом, например еженедельную. Хорошо проработанный
бэклог продукта  — это необходимое условие для успеш-
ного совещания по планированию спринта.
Отличное средство, облегчающее работу с бэклогом
продукта, — бумажные карточки. Они дешевы, удобны­
3. Работа с бэклогом продукта 107

в  использовании и  облегчают совместную работу: кто


угодно может взять карточку и  записать в  ней свою
идею. Карточки можно сгруппировать на столе или сте-
не и  сверяться с  ними по  мере необходимости. Карто-
чки и электронные средства ведения бэклога продукта,
такие как электронные таблицы, дополняют друг друга:
перед сессией работы с  бэклогом распечатайте на  бу-
мажных карточках уже имеющиеся требования, а  за-
тем вновь перенесите эту информацию в  электронные
инструменты­.
Ниже подробно рассмотрим четыре этапа работы
с бэк­логом продукта, начав с выявления и описания его
элементов.

Выявление и описание
элементов
Выявление и  описание элементов бэклога продукта  —
это постоянный процесс. Если вы привыкли составлять
полные и подробные спецификации, смиритесь с тем, что
Scrum поддерживает совершенно иной подход. Требова-
ния больше не замораживаются на ранней стадии — они
выявляются и детализируются в течение всего проекта.
По мере того как улучшается наше понимание потребнос-
тей покупателя и того, как оптимально их удовлетворить­,
108 Управление продуктом в Scrum

существующие требования либо изменяются, либо ста-


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

Выявление элементов

Выявление элементов бэклога продукта начинается с его


создания. Лучше всего это делается совместными усили-
ями: члены scrum-команды и  при необходимости заин-
тересованные лица в  ходе мозгового штурма выявляют
элементы, нужные для создания продукта, используя в ка-
честве точки отсчета его идею, его видение или дорожную
карту. При этом не пытайтесь думать обо всех элементах
сразу. Каждый раз, когда вы работаете с бэклогом, сосре-
доточивайтесь на минимальной функциональности, необ-
ходимой для выхода продукта на рынок, и придерживай-
тесь принципа простоты, который обсуждался в главе 2.
В  ходе проекта появятся новые идеи, и  бэк­лог продукта
будет развиваться в  соответствии с  отзывами клиентов
и  пользователей. Если в  самом начале бэклог продукта
станет слишком длинным и сложным, будет трудно сосре-
3. Работа с бэклогом продукта 109

доточиться и правильно расставить приоритеты. Исполь-


зуйте идею или видение продукта, чтобы направлять свои
усилия. Сконцентрируйтесь на главном и отложите в сто-
рону остальное. Нужно противостоять искушению слиш-
ком быстро добавлять новые подробности. Элементы пе-
речня описываются с  течением времени в  соответствии
с  их приоритетностью. Низкоприоритетные элементы
остаются неделимыми и обобщенными, пока их приори-
тет не изменится (либо они станут более срочными, либо
основные задачи будут уже выполнены). Нефункциональ-
ные требования, которые относятся к  свойствам всего
продукта, служат исключением из этого правила. Как вы
узнаете из этой главы, они должны быть подробно описа-
ны с самого начала.
Как только первичный бэклог продукта составлен, по-
является масса возможностей для выявления новых эле-
ментов. Это и груминг-сессии, когда scrum-команда рас-
ставляет приоритеты и декомпозирует элементы бэклога
продукта, и обзорные совещания по спринтам, где заин-
тересованные лица сообщают свои отзывы, и  коммента-
рии пользователей и клиентов по выходящим обновлени-
ям продукта.
Всякий раз, когда в бэклог вносится требование, сле-
дует убедиться, что соответствующая потребность кли-
ента была правильно понята. Спросите себя, зачем нуж-
но это требование и почему оно идет на пользу клиенту.
110 Управление продуктом в Scrum

Не нужно слепо копировать требования в бэклог продук-


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

Описание элементов

Scrum не  предписывает методов описания элементов


бэклога продукта, но  я предпочитаю работать с  пользо-
вательскими историями (Cohn, 2004). Как можно дога-
даться по  названию, это история о  том, как клиент или
пользователь работают с продуктом. Она содержит имя,
краткую информацию и  критерии приемки  — условия,
которые позволяют понять, реализована история или
нет. История может быть обобщенной или подробной.
Обобщенные истории называются эпиками. Писать, де-
композировать и детализировать пользовательские исто-
рии несложно. Конечно, для описания требований можно
применять любой другой метод. А если вы предпочитаете
3. Работа с бэклогом продукта 111

пользовательские истории, то  необязательно описывать


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

Структурирование бэклога продукта

Бэклогу часто идет на  пользу группировка элементов


по тематическому признаку. Темы — это будущая функ­
циональность продукта. Они структурируют бэклог, по-
могают расставить приоритеты, делают удобным доступ­
112 Управление продуктом в Scrum

к информации. Так, примеры тем для мобильного теле-


фона  — это электронная почта, календарь, голосовая
связь и  органайзер. В  принципе, каждая тема должна
для начала содержать от двух до пяти обобщенных тре-
бований. Этой информации достаточно, чтобы понять,
что нужно для производства продукта, при этом содер-
жание бэклога не  замусоривается лишними деталями.
Темы создают иерархию в  бэклоге, который теперь по-
мимо индивидуальных элементов содержит и  их груп-
пы. Вдобавок полезно провести дальнейшее разграни-
чение между обобщенными требованиями, например
эпиками, и детализированными элементами, например
историями. Пример такого бэклога частично приведен
в таблице 3.1.

Таблица 3.1. Образец бэклога продукта

Тема Обобщенный Детализированный Усилия


элемент элемент
Электронная Создать элект- Как корпоративный 1
почта ронное письмо пользователь, я хочу
создавать тему письма

Темы в таблице 3.1 содержат обобщенные элементы.


Со  временем они декомпозируются на  более детально
описанные элементы. После оценки элемента коман-
дой фиксируется общий размер бэклога. Структуру­
3. Работа с бэклогом продукта 113

из  таблицы­  3.1 можно применять вне зависимости


от средства, которым вы пользуетесь для создания бэк­
лога,  — например, расположив соответствующим об-
разом бумажные карточки на  специальной доске или
на стене офиса.

Расстановка приоритетов
в бэклоге продукта
Никогда не забуду тот день, когда я предложил менеджеру
продукта в области здравоохранения расставить приори-
теты в отношении лежащих перед ней вариантов исполь-
зования. Она посмотрела на меня с удивлением и ответи-
ла: «Я не могу. Они все очень важные».
Расстановка приоритетов требует решить, насколько
значим тот или иной элемент. Если у  всех высокий при-
оритет, значит, все одинаково важны. На самом деле это
значит, что приоритета нет вообще и  шансы создать то,
что действительно нужно покупателю, очень невели-
ки. Расстановка приоритетов в  бэклоге продукта входит
в сферу ответственности владельца продукта. Однако, как
и при любой работе с бэклогом, лучше всего расставлять
приоритеты всей scrum-командой. В этом случае исполь-
зуется коллективный опыт команды и  поддерживается
мотивация.
114 Управление продуктом в Scrum

Расстановка приоритетов направляет работу команды,


сосредоточивая ее на самых важных элементах. Она также
поддерживает на  одном уровне содержание бэклога про-
дукта. Как уже говорилось, элементы конкретизируются
в зависимости от их приоритета. Это вносит гибкость в про-
цесс и позволяет откладывать на потом решения по низко-
приоритетным элементам, что дает scrum-команде больше
времени на  оценку вариантов, сбор отзывов от  клиентов
и  получение нового знания. В  итоге это приводит к  наи­
лучшим решениям и более качественному продукту*.
Поскольку индивидуальные элементы бэклога могут
быть очень мелкими и с трудом поддаваться приоритиза-
ции, полезно сначала назначить приоритет для тем. После
этого можно расставить приоритеты для элементов внутри
этих тем и, при необходимости, между ними. Ниже рассма­
триваются следующие факторы расстановки приоритетов
в  бэклоге продукта: ценность, знания, неопределенность
и риск, возможность выпуска и взаимозависимости.

Ценность

Ценность — это довольно обычный фактор при расстанов-


ке приоритетов. Разумеется, в первую очередь мы хотим

* Откладывание решений до того момента, когда их все же придется


принять, также называется самым поздним ответственным реше-
нием (Poppendieck, 2003)
3. Работа с бэклогом продукта 115

реализовать самые ценные элементы бэклога продукта.


Но  что делает элемент бэклога ценным? Ответ прост  —
его важность для выхода продукта. Если это не  так, то
элемент не имеет значения и его можно исключить из те-
кущего релиза или версии продукта. Scrum-команда либо
лишает такой элемент приоритетности и  помещает его
в  самый низ бэклога, либо отказывается от  него. Если
элемент важен для какой-то из будущих версий, то он по-
явится вновь.
Прежде чем включить элемент в релиз, нужно понять,
не будет ли продукт и без данного элемента приносить те
же преимущества. Это помогает создать простой продукт
с  минимальной функциональностью, как описано в  гла-
ве 2. Apple, например, выпускала iPhone первого и второ-
го поколения без возможности копирования и  вставки,
что не повредило успеху гаджета. Если элемент действи-
тельно нужен, подумайте, нет ли альтернативы, которая
приносит те же выгоды, но требует меньше усилий, вре-
мени или денег. Команды, к сожалению, часто сдержива-
ют какие-то неявные ограничения, поэтому они не всегда
способны оценить все варианты.
Тщательно нужно проверять не  только новые требо-
вания. Постоянно пересматривайте и уже существующие.
По  мере того как scrum-команда осознает потребности
клиента, часто возникают более интересные альтернати-
вы и вырабатываются решения. Упрощайте, сокращайте
116 Управление продуктом в Scrum

и  стремитесь к  порядку, как садовник, выпалывающий


сорняки и подрезающий кустарник.
В случае сомнений исключайте требование из рели-
за и  быстро выпускайте продукт без него, как сделала
Google при разработке первого релиза Google News — аг-
регатора всемирных новостей. Разработчики не  могли
решить, как фильтровать новости — по дате или по месту.
По­этому Google решила выпустить продукт вообще без
этой функции. Вскоре после запуска появились запросы
новых функций. Триста человек высказались за фильтра-
цию по дате, и только трое захотели фильтровать по мес-
ту  — явное указание на  то, какая функциональность
должна быть приоритетной. Если бы Google выпустила
продукт с обеими функциями, то релиз отнял бы больше
времени и  денег, а  получить отзывы о  том, какая функ-
ция важнее, было бы сложнее. Поставив на рынок наме-
ренно недостаточный продукт, Google быстро осознала,
что делать дальше.

Знания, неопределенность и риск

«Риск  — сущностная характеристика инновационного


продукта. Каждое решение, касающееся проекта (при-
нимается оно явно или по умолчанию), связано с риска-
ми», — пишут Смит и Мерритт (Smith and Merritt, 2002; 4).
Таким образом, риск — неотъемлемая часть разработки­
3. Работа с бэклогом продукта 117

ПО. Ни  один продукт без риска просто не  выпустить.


С риском связана неопределенность, и чем она выше, тем
рискованнее проект. Неопределенность же, в  свою оче-
редь, связана с недостатком знаний. Чем меньше мы зна-
ем о том, что нужно разрабатывать и как это делать, тем
больше неопределенность. Таким образом, знания, неоп-
ределенность и риск взаимосвязаны.
Поскольку риск и  неопределенность влияют на  ус-
пех продукта, неопределенные и  рискованные элемен-
ты должны быть наделены высоким приоритетом. Это
ускоряет процесс получения нового знания, устраня-
ет неопределенность и  снижает риск. Если, например,
scrum-команда не  уверена в  некоторых аспектах дизай-
на пользовательского интерфейса, то  соответствующие
варианты нужно побыстрее изучить и проверить, собрав
отзывы клиентов и пользователей. Если команда не зна-
ет, какой уровень доступа к  данным для третьей сторо-
ны применить, нужно ввести требования, запускающие
транзакции базы данных, чтобы можно было оценить
различные варианты. Риск может содержаться и  в инф-
раструктуре, и в среде — например, не до конца настро-
енном процессе разработки или в том, что члены scrum-
коман­ды не сидят в одном помещении.
Немедленное обращение к  неопределенным, рис-
кованным элементам  — это подход, который способен
быстро привести к  неудаче. Ранняя неудача позволяет
118 Управление продуктом в Scrum

scrum-команде вовремя менять курс, например модифи-


цировать архитектуру и  технологии или изменить со-
став команды. Рискованный подход, часто приводящий
к неудачам, может стать проблемой для людей и органи-
заций, привыкших к традиционным процедурам, когда
проблемы и  препятствия выявляются слишком позд-
но и  воспринимаются скорее как плохая новость, чем
как возможность учиться на  ошибках и  совершенство­
ваться.

Возможность выпуска

Быстрые и частые релизы — отличный способ превратить


ваше ПО в продукт, любимый покупателями, о чем будет
говориться в главе 4.
Кроме того, это хороший способ уменьшить риски.
Если scrum-команда сомневается, стоит ли внедрять
функ­цию и как именно это делать, ранние релизы помо-
гут ответить на этот вопрос, как в упоминавшемся случае
с Google News.
Таким образом, возможность быстро и  часто выпус-
кать обновления продукта должна оказывать влияние
на расстановку приоритетов в бэклоге продукта. Каждый
релиз должен предлагать такую функциональность, кото-
рая будет полезна клиентам и  пользователям и  породит
3. Работа с бэклогом продукта 119

желаемые отзывы. При этом обычно полное внедрение


темы не нужно, для первых релизов достаточно частично-
го внедрения.

Взаимозависимости

Взаимозависимости в бэклоге продукта — это непрелож-


ный факт. Например, функциональные требования часто
зависят от  других функциональных и  даже нефункцио-
нальных. А  если вместе работают несколько команд, то
взаимозависимости между ними могут влиять на  рас-
становку приоритетов, о чем подробнее говорится в гла-
ве  4. Взаимозависимости ограничивают свободу выбора
приоритетов и  сказываются на  оценке усилий: элемент,
на  который влияют другие, придется внедрять первым.
Поэтому следует по возможности решать вопрос с взаимо­
зависимостями.
Объединение нескольких зависящих друг от  дру-
га элементов бэклога продукта в  один более крупный
и  пере­формулирование для устранения зависимости  —
вот два основных метода работы с  взаимозависимыми
пользовательскими историями (Cohn, 2004; 17). Рассмот-
рим в качестве примера две истории: «Я как пользователь
хочу написать текстовое сообщение» и  «Я  как  пользова-
тель хочу написать электронное письмо». Они зависят
120 Управление продуктом в Scrum

друг от друга, поскольку обе связаны с обработкой текста.


Если сначала внедрить текстовые сообщения, это сокра-
тит усилия на работу с электронными письмами, и наобо-
рот. Первый вариант  — соединить их в  более крупную
пользовательскую историю  — не  очень подходит нам,
поскольку история получается слишком сложной. Второй
вариант  — разбить требования по-иному. Если общая
функциональность выделяется в  отдельную историю  —
«Я как пользователь хочу вводить текст», то две исходные
истории больше не  зависят друг от  друга. Таким обра-
зом, их оценка больше не связана с порядком работы над
ними.

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

Выбор цели спринта

Цель спринта формулирует его желаемый резуль-


тат. Он  должен подвести scrum-команду на  шаг ближе
3. Работа с бэклогом продукта 121

к  запуску­ успешного продукта. Один владелец продукта


выбрал для первого спринта следующую цель: «У высоких
деревьев глубокие корни». Эта фраза отлично описывала
цель спринта  — закладку основания для всего последу-
ющего проекта. Хорошая цель спринта обширна, но реа-
листична. Она должна оставлять команде пространство
для маневра и не предполагать непременную реализацию
всех главных элементов бэклога продукта. Как и  в слу-
чае с  бэклогом, вся команда должна принимать участие
в формулировке цели. Это обеспечит ясность задач и мо-
тивацию. Установить цель спринта важно по нескольким
при­чинам.
— Она порождает единение между владельцем про-
дукта, scrum-мастером и командой: все движутся
к единой цели.
— Она минимизирует вариативность, ограничивая
тип требований, над которыми предстоит рабо-
та в  ходе ближайшего спринта,  — например, по­
средством выбора элементов одной темы. Так
облегчается командная деятельность и  увеличи-
вается темп разработки.
— С ее помощью проще объяснить заинтересован-
ным лицам, над чем работает команда.
Выбор цели спринта может привести к  изменениям
в приоритетах в бэклоге продукта, при которых элементы
продвигаются в  его верхнюю часть и  удаляются из  нее.
122 Управление продуктом в Scrum

Не исключено, что придется пойти на компромисс, выби-


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

Когда нужно и ровно столько,


сколько нужно

Как только избрана цель спринта, нужно подготовить


ровно столько элементов для будущего спринта, сколь-
ко нужно и  когда нужно*. (Крупные проекты, при ра-
боте над которыми необходимо заглядывать далеко
вперед, описаны ниже в этой же главе.) Работа с бэкло-
гом продукта во  время первого спринта строится вок-
руг элементов для второго спринта, во  время второго
спринта — вокруг элементов для третьего и т. д. У тако-
го подхода есть ряд преимуществ: сводятся к минимуму
траты времени и денег на описание элементов, а также
снижается количество элементов, нуждающихся в под-
робном описании. Избыточное количество информа-
ции  — это пустая трата сил. Подробно описывая лишь
те элементы, которые, вероятнее всего, понадобятся для

* Термины «сколько нужно» и «когда нужно» впервые использованы


в работе Кона (Cohn, 2008) для описания работы над бэклогом про-
дукта.
3. Работа с бэклогом продукта 123

следующего спринта, мы даем бэклогу продукта воз-


можность развиваться.
Подготовка элементов для совещания по  планиро-
ванию спринта требует декомпозиции более крупных
элементов бэклога продукта. Они должны стать до-
статочно малы для спринта, и  их необходимо довести
до  совершенства, чтобы они были понятными, испол-
нимыми и  контролируемыми. Этот процесс показан
на  рисунке  3.2. Реализация декомпозированного эле-
мента может занять несколько спринтов. Об этом речь
пойдет ниже.

Размер

Большие
необра-
Большой ботанные
элементы

Небольшие Четкие, осу-


Малый необра- ществимые
ботанные и контролиру-
элементы емые элементы

Низкий     Высокий   Уровень детализации

Рисунок 3.2. Расширение и улучшение компонентов бэклога


продукта

Количество элементов, которые следует подготовить,


зависит от общей скорости работы команды и желаемой
124 Управление продуктом в Scrum

проработанности элементов. Чем выше скорость коман-


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

Декомпозиция элементов

Декомпозиция элементов бэклога продукта — это посте-


пенное их уменьшение до степени готовности для сприн-
та. Такой процесс, известный также как последовательная­
3. Работа с бэклогом продукта 125

декомпозиция элементов (Reinertsen, 1997), может зани-


мать более чем один спринт. Возможно, декомпозицию
какого-то­ элемента придется начать за несколько сприн-
тов до его возможного внедрения, особенно если он боль-
шой и сложный. Это позволяет собрать необходимые отзы-
вы клиентов, пользователей и других заинтересованных
лиц еще до подробного описания элемента. Рассмотрим,
как можно провести последовательную декомпозицию
пользовательских историй.

Задать тему: Я как


Выбрать полу-
корпоративный
чателя: Я как
пользователь хочу
корпоративный
задать тему
пользователь хочу
выбрать одного
Задать полу- или нескольких
Создать электрон-
чателя: Я как получателей
ное письмо: Я как
корпоративный из своего списка
корпоративный
пользователь хочу контактов
пользователь хочу
задать одного
создать электрон-
или нескольких Ввести получате-
ное письмо
получателей ля: Я как корпора-
тивный пользова-
Задать важность:
тель хочу ввести
Я как корпора-
получателя
тивный пользова-
тель хочу задать
важность

Рисунок 3.3. Декомпозиция пользовательских историй

Как показано на  рисун