Как участвовал в ранжировании?

Мой опыт в ранжировании и приоритизации

Контекст и определение

Ранжирование в работе Product Analyst — это упорядочивание задач, фич, идей или метрик по степени важности и влияния. Я активно участвовал в создании системы приоритизации, которая обеспечивала alignment команды вокруг стратегических целей.

Методологии, которые я использовал

1. RICE Framework (Reach, Impact, Confidence, Effort)

Это был основной инструмент нашей команды. Каждую идею мы оценивали по четырём параметрам:

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

Пример расчёта:
- Reach: 10,000 пользователей = 10
- Impact: высокий = 3
- Confidence: 80% = 0.8
- Effort: 5 недель = 5

Score = (10 * 3 * 0.8) / 5 = 4.8

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

• Объективное сравнение разнородных идей
• Учёт затрат на реализацию
• Баланс между амбициозностью и реальностью

Когда я использовал:

• Квартальное планирование фич
• Сравнение конкурирующих идей
• Презентация приоритетов стейкхолдерам

2. Value vs. Effort Matrix (2x2 Priority Grid)

Проще визуализировать приоритеты:

         EFFORT →
      LOW    HIGH
VAL ↑ Q2   Q1      HIGH VALUE
UE  │ (Do Later) (Do First)
    │
    ↓ Q3   Q4      LOW VALUE
     (Eliminate) (Maybe Later)

Мой пример:

• Q1 (Do First): Добавить фильтры в search — низкий effort, высокий value
• Q4 (Eliminate): Кастомные темы оформления — высокий effort, низкий value

3. MoSCoW Method (Must, Should, Could, Won't)

Для спринтов и релизов:

• Must — критические фичи для релиза (40% бэклога)
• Should — важные, но не критичные (30%)
• Could — хорошо иметь (20%)
• Won't — отложить на позже (10%)

Реальные примеры участия

Кейс 1: Ранжирование фич для мобильного приложения

Задача: Было 15 идей, бюджет на 3 месяца разработки.

Процесс:

1. Провёл интервью с 20 пользователями о болях
2. Собрал данные из аналитики (где падают пользователи, где зависания)
3. Оценил каждую фичу по RICE
4. Провёл фиджибилити встречу с инженерами
5. Согласовал с бизнесом (CPO, CEO)

Результат:

Топ 5 приоритетов:
1. Offline mode (Score: 8.2) → Must Have
2. Dark theme (Score: 6.5) → Should Have
3. Push notifications (Score: 5.8) → Should Have
4. Social sharing (Score: 3.2) → Could Have
5. AR preview (Score: 2.1) → Won't (moved to Q2 2025)

Метрики успеха:

• Реализовали за 12 недель (в срок)
• Retention через 30 дней: +15%
• App Store rating: 4.6 → 4.8

Кейс 2: Приоритизация метрик для овалидации гипотез

Задача: Какие метрики отслеживать при запуске нового фила?

Мой подход:

Первичные метрики (что мы хотим улучшить):
- Adoption Rate (% новых пользователей, использующих фичу)
- DAU (ежедневно активные пользователи)

Вторичные метрики (здоровье продукта):
- Retention D7, D30
- Session length
- Crash rate

Gauge метрики (контроль за побочными эффектами):
- Bounce rate
- Support tickets
- CSAT score

Это помогло избежать ошибок типа фича получила трафик, но люди уходят.

Кейс 3: Ранжирование багов vs. Фич

Проблема: Инженеры хотят фиксить баги, продукт хочет новые фичи.

Решение — 3-уровневая система:

# Severity Level
P0 (Critical): Приложение не работает, есть потеря данных → Fix immediately
P1 (High): Серьёзные ошибки, которые влияют на 10%+ пользователей → Fix in current sprint
P2 (Medium): Ошибки, которые можно обойти → Fix next sprint
P3 (Low): Косметические проблемы → Backlog

Правило: На каждый спринт минимум 30% мощности идёт на P0-P1 баги.

Инструменты, которые я использовал

1. Spreadsheet (Google Sheets)

   • Таблица со всеми идеями и их оценками
   • Фильтры и сортировка по RICE Score
   • Shared с командой для транспарентности

2. Figma Whiteboards

   • Визуализация приоритет-матриц
   • Вертуальные планерки в удалённом режиме

3. Jira / Linear

   • Теги для категоризации (feature, bug, tech-debt)
   • Custom fields для effort estimate
   • Epic-based grouping для квартального плана

4. Data Analysis (SQL, Python)

   • Расчёт Reach из базы данных
   • Анализ Impact через юзер-сегменты
   • Построение зависимостей между фичами

Ключевые принципы, которые я выработал

1. Транспарентность — все знают, почему фича приоритизирована так, а не иначе
2. Итеративность — приоритеты пересматриваются каждый спринт/месяц
3. Данные vs. Мнение — стараюсь использовать числа, а не интуицию
4. Баланс — балансирую между стратегией (квартальные цели) и тактикой (срочные баги)
5. Взаимозависимость — учитываю, что одна фича может блокировать другую

Вызовы и решения

Вызов: Stakeholder alignment — когда CEO, CTO и Head of Design видят приоритеты по-разному.

Решение: Ежемесячные встречи с представителями каждого направления (продукт, инженеринг, дизайн, бизнес). На встречах показываю данные, проводим дебаты в рамках RICE framework. Решение принимаем коллективно.

Результаты моего участия в ранжировании

• Скорость разработки +25% за счёт сфокусированности команды
• Удовлетворённость пользователей с 3.2 до 4.5 звёзд
• Time to Market сократился на 30% благодаря отказу от лишних фич
• Alignment в команде улучшился — меньше конфликтов о том, что делать в спринте

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