Комментарии, вопросы, пожелания приветствуются.
Буду рад ответить на ваши вопросы: alimbekovr@hotmail.com.

1 заметка с тегом

Техники формирования видения продукта

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

Аннотация

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

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

Роман Пихлер Управление продуктом в SCRUM Agile методы для вашего бизнеса
Издательство: Манн, Иванов и Фербер— 2017

Скачать краткий конспект в формате Word или pdf.

Купить цифровую книгу в Ozon или ЛитРес, бумажную книгу в FLIP или Ozon.

Введение

Не так давно попала мне в руки новая книга по Scrum Романа Пихлера — Управление продуктом в SCRUM Agile методы для вашего бизнеса. Книга оказалось очень интересной, понятной и она содержит много полезных нюансов, которых нет в скрайм-гайде. Наиболее интересные моменты постараюсь описать в этом конспекте.

Характеристики правильного владельца продукта

Визионер и человек действия способный оценить трудоемкость всех этапов работы вплоть до ее завершения. Он может описывать требования, тесно сотрудничать с командой, принимать или отвергать рабочие результаты и руководить проектом, отслеживая и предсказывая его прогресс.
Лидер и командный игрок, отвечая за успех продукта, он обеспечивает руководство всеми, кто занят разработкой, и готов принимать сложные решения. Например, укажет, отложить дату запуска или ограничиться меньшей функциональностью. В то же время владелец продукта — командный игрок, он вступает в тесное сотрудничество с другими членами scrum-команды и не обладает формальной властью над ними. Мы можем определить владельца продукта как primus inter pares — первого среди равных в том, что касается продукта.
Пропагандист и переговорщик- этот человек общается с разными сторонами, объединяя клиентов, пользователей, разработчиков, инженеров, маркетологов, сотрудников отдела продаж, операционных сотрудников и руководство.
Наделенный полномочиями и преданный делу — владелец продукта должен обладать полнотой власти для принятия решений, касающихся любых аспектов — подбора подходящих членов команды, определения того, какая функциональность будет входить в тот или иной релиз, и т. д
Доступный и квалифицированный владелец продукта должен быть доступным и иметь нужный уровень квалификации. Его роль обычно предполагает полную занятость. Важно предоставить владельцам продукта достаточно времени для эффективного выполнения своих обязанностей. Если человек перегружен, от этого страдает результат, а получившийся продукт бывает не оптимальным.

Распространенные ошибки при выборе владельцев продукта

  1. Владелец продукта с недостаточными полномочиями
  2. Перегруженность владельца продукта
  3. Частичный владелец продукта
  4. Удаленный владелец продукта
  5. Заместитель владельца продукта
  6. Комитет владельцев продукта

Техники формирования видения продукта

Прототипирование и макетирование — формирование видения лучше всего понимать как процесс открытия, обретения знания и обучения, которое требует экспериментов. В экспериментах исследуются причинно-следственные взаимоотношения, когда процесс манипулирования причиной идет до тех пор, пока не будет получено желаемое следствие. Это одновременно и поощрение открытого, исследовательского, живого ума, и следование строгим процедурам. Ключ к эффективному эксперименту состоит в быстром получении необходимого знания посредством внедрения и тестирования прототипов и макетов, которые служат средствами создания знания и обучения. Они помогают понять, как должен выглядеть и работать продукт, какая технология и архитектура будут для него наиболее успешны, насколько вообще осуществима идея.
Планирование, выполнение, проверка и воздействие — организованный эксперимент проходит по четырехшаговой модели, известной также как цикл Деминга. Сначала мы вырабатываем гипотезу(планирование). Затем воплощаем ее (выполнение) и анализируем результаты (проверка). Если эксперимент оказался неудачным, мы вносим в гипотезу изменения, где необходимо, и проводим следующий эксперимент — либо для достижения лучшего результата, либо чтобы попробовать другой подход (воздействие).
Персоны и сценарии — персона — это «гипотетический архетип», представляющий целевого клиента или пользователя. Можно считать персону частным случаем носителя пользовательского сценария или пользовательской роли. Сформировав корректно персоны, мы можем исследовать то, как продукт, который мы собираемся разрабатывать, будет влиять на их жизнь. Для этого создаем сценарии, которые описывают, как персона достигает своих целей без продукта и с ним.
Модель Кано — она рассказывает, насколько может быть удовлетворен покупатель при внедрении определенного свойства продукта. В модели разграничиваются три типа функций: основные, производительные и привлекательные. Рассмотрим работу модели Кано на примере мобильного телефона. Основные функции мобильного телефона — это его включение и выключение, совершение и прием звонков, создание, отправка, получение и чтение текстовых сообщений. Эти рудиментарные функции необходимы, чтобы продать продукт, но удовлетворенность покупателя ими быстро исчерпывается. Например, если добавить еще одну кнопку для включения и выключения телефона, это не создаст никакой дополнительной ценности. Невозможность обеспечить основные функции обычно делает продукт бесполезным. Производительные функции, как правило, приводят к прогрессивному повышению удовлетворения. Они следуют принципу «чем больше, тем лучше». Например, чем легче телефон и чем быстрее он включается, тем более удовлетворенными, вероятнее всего, будут клиенты. Они не могут насытиться требованиями производительности. Однако производительных функций недостаточно, чтобы продукт существенно отличался от всего остального на рынке. Привлекательные функции, как свидетельствует название, призваны привлекать и восхищать покупателей. Интересный дизайн продукта и способность индивидуализировать телефон — это примеры привлекательных функций. Они могут удовлетворять скрытые потребности клиентов, о которых те могли и не догадываться. Именно эти функции продукта создают конкурентное преимущество и уникальное коммерческое предложение.
Дорожная карта продукта — это тип плана, который показывает, как продукт должен развиваться в своих версиях, и облегчает диалог между scrum-командой и заинтересованными лицами. Дорожная карта продукта позволяет организациям координировать разработку и запуск смежных продуктов — например, линейки продуктов или продуктового портфеля. Рекомендуется не усложнять план развития продукта, а сосредоточиться на самой сути. План развития продукта должен содержать примерную дату выхода следующей версии, указание целевых потребителей и их нужд и три-пять основных функций.

