Как происходит приоритизация задач?

Как происходит приоритизация задач

Приоритизация — это один из самых важных навыков PM, потому что ресурсы всегда ограничены, а идей бесконечно. Я применяю многоуровневый подход, который комбинирует данные, стратегию и pragmatism.

Уровень 1: Стратегическое выравнивание

Перед тем, как приоритизировать конкретные задачи, я убеждаюсь, что все они выравнены со стратегией:

Вопросы, которые я задаю:

• Соответствует ли задача OKR (Objectives and Key Results) компании на этот квартал?
• Соответствует ли она long-term vision и roadmap?
• Решает ли она реальную проблему пользователей или бизнеса?

Если задача не соответствует стратегии, она идёт в backlog (может быть, кому-то её даст) или отклоняется.

Пример: Если стратегия: "Увеличить retention новых пользователей", то задача "добавить 50 новых эмодзи" не приоритет, даже если это просит много пользователей.

Уровень 2: Фреймворк приоритизации

Мой основной инструмент — это RICE score, хотя я адаптирую его в зависимости от контекста:

RICE = (Reach × Impact × Confidence) / Effort

Каждый компонент объясняю подробнее:

Reach (охват):

• Сколько пользователей это затронет в течение квартала?
• Единица: users per quarter (или % от базы)
• Примеры: 10,000 users, 50% of user base
• Вопрос: кто чувствует боль от отсутствия этого решения?

Impact (влияние):

• Как сильно это улучшит experience для затронутого пользователя?
• Шкала: massive (3x лучше) → high (2x) → medium (улучшение заметно) → low (маленькое улучшение) → minimal
• Примеры: если loading улучшится с 5 сек до 0.5 сек = massive impact
• Вопрос: насколько это сильно улучшит метрики (retention, NPS, revenue)?

Confidence (уверенность):

• Насколько я уверен в оценках Reach и Impact?
• Шкала: high (100%, есть данные) → medium (70%, есть некоторые данные) → low (50%, это гипотеза)
• Примеры: если есть A/B тест, confidence = high. Если это idea from user, confidence = low
• Вопрос: есть ли данные, подтверждающие impact?

Effort (затраты):

• Сколько человеко-недель нужно, чтобы реализовать?
• Единица: person-weeks (1 разработчик × 1 неделя = 1 person-week)
• Примеры: 1 pw (1 дизайнер на 3 дня), 20 pw (2 разработчика на месяц)
• Вопрос: какие ресурсы нужны? (Design, Engineering, QA, Analytics)

Расчет RICE:

Предположим:

• Reach: 50,000 users
• Impact: high (2x улучшение метрики)
• Confidence: high (100%)
• Effort: 8 person-weeks

RICE = (50,000 × 2 × 1.0) / 8 = 100,000 / 8 = 12,500

Уровень 3: Сравнение задач

Когда я посчитал RICE для всех задач, я:

1. Сортирую по RICE score — задачи с большим score идут наверх

2. Смотрю на распределение:

   • Обычно топ 20% задач дают 80% ценности (Парето)
   • Задачи с score > 10,000: обязательно делаем
   • Tasks с score 5,000-10,000: высокий приоритет
   • Tasks с score 1,000-5,000: рассматриваем
   • Tasks с score < 1,000: backlog

3. Учитываю зависимости:

   • Даже если задача B имеет lower score, если она блокирует более важную задачу A, я делаю B раньше
   • Пример: bug fix может быть lower score, но если он блокирует feature, fix идёт первым

Уровень 4: Контекстные факторы

RICE — это не абсолютная истина. Я также учитываю:

Срочность vs Важность (Eisenhower Matrix):

• Urgent + Important = делаем сразу (emergency bugs, critical business decision)
• Important + Not Urgent = планируем (стратегические инициативы, улучшения)
• Urgent + Not Important = делегируем (срочные, но не критичные запросы)
• Not Urgent + Not Important = не делаем (можем отклонить)

Синергия (Synergy):

• Если две задачи можно делать параллельно с минимальным overhead, я их объединяю
• Пример: улучшение onboarding flow можно сделать одновременно с A/B тестом push notifications

Risk:

• Если задача имеет высокий risk (может сломать что-то), я добавляю effort estimate
• Если risk управляем, я приоритизирую выше
• Пример: refactoring architecture может иметь high impact, но и high risk

Timing и Market Window:

• Некоторые возможности (market trends, seasonal demand) имеют окно
• Пример: если конкурент выпустил фичу, а пользователи ждут, это может skew приоритет

Уровень 5: Коммуникация и консенсус

Приоритизация — это не только мой процесс, это кросс-функциональный диалог:

1. Я представляю RICE scores в meeting с инженерами, дизайнерами, маркетингом
2. Они бросают вызовы:
   • "Технически это займёт 20 pw, не 8" → меняю effort
   • "Наши данные показывают, что reach только 10,000" → меняю reach
   • "Это решает не main pain point пользователей" → меняю impact
3. Мы договариваемся об итоговом приоритете
4. Я документирую решение и причину (важно для transparency)

Практический пример из реального проекта

Проект: Мобильный app с 1M DAU

Три задачи в очереди на квартал:

Задача A: Улучшение поиска (performance: 2 сек → 0.5 сек)

• Reach: 500k (половина ищет каждый день)
• Impact: high (2x, поиск критичен)
• Confidence: high (test на subset показал результат)
• Effort: 12 pw
• RICE = (500k × 2 × 1.0) / 12 = 83,333

Задача B: Новая социальная фича (sharing с друзьями)

• Reach: 200k (не все используют sharing)
• Impact: massive (3x, может drive virality)
• Confidence: medium (это гипотеза, не test)
• Effort: 16 pw
• RICE = (200k × 3 × 0.7) / 16 = 26,250

Задача C: Bug fix (login на iOS не работает)

• Reach: 50k (только iOS users unable to login)
• Impact: massive (3x, без login ничего не работает)
• Confidence: high (реальный баг)
• Effort: 2 pw
• RICE = (50k × 3 × 1.0) / 2 = 75,000

Приоритизация:

1. Task C (bug fix): 75,000 — делаем первым, это urgent и critical
2. Task A (search): 83,333 — второе, high value
3. Task B (social): 26,250 — third, lower priority despite massive impact (confidence и effort факторы)

Кап нужно 30 pw на квартал? Делаем C + A (18 pw), Task B идёт в backlog на следующий квартал.

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

• Spreadsheets: Google Sheets с RICE scores, отслеживанием
• Jira/Linear: для tracking задач и фильтрации по приоритету
• Miro: для визуализации приоритетов и зависимостей
• SQL: для анализа reach и impact данных
• Slack polling: для quick input от команды

Главный принцип

Приоритизация работает лучше всего, когда она data-informed, но не data-dictated. RICE даёт мне framework для рационального обсуждения, но финальное решение всегда учитывает контекст, стратегию и мнение экспертов в команде.