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

Roman Pichler

AGILE PRODUCT MANAGEMENT WITH SCRUM

Creating Products that Customers Love

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

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

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

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

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

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

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

Deadline

Том Демарко

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

Джим Коллинз

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

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

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

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

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