6 подходов к приоритизации задач. Опыт Readdle, MacPaw, Grammarly и EduNav
Привет, меня зовут Руслан. Я работаю проектным менеджером в аутсорс-компании 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.
Как приоритизируют в украинских продуктовых компаниях
Евгений Плохой, Product Manager в Readdle
Все зависит от продукта, его стадии и контекста. Есть небольшие исправления, которые будут иметь большое значение для наших пользователей. Есть маркетинговая активность. Есть стратегические задачи, результат которых может проявиться через год, или они носят аккумулятивный эффект (результат после реализации скоупа задач, а не одной конкретной).
В целом оценивается степень влияния на продукт (пользователей), стоимость задачи, сроки на реализацию и конъюнктура рынка. Величина каждого коэффициента может компенсировать недостатки других. В целом задачи можно поделить на blockers (current, potential), must have features, improvements, marketing, bug fixes и другие. В каждом из типов, очевидно, своя модель приоритизации. Но основной фокус, конечно, — на стратегический, идеальный продукт. На этом пути мы не забываем делать лучший опыт сейчас, а не только потом, зарабатывать деньги и формировать рынок своими решениями.
Проблемы и решения
Могут быть задачи, связанные с формированием стратегии: какой продукт, какой рынок, какая модель монетизации, почему и т. д. Они требуют время на формирование идей, обсуждение, выбор и т. д. Но когда стратегия сформирована, то и приоритеты следующего уровня уже определены, так как задачи рассматриваются уже через призму стратегии. Если мы видим, что не хватает ресурсов, но мы можем двигаться быстрее, приглашаем в команду новых профессионалов из области, где чувствуется нехватка. Растем мы очень активно.
Решаем стратегией и планированием. Роадмап покрывает минимум
Андрей Кароль, Product Manager в EduNav
В EduNav мы помогаем американским студентам закончить обучение вовремя — рассчитываем для них индивидуальные учебные планы. Проблема состоит в том, что оптимальный по времени и деньгам план нужно выбрать из миллионов вариантов с учетом истории сданных курсов, целей и ограничений студента (не хочу учиться по утрам, нравится другой преподаватель, моя подруга записалась на этот класс и пр.).
Наши клиенты — колледжи и университеты, пользователи — студенты и адвайзеры. А в качестве гейткиперов выступают IT-департаменты — уж очень они не любят внедрять что-то новое. Каждый из стейкхолдеров имеет свои цели:
- руководство вузов — достигнуть KPI и получить государственные дотации;
- студенты — с учетом всех ограничений выбрать и зарегистрироваться на курсы, которые позволят им вовремя получить диплом;
- адвайзеры — помочь большему количеству студентов и быть уверенными в том, что планы точные;
- IT-департамент — безопасность данных и отсутствие багов.
С учетом этого, приоритизируя фичи, мы ищем баланс между интересами всех стейкхолдеров. Можно сказать, мы балансируем между достижением KPI, юзабилити, точностью планов и скоростью обработки данных.
Проблемы и решения
Сложных задач много, мы же растущий стартап. Одна из последних — оптимизация скорости расчета и улучшение субъективного ощущения производительности для пользователя. Когда с одной стороны, мы оптимизируем математические модели для ускорения расчета, а с другой — учим пользователя ждать. В трудных случаях расчет нового плана занимает порядка 40 секунд, что о-о-очень долго по современным меркам. А пользователь забывает, что на то, чтобы ручками такой план составить уйдет около часа.
Павел Педенко, Product Manager в Macpaw
Мне кажется, что подход к приоритизации очень зависит от того, в какой компании вы работаете, в какой организационной структуре и какие цели стоят перед продуктом. Например, если у продукта одна команда и ее цель — это рост revenue квартал к кварталу, то в такой среде вы вряд ли приоритизируете какую-либо инновационную фичу достаточно высоко.
Скажу честно, сколько бы мы в Setapp подходов к приоритизации ни пробовали — все равно не довольны.
Пока что мы остановились на следующем подходе:
- Определили цель продукта.
- В рамках брейнштормов и работы с пользователями получаем перечень идей.
- Оттуда формируем гипотезы.
- Гипотезы приоритизируем майками по Impact/Effort.
Хочу также попробовать ввести confidence level как параметр в приоритизации, но пока что до этого не дошел.
Игорь Соколов, Product Manager в Grammarly
Нельзя сказать, что в Grammarly есть единый подход к приоритизации задач. PM-ы разных направлений выбирают метод приоритизации под свои задачи.
Большинство целей мы задаем при помощи квартального планирования на основании нашей более долгосрочной стратегии. Описываем мы наши цели при помощи системы OKR (Objectives and key results).
Для приоритизации задач внутри квартала я использую принцип, который лежит в основе WSJF (Weighted Shortest Job First). Главное отличие от остальных методов оценки — замена более узкой цели «увеличения прибыли/выгоды» на более широкое — «уменьшение недополученной прибыли».
Сейчас этот подход мне кажется близким к оптимуму для наших задач, но мы готовы менять парадигму и не зацикливаемся на определенной методологии.
Резюме
Описанные в статье подходы к приоритизации не единственные, но почти все они базируются на одних и тех же принципах. При выборе фреймворка для приоритизации следует ответить на вопросы. В каких условиях мы приоритизируем задачи? Как много внешнего вмешательства в процесс приоритизации? На сколько приоритизация будет опираться на экспертное мнение, а не на количественные показатели? На какую метрику мы будем равняться? Какие у нас стратегические задачи? Очень редко используется какой-то один определенный фреймворк. Чаще всего это комбинация из нескольких или вообще свой, заточенный под конкретные условия.
