7 методов приоритизации требований и продуктовых фич для бизнес-аналитика

автор
7 методов приоритизации требований и продуктовых фич для бизнес-аналитика

Продолжая разговор про приоритизацию требований и продуктовых фич, сегодня рассмотрим популярные методы определения приоритетов с комментариями Agile Extension к BABOK®Guide и Guide to Product Ownership Analysis от международного института бизнес-анализа IIBA®. Читайте далее, что такое модель Кано, как использовать метод Карла Вигерса для приоритизации требований и какие техники больше подходят для оценки важности продуктовых характеристик с учетом рыночных метрик.

MoSCoW-приоритизация

Прежде всего отметим, что из всех практических методов определения приоритетов BABOK®Guide упоминает только MoSCoW, отмечая его в описании Agile-подходов и техник. Свое название этот метод приоритизации пользовательских историй (user story) и требований получил не в честь российской столицы, а как сокращение следующих 4 категорий:

  • Must haveто, что необходимо сделать в любом случае. Считается, что без реализации этих требований решение не будет работать или при отсутствии этих фич продукт не будет нужен потребителям;
  • Should haveтребования 2-ой очереди, которые должны быть реализованы после тех, что отнесены к группе Must;
  • Could haveжелательные требования, которые можно сделать, если останется время и будут ресурсы;
  • Would haveтребования, которые хотелось бы реализовать, но пока их можно проигнорировать или перенести на следующие итерации без вреда для продукта.

На практике метод MoSCoW используется довольно часто – не случайно он отмечен в Agile-расширении к BABOK (Agile Extension to the BABOK®Guide) и в руководстве к продуктовому мышлению Guide to Product Ownership Analysis, также выпускаемом под эгидой международного института бизнес-анализа IIBA®. В частности, Guide to Product Ownership Analysis упоминает метод MoSCoW в технике управления продуктовым бэклогом, предупреждая об опасности отнесения всех фич к категории Must. Это чревато расползанием бэклога и невыполнением планов по релизам, а также свидетельствует о недостаточно четком видении продукта и пользовательских потребностей.

Впрочем, с идентификацией их важности поможет техника Кано-анализа (Kano Analysis), которая основана на эмоциональном восприятии пользователем продуктовых характеристик.

Кано-анализ для приоритизации

Модель, названная в честь японского профессора Норияки Кано, предполагает разделение продуктовых фич на следующие 3 категории:

  • Характеристики возбуждения (Excitement characteristics), особо значимые в краткосрочной перспективе, вызывая «wow-эффект», когда потребитель получает дополнительный бонус сверх ожиданий. Например, в мои курсы по классическому бизнес-анализу я включаю полезные приемы из продуктовой аналитики и дополнительные материалы из системного анализа. Это существенно повышает ценность образовательных продуктов и приятно удивляет клиентов. Однако, отсутствие подобных фич НЕ вызовет недовольства пользователей.
  • Рабочие характеристики (Performance characteristics) продукта, например, удобство пользования элементами UI или наличие практических кейсов по каждой теме образовательного курса. Если эти продуктовые фичи реализованы хорошо, пользователи довольны и разочарованы в противоположном случае. Например, сюда относятся требования, которые должны быть реализованы в первую очередь, т.к. они обязательно нужны для самого существования продукта и его функционирования.
  • Пороговые характеристики (Threshold characteristics), отсутствие которых может отрицательно повлиять на восприятие продукта даже при наличии других интересных или эффективных функций. В этой категории чаще всего находятся требования или фичи, источником которых является рынок. Например, адаптация сайта под мобильные устройства, бесплатная доставка крупногабаритных товаров, минимум год гарантийного обслуживания и пр. Важно не спутать пороговые характеристики с неважными (Indifferent) и нежелательными атрибутами: первые не добавляют клиенту никакой ценности (хотя могут быть важными для бизнеса), а вторые натурально вредят. Например, большинству пользователей неважно, на каком языке программирования разработано приложение, лишь бы позволяло решить конкретные бизнес-задачи и желательно быстро. Причем слишком большое количество элементов управления в UI будет отвлекать от основной цели, а потому является вредным.

Техника Кано-анализа достаточно подробно рассмотрена в Guide to Product Ownership Analysis и Agile Extension to the BABOK®Guide. Если использовать модель Кано для расстановки приоритетов, то в первую очередь реализуются требования, обеспечивающие функционирование продукта (рабочие характеристики), а затем пороговые – те, отсутствие которых пользователи воспримут негативно.

Метод Карла Вигерса

В проектах разработки ПО для оценки приоритетов требований можно использовать метод классика управления требованиями и современного системного анализа Карла Вигерса (Karl Wiegers). Здесь для каждого требования по шкале от 1 до 9 оцениваются польза от его реализации (benefit), вред от отсутствия (penalty), расходы (cost) и риски (risk). Польза и вред рассматривается с точки зрения пользователей, а расходы и риски – с позиции разработчиков. Полученные оценки подставляются в формулу, уникальную для каждой компании и отдельно взятого продукта, где разные признаки (польза, вред, расходы, риски) имеют разные весовые коэффициенты. В итоге рассчитывается результирующий коэффициент приоритетности для каждого требования.

Эффективность вложенных усилий

Модель Impact/Effort позволяет оценить, как усилия, потраченные на реализацию требования или фичи, соотносятся с нужным бизнесу результатом. В отличие от финансового показателя по возврату вложенных инвестиций (ROI, Return of Investments), подход Impact/Effort рассчитывается не в деньгах, а в условных единицах. Например, усилия можно оценивать в человеко-часах или story point’ах (сложность реализации пользовательской истории), что активно используется в Agile-проектах и упоминается в технике Relative Estimation в Agile-расширении к BABOK®Guide. Влияние на результат выражается в оценке по числовой шкале (1-5, 1-10) или распределяется по категориям высокое/среднее/низкое.

RICE для оценки продуктовых изменений

Этот подход, предложенный ИТ-корпорацией Intercom, получил свое название от сокращения следующих точек зрения на влияние изменений продуктовых фич или требований на потребителей:

  • Reach (охват) – сколько пользователей охватит это нововведение;
  • Impact (эффект)— насколько оно улучшит или ухудшит жизнь пользователей;
  • Confidence (уверенность)— степень уверенности в том, что вообще можно что-то улучшить;
  • Effort (усилия)— сколько времени, людей, денег и других ресурсов понадобится на реализацию.

Аналогично методу Карла Вигерса, каждая из точек зрения имеет свои весовые коэффициенты. Поскольку метод RICE ориентирован на рассмотрение уже существующего продукта, целесообразно применять его для оценки изменения требований или приоритизации продуктовых характеристик.

Метод Feature Bucket для приоритизации продуктовых фич

Этот подход от бывшего руководителя соцсети LinkedIn Адама Нэша предполагает разделение всех продуктовых фич на 3 категории:

  • Metric Movers – наиболее востребованные бизнесом функции и продуктовые метрики (охват, доход, число пользователей и пр.).
  • Customer Requests – нужные пользователям функции;
  • Customer Delight – фичи, которые не обязательно запрашивают пользователи, но которые будут им полезны, аналогично Excitement characteristics из метода Кано.

Как и предыдущий подход, Feature Bucket ориентирован не столько на требования, сколько на характеристики продукта. С точки зрения приоритизации в первую очередь следует удовлетворить элементы категорий Metric Movers и Customer Requests, соблюдая баланс между фичами, нужными бизнесу и потребителям. Для этого можно подключить Кано-анализ, прежде всего пустить в реализацию те фичи, которые пользователи ожидают от продукта по умолчанию и те, что вызовут к нему положительную эмоциональную привязку.

Guide to Product Ownership Analysis также рекомендует продуктовым командам одну из групповых (деловых) игр для приоритизации фич. В частности, “тест на $100” или другой ограниченный бюджет, который можно потратить только на реализацию самых важных продуктовых фич. Подробнее про технику деловых игр и их применение в бизнес-анализе с комментариями BABOK®Guide и Guide to Product Ownership Analysis читайте в новой статье.

Наконец, в качестве самого примитивного способа определения приоритетов с точки зрения важности и срочности, можно использовать матрицу Эйзенхауэра, распределив элементы по ее 4-м квадрантам. Впрочем, как мы уже отмечали в прошлый раз, этот простой и удобный метод тайм-менеджмента не всегда применим для управления требованиями и продуктовыми фичами, приоритет которых зависит не только от фактора времени.

Больше полезных советов о том, как внедрить продуктовое мышление и Agile-практики в классический бизнес-анализ, подружив требования с фичами, рассматривается в моем новом курсе «От процессов к продуктам: Product ownership и Agile-практики для бизнес-аналитика».

А все подробности руководства к профессиональному своду знаний по бизнес-анализу BABOK, включая подготовку к сертификационному экзамену IIBA на уровни CBAP, CCAB, ECBA вам помогут узнать авторизованные курсы Школы прикладного бизнес-анализа в нашем лицензированном учебном центре обучения и повышения квалификации системных и бизнес-аналитиков в Москве:

 

Комментировать