Как приоритизировать фичи: RICE, Kano, MoSCoW и другие методы

У каждой продуктовой команды есть одна общая проблема: бесконечный список идей и ограниченные ресурсы. Дизайнеры хотят улучшить UX, разработчики предлагают технические оптимизации, маркетинг просит новые фичи для привлечения клиентов, а CEO мечтает обогнать конкурентов. Как выбрать, что делать первым? Как не потратить месяцы на разработку фичи, которую никто не будет использовать?

Приоритизация — это не интуиция и не политика. Это систематический процесс оценки идей на основе конкретных критериев. В 2025 году существует множество проверенных методов приоритизации, каждый из которых решает свои задачи. В этой статье мы детально разберём самые популярные фреймворки — RICE, Kano, MoSCoW, ICE, Value vs Effort и другие — и поможем вам выбрать подходящий для вашей ситуации.

Почему приоритизация критически важна?

Прежде чем погружаться в методы, давайте поймём, почему нельзя просто делать всё подряд или полагаться на интуицию.

Проблема №1: Ограниченные ресурсы

Команда разработки не резиновая. Даже у Google и Apple есть лимиты по времени, людям и деньгам. Каждая выбранная фича — это opportunity cost: вы отказываетесь от десятков других идей.

Пример: Команда из 5 разработчиков может выпустить примерно 8-12 значимых фич в год (при двухнедельных спринтах). Если в бэклоге 100 идей, то 88-92 из них не будут реализованы никогда. Вопрос: какие 12 фич принесут максимальную ценность?

Проблема №2: Эффект «блестящего объекта»

Команды часто увлекаются новыми идеями, забывая про стратегические цели. Конкурент выпустил фичу X? Давайте сделаем такую же! CEO прочитал статью про тренд Y? Срочно внедряем!

Без систематической приоритизации команда превращается в «feature factory» — производит фичи ради фич, а не ради бизнес-целей.

Проблема №3: Субъективность и политика

Когда приоритизация основана на мнениях, побеждает тот, кто громче кричит или выше в иерархии. Это приводит к:
- Демотивации команды (их идеи игнорируются)
- Неоптимальным решениям (выбирают не лучшее, а то, что продвигает самый влиятельный человек)
- Конфликтам между отделами

Проблема №4: Отсутствие фокуса

Без приоритизации команда распыляется: начинает 10 фич одновременно, ни одна не доходит до конца. Результат — ничего не выпускается, пользователи недовольны.

Принцип: Лучше выпустить 3 отличные фичи, чем начать 10 и не закончить ни одну.

Как систематическая приоритизация решает эти проблемы?

1. Объективность — решения основаны на данных и критериях, а не на мнениях

2. Прозрачность — все понимают, почему выбрана именно эта фича

3. Фокус — команда работает над ограниченным набором приоритетных задач

4. Alignment — приоритеты связаны с бизнес-целями и стратегией

5. Скорость — меньше времени на споры, больше на разработку

Теперь давайте разберём конкретные методы.

1. RICE: универсальный метод для продуктовых команд

RICE — один из самых популярных методов приоритизации, разработанный командой Intercom. Это количественный метод, который даёт каждой фиче числовой скор на основе четырёх факторов.

Расшифровка RICE

R — Reach (Охват): Сколько пользователей будет затронуто фичей за определённый период (обычно квартал)?

Примеры:
- Новая фича в основном продукте: 10 000 пользователей/квартал
- Фича в редко используемом разделе: 500 пользователей/квартал
- Улучшение онбординга: 2 000 новых пользователей/квартал

I — Impact (Влияние): Насколько сильно фича повлияет на каждого пользователя? Используется шкала:
- 3 = Massive impact (огромное влияние)
- 2 = High impact (высокое влияние)
- 1 = Medium impact (среднее влияние)
- 0.5 = Low impact (низкое влияние)
- 0.25 = Minimal impact (минимальное влияние)

