Пихлер Р. - Управление Продуктом в Scrum. Agile-методы Для Вашего Бизнеса - 2017

Эту книгу хорошо дополняют:
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
3. Работа с бэклогом продукта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

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

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

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

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

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

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

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

Осознайте важность роли . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
Выбирайте правильного владельца
продукта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
Наделяйте владельцев продукта
полномочиями и поддерживайте их . . . . . . . . . . . . . . . . . . 213
Поддерживайте институт владельцев
продукта в компании . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
Библиография . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
Благодарности . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
Об авторе . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
Посвящается Мелиссе
Предисловие
Джеффа Сазерленда
Владелец продукта — новая роль для большинства ком-

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

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

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

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

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

тет компании? Оказалось — да, можно.
Мне как главному владельцу продукта в 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 приведено резюме наиболее
важных различий.
Таблица 1. Управление продуктом по-старому и по-новому
Старые методы Новые методы
Несколько ролей — напри- Один человек, владелец продукта,

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

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

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

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

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

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

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

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

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

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

В Scrum Guide Кен Швабер пишет о владельце продукта:
Владелец продукта — единственный человек, отве-

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

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

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

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

ность в компании. В принятой в России иерархии аналог генераль-
ного директора. Прим. ред.
усилий Джерри Лейборна, CEO компанииOxygen Media,

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

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

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

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

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

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

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

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

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

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

18 июня 2009 года.
и т. д. Это человек, имеющий доступ к бюджету и спо-

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

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

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

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

от 2 октября 2008 года и из личного сообщения Джеффа Сазерлен-
да от 16 декабря 2008 года.
Работа с командой
Владелец продукта — это такой же член scrum-команды,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

продукта А продукта и владелец продукта В
продукта Б
Команда А Команда Б Команда В
Рисунок 1.2. Простая иерархия владельцев продукта
На рисунке 1.3 представлен другой вариант, подхо-

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

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

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

«Мобильный телефон»
Владелец про- Владелец про- Владелец про- Владелец

дукта «Развле- дукта «Комму- дукта «Фото продукта
чения» никации» и видео» «Органайзер»
Владелец Владелец
продукта продукта
«МР3-плеер» «Игры»
Владелец Владелец
продукта продукта
«Тетрис» «Шахматы»
Рисунок 1.3. Сложная иерархия владельцев продукта
Сложная иерархия владельцев продукта предпо-

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

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

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

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

дукта непросто, даже когда нужен только один такой
кандидат. По каким же критериям выбирать правиль-
ных владельцев продукта для больших проектов? Ответ
на этот вопрос дает понимание разных способов органи-
зации команд в большом проекте. Существует всего два
варианта: функциональные команды и компонентные
команды (Pichler, 2008; Larman and Vodde, 2009). Функ-

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

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

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

точными полномочиями, похож на автомобиль с мало-
мощным двигателем: он, конечно, едет, но с увеличением

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

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

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

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

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

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

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

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

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

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

цев продукта, в которой никто персонально не отвечает
за общий продукт. Ни один из них не руководит этой

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

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

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

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

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

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

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

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

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

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

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

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

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

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

приводит к наилучшим результатам*.
Нужно противостоять искушению перегружать про-

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

кратким и сжатым, содержать только информацию, не-
обходимую для его успеха. Например, продукты-блок-
бастеры, как показало десятилетнее исследование Линна
и Рейли, обладали всего шестью атрибутами (Lynn and
Reilly, 2002). Таким образом, видение продукта — это
не список функций и оно не должно содержать избы-
точные подробности. Специалист по agile-управлению
проектами Джим Хайсмит поясняет: «Как оказалось,
описание пятнадцати-двадцати признаков или функ-
ций продукта — задача довольно легкая. А вот выбор
трех-четырех из них, которые побудили бы человека этот
* “Inside Google’s New-Product Process”, BusinessWeek.com, June 30,

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

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

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

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

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

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

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

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

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

