6 подходов к приоритизации задач. Опыт Readdle, MacPaw, Grammarly и EduNav

Привет, меня зовут Руслан. Я работаю проектным менеджером в аутсорс-компании Relevant Software. За 4 года своей карьеры я видел много грамотно написанных проектов. К сожалению, не все из них стали успешными. Почти все проекты были сделаны в сроки, в оговоренный бюджет и скоуп. Но у них были одни и те же недостатки: отсутствие Problem/Solution fit, отсутствие ключевых метрик, непонимание того, как правильно приоритизировать, ориентир на чутье вместо данных. Именно поэтому в последнее время я работаю над внедрением продуктового подхода во всех проектах. 60% наших проектов — это стартапы, 40% — средний бизнес, которому нужна автоматизация процессов.

Общаясь со многими украинскими продуктовыми менеджерами, я обнаружил, что даже для них приоритизация — это весьма непростая задача. Об этом также часто пишут наши западные коллеги.

Цель этой статьи — дать выжимку самых популярных методологий и увидеть, как в действительности приоритизируют задачи в украинских продуктовых компаниях на примере Readdle, MacPaw, EduNav и Grammarly.

1. Impact/Effort

Самый распространенный подход — соотношение приложенных усилий к отдаче, которую мы получаем после реализации функционала. Effort может быть в человеко-часах либо в сторипоинтах. Impact может распределяться по шкале 1-5 либо по шкале high/medium/low.

Очень важно измерять 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. Все фичи условно распределяются между 3-мя ведрами:

• Metric Movers — функционал, который двигает основные бизнес & продуктовые метрики: Engagement, Growth, Revenue etc.
• Customer Requests — функционал, который запрашивают пользователи. Не каждое желание пользователя может быть реализовано, но это уже тема отдельной статьи.
• Customer Delight — фичи, которые не обязательно запрашивают пользователи, но которые однозначно принесут им value.

Распределяя функционал по этим 3 категориям, можно честно ответить на вопрос: «Почему мы делаем этот функционал?». Потому что пользователи требуют? Потому что компания требует? Или просто потому что это killer фича?

Больше можно узнать в статье «Guide to Product Planning: Three Feature Buckets» by Adam Nash.

Как приоритизируют в украинских продуктовых компаниях

Резюме

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

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU