Какие знаешь способы приоритизации задач?

Методы приоритизации задач: полный обзор

Знаю несколько проверенных методов приоритизации. Каждый имеет свои преимущества и лучше работает в разных контекстах.

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

Это мой любимый метод, разработанный в Intercom. Он комбинирует количественные и качественные метрики.

Компоненты:

• Reach (охват) — сколько пользователей коснётся фича за квартал (в числах)
• Impact (влияние) — как изменится поведение каждого пользователя (3x, 2x, 1x, 0.5x, 0.25x)
• Confidence (уверенность) — на сколько процентов я уверен в оценке (50%, 75%, 100%)
• Effort (усилия) — сколько недель разработки требуется

Формула: RICE = (Reach × Impact × Confidence) / Effort

Пример: Фича касается 5000 пользователей (Reach), даст 2x увеличение retention (Impact), я на 75% уверен (Confidence), требует 4 недели работы (Effort). Score = (5000 × 2 × 0.75) / 4 = 1875

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

• Объективная, воспроизводимая система
• Мотивирует думать об усилиях относительно потенциала
• Легко объяснить стейкхолдерам

Недостатки:

• Сложно точно оценить Reach и Impact заранее
• Требует дисциплины и регулярного пересчета

2. MoSCoW (Must, Should, Could, Won't)

Простой метод для квартального или спринтового планирования.

Категории:

• Must — критические фичи, без них продукт нежизнеспособен
• Should — высокий приоритет, важны для бизнеса, но не критичны
• Could — хотелось бы иметь, но можно отложить
• Won't — не планируем в этом цикле, но документируем на будущее

Пример распределения в спринте:

• Must: 40-50% спринта
• Should: 30-40%
• Could: 10-20%
• Won't: документируются, но не берутся

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

• Очень быстро применить
• Интуитивно понятно команде
• Хорошо для긴급ных ситуаций

Недостатки:

• Субъективно
• Не учитывает Effort
• Может привести к перегрузу Must-задач

3. Kano Model

Фокусируется на том, как фичи влияют на удовлетворение пользователей.

Три категории фич:

• Basic (базовые) — ожидают пользователи, их отсутствие сильно расстраивает, но наличие не радует (заряд батареи в телефоне)
• Performance (производительность) — чем лучше, тем больше довольны пользователи (скорость загрузки приложения)
• Delighter (радость) — неожиданные приятные фичи, создающие WOW-эффект (красивая анимация, Easter Eggs)

Стратегия:

1. Убедитесь, что все Basic фичи реализованы
2. Инвестируйте в Performance, так как это дает ROI
3. Добавляйте Delighters для дифференциации от конкурентов

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

• Фокус на user satisfaction
• Помогает различить критичное от приятного
• Долгосрочный взгляд на продукт

Недостатки:

• Требует понимания пользователей (часто требует research)
• Не дает четкую числовую оценку

4. Value vs. Effort Matrix (2x2)

Просто: рисуем матрицу с двумя осями.

Оси:

• Y (вертикаль) — Value (бизнес-ценность)
• X (горизонталь) — Effort (сложность реализации)

Четыре квадранта:

• High Value, Low Effort — QUICK WINS (делаем первыми)
• High Value, High Effort — STRATEGIC (планируем на лонг-терм)
• Low Value, Low Effort — FILL-INS (берем если есть время)
• Low Value, High Effort — AVOID (отклоняем)

Пример: Фиксить баг авторизации (HV, LE) vs. Полная переработка архитектуры (HV, HE)

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

• Очень быстро применить
• Визуально понятно
• Хорошо для быстрого обсуждения со стейкхолдерами

Недостатки:

• Слишком упрощённо
• Сложно оценить Value объективно
• Не учитывает Reach

5. Weighted Scoring

Получше, чем Value vs. Effort, но сложнее в применении.

Процесс:

1. Определить критерии: User Impact (30%), Business Value (25%), Technical Feasibility (20%), Market Urgency (15%), Team Capacity (10%)
2. Каждый критерий оценивается от 1 до 5
3. Вес умножается на оценку
4. Сумма = итоговый score

Пример для фичи:

• User Impact: 5 × 30% = 150
• Business Value: 4 × 25% = 100
• Technical Feasibility: 3 × 20% = 60
• Market Urgency: 4 × 15% = 60
• Team Capacity: 2 × 10% = 20
• Total: 390 из 500

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

• Гибкий, можно адаптировать под бизнес
• Учитывает множество факторов
• Объективнее, чем просто экспертное мнение

Недостатки:

• Требует больше времени на расчеты
• Легко манипулировать весами
• Может быть громоздким для больших бэклогов

6. Buy a Feature

Интерактивный метод, часто использует на workshop'ах.

Процесс:

1. Даёте стейкхолдерам виртуальный бюджет
2. Они "покупают" фичи из бэклога
3. Дорогие фичи требуют больше бюджета
4. Видно, что реально хотят стейкхолдеры

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

• Быстро выявляет истинные приоритеты
• Вовлекает стейкхолдеров в процесс
• Весело и интерактивно

Недостатки:

• Требует подготовки workshop'а
• Субъективно
• Не масштабируется на большие команды

Какой метод выбрать?

RICE — если нужна научный подход, большой бэклог, и есть данные MoSCoW — если работаете в Scrum, нужна скорость, часто переплюсовываете Kano — если фокусируетесь на customer satisfaction и дифференциации Value vs. Effort — если нужна быстрая визуализация для встреч Weighted Scoring — если много критериев, сложный бизнес Buy a Feature — если хотите вовлечь стейкхолдеров в принятие решений

В моей практике: Обычно комбинирую RICE для долгосрочного роадмэпа и MoSCoW для спринтового планирования. Это дает баланс между точностью и скоростью.