4. Управление продуктом

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

Для эффективного и непротиворечивого управления  беклогом  следует использовать два правила:

  1. Добавлять истории пользователей в беклог может, кто угодно.
  2. Определять порядок реализации, путем выставления важности, может только владелец продукта.

Построение бизнес модели

Наиболее подробно построение бизнес моделей описано в работе Александра Остервальда и Ива Пинье «Построение бизнес моделей. Настольная книга стратега и новатора». Бизнес-канвасы представляют собой способ визуализации бизнес модели и их можно адаптировать к проектам по разработки ПО (Филиппов, и др., 2011):

Проблемы

3 самые важные проблемы заказчиков

Решения Функциональность продукта, которая решает проблемы

Уникальное

предложение

Простое и

понятное

сообщение,

почему

заказчик

должен

выбрать

именно вас

Преимущество Что нельзя быстро скопировать или купить

Сегменты заказчиков Заказчики или конечные пользователи вашего продукта

Метрики оценки Как можно понять, что ваш продукт успешно решает проблемы?

Каналы продаж Как ваш продукт достигнет ваших заказчиков?

Структура затрат

На что вы будете тратить деньги при изготовлении продукта?

Потоки прибыли

Как вы будете получать прибыль?

Такую визуализацию лучше всего проводить при помощи стикеров на доске с участием всей команды и заинтересованных лиц, например, маркетологов и продавцов.

Персоны

Практика анализа персон («Personas») пришла в управление продуктами из практик User Experience. Она заключается в описании пользователей создаваемого продукта как реального персонажа с конкретными ценностями и целями.

Сторимаппинг

После выявления персон необходимо перейти к выявлению функционала, который необходимо реализовать для персон. Для этого используется сторимаппинг («story mapping») – способ визуализации и планирования функционала.

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

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

  • дополнительных возможностей;
  • безопасности;
  • удобства использования;
  • производительности.

Чем ниже мы опускаемся по подзадачам, тем меньше у них важность:

Беклог продукта

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

  • Уникальный числовой идентификатор истории – обычно совпадает с идентификатором истории пользователя из трекера, которым пользуется команда.

Этот идентификатор позволяет точно сказать, о какой истории пользователя в данный момент идет речь.

  • Название истории пользователя – короткое (примерно до 10 слов) описание функционала с точки зрения пользователя, сформулированное в виде тройки «Роль», «Действие», «Цель». Например: «Пользователь вводит логин и пароль для того, чтобы авторизоваться на сайте».
  • Важность – уникальный числовой приоритет истории пользователя, чем она выше, тем раньше данную историю необходимо сделать.
  • Оценка – числовая относительная оценка истории пользователя по специальной шкале. Указанные поля удобно размещать на стикере, который прикрепляется на доску.

Например, историю пользователя для авторизации на сайте с оценкой в 10 сторипоинтов, важностью 200 и номером в трекере 1453, можно представить на стикере так:

Данные четыре поля являются фактически обязательными, но достаточно часто используются и дополнительные поля, которые, например, заносятся в трекер:

  • Подробное описание – текстовое и графическое описание истории пользователя. Применяется, прежде всего, в распределенных командах для хранения знаний о функционале продукта.
  • Демонстрация – достаточно подробный сценарий, позволяющий провести демонстрацию истории пользователя. Например, для вышеприведенной истории пользователя с авторизацией, можно использовать следующие краткие сценарии для демонстрации:
  1. Пользователь вводит логин «root» и пароль «pass», и переходит на страницу личного профиля на сайте.
  2. Пользователь вводит логин «root» и пароль «wrongpass», и получает сообщение «Введен неправильный логин или пароль».
  • Категория – используется для повышения управляемости с помощью категоризации задач. В качестве категорий могут выступать как продуктовые категории («темы» и «эпики» в терминологии Scrum), так и категории типа «Оптимизация производительности», «Техническая история» и тому подобные.

Размер беклога и стратегическое планирование

Для сохранения управляемости необходимо поддерживать минимальный размер беклога, но для стратегического планирования, скажем, на несколько кварталов вперед, необходимо иметь достаточно длинный беклог. Используя нотацию «грозовых туч» Э. Голдратта, это противоречие можно изобразить следующим образом:

Какой бы размер беклога мы ни выбрали, у нас все равно не получится разрешить конфликт – нам нужно прорывное решение. Оно достаточно просто и лежит на поверхности: использовать метод «набегающий волны» («rolling wave planning»). В рамках Scrum такой подход означает, что мы разбиваем очень подробно истории пользователей на несколько ближайших спринтов, а остальные истории пользователей – храним в виде больших кусков функциональности, подробно не описывая их. Такие большие истории пользователей, которые в дальнейшем будут разбиты на маленькие, называются «эпиками» («epic»):

Как вы видите, чем позднее планируется реализация того или иного функционала, тем более крупные куски функционала берутся. Отмечу, что это также согласуется полностью с принципами KISS и YAGNI.

Технические истории

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

  • Рефакторинг модуля
  • Оптимизация производительности
  • Исправления сложного дефекта
  • Настройка инфраструктуры

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

Определение приоритетов историй пользователя

Владелец продукта определяет порядок реализации функционала путем установки приоритетов, выбирая истории пользователей с наибольшей ценностью. Классическим представлением является мысль о том, что чем больше будет функционала в продукте, тем выше будет удовлетворенность конечного пользователя.

Давайте рассмотрим более точную модель – модель удовлетворения потребностей Кано. Японский профессор Нориаки Кано предложил в работе «Привлекательное качество и необходимое качество» еще в 1982 году.

Разделим всю функциональность продукта на три категории в соответствии с удовлетворенностью пользователя и полнотой функциональности продукта:

Таким образом, можно выделить три типа функций продукта:

  1. Обязательные функции – пользователь ждет этих функций от продукта, без них ему продукт не нужен. Например, для сотового телефона – эта возможность совершать звонки.
  2. Линейные функции – чем больше и качественней они реализованы, тем больше доволен пользователь. Например, долгая работа сотового телефона без перезарядки.
  3. Привлекательные функции – функции, которые придают вашему продукту «wow»- эффект. В качестве примера можно рассмотреть эргономику и юзабилити Apple IPhone.

Владелец продукта может либо воспользоваться своей интуицией и опытом для отнесения функционала к той или иной категории или собрать небольшую группу потенциальных (20-30 человек) и провести в ней опрос. Для оценки мы будем рассматривать отдельные истории пользователей либо целые эпики и задавать по каждой истории пользователю два вопроса:

  1. Как вы отнесетесь к наличию данной функциональности в продукте?
  2. Как вы отнесетесь к отсутствию данной функциональности в продукте?

Кроме функциональных требований (историй пользователей) можно проводить и анализ по нефункциональным требованиям и отображать их соответствующим образом в беклоге продукта.

В качестве ответов опрашиваемому пользователю предлагаются следующие варианты ответов:

  • нравится
  • ожидаю этого
  • всё равно
  • могу смириться с этим
  • не нравится это

После такого опроса можно проводить анализ результатов при помощи следующей таблицы:

 

 

Отсутствует

 

 

Нравится

Ожидаю этого

Все равно

Могу смириться с этим

Не нравится

Присутствует

Нравится

Q

A

A

A

O

Ожидаю этого

R

I

I

I

M

Все равно

R

I

I

I

M

Могу смириться с этим

R

I

I

I

M

Не нравится

R

R

R

R

Q

В результате функции продукта разобьются на шесть категорий:

  • A (attractive) – привлекательный;
  • O (one–dimensional) – линейные;
  • M (must–be) – обязательные;
  • R (reverse) – обратные (ненужные функции);
  • Q (questionable result) – сомнительный/противоречивый результат;
  • I (indifferent) – безразлично;

Первые три категории для нашего анализа и являются самыми интересными и дают нам более глубокое понимание требований по нашему продукту:

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

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

Таким образом, можно сделать выводы к каким типам относятся те или иные функции исследуемого продукта.

Первая часть - Вольфсон Борис "Гибкие методологии разработки" - Часть 1

Вторая часть - Вольфсон Борис "Гибкие методологии разработки" - Часть 2

Третья часть - Вольфсон Борис "Гибкие методологии разработки" - Часть 3

Скоро -  Четвертая часть - Вольфсон Борис "Гибкие методологии разработки" - Часть 4

Последние статьи из раздела "Про управление проектами":

Кейс: как ускорить развитие проекта

Публикую этот пост, чтобы он всегда был "под рукой". Авторство и повествование от имени Carrot Quest. Представители ФРИИ, Илья Красинский и Carrot Quest провели воркшоп, главной задачей которого было улучшение юнит-экономики 5 стартапов. ... читать далее
10.01.18

Что такое эскалация в управлении проектами и зачем она нужна?

Отдельно хочу отметить, что я являюсь поклонницей Юлии Бажановой. Статья - Что такое эскалация в управлении проектами и зачем она нужна? - ее авторства. Юлия легко и непринужденно рассказывает о проектном менеджменте. ... читать далее
12.12.17

Что такое тестирование. Большая и крайне полезная статья от Алексея Баранцева

Гарантирование качества возможно при наличии инструментов опережающих технологии находящиеся у потребителя. Специалист QA всегда находиться на передовой IT технологий и умеет предугадать некоторые баги еще до их официального появления.... читать далее
12.12.17

Возможно Вам будут интересны другие статьи из разделов:

Интересно, полезно? Поделитесь у себя:



comments powered by HyperComments