пользовательским потенциалом»*.
Поскольку будущее неопределенно, концепция долж-
на распространяться только на следующую версию про-
дукта. Даже если долгосрочной мечтой Стива Джобса
было доминирование на рынке мобильных телефонов,
это определенно не являлось целью первого iPhone. Боль-
шие амбиции лучше всего реализовывать пошагово. «Ва-
жен только один шаг — следующий» (Gilb, 1988; 97). Как
только появляется концепция, она превращается в го-
товый продукт благодаря использованию пользователь-
ских и клиентских отзывов. Их собирают по результатам
демонстрации новых версий продукта на обзорных со-
вещаниях во время спринтов, а также быстрых и частых
релизов продукта. Подобный метод работы позволяет
scrum-команде сразу же определить, действительно ли
они производят нужный продукт. Если же нет, то виде-
ние, вероятно, сформировано неверно, так что следует
внести коррективы.
Заметьте, что видение продукта может воплощать-
ся более чем в одном релизе. Например, запуску первой
* “So Much Fanfare, So Few Hits”, BusinessWeek.com, July 10, 2006. По-
добный же подход отражен в знаменитом изречении Арта Фрая
из 3М: «Чтобы найти принца, придется перецеловать много лягу-
шек». Заметьте, что прекрасный принц заплатит за всех этих ля-
гушек. (Имеется в виду сказка братьев Гримм «Принц-лягушка».
Прим. ред.)
версии Google Chrome в декабре 2008 года предшество-

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

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

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

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

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

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

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

продукты, которые требуют большого количества функ-
ций и сложного дизайна, должны быть столь же просты,
сколь и эффективны… Мы стараемся не просто добав-
лять новые функции, но и развивать продукты в других
направлениях»*. Разработка простых пользовательских
интерфейсов, по утверждению Лидуэлла, Холдена и Бат-
лера, прекрасно оправдала себя в 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.
Потребности покупателя
и свойства продукта
Потребности покупателя и свойства продукта лежат
в основе любой концепции и заслуживают самого при-
стального внимания. От выбора важнейших потребнос-
тей покупателя зависит то, к какому рынку или его сег-
менту мы собираемся обращаться. Сосредоточившись
на пот ребностях, мы рассматриваем продукт как средс-
тво достижения цели — удовлетворения нужд клиента
или пользователя. В то же время свойства продукта —
критически важные параметры, которыми должен об-
ладать продукт для удовлетворения этих потребностей.
Например, сенсорный экран — это свойство продукта.
Вероятно, потребность, обусловившая это свойство, —
простота в использовании. Свойства могут быть как
функциональными, так и нефункциональными. Функци-
ональные свойства — это конкретные функции или черты
продукта, например способность совершать и принимать
звонки. Нефункциональные свойства — это производи-
тельность, выносливость, стиль, дизайн и удобство в ис-
пользовании. Нефункциональные атрибуты могут стать
важным дифференцирующим фактором — воздейство-
вать на пользовательский опыт, а также на расширяе-
мость продукта и удобство его эксплуатации, которые,
в свою очередь, влияют на общую стоимость владения

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

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

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

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

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

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

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

Раковски(Levy, 2008).
мероприятия по выработке продуктового видения, воз-

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Visio — Standard, Pro и Tech. Затем компания решила упростить
свой портфель.
распространенных ошибок: отсутствия видения, про-

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

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

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

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

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

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

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

кая ПО.
«Большое — значит хорошее»
Создание продуктов с огромным количеством функций

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

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

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

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

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

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

для концепции, обсуждавшиеся в этой главе.
— Преследуют ли ваши продукты общие цели?

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

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

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

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

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

3. Работа с бэклогом продукта 103
вплоть до полного минимума», — пишут Швабер и Бидл

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

тат. Он должен подвести scrum-команду на шаг ближе
к запуску успешного продукта. Один владелец продукта

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

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

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

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

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

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

Малый необра- ществимые
ботанные и контролиру-
элементы емые элементы
Низкий Высокий Уровень детализации
Рисунок 3.2. Расширение и улучшение компонентов бэклога

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

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

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

пенное их уменьшение до степени готовности для сприн-
та. Такой процесс, известный также как последовательная
декомпозиция элементов (Reinertsen, 1997), может зани-

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

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

Язык

Пихлер Р. - Управление Продуктом в Scrum. Agile-методы Для Вашего Бизнеса - 2017

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Пихлер Р. - Управление Продуктом в Scrum. Agile-методы Для Вашего Бизнеса - 2017

Загружено:

Авторское право:

Доступные форматы

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

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

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

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

Authorized translation from the English language

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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