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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Managing Partner

+7 495 221 87 39

dmitry@onagile.ru

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