Кому будет интересно:
- Владельцам продукта и менеджерам, которые хотят ими стать.
- Скрам-мастерам, коучам, участникам команды.
- Всем, кто хочет разобраться, как Agile помогает создавать успешные продукты.
Видение продукта в Scrum
«В любом случае концептуальная работа [по формированию видения продукта] должна быть сведена к минимуму — важно быстро выпустить первый вариант продукта или демоверсию для клиентов и пользователей. Прислушайтесь к рецензиям, и поймете, на правильном ли вы пути. Затем внесите изменения».
«В начале нового проекта мы часто не имеем представления о том, чего именно не знаем. Более того, наша целевая группа покупателей и основные пользователи находятся в таком же положении, поэтому не могут сразу объяснить, как должен выглядеть и работать наш продукт. Таким образом, формирование видения лучше всего понимать как процесс открытия, обретения знания и обучения, которое требует экспериментов».
«Компании часто совершают ошибку — пытаются найти идеальное решение, которое с первого же дня всех устроит. Часто это выливается в создание слишком больших и сложных продуктов, которые не очень хорошо функционируют». <…> «Этой ошибки можно избежать, начав с работы над продуктом, призванным удовлетворить узкий набор клиентских требований и предлагающим минимальную, но достаточную функциональность».
Работа с бэклогом продукта
«Хотя владелец продукта отвечает за хорошее состояние бэклога продукта, работа над ним — это командный процесс. Выявляются и описываются элементы, они выстраиваются по приоритету, декомпозируются и детализируются scrum-командой».
«Выявление и описание элементов бэклога продукта – это постоянный процесс. Если вы привыкли составлять полные и подробные спецификации, смиритесь с тем, что Scrum поддерживает совершенно иной подход. Требования больше не замораживаются на ранней стадии – они выявляются и детализируются в течение всего проекта».
«Определение приоритетов [в бэклоге продукта] требует решить, насколько значим тот или иной элемент. Если у всех высокий приоритет, значит, все одинаково важны. На самом деле это значит, что приоритета нет вообще и шансы создать то, что действительно нужно покупателю, очень невелики».
«Избыточное количество информации [в описании элементов бэклога] — это пустая трата сил. Подробно описывая лишь те элементы, которые, вероятнее всего, понадобятся для следующего спринта, мы даем бэклогу продукта возможность развиваться».
«Мне встречались организации, которые, привыкнув к предварительному составлению детального плана проекта, бросались в другую крайность и вообще отказывались от планирования релиза. Жить от спринта к спринту опасно, а попасть в эту ловушку довольно легко. Из-за этого трудно оценить прогресс проекта и внести нужные изменения в продукт и проект».
Совместная работа команды и Владельца продукта
«Как команда понимает, что работа действительно сделана? И как владельцу продукта определить, что какой-то участок работы был успешно внедрен? Для этого необходимо заранее разработать критерии готовности, то есть описание требований, которым должно соответствовать каждое обновление. <…> Перед первым спринтом владелец продукта должен встретить со scrum-мастером и командой и выработать критерии готовности».
«Нерешенные проблемы множатся как грибы после дождя. Вот почему Scrum уделяет особое внимание борьбе с препятствиями — выявлению и устранению проблем, которые мешают работе и причиняют вред проекту. Члены команды рассказывают о препятствиях и проблемах на ежедневном scrum-митинге, и scrum-мастер отвечает за то, чтобы они были устранены как можно быстрее».
«Обзор итогов спринта способствует созданию успешного продукта. <…> Отметим, что подготовка к обзору должна быть сведена к минимуму. Обзор — это рабочая процедура, а не шоу. Командам стоит воздержаться от формальных презентаций и не использовать слайды».
«К сожалению, очень часто на демонстрации результатов спринта владельцы продукта ведут себя как посторонние. Но демо — это не шоу, которое вы смотрите из зала. Его цель – выяснить, что должно быть сделано для увеличения шансов на создание успешного продукта. И владелец продукта должен активно вносить свой вклад в совещание, чтобы гарантировать правильное развитие продукта».
Разработка продукта похожа на марафон. Если вы хотите финишировать, нужно подобрать оптимальный темп. Многие РО совершают ошибку, оказывая на команду давление, чтобы она работала активнее. <…> Если дело движется медленно, соберите совещание, чтобы найти подходящее решение. Но не требуйте от сотрудников, чтобы они работали больше.
«Раннее погружение владельцев продукта в agile-принципы и их обучение, создание бэклога продукта и пользовательских историй, оценка и планирование – вот ключи к успеху любой agile-команды».
Если вы только начинаете свой путь в роли Владельца продукта, посмотрите на Типичные ошибки работы с новой Scrum-командой и Как создать бэклог продукта.