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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Публикация
Разработка ПО
Подборка книг о проектировании и запуске прорывных продуктов
Эта подборка книг — для тех, кто связан с проектированием, запуском и развитием продуктов в компаниях.
Публикация
Управление продуктом
Backlog refinement (grooming): чем полезна регулярная актуализация бэклога
Запросы бизнеса всегда превышают возможности команд по их реализации. Практика backlog refinement помогает контролировать постоянно растущий бэклог.
Публикация
Управление продуктом
Практика Scrum: как создать бэклог продукта
Пошаговый алгоритм создания бэклога продукта для Scrum-команд.
Публикация
Управление продуктом
Как создать успешный продукт. Фреймворк Jobs To Be Done
Концепция Jobs To Be Done помогает определиться с видением продукта и отдельными его функциями, которые будут привлекательны для пользователей.

Мы помогаем организациям с 2004 года

Свяжитесь с нами

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

Managing Partner

+7 495 221 87 39

dmitry@onagile.ru

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