Распространенные ошибки при формировании видения продукта

  1. Отсутствие видения
  2. Пророческое видение
  3. Аналитический паралич
  4. «Мы-лучше-знаем-что-нужно-клиентам»
  5. «Большое — значит хорошее»

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

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

  1. Выявляются и описываются новые элементы, а существующие при необходимости изменяются или удаляются.
  2. Происходит расстановка приоритетов. Самые важные задачи помещаются в верхнюю часть.
  3. Высокоприоритетные элементы подготавливаются к ближайшему совещанию по планированию спринта. Они декомпозируются и детализируются.
  4. Команда определяет масштаб элементов бэклога продукта. Это необходимо ввиду внесения в него новых элементов, изменения существующих и исправления оценок.

Планирование релиза

Планирование релиза начинается с принятия решения о том, какая из составляющих проекта — время, затраты или функциональность — должна остаться неизменной для запуска успешного продукта. Необходим ли запуск именно в указанную дату? Жестко ли задан бюджет на разработку? Нужно ли реализовать все требования, отраженные в бэклоге продукта? Одновременная фиксация времени, бюджета и функциональности невозможна. По крайней мере одна из составляющих должна играть роль высвобождающего клапана. Самое удачное решение — ограничить время и делать гибкой функциональность.
Фиксирование функциональности — плохой вариант. Даже при наличии видения продукта его точные свойства, функциональность и особенности не известны сразу. Они открываются постепенно, на основе отзывов клиентов и пользователей. Появляются новые требования, бэклог продукта развивается по мере того, как scrum-команда больше узнает о потребностях клиентов и возможностях их удовлетворения. Попытка фиксировать функциональность вредит способностям команды адаптировать продукт к отзывам пользователей. В результате получится не тот продукт, который могут полюбить покупатели.
План релиза — это своего рода карта, показывающая нам направление. Он показывает, насколько мы приблизились к выпуску продукта и когда он состоится. Можно сказать, что план релиза — это расширенная версия диаграммы сгорания работ. Он не только содержит больше информации, но и более комплексный. План релиза основывается на четырех факторах: элементах бэклога продукта, оставшегося объема работ, скорости команды и времени. План релиза не является фиксированным. Он меняется вместе с развитием бэклога продукта, а также нашего понимания оставшегося объема работ и скорости. Как и диаграмму сгорания работ, план релиза лучше всего составлять и обновлять совместными усилиями команды во время демонстрации результатов спринта

Прогнозирование скорости

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

Критерии готовности

Как команда понимает, что работа действительно сделана? И как владельцу продукта определить, что какой-то участок работы был успешно внедрен? Для этого необходимо заранее выработать критерии готовности, то есть описание требований, которым должно соответствовать каждое обновление. Эти критерии обычно требуют превращения элементов бэклога продукта в работающие программы, тщательно протестированные и задокументированные. Требования должны быть соответствующим образом внедрены, протестированы и задокументированы в ходе одного спринта. Исключение — концептуальные спринты, цель которых — не выдать готовый продукт, а получить необходимые для создания концепции продукта знания. У этих спринтов есть собственные критерии готовности.
Перед первым спринтом владелец продукта должен встретиться со scrum-мастером и командой и выработать критерии готовности. В некоторых проектах в критерии готовности включаются конкретные цели — например тестирование единиц ПО. После выработки критериев они должны быть записаны и доступны в течение всего проекта.

Вывод

Отличная книга для тех, кто только начал знакомится с фрэймворков Scrum так и для тех, кто уже в теме, эта книга поможет взглянуть по-новому. Рекомендую.