C — Confidence (Уверенность): Насколько вы уверены в своих оценках Reach и Impact? Измеряется в процентах:
- 100% = Высокая уверенность (есть данные, исследования, тесты)
- 80% = Средняя уверенность (есть некоторые данные)
- 50% = Низкая уверенность (в основном интуиция)

E — Effort (Усилия): Сколько времени нужно команде на разработку? Измеряется в «person-months» (человеко-месяцах):
- 0.5 = Неделя работы одного разработчика
- 1 = Месяц работы одного разработчика
- 3 = Три месяца работы одного разработчика

Формула расчёта RICE Score

RICE Score = (Reach × Impact × Confidence) / Effort

Чем выше RICE Score, тем выше приоритет фичи.

Пример расчёта

Фича А: Добавить поиск по фильтрам в каталоге
- Reach: 5000 пользователей/квартал используют каталог
- Impact: 2 (High) — значительно упростит поиск нужного товара
- Confidence: 80% (есть данные из опросов и аналитики)
- Effort: 2 человеко-месяца

RICE Score = (5000 × 2 × 0.8) / 2 = 4000

Фича Б: Интеграция с редким платёжным методом
- Reach: 200 пользователей/квартал запрашивали этот метод
- Impact: 3 (Massive) — для этих пользователей это критично
- Confidence: 100% (точно знаем количество запросов)
- Effort: 1 человеко-месяц

RICE Score = (200 × 3 × 1.0) / 1 = 600

Фича В: Редизайн главной страницы
- Reach: 20 000 пользователей/квартал посещают главную
- Impact: 0.5 (Low) — улучшение визуальное, но не функциональное
- Confidence: 50% (не уверены, что это повысит метрики)
- Effort: 4 человеко-месяца

RICE Score = (20 000 × 0.5 × 0.5) / 4 = 1250

Приоритизация: Фича А (4000) → Фича В (1250) → Фича Б (600)

Преимущества RICE

• Объективность: Сложно манипулировать результатами, нужны данные

• Быстрота: Можно оценить десятки фич за несколько часов

• Баланс факторов: Учитывает и бизнес-ценность, и затраты

• Снижает эффект HiPPO (Highest Paid Person's Opinion) — мнение босса не перевешивает данные

Недостатки RICE

• Сложность оценки: Как точно определить Reach и Impact?

• Не учитывает зависимости: Фича A может быть нужна для фичи B

• Игнорирует стратегические цели: Высокий RICE Score не означает, что фича соответствует стратегии

• Требует данных: Если у вас нет аналитики, оценки будут интуитивными

Когда использовать RICE

• У вас большой бэклог (50+ фич) и нужно быстро расставить приоритеты

• В команде есть продуктовые аналитики, которые могут оценить метрики

• Вы хотите снизить субъективность и добавить объективности

• У вас есть минимальная аналитика (количество пользователей, поведение)

Лайфхаки по использованию RICE

1. Стандартизируйте период для Reach: Используйте квартал, чтобы все оценивали одинаково

2. Калибруйте Impact вместе с командой: Проведите сессию, где обсудите примеры для каждого уровня

3. Будьте консервативны в Confidence: Если сомневаетесь, ставьте 50%, а не 80%

4. Пересматривайте RICE Score регулярно: После выпуска фичи проверяйте, совпали ли прогнозы с реальностью

2. Модель Kano: понимание ожиданий пользователей

Модель Kano — это уникальный подход, который фокусируется не на цифрах, а на эмоциях пользователей. Разработана японским профессором Нориаки Кано в 1984 году и до сих пор актуальна.

Идея модели

Не все фичи одинаковы. Одни пользователи воспринимают как «должно быть», другие как «приятный бонус», третьи вызывают восторг. Модель Kano классифицирует фичи по тому, как они влияют на удовлетворённость пользователей.

Пять категорий фич

1. Базовые (Must-be / Basic Needs)

Это фичи, которые пользователи воспринимают как данность. Если они есть — нормально. Если их нет — гнев и разочарование.

Примеры:
- В автомобиле должны быть колёса и руль
- В смартфоне должна быть возможность звонить
- В интернет-магазине должна быть корзина
- В SaaS-продукте должна быть возможность сохранить данные

Ключевое: Наличие базовых фич не увеличивает удовлетворённость, но их отсутствие делает продукт непригодным.

2. Производительные / Линейные (Performance / One-dimensional)

Чем лучше реализована фича, тем выше удовлетворённость. Связь прямая и линейная.

Примеры:
- Скорость загрузки страниц (чем быстрее, тем лучше)
- Объём оперативной памяти в смартфоне (чем больше, тем лучше)
- Качество фотографий с камеры (чем выше, тем лучше)
- Количество интеграций в B2B-продукте

Ключевое: Это то, что пользователи сравнивают между конкурентами. «У этого продукта скорость 2х, а у того 3х».

3. Привлекательные / Восхитительные (Attractive / Delighters)

Фичи, которых пользователи не ожидают. Если их нет — никто не расстроится. Если есть — восторг и лояльность.

Примеры:
- Tesla впервые добавила автопилот — это был восторг
- Spotify создал персонализированные плейлисты (Discover Weekly) — пользователи не ожидали
- Amazon добавил one-click покупки — удивили простотой
- Notion позволил создавать базы данных в блокноте — wow-эффект

Ключевое: Это конкурентное преимущество. Восхитительные фичи создают «сарафанное радио» и отличают вас от конкурентов.

4. Безразличные (Indifferent)

Фичи, которые не влияют на удовлетворённость. Пользователям всё равно, есть они или нет.

Примеры:
- Возможность сменить тему интерфейса с синей на зелёную (если это не дизайнерский инструмент)
- 150 разных шрифтов в текстовом редакторе (большинству нужно 5)
- Интеграция с сервисом, которым никто не пользуется

Ключевое: Разработка таких фич — пустая трата ресурсов.

5. Нежелательные / Обратные (Reverse)

Фичи, которые раздражают пользователей. Чем больше — тем хуже.

Примеры:
- Слишком много уведомлений (спам)
- Избыток анимаций, которые замедляют интерфейс
- Сложные настройки, когда нужна простота
- Автоматическое воспроизведение видео со звуком

Ключевое: Таких фич нужно избегать или делать опциональными.

Как применять модель Kano?

Шаг 1: Проведите Kano-опрос

Для каждой фичи задайте пользователям два вопроса:

1. Функциональный вопрос: Как вы себя почувствуете, если фича X будет в продукте?

2. Мне это нравится

3. Это ожидаемо

4. Мне всё равно

5. Я могу это терпеть

6. Мне это не нравится

7. Дисфункциональный вопрос: Как вы себя почувствуете, если фичи X НЕ будет в продукте?

8. Мне это нравится

9. Это ожидаемо

10. Мне всё равно

11. Я могу это терпеть

12. Мне это не нравится

Шаг 2: Классифицируйте ответы

На основе комбинации ответов определите категорию фичи. Существует таблица Kano, которая сопоставляет ответы с категориями.

Шаг 3: Приоритизируйте

Общее правило приоритизации:
1. Сначала: Базовые фичи (без них продукт не жизнеспособен)
2. Затем: Производительные фичи (для конкурентоспособности)
3. Потом: Привлекательные фичи (для дифференциации и wow-эффекта)
4. Избегайте: Безразличные и нежелательные фичи

Динамическая природа Kano

Важная особенность: категории фич меняются со временем.

Пример:
- 1990 год: Сенсорный экран в телефоне — Привлекательная фича (wow!)
- 2007 год: После iPhone — Производительная фича (чем лучше, тем лучше)
- 2015 год: Сенсорный экран — Базовая фича (без него телефон не продать)

Вывод: Регулярно пересматривайте классификацию фич. То, что вчера было инновацией, сегодня — стандарт рынка.

Преимущества модели Kano

• Фокус на пользователях: Принимаете решения на основе реальных потребностей

• Помогает избежать лишнего: Выявляет безразличные и нежелательные фичи

• Находит wow-фичи: Идентифицирует возможности для дифференциации

• Простота понимания: Интуитивно понятная логика

Недостатки модели Kano

• Требует опросов: Нужно собрать данные от пользователей

• Субъективность интерпретации: Один и тот же пользователь может ответить по-разному в разные дни

• Не учитывает бизнес-цели: Фича может быть привлекательной для пользователей, но не выгодной для бизнеса

• Игнорирует усилия: Не говорит, сколько стоит реализация

Когда использовать Kano

• Вы разрабатываете новый продукт и хотите понять, какие фичи критичны

• У вас есть доступ к пользователям для опросов

• Вы хотите найти wow-фичи для дифференциации от конкурентов

• Команда спорит, что важнее — нужны данные от пользователей

Лайфхак: Kano + RICE

Используйте Kano для категоризации фич, а затем RICE для приоритизации внутри категорий:
1. Сначала делаете базовые фичи (по Kano)
2. Внутри базовых приоритизируете по RICE
3. Затем производительные фичи (по RICE)
4. Потом привлекательные фичи (по RICE)

3. MoSCoW: простота для Agile-команд

MoSCoW — один из самых простых методов приоритизации, идеально подходящий для Agile-команд. Разработан Даем Клеггом в 1994 году для компании Oracle.

Расшифровка MoSCoW

Каждая фича относится к одной из четырёх категорий:

M — Must have (Обязательно нужно)

Фичи, без которых продукт не может быть выпущен. Если их не сделать, проект провален.

Критерий: Если убрать эту фичу, продукт станет бесполезным или непригодным к использованию.

Примеры:
- В MVP интернет-магазина: каталог товаров, корзина, оформление заказа, оплата
- В мобильном приложении для такси: возможность вызвать машину и оплатить поездку
- В CRM-системе: возможность добавлять и редактировать контакты

S — Should have (Желательно иметь)

Важные фичи, которые сильно улучшают продукт, но без них можно выпустить MVP.

Критерий: Отсутствие этой фичи болезненно, но не критично.

Примеры:
- В интернет-магазине: фильтры по категориям, избранное, история заказов
- В приложении для такси: история поездок, избранные адреса
- В CRM: импорт контактов из файла, автоматические напоминания

C — Could have (Можно иметь)

«Nice to have» фичи — улучшают UX, но не критичны. Делаются, если останется время и ресурсы.

Критерий: Отсутствие не вызывает боли. Это «бонус».

Примеры:
- В интернет-магазине: рекомендации «похожие товары», возможность оставить отзыв с фото
- В приложении для такси: выбор музыки в машине, чаевые водителю
- В CRM: кастомизация цветов интерфейса, виджеты на дашборде

W — Won't have (В этот раз не будет)

Фичи, которые сознательно откладываются на будущее. Это не значит «никогда», а «не в этом релизе».

Критерий: Фича может быть полезной, но сейчас не приоритет.

Примеры:
- Интеграция с редкими платёжными системами
- Версия приложения для редкой платформы (Windows Phone)
- Расширенная аналитика (когда нет базовой)

Правило распределения

Рекомендуемое распределение фич по категориям:
- 60% — Must have
- 20% — Should have
- 20% — Could have + Won't have

Если в Must have больше 60%, это сигнал, что вы пытаетесь запихнуть слишком много в релиз.

Пример использования

Проект: MVP мобильного приложения для фитнеса

Must have:
- Регистрация и авторизация
- База упражнений с видео
- Возможность создать тренировку
- Таймер для упражнений
- История тренировок

Should have:
- Статистика прогресса (графики)
- Напоминания о тренировках
- Готовые программы тренировок
- Калькулятор калорий

Could have:
- Социальные фичи (добавить друзей)
- Интеграция с Apple Health
- Темная тема интерфейса
- Персонализированные рекомендации

Won't have (в первом релизе):
- AI-тренер с видеоаналитикой
- Интеграция с умными часами
- Marketplace программ тренировок
- VR-тренировки

Преимущества MoSCoW

• Простота: Можно объяснить за 5 минут

• Быстрота: Можно категоризировать фичи за пару часов

• Гибкость: Легко адаптируется под любой проект

• Совместимость с Agile: Идеально для спринтов и итераций

• Помогает резать scope: Явно показывает, что можно отложить

Недостатки MoSCoW

• Субъективность: Нет чётких критериев, что Must, а что Should

• Склонность к «Must have инфляции»: Все хотят, чтобы их фича была Must have

• Не учитывает усилия: Could have фича может требовать 6 месяцев работы

• Не учитывает бизнес-ценность: Фокус на «нужности», а не на ROI

Когда использовать MoSCoW

• У вас фиксированный дедлайн (релиз через 3 месяца, нужно понять, что точно успеете)

• Команда работает по Agile/Scrum и планирует спринты

• Нужно быстро договориться о scope проекта с заказчиком

• Вы запускаете MVP и нужно отсечь лишнее

Лайфхак: MoSCoW + оценка усилий

Комбинируйте MoSCoW с оценкой усилий:
1. Категоризируйте фичи по MoSCoW
2. Оцените усилия (в story points или днях)
3. Планируйте спринт: сначала все Must have, затем Should have, пока не закончится capacity

Это поможет избежать ситуации, когда в Must have 100 задач, а команда может сделать 20 за релиз.

4. ICE: быстрая оценка для экспериментов

ICE — упрощённая версия RICE, популярная в стартапах и growth-командах. Автор — Шон Эллис, создатель термина «growth hacking».

Расшифровка ICE

I — Impact (Влияние): Насколько сильно фича повлияет на ключевую метрику? Оценка от 1 до 10.
- 10 = Огромное влияние
- 5 = Среднее влияние
- 1 = Минимальное влияние

C — Confidence (Уверенность): Насколько вы уверены, что фича сработает? Оценка от 1 до 10.
- 10 = Высокая уверенность (есть данные, исследования)
- 5 = Средняя уверенность (гипотеза)
- 1 = Низкая уверенность (выстрел в темноте)

E — Ease (Лёгкость реализации): Насколько легко реализовать фичу? Оценка от 1 до 10.
- 10 = Очень легко (пара часов)
- 5 = Среднее (несколько дней)
- 1 = Очень сложно (месяцы работы)

Формула расчёта ICE Score

ICE Score = (Impact + Confidence + Ease) / 3

Или упрощённо:

ICE Score = Impact × Confidence × Ease

Пример расчёта

Эксперимент А: Добавить кнопку «Купить в 1 клик»
- Impact: 7 (может значительно повысить конверсию)
- Confidence: 6 (видели кейсы других компаний, но не тестировали у себя)
- Ease: 8 (технически просто, 2-3 дня работы)

ICE Score = (7 + 6 + 8) / 3 = 7.0

Эксперимент Б: Персонализированные рекомендации на основе ML
- Impact: 9 (может сильно увеличить средний чек)
- Confidence: 4 (ML-модели непредсказуемы, нет гарантий)
- Ease: 2 (нужно обучить модель, собрать данные, 2-3 месяца работы)

ICE Score = (9 + 4 + 2) / 3 = 5.0

Эксперимент В: Изменить цвет кнопки с синего на зелёный
- Impact: 3 (маловероятно, что цвет сильно повлияет)
- Confidence: 5 (нужно тестировать, результат неочевиден)
- Ease: 10 (5 минут работы)

ICE Score = (3 + 5 + 10) / 3 = 6.0

Приоритизация: Эксперимент А (7.0) → Эксперимент В (6.0) → Эксперимент Б (5.0)

Преимущества ICE

• Скорость: Можно оценить десятки гипотез за час

• Простота: Не нужны сложные расчёты и данные

• Баланс факторов: Учитывает и ценность, и сложность, и риски

• Идеален для экспериментов: Growth-команды живут этим методом

Недостатки ICE

• Субъективность: Оценки от 1 до 10 — это мнения, а не факты

• Не учитывает охват: Фича может быть лёгкой и эффектной, но для 10 пользователей

• Риск «quick wins bias»: Лёгкие задачи получают высокий приоритет, даже если Impact низкий

Когда использовать ICE

• Вы в growth-команде и тестируете много гипотез

• Нужно быстро приоритизировать backlog экспериментов

• У вас нет времени на сложные методы типа RICE

• Вы в раннем стартапе и работаете в условиях неопределённости

Лайфхак: ICE для быстрых побед

Используйте ICE для поиска «quick wins» — фич с высоким ICE Score (7+), которые можно реализовать за неделю. Это даёт быстрые результаты и мотивирует команду.

5. Value vs Effort: визуальная матрица приоритизации

Value vs Effort (Ценность против Усилий) — это визуальный метод, который использует матрицу 2×2 для категоризации фич.

Как работает матрица

Каждая фича оценивается по двум осям:
- Ось X (горизонталь): Усилия (Effort) — сколько времени и ресурсов нужно
- Ось Y (вертикаль): Ценность (Value) — какую пользу принесёт

Оценка обычно: Low / Medium / High или по шкале 1-10.

Четыре квадранта матрицы

             Высокая ценность
                    |
                    |
    Quick Wins      |      Big Bets
    (Быстрые победы)|   (Крупные ставки)
                    |
    ----------------+----------------
                    |
    Fill-ins        |      Money Pit
    (Заполнители)   | (Денежная яма)
                    |
             Низкая ценность

    Низкие усилия   |   Высокие усилия

1. Quick Wins (Быстрые победы) — Высокая ценность, низкие усилия
- Делайте в первую очередь!
- Это «низко висящие фрукты» — легко достать, вкусные
- Примеры: исправление критичного бага, добавление кнопки, улучшение текста

2. Big Bets (Крупные ставки) — Высокая ценность, высокие усилия
- Стратегические проекты
- Требуют планирования и ресурсов
- Делайте после Quick Wins
- Примеры: разработка нового продукта, полный редизайн, новая платформа

3. Fill-ins (Заполнители) — Низкая ценность, низкие усилия
- Делайте, когда есть свободное время
- Могут улучшить UX, но не критичны
- Примеры: мелкие косметические улучшения, «nice to have» фичи

4. Money Pit (Денежная яма / Временные ловушки) — Низкая ценность, высокие усилия
- Избегайте!
- Пожиратели ресурсов без ROI
- Примеры: over-engineering, фичи «потому что так делают конкуренты»

Пример использования

Фича А: Добавить избранное в каталог
- Value: High (пользователи часто просят)
- Effort: Low (1-2 дня работы)
- Квадрант: Quick Wins ✅

Фича Б: Разработать мобильное приложение
- Value: High (50% пользователей заходят с мобильных)
- Effort: High (6 месяцев работы команды)
- Квадрант: Big Bets 📊

Фича В: Добавить 20 новых языков интерфейса
- Value: Low (95% пользователей из России)
- Effort: High (перевод, тестирование, поддержка)
- Квадрант: Money Pit ❌

Фича Г: Изменить иконку в футере
- Value: Low (никто не обращает внимания)
- Effort: Low (5 минут работы)
- Квадрант: Fill-ins 🤷

Преимущества Value vs Effort

• Визуальность: Сразу видно, где находятся фичи

• Простота: Понятна даже нетехнической аудитории

• Быстрота: Можно оценить за 30 минут на воркшопе

• Помогает фокусироваться: Явно показывает, чего избегать (Money Pit)

Недостатки Value vs Effort

• Упрощение: Два параметра — это грубая оценка, не учитывает нюансы

• Субъективность: Что такое «High» и «Low» — каждый понимает по-своему

• Не учитывает риски: Фича может быть ценной и лёгкой, но рискованной

• Игнорирует охват: Ценность для 10 или 10 000 пользователей — одинаково High?

Когда использовать Value vs Effort

• Нужно быстро визуализировать приоритеты для стейкхолдеров

• Проводите воркшоп по приоритизации с командой

• У вас не очень много фич (до 30), иначе матрица станет нечитаемой

• Хотите выявить «денежные ямы» и убедить команду от них отказаться

Лайфхак: Матрица 3×3

Для более детальной оценки используйте матрицу 3×3 (Low / Medium / High по обеим осям). Это даст 9 квадрантов и больше градаций.

6. Weighted Scoring (Взвешенная оценка): кастомизация критериев

Weighted Scoring — это гибкий метод, где вы сами выбираете критерии оценки и их веса.

Как работает метод

Шаг 1: Выберите критерии

Например, для B2B SaaS:
- Влияние на retention (удержание клиентов)
- Влияние на acquisition (привлечение новых клиентов)
- Влияние на monetization (монетизация)
- Стратегическая важность
- Усилия на разработку

Шаг 2: Назначьте веса

Распределите 100% между критериями в зависимости от приоритетов:
- Retention: 30%
- Acquisition: 20%
- Monetization: 25%
- Стратегия: 15%
- Усилия: 10%

Шаг 3: Оцените каждую фичу

По каждому критерию поставьте оценку от 1 до 10.

Шаг 4: Посчитайте взвешенный скор

Score = (Оценка1 × Вес1) + (Оценка2 × Вес2) + ... + (ОценкаN × ВесN)

Пример расчёта

Фича: Добавить интеграцию с Slack

Фича: Редизайн главной страницы

Приоритизация: Интеграция с Slack (6.6) > Редизайн (6.0)

Преимущества Weighted Scoring

• Кастомизация: Вы выбираете критерии, важные для вашего бизнеса

• Прозрачность: Все видят, почему одна фича важнее другой

• Гибкость: Можно адаптировать под любую индустрию и продукт

• Учитывает многофакторность: 5-10 критериев вместо 2-4

Недостатки Weighted Scoring

• Сложность: Требует времени на настройку критериев и весов

• Риск analysis paralysis: Можно увязнуть в бесконечном анализе

• Субъективность весов: Как решить, что retention 30%, а acquisition 20%?

• Трудоёмкость: Оценка каждой фичи по 5-10 критериям занимает время

Когда использовать Weighted Scoring

• У вас специфический продукт, и стандартные методы не подходят

• Вам нужно учесть множество факторов (не только value и effort)

• Команда спорит о приоритетах — нужна прозрачная система

• Вы принимаете решения для крупного проекта с высокими ставками

Лайфхак: Автоматизация в Google Sheets

Создайте таблицу с формулами, чтобы автоматически считать взвешенный скор. Это превращает процесс в 5-минутную процедуру.

Сравнение методов: какой выбрать?

Универсального метода не существует. Выбор зависит от контекста, размера команды, стадии продукта и доступных данных.

Сравнительная таблица

Принципы выбора метода

Стадия продукта:
- Discovery / MVP: MoSCoW, Kano (понять, что критично)
- Growth: ICE, RICE (быстро тестировать гипотезы)
- Maturity: Weighted Scoring, RICE (сложные решения, много факторов)

Размер команды:
- Малая команда (2-5 человек): ICE, Value vs Effort (быстро и просто)
- Средняя команда (6-15 человек): RICE, MoSCoW (баланс скорости и объективности)
- Большая команда (15+ человек): Weighted Scoring, RICE (нужна прозрачность)

Доступность данных:
- Много данных и аналитики: RICE, Kano (можно опираться на факты)
- Мало данных: ICE, MoSCoW (быстрые оценки на интуиции)

Цель приоритизации:
- Планирование спринта: MoSCoW (быстро отсечь лишнее)
- Годовой роадмап: RICE, Weighted Scoring (стратегическое планирование)
- Эксперименты и A/B-тесты: ICE (скорость важнее точности)

Лайфхаки и best practices приоритизации

1. Комбинируйте методы

Не обязательно выбирать один метод. Используйте несколько последовательно:
1. MoSCoW — отсеять явно ненужное (Won't have)
2. RICE — приоритизировать Must have и Should have
3. ICE — для быстрых экспериментов внутри спринта

2. Пересматривайте приоритеты регулярно

Приоритеты не высечены в камне. Пересматривайте их:
- Каждый квартал — для роадмапа
- Каждый спринт — для бэклога
- После релиза фичи — проверяйте, совпали ли прогнозы с реальностью

3. Вовлекайте команду

Не принимайте решения в вакууме. Проводите воркшопы по приоритизации с:
- Разработчиками (оценка усилий)
- Дизайнерами (UX-последствия)
- Аналитиками (данные и метрики)
- Продажами и поддержкой (обратная связь от клиентов)

4. Фокусируйтесь на метриках

Любая приоритизация должна быть связана с бизнес-метриками:
- Какую метрику должна улучшить фича?
- Как мы измерим успех?
- Какой целевой показатель?

Без метрик приоритизация превращается в гадание.

5. Учитывайте зависимости

Иногда фича с низким приоритетом критична для фичи с высоким приоритетом. Учитывайте технические зависимости при планировании.

6. Не бойтесь говорить «нет»

80% идей не должны быть реализованы. Хороший Product Manager говорит «нет» чаще, чем «да». Приоритизация — это искусство отказа.

7. Документируйте решения

Записывайте, почему выбрали эту фичу. Через 6 месяцев вы забудете логику. Документация помогает объяснить решения новым членам команды.

8. Тестируйте предположения

Если приоритизация основана на гипотезах, тестируйте их:
- Прототипы
- Landing pages
- A/B-тесты
- Опросы пользователей

Не стройте то, в чём не уверены.

Заключение

Приоритизация фич — это не магия и не интуиция. Это систематический процесс, основанный на методах, данных и критериях. В 2025 году у Product Manager'ов есть богатый арсенал инструментов:

• RICE — для объективной оценки на основе метрик

• Kano — для понимания эмоций пользователей

• MoSCoW — для быстрого планирования спринтов

• ICE — для экспериментов и гипотез

• Value vs Effort — для визуализации и воркшопов

• Weighted Scoring — для кастомизации под специфику бизнеса

Ключевые выводы:

1. Нет универсального метода — выбирайте под контекст

2. Комбинируйте методы — используйте несколько последовательно

3. Фокусируйтесь на данных — минимизируйте субъективность

4. Вовлекайте команду — приоритизация — это командная работа

5. Пересматривайте регулярно — приоритеты меняются

6. Связывайте с метриками — знайте, как измерите успех

7. Говорите «нет» — 80% идей не нужны прямо сейчас

Помните: хорошая приоритизация — это не о том, чтобы делать всё. Это о том, чтобы делать правильное. Лучше выпустить 5 отличных фич, которые решают реальные проблемы пользователей, чем 50 посредственных, которые никто не использует.

Начните с простого метода (MoSCoW или ICE), освойте его, затем переходите к более сложным (RICE, Weighted Scoring). Главное — начать использовать хоть какой-то систематический подход. Это уже на порядок лучше, чем «делаем то, что просит CEO».

Удачи в приоритизации! Пусть ваш бэклог всегда будет актуальным, а фичи — ценными.

А лучшие вакансии продактам менеджерам на сайте Hirehi.ru