Привет, меня зовут Руслан. Я работаю проектным менеджером в аутсорс-компании Relevant Software. За 4 года своей карьеры я видел много грамотно написанных проектов. К сожалению, не все из них стали успешными. Почти все проекты были сделаны в сроки, в оговоренный бюджет и скоуп. Но у них были одни и те же недостатки: отсутствие Problem/Solution fit, отсутствие ключевых метрик, непонимание того, как правильно приоритизировать, ориентир на чутье вместо данных. Именно поэтому в последнее время я работаю над внедрением продуктового подхода во всех проектах. 60% наших проектов — это стартапы, 40% — средний бизнес, которому нужна автоматизация процессов.
Общаясь со многими украинскими продуктовыми менеджерами, я обнаружил, что даже для них приоритизация — это весьма непростая задача. Об этом также часто пишут наши западные коллеги.
Цель этой статьи — дать выжимку самых популярных методологий и увидеть, как в действительности приоритизируют задачи в украинских продуктовых компаниях на примере Readdle, MacPaw, EduNav и Grammarly.
1. Impact/Effort
Самый распространенный подход — соотношение приложенных усилий к отдаче, которую мы получаем после реализации функционала. Effort может быть в человеко-часах либо в сторипоинтах. Impact может распределяться по шкале
Очень важно измерять impact по метрике или набору метрик, важных для бизнеса. Сложность заключается в определении этой ключевой метрики, или, как ее еще называют, North Star Metric. У Facebook — это количество уникальных пользователей (DAU), у Booking.com — количество забронированных ночевок.
Сначала сосредотачиваемся на High Impact/Low Effort функционале, а затем Low Impact/Low Effort и High Impact/High Effort. Про функционал типа Low Impact/ High Effort забываем.
Itamar Gilad, бывший продуктовый менеджер Google, предлагает добавить еще один критерий к этому подходу — коэффициент уверенности в прогнозах. Больше можно прочитать в его статье «Why Impact/Effort Prioritization Doesn’t Work».
Приоритизацию Return on Investment часто путают с Impact/Effort. Единственное отличие от предыдущего подхода — в том, что ROI приоритизация базируется на финансовых показателях. Это отношение конечной прибыли к сумме инвестиций. Очень часто от клиентов можно услышать: «Я не могу оценить ценность этой фичи в долларах. Это будет слишком субъективно». Если страховые компании могут оценить ценность потерянного пальца или эмоционального расстройства в денежном эквиваленте, то такой же подход может быть применен и к оценке фичи.
2. Kano Model
Подход разработал японский ученый и профессор Нориаки Кано. Он основывается на эмоциональном восприятии пользователем той или иной функциональности. Кано выделяет следующие типы реакции пользователя:
- Must Be — минимальные требования; если их нет — пользователь не удовлетворен.
- Indifferent — функционал, который вызывает неоднозначную реакцию. Пользователям все равно, есть он или нет.
- Satisfiers (Performance) — функционал, который вызывает удовлетворенность, если он выполнен хорошо, или разочарование — если качество низкое.
- Exciters (Attractive) — функционал, повышающий удовлетворенность пользователя, если он есть. Если его нет — недовольства не возникает.
Обычно сначала фокусируются на Must be, затем — на Satisfiers и только потом — на Exciters.
Очень детальная статья на Folding Burritosо том, как применять модель Кано и как рассчитать ее показатели.
3. Buy the Feature
Отлично работает, когда у вас много стейкхолдеров. Денежные купоны из настольной игры «Монополия» приравниваются к бюджету проекта. Даете купоны и просите распределить средства между фичами. Приоритизация выстраивается по сумме вложенных монопольных денег.
Как правильно организовать такой подход к приоритизации, можно прочитать на UX for the Masses.
4. RICE
Этот фреймворк был разработан в Intercom. После кучи тестов и итераций они остановились на 4 факторах:
- Reach (охват) — скольким пользователям мы улучшим жизнь?
- Impact (эффект) — насколько мы улучшим жизнь нашим пользователям?
- Confidence (уверенность) — насколько мы уверены, что вообще можем что-то улучшить?
- Effort (усилия) — сколько времени нам понадобится, чтобы реализовать задуманное?
По соотношению этих 4 факторов приоритизируем бэклог задач. C деталями можно ознакомиться в блоге Intercom.
5. Karl Wiegers Method
Фреймворк придумал американский инженер, консультант и автор книги «Software requirements» Karl Wiegers. C этим подходом оцениваются benefit, penalty, cost и risk по шкале от 1 до 9. Пользователи одновременно оценивают пользу от присутствия фичи и вред от ее отсутствия. Разработчики оценивают стоимость имплементации этой фичи и риск, связанный с ее разработкой. Далее данные подставляются в формулу и рассчитывается коэффициент приоритетности.
Больше можно прочитать в статье «First Things First: Prioritizing Requirements» by Karl Wiegers.
6. Feature buckets
Подход придумал бывший СEO LinkedIn Adam Nash. Все фичи условно распределяются между
- Metric Movers — функционал, который двигает основные бизнес & продуктовые метрики: Engagement, Growth, Revenue etc.
- Customer Requests — функционал, который запрашивают пользователи. Не каждое желание пользователя может быть реализовано, но это уже тема отдельной статьи.
- Customer Delight — фичи, которые не обязательно запрашивают пользователи, но которые однозначно принесут им value.
Распределяя функционал по этим 3 категориям, можно честно ответить на вопрос: «Почему мы делаем этот функционал?». Потому что пользователи требуют? Потому что компания требует? Или просто потому что это killer фича?
Больше можно узнать в статье «Guide to Product Planning: Three Feature Buckets» by Adam Nash.
Как приоритизируют в украинских продуктовых компаниях
Все зависит от продукта, его стадии и контекста. Есть небольшие исправления, которые будут иметь большое значение для наших пользователей. Есть маркетинговая активность. Есть стратегические задачи, результат которых может проявиться через год, или они носят аккумулятивный эффект (результат после реализации скоупа задач, а не одной конкретной).
В EduNav мы помогаем американским студентам закончить обучение вовремя — рассчитываем для них индивидуальные учебные планы. Проблема состоит в том, что оптимальный по времени и деньгам план нужно выбрать из миллионов вариантов с учетом истории сданных курсов, целей и ограничений студента (не хочу учиться по утрам, нравится другой преподаватель, моя подруга записалась на этот класс и пр.).
Мне кажется, что подход к приоритизации очень зависит от того, в какой компании вы работаете, в какой организационной структуре и какие цели стоят перед продуктом. Например, если у продукта одна команда и ее цель — это рост revenue квартал к кварталу, то в такой среде вы вряд ли приоритизируете какую-либо инновационную фичу достаточно высоко.
Нельзя сказать, что в Grammarly есть единый подход к приоритизации задач. PM-ы разных направлений выбирают метод приоритизации под свои задачи.Резюме
Описанные в статье подходы к приоритизации не единственные, но почти все они базируются на одних и тех же принципах. При выборе фреймворка для приоритизации следует ответить на вопросы. В каких условиях мы приоритизируем задачи? Как много внешнего вмешательства в процесс приоритизации? На сколько приоритизация будет опираться на экспертное мнение, а не на количественные показатели? На какую метрику мы будем равняться? Какие у нас стратегические задачи? Очень редко используется какой-то один определенный фреймворк. Чаще всего это комбинация из нескольких или вообще свой, заточенный под конкретные условия.