«Управление продуктом в Scrum». Советы для бизнеса из книги Р.Пихлера | OnAgile Consulting

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

Какие ошибки мешают создавать успешный продукт. Как развивать видение продукта и работать с бэклогом. Важные цитаты из книги «Управление продуктом в Scrum: Agile-методы для вашего бизнеса» Романа Пихлера.

Кому будет интересно:

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

Видение продукта в Scrum

«В любом случае концептуальная работа [по формированию видения продукта] должна быть сведена к минимуму — важно быстро выпустить первый вариант продукта или демоверсию для клиентов и пользователей. Прислушайтесь к рецензиям, и поймете, на правильном ли вы пути. Затем внесите изменения».

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

«Компании часто совершают ошибку — пытаются найти идеальное решение, которое с первого же дня всех устроит. Часто это выливается в создание слишком больших и сложных продуктов, которые не очень хорошо функционируют». <…>  «Этой ошибки можно избежать, начав с работы над продуктом, призванным удовлетворить узкий набор клиентских требований и предлагающим минимальную, но достаточную функциональность».

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

«Хотя владелец продукта отвечает за хорошее состояние бэклога продукта, работа над ним — это командный процесс. Выявляются и описываются элементы, они выстраиваются по приоритету, декомпозируются и детализируются scrum-командой».

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

«Определение приоритетов [в бэклоге продукта] требует решить, насколько значим тот или иной элемент. Если у всех высокий приоритет, значит, все одинаково важны. На самом деле это значит, что приоритета нет вообще и шансы создать то, что действительно нужно покупателю, очень невелики».

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

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

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

«Как команда понимает, что работа действительно сделана? И как владельцу продукта определить, что какой-то участок работы был успешно внедрен? Для этого необходимо заранее разработать критерии готовности, то есть описание требований, которым должно соответствовать каждое обновление. <…> Перед первым спринтом владелец продукта должен встретить со scrum-мастером и командой и выработать критерии готовности».

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

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

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

Разработка продукта похожа на марафон. Если вы хотите финишировать, нужно подобрать оптимальный темп. Многие РО совершают ошибку, оказывая на команду давление, чтобы она работала активнее. <...> Если дело движется медленно, соберите совещание, чтобы найти подходящее решение. Но не требуйте от сотрудников, чтобы они работали больше.

«Раннее погружение владельцев продукта в agile-принципы и их обучение, создание бэклога продукта и пользовательских историй, оценка и планирование – вот ключи к успеху любой agile-команды».

Если вы только начинаете свой путь в роли Владельца продукта, посмотрите на Типичные ошибки работы с новой Scrum-командой и Как создать бэклог продукта.

Интересно узнать подробнее?

Приходите на один из наших тренингов, где вы в деталях разберете эту тему и сможете задать тренеру свои вопросы.

Вопросы и ответы по теме

Почему классические методы разработки продукта убивают инновации в бизнесе?

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

Как избежать главной ловушки при ведении бэклога продукта в Scrum?

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

Какой неожиданный подход к демонстрации результатов спринта использует Scrum?

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

Почему формирование видения продукта в Scrum противоречит здравому смыслу?

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

Как опытные владельцы продукта избегают выгорания команды в Scrum?

Успешные Product Owner не давят на команду ради повышения скорости работы. Вместо этого они организуют обсуждение для поиска системных решений и уделяют особое внимание устранению препятствий, которые выявляются на ежедневных встречах.

В чем секрет правильной приоритизации задач в бэклоге продукта?

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

Еще публикации по Agile в Управление продуктами

Как создать бэклог продукта в Scrum
Публикация Управление продуктами

Как создать бэклог продукта в Scrum

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

Lean Customer Development, или Бережливое развитие потребителей
Публикация Управление продуктами

Lean Customer Development, или Бережливое развитие потребителей

Важные цитаты из книги С. Альварес «Как создать продукт, который купят. Метод Lean Customer Development».

Почему мы мыслим короткими циклами, но не хотим переходить на Scrum
Публикация Управление продуктами

Почему мы мыслим короткими циклами, но не хотим переходить на Scrum

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

Ближайшее обучение по Agile и Scrum

С 2015 года мы помогаем адаптировать к изменениям культуру и процессы компании

Связаться с нами

Дмитрий Лобасев

Managing Partner

+7 495 221 87 39

dmitry@onagile.ru

Наш Telegram канал об Agile и гибких организациях, присоединяйтесь!