Это третья публикация цикла статей из жизни продуктового приоритизатора.
В предыдущей статье цикла мы говорили о том, что такое жизненный продукта и как он может влиять на выбор метода приоритезации.
Сегодня обсудим, как приоритизация бизнес-целей отличается от приоритизации низкоуровневых пользовательских историй, и как учитывать контекстные факторы при выборе метода приоритизации.
Предыдущие статьи цикла можно найти здесь:
Следующий фактор, который нужно учесть, выбирая инструмент для приоритизации - уровень или глубина
На рисунке 3 уровня:
Белый для работы с абстрактными элементами, такими как бизнес-цели и бизнес-требования (называются они по-разному в разных источниках, я через слэш привела наиболее употребимые). Пример “белого” элемента: стать лидером рынка почтовых сервисов в сегменте для домашних хозяек Германии
Голубой - для более конкретного функционала, это уже эпики. Например, функция архивирования писем
Индиго - уже конкретные истории, которые пойдут в разработку
Любая статья на тему приоритизации содержит предостережение: если вы не можете договориться по поводу приоритетов высокоуровневых целей, по поводу vision, то приоритезация функций любого уровня преждевременна.
Она пока не имеет смысла, так как нет базы.
Только по мере приоритизации высокоуровневых целей, можно опускаться ниже
Опять же, повторюсь, на каждом уровне - свои техники приоритизации
Как вы наверняка понимаете, мнение клиента имеет смысл спрашивать на уровне больших фич продукта, а не того, где разместить кнопку “купить” на конкретной странице. Про кнопку, кстати, должно быть понятно на основании приоритизации более высокоуровневых сценариев. Если у нас сценарий “покупка” важнее сценария “читать отзывы” (как же иначе?), то и положение соответствующих элементов очевидно. A/B тесты помогут проверить сформированную таким образом гипотезу о положении кнопки.
Вот еще что. На низких уровнях команда может выполнять приоритизацию самостоятельно. Так гораздо эффективнее. Имея приоритеты высокого уровня, трассируемые на пользовательские истории (или что там у вас низкоуровневое), можно без труда сказать, какую историю нужно делать вначале, а какую отложить навсегда ;)
В предыдущих разделах мы говорили о том как вопрос “ЧТО” мы приоритизируем, влияет на то, “КАК” мы это делаем. Давайте теперь попробуем понять, как учитывать ваш контекст, то какие ресурсы нам доступны и "КТО" учавствует в процессе.
Периодическая таблица методов приоритизации (мы уже сталкивались с ней в предыдущих статьях цикла) дает нам дополнительные критерии выбора.
У нее, если присмотреться, есть 2 шкалы
External vs. Internal (горизонтальная)
Quantitative VS qualitative (вертикальная)
External vs. Internal: располагает техники так:
в начале координат лидер продукта,
правее команда,
еще правее – стейкхолдеры,
и лишь потом ‑ клиенты
Как обсуждалось ранее, External инструменты лучше подходят для более абстрактных вещей уровня бизнес-целей, такие как Strategic Themes, больших Epic-и
Internal инструменты лучше подходят для более конкретных функций, историй типа ‘выбрать товар из списка доступных’
Вертикальная шкала схемы - количественно-качественная.
На выходе количественного метода - цифра - скоринг,
качественные методы дают категории: важно/не важно, удобно/не удобно
Количественные методы не лучше качественных, как и наоборот.
Например, общеизвестный негативный эффект количественных методов, что люди их воспринимают как научные, и не подвергают сомнению лишний раз. И желания пересматривать уже выполненную приоритизацию минимально (ну как, там же столько сложных формул!). Этот эффект необоснованного доверия нужно обязательно иметь в виду, если выбираете использовать что-то количественно-заумное.
Выбирая между количественными и качественными методами, нужно использовать знания контекста: кто будет приоритизировать, как много на это отведено времени, и так далее. Например, если в процессе принимают участие много сеньерных стейкхолдеров с разными бэкграундами, то проще с ними обсудить формулу, по которой вы посчитаете скоринг каждой фичи, чем проводить качественную оценку.
Выбор между Internal и External также ситуативный, например, можно учесть: наличие доступа к внешним стейкхолдерам, способности команды понимания бизнес-контекста продукта, и так далее.
В любом случае, нужно помнить, что приоритизация субъективна, какой метод вы бы не выбрали. И она не раз и на всегда делается, приоритеты должны пересматриваться так часто, как того требуют изменения во внешней среде.
Казалось бы, мы уже много всего знаем, давайте уже рецепт, как выбрать нужный метод из сотни доступных!
В следубщей статье он будет, обещаю!
В ней мы соберем все рассмотренные ранее факторы в единый алгоритм выбора метода приоритизации.
Не пропустите ;)
Comments