Управление продуктом в SCRUM - Роман Пихлер - E-Book

Управление продуктом в SCRUM E-Book

Роман Пихлер

0,0

Beschreibung

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

Sie lesen das E-Book in den Legimi-Apps auf:

Android
iOS
von Legimi
zertifizierten E-Readern
Kindle™-E-Readern
(für ausgewählte Pakete)

Seitenzahl: 158

Veröffentlichungsjahr: 2016

Das E-Book (TTS) können Sie hören im Abo „Legimi Premium” in Legimi-Apps auf:

Android
iOS
Bewertungen
0,0
0
0
0
0
0
Mehr Informationen
Mehr Informationen
Legimi prüft nicht, ob Rezensionen von Nutzern stammen, die den betreffenden Titel tatsächlich gekauft oder gelesen/gehört haben. Wir entfernen aber gefälschte Rezensionen.



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

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

Джефф Сазерленд

Deadline

Том Демарко

От хорошего к великому

Джим Коллинз

Roman Pichler

AGILE PRODUCT MANAGEMENT WITH SCRUM

Creating Products that Customers Love

Addison-Wesley2010

Роман Пихлер

УПРАВЛЕНИЕ ПРОДУКТОМ В SCRUM

Agile-методы для вашего бизнеса

Москва «Манн, Иванов и Фербер» 2017

Информация от издательства

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

На русском языке публикуется впервые

Книга рекомендована к изданию Лианой Мартиросян и Наталией Юлдашевой

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

Пихлер, Роман

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

ISBN 978-5-00100-354-0

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

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

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

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

Authorized translation from the English language edition, entitled Agile product management with Scrum: creating products that customers love, 1st edition, published by Pearson, publishing as Addison-Wesley Professional.

© Roman Pichler, 2010

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

СОДЕРЖАНИЕ

Предисловие Джеффа Сазерленда
Предисловие Бретта Квинера
Предисловие
Чем отличается agile-управление продуктом
Что предлагает эта книга и кто должен ее прочесть
1. Кто такой владелец продукта?
Роль владельца продукта
Характеристики правильного владельца продукта
Визионер и человек действия
Лидер и командный игрок
Пропагандист и переговорщик
Наделенный полномочиями и преданный делу
Доступный и квалифицированный
Работа с командой
Взаимодействие со scrum-мастером
Работа с клиентами, пользователями и другими заинтересованными лицами
Моделирование роли владельца продукта
Главный владелец продукта
Иерархия владельцев продукта
Как правильно выбрать владельцев продукта
Распространенные ошибки
Владелец продукта с недостаточными полномочиями
Перегруженность владельца продукта
Частичный владелец продукта
Удаленный владелец продукта
Заместитель владельца продукта
Комитет владельцев продукта
Вопросы для самоконтроля
2. Планирование концепции продукта
Видение продукта
Желаемые качества видения
Общее и объединяющее
Широкое и мотивирующее
Краткое и приятное
Минимально функциональный продукт
Простота
Бритва оккама
Чем меньше, тем лучше
Простые пользовательские интерфейсы
Потребности покупателя и свойства продукта
Рождение видения продукта
Любимые проекты
Использование Scrum
Техники формирования видения
Прототипирование и макетирование
Персоны и сценарии
Визуализация и обзор в отраслевом журнале
Модель Кано
Формирование видения и дорожная карта продукта
Минимальные продукты и варианты продукта
Распространенные ошибки
Отсутствие видения
Пророческое видение
Аналитический паралич
«Мы-лучше-знаем-что-нужно-клиентам»
«Большое — значит хорошее»
Вопросы для самоконтроля
3. Работа с бэклогом продукта
Глубинные свойства бэклога продукта
Достаточная степень детализации
Оценка
Развитие
Приоритетность
Работа над бэклогом продукта
Выявление и описание элементов
Выявление элементов
Описание элементов
Структурирование бэклога продукта
Расстановка приоритетов в бэклоге продукта
Ценность
Знания, неопределенность и риск
Возможность выпуска
Взаимозависимости
Подготовка к планированию спринта
Выбор цели спринта
Когда нужно и ровно столько, сколько нужно
Декомпозиция элементов
Обеспечение четкости, проверяемости и осуществимости
Определение масштабов элементов
Очки историй
Покерное планирование
Работа с нефункциональными требованиями
Описание нефункциональных требований
Управление нефункциональными требованиями
Бэклог продукта при масштабировании
Использование единого бэклога продукта
Расширьте горизонт груминга
Создайте различные видения бэклога продукта
Распространенные ошибки
Замаскированная спецификация
Список просьб к санта-клаусу
Навязывание требований
Пренебрежение грумингом
Конкурирующие бэклоги продуктов
Вопросы для самоконтроля
4. Планирование релиза
Время, затраты и функциональность
Стабильность качества
Быстрые и частые релизы
Квартальные циклы
Скорость
Диаграмма сгорания работ для релиза
График сгорания работ для релиза
Столбиковая диаграмма сгорания работ
План релиза
Прогнозирование скорости
Составление плана релиза
Планирование релизов в больших проектах
Общие ориентиры для оценок
Перспективное планирование
Конвейерная работа
Распространенные ошибки
Отсутствие диаграммы сгорания работ или плана релиза
Владелец продукта в кресле пассажира
Взрывной релиз
Работа в ущерб качеству
Вопросы для самоконтроля
5. Совместная работа на совещаниях по спринту
Планирование спринта
Критерии готовности
Ежедневный scrum-митинг
Спринт-бэклог и диаграмма сгорания работ для спринта
Обзор итогов спринта
Ретроспективный анализ спринта
Совещания по спринтам в крупных проектах
Совместное планирование спринта
Scrum-совещание по Scrum
Демонстрация результатов спринта
Совместная ретроспектива спринта
Распространенные ошибки
Владелец продукта — «чайка»
Незаинтересованный владелец продукта
Нежизнеспособный темп
Стремление создать иллюзию
Включение в отчет диаграммы сгорания задач спринта
Вопросы для самоконтроля
6. Превращение во владельца продукта
Как стать отличным владельцем продукта
Познайте себя
Развитие и рост
Найдите наставника
Убедитесь в поддержке на нужном уровне
Вы еще не готовы
Как развивать владельцев продукта
Осознайте важность роли
Выбирайте правильного владельца продукта
Наделяйте владельцев продукта полномочиями и поддерживайте их
Поддерживайте институт владельцев продукта в компании
Вопросы для самоконтроля
Библиография
Благодарности
Об авторе

Посвящается Мелиссе

ПРЕДИСЛОВИЕ ДЖЕФФА САЗЕРЛЕНДА

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

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

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

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

Джефф Сазерленд,

один из создателей Scrum

ПРЕДИСЛОВИЕ БРЕТТА КВИНЕРА

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

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

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

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

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

Бретт Квинер,

старший вице-президент по продукту Salesforce.com

ПРЕДИСЛОВИЕ

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

В 1999 году я познакомился с agile-идеологи­ей, и ме­ня поразило тесное сотрудничество между техниче­скими и бизнес-специалистами и технарями. Я всегда считал, что разработка ПО — это то, что интересует гиков2, но не бизнесменов­. Занимаясь коучингом своего первого 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

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

ЧТО ПРЕДЛАГАЕТ ЭТА КНИГА И КТО ДОЛЖЕН ЕЕ ПРОЧЕСТЬ

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

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

Эта книга предполагает, что вы знакомы со Scrum и обладаете актуальными познаниями в области управления продуктом.

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

1

КТО ТАКОЙ ВЛАДЕЛЕЦ ПРОДУКТА?

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

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

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

РОЛЬ ВЛАДЕЛЬЦА ПРОДУКТА

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

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

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

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

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

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

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

ХАРАКТЕРИСТИКИ ПРАВИЛЬНОГО ВЛАДЕЛЬЦА ПРОДУКТА

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

ВИЗИОНЕР4 И ЧЕЛОВЕК ДЕЙСТВИЯ

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

ЛИДЕР И КОМАНДНЫЙ ИГРОК

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

Двойственная природа владельца продукта (как лидера и командного игрока) накладывает свои ограничения. Он ни в коем случае не должен быть диктатором, но в то же время не может себе позволить нерешительности и мягкотелости в управлении.

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

КОМАНДА ПРЕДПРИНИМАТЕЛЕЙ