Открыть Электронные книги
Категории
Открыть Аудиокниги
Категории
Открыть Журналы
Категории
Открыть Документы
Категории
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
Пихлер, Роман
П36 Управление продуктом в Scrum. Agile-методы для вашего бизне-
са / Роман Пихлер ; пер. с англ. Александра Коробейникова. —
М. : Манн, Иванов и Фербер, 2017. — 240 с.
ISBN 978-5-00100-354-0
УДК 658.5.012.1
ББК 65.291.217
Все права защищены. Никакая часть данной
книги не может быть воспроизведена
в какой бы то ни было форме без письменного
разрешения владельцев авторских прав.
Предисловие Джеффа Сазерленда . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Предисловие Бретта Квинера . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Предисловие . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Чем отличается agile‑управление продуктом . . . . . . . . . . . . 23
Что предлагает эта книга и кто должен
ее прочесть . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Работа с командой . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Взаимодействие со scrum‑мастером . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Работа с клиентами, пользователями
и другими заинтересованными лицами . . . . . . . . . . . . . . . . . . . . . 41
Моделирование роли владельца продукта . . . . . . . . . . . . . . . . . 45
Главный владелец продукта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Иерархия владельцев продукта . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Как правильно выбрать владельцев
продукта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Распространенные ошибки . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Владелец продукта с недостаточными
полномочиями . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Перегруженность владельца продукта . . . . . . . . . . . . . . . 53
Частичный владелец продукта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Удаленный владелец продукта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Заместитель владельца продукта . . . . . . . . . . . . . . . . . . . . . . . . . 57
Комитет владельцев продукта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Вопросы для самоконтроля . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Минимально функциональный продукт . . . . . . . . . . . . . . . . . . . . 68
Простота . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Бритва Оккама . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Чем меньше, тем лучше . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Простые пользовательские интерфейсы . . . . . . . . . . . . . 76
Потребности покупателя и свойства продукта . . . . . . . . . 78
Рождение видения продукта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Любимые проекты . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Использование Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Техники формирования видения . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Прототипирование и макетирование . . . . . . . . . . . . . . . . . 84
Персоны и сценарии . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Визуализация и обзор в отраслевом журнале . . . . 88
Модель Кано . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Формирование видения и дорожная карта
продукта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Минимальные продукты и варианты продукта . . . . . . . . 92
Распространенные ошибки . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Отсутствие видения . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Пророческое видение . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Аналитический паралич . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
«Мы-лучше-знаем-что-нужно-клиентам» . . . . . . . . . . . 97
«Большое — значит хорошее» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Вопросы для самоконтроля . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
10 Содержание
Библиография . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
Благодарности . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
Об авторе . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
Посвящается Мелиссе
Предисловие
Джеффа Сазерленда
Чем отличается
agile‑управление продуктом
Agile, или гибкое управление продуктом, основанное
на Scrum, отличается от традиционных подходов во мно-
гих отношениях. В таблице 1 приведено резюме наиболее
важных различий.
24 Управление продуктом в Scrum
Характеристики правильного
владельца продукта
Выбор правильного владельца продукта необходим
в любом scrum-проекте. Успешные владельцы продук-
та, с которыми я работал, обладали некоторыми общи-
ми чертами. Поскольку владелец продукта — это новая
роль, людям часто требуются время и поддержка, чтобы
приспособиться к ней и приобрести необходимые навы-
ки. Основная проблема — найти сотрудников с прием-
лемым уровнем знаний и опыта, которые смогут хорошо
выполнить задачу. (Переход к роли владельца продукта
и самосовершенствование в этой должности описаны
в главе 6.)
Команда предпринимателей
Порой мы излишне концентрируемся на знаменитых
предпринимателях и лидерах — Билле Гейтсе, Стиве
Джобсе и других. На самом деле лишь немногие ин-
новации — это действительно результат гениальности
34 Управление продуктом в Scrum
Пропагандист и переговорщик
Наделенный полномочиями
и преданный делу
Доступный и квалифицированный
Работа с командой
Взаимодействие
со scrum‑мастером
Чтобы постоянно играть на высшем уровне, спортивной
команде необходим тренер, а scrum-команде — scrum-
мастер*. Он оказывает поддержку владельцу продукта
и команде, защищает ее и процесс работы и при необхо-
димости вмешивается, чтобы удостовериться, справляет-
ся ли команда с задачей, сохраняет ли здоровую атмосфе-
ру и мотивацию и не создает ли технического долга**.
Роли владельца продукта и scrum-мастера дополняют
друг друга. Владелец продукта в первую очередь отвечает
за создание нужного продукта. Scrum-мастер в основном
несет ответственность за то, «как» правильно использо-
вать практики Scrum. Эти два аспекта проиллюстриро-
ваны на рисунке 1.1. Долгосрочный успех достигается,
когда правильный продукт создается правильными ме-
тодами.
Неправильно Правильно
Работа с клиентами,
пользователями и другими
заинтересованными лицами
Клиент — это тот, кто приобретает продукт, а пользо-
ватель — человек, применяющий продукт. Они опреде-
ляют его успех или неудачу. Продукт будет востребован
42 Управление продуктом в Scrum
Менеджеры по продуктовому
маркетингу и менеджеры продукта
Некоторые компании разграничивают стратегиче
ский и тактический продакт-менеджмент и выделяют
отдельные должности для каждого из них: менеджер
по продуктовому маркетингу и (технический) менед-
жер продукта. Деятельность менеджеров по продук-
товому маркетингу обычно направлена вовне: в их
обязанности входит понимать рынок, управлять пла-
ном развития продукта и следить за общими дохода-
ми после релизов. А менеджеры продукта смотрят
внутрь: их задача — подробное описание функций,
расстановка приоритетов и сотрудничество с коман
дой разработчиков. В Scrum владелец продукта
совмещает все эти обязанности. По стратегическим
вопросам управления продуктом владелец продукта
44 Управление продуктом в Scrum
Моделирование роли
владельца продукта
Прежде чем рассказать о методах работы владельца про-
дукта в крупных scrum-проектах, хочу дать совет: избе-
гайте больших проектов! Начинайте с малого и быстро
разрабатывайте продукт с минимальной функциональ-
ностью. Об этом пойдет речь в главе 2. Если приходится
заниматься крупным проектом, увеличивайте объемы
медленно. Пусть он растет естественным образом, при-
бавляя по одной команде за раз. Если работу начинает
слишком большое число людей, то проект может стать
чересчур сложным, так что последующие обновления по
требуют массу времени и денег*.
Владелец Владелец
продукта продукта
«МР3-плеер» «Игры»
Владелец Владелец
продукта продукта
«Тетрис» «Шахматы»
Распространенные ошибки
Введение роли владельца продукта для многих организа-
ций означает вход на новую для них территорию. И путь
к эффективному использованию этой должности полон
опасностей и ловушек. Данный раздел поможет избежать
некоторых наиболее распространенных ошибок.
Видение продукта
— Скажите, пожалуйста, куда мне отсюда идти?
— Это во многом зависит от того, куда ты хочешь
прийти, — ответил Кот.
— Да мне почти все равно, — начала Алиса.
— Тогда все равно, куда идти, — сказал Кот.
Льюис Кэрролл, «Алиса в Стране чудес»*
Общее и объединяющее
Широкое и мотивирующее
Краткое и приятное
Минимально
функциональный продукт
Чтобы создать видение продукта, scrum-команда долж-
на заглянуть в будущее и сформулировать то, как, по ее
мнению, будет выглядеть и работать будущий продукт.
Конечно, для любого человека, не наделенного даром яс-
новидения, верное предсказание будущего — дело чрез-
вычайно сложное. В конце концов, единственное, что мы
точно знаем о будущем, — это то, что оно неопределенное.
Не существует методики исследования рынка, способной
2. Планирование концепции продукта 69
* “So Much Fanfare, So Few Hits”, BusinessWeek.com, July 10, 2006. По-
добный же подход отражен в знаменитом изречении Арта Фрая
из 3М: «Чтобы найти принца, придется перецеловать много лягу-
шек». Заметьте, что прекрасный принц заплатит за всех этих ля-
гушек. (Имеется в виду сказка братьев Гримм «Принц-лягушка».
Прим. ред.)
74 Управление продуктом в Scrum
Простота
Простота облегчает создание удобного в использовании
продукта с минимальной функциональностью. Не сто-
ит путать простоту с упрощенностью. Еще Леонардо
да Винчи говорил: «Простота — это высшая степень слож
ности».
Бритва Оккама
Потребности покупателя
и свойства продукта
Потребности покупателя и свойства продукта лежат
в основе любой концепции и заслуживают самого при-
стального внимания. От выбора важнейших потребнос-
тей покупателя зависит то, к какому рынку или его сег-
менту мы собираемся обращаться. Сосредоточившись
на пот ребностях, мы рассматриваем продукт как средс-
тво достижения цели — удовлетворения нужд клиента
или пользователя. В то же время свойства продукта —
критически важные параметры, которыми должен об-
ладать продукт для удовлетворения этих потребностей.
Например, сенсорный экран — это свойство продукта.
Вероятно, потребность, обусловившая это свойство, —
простота в использовании. Свойства могут быть как
функциональными, так и нефункциональными. Функци-
ональные свойства — это конкретные функции или черты
продукта, например способность совершать и принимать
звонки. Нефункциональные свойства — это производи-
тельность, выносливость, стиль, дизайн и удобство в ис-
пользовании. Нефункциональные атрибуты могут стать
важным дифференцирующим фактором — воздейство-
вать на пользовательский опыт, а также на расширяе-
мость продукта и удобство его эксплуатации, которые,
2. Планирование концепции продукта 79
Любимые проекты
Использование Scrum
Прототипирование и макетирование
Планирование, выполнение,
проверка и воздействие
Организованный эксперимент проходит по четырех-
шаговой модели, известной также как цикл Деминга.
Сначала мы вырабатываем гипотезу (планирование).
Затем воплощаем ее (выполнение) и анализируем
результаты (проверка). Если эксперимент оказал-
ся неудачным, мы вносим в гипотезу изменения, где
необходимо, и проводим следующий эксперимент —
либо для достижения лучшего результата, либо что-
бы попробовать другой подход (воздействие). Томас
Эдисон, создатель первой коммерчески успешной
электрической лампочки, знал о неизбежности проб
и ошибок — необходимости многократно ошибиться,
чтобы воплотить в жизнь полноценный продукт. Хо-
рошо известна его фраза:
«Если я обнаружил десять тысяч методов, кото-
рые не работают, это не ошибка. Я не обескуражен,
потому что исключение каждого неверного метода —
это шаг вперед».
2. Планирование концепции продукта 87
Персоны и сценарии
Визуализация и обзор
в отраслевом журнале
Модель Кано
Формирование видения
и дорожная карта продукта
До сих пор в этой главе рассматривались вопросы со-
здания видения нового продукта, что особенно сложно.
По мере «взросления» продукта и выхода пошаговых об-
новлений визионерская деятельность обычно сокраща-
ется. Но новым версиям продукта все еще нужны цели.
План развития продукта позволяет scrum-команде сфор-
мулировать цели будущих версий продукта. Пока виде-
ние заключается в создании и корректировке дорожной
карты продукта.
Дорожная карта продукта — это тип плана, который
показывает, как продукт должен развиваться в своих вер-
сиях, и облегчает диалог между scrum-командой и заин-
тересованными лицами. Дорожная карта продукта позво-
ляет организациям координировать разработку и запуск
смежных продуктов — например, линейки продуктов или
продуктового портфеля. Рекомендуется не усложнять
план развития продукта, а сосредоточиться на самой
сути. План развития продукта должен содержать пример-
ную дату выхода следующей версии, указание целевых
потребителей и их нужд и три-пять основных функций.
Не беспокойтесь о деталях. Они появятся и будут отра-
жены в бэклоге продукта. Заметьте, что дорожная карта
92 Управление продуктом в Scrum
Минимальные продукты
и варианты продукта
В процессе взросления продукт начинает отвечать все
большему числу потребностей покупателей: обслуживает
потребителей в разных сегментах и регионах. Поскольку
2. Планирование концепции продукта 93
Распространенные ошибки
Выработка продуктового видения — это необходимый
шаг в подготовке его к запуску. Берегитесь следующих
Отсутствие видения
Пророческое видение
Аналитический паралич
«Мы-лучше-знаем-что-нужно-клиентам»
истории
Низкий
Оценка
Развитие
Приоритетность
Выявление и описание
элементов
Выявление и описание элементов бэклога продукта —
это постоянный процесс. Если вы привыкли составлять
полные и подробные спецификации, смиритесь с тем, что
Scrum поддерживает совершенно иной подход. Требова-
ния больше не замораживаются на ранней стадии — они
выявляются и детализируются в течение всего проекта.
По мере того как улучшается наше понимание потребнос-
тей покупателя и того, как оптимально их удовлетворить,
108 Управление продуктом в Scrum
Выявление элементов
Описание элементов
Расстановка приоритетов
в бэклоге продукта
Никогда не забуду тот день, когда я предложил менеджеру
продукта в области здравоохранения расставить приори-
теты в отношении лежащих перед ней вариантов исполь-
зования. Она посмотрела на меня с удивлением и ответи-
ла: «Я не могу. Они все очень важные».
Расстановка приоритетов требует решить, насколько
значим тот или иной элемент. Если у всех высокий при-
оритет, значит, все одинаково важны. На самом деле это
значит, что приоритета нет вообще и шансы создать то,
что действительно нужно покупателю, очень невели-
ки. Расстановка приоритетов в бэклоге продукта входит
в сферу ответственности владельца продукта. Однако, как
и при любой работе с бэклогом, лучше всего расставлять
приоритеты всей scrum-командой. В этом случае исполь-
зуется коллективный опыт команды и поддерживается
мотивация.
114 Управление продуктом в Scrum
Ценность
Возможность выпуска
Взаимозависимости
Подготовка к планированию
спринта
Перед каждым совещанием по планированию спринта
нужно подготовить элементы бэклога продукта, которые,
по всей вероятности, будут реализованы в ходе ближай-
шего спринта. Начинать следует с выбора цели спринта.
Размер
Большие
необра-
Большой ботанные
элементы
Декомпозиция элементов