Как приоритезируешь задачи?

# Приоритизация задач: Методология и практика

Приоритизация — это один из самых критичных навыков BA'а. Это не просто выбор того, что сделать первым. Это умение балансировать между бизнес-ценностью, техническими ограничениями, рисками и ресурсами.

Мой многоуровневый подход

Уровень 1: Стратегическая приоритизация (Roadmap level)

На уровне roadmap'а я использую framework MoSCoW:

Must Have (критическое)

• Features, без которых продукт не может запуститься
• Обязательные compliance требования
• Блокеры для других фич Примеры: аутентификация, базовая функциональность, критичные для BOM

Should Have (важное)

• High-value features для пользователей
• Features, которые дифференцируют нас от конкурентов
• Улучшают user experience, но не critical Примеры: advanced search, personalization, интеграции

Could Have (приятное)

• Nice-to-have features
• Улучшают experience, но не essential
• Можно отложить Примеры: dark mode, advanced analytics, social sharing

Won't Have (отложено)

• Явно исключено из текущего scope
• Может быть рассмотрено в future releases

Это дает ясную картину всем стейкхолдерам.

Уровень 2: Динамическая приоритизация (Sprint level)

В рамках спринта используют более сложный scoring system. Я применяю RICE Score или Value vs Effort:

RICE метод (когда есть данные):

• R (Reach): Сколько пользователей затронет? (в месяц)
• I (Impact): Какой impact на одного пользователя? (massive/high/medium/low/minimal)
• C (Confidence): На сколько % уверены в оценке?
• E (Effort): Сколько времени (в person-weeks)?

Формула: Score = (R × I × C) / E

Пример из реальной практики:

Текла работа над несколькими features:

• Улучшение search: Reach=5000, Impact=high (3), Confidence=90%, Effort=2 недели → Score = (5000×3×0.9)/2 = 6750
• Экспорт в CSV: Reach=500, Impact=medium (2), Confidence=95%, Effort=1 неделя → Score = (500×2×0.95)/1 = 950
• Dark mode: Reach=1000, Impact=low (1), Confidence=100%, Effort=3 недели → Score = (1000×1×1)/3 = 333

Результат: Search имеет наивысший score, должен быть сделан первым.

Value vs Effort матрица (когда нет данных):

        High Value
           │
    Quick wins │ Strategic
    (низкий    │ (высокий
     effort)   │ effort)
────────────┼────────────
    Time-   │ Money pits
   sinks    │ (низкий
 (низкое    │ value,
 value,     │ высокий
 низкий     │ effort)
 effort)    │
            ▼
        Low Value

Уровень 3: Зависимости и блокеры

Чем бы ни был high score, если feature A зависит от feature B, то B должна быть сделана первой.

Я использую dependency matrix и наглядные диаграммы (с помощью Miro или инструментов JIRA).

Реальный кейс: E-commerce Marketplace

Рабортал над приоритизацией features для нового marketplace. Было 15+ инициатив, конкурирующих за внимание.

Процесс:

1. Собрал stakeholders: Product Manager, CFO, Head of Support, CTO

2. Определил constraints:

   • 3 разработчика на 8 недель
   • 1 дизайнер
   • Critical deadline: launch to 5 key partners

3. Применил RICE для каждой инициативы:

   • Seller dashboard: 12500
   • Product catalog management: 11000
   • Review system: 9500
   • Advanced analytics: 4200
   • Mobile app: 3800 (но это был другой effort)

4. Добавил risk factor:

   • Seller dashboard: Technical risk (medium) → -20% score
   • Product catalog: Technical risk (low) → -5% score

5. Построил dependency map:

   • Review system зависит от Product catalog
   • Analytics зависит от обеих

6. Итоговый roadmap:

   • Неделя 1-2: Foundation (authentication, basic product upload)
   • Неделя 3-4: Product catalog management
   • Неделя 5-6: Seller dashboard
   • Неделя 7-8: Review system
   • Future: Advanced analytics

Результат: Успешный launch в deadline с buy-in всех стейкхолдеров.

Как я получаю данные для приоритизации

Quantitative:

• User research: сколько людей просят эту feature
• Product analytics: какие части продукта используются больше
• Support tickets: какие проблемы создают наибольший volume
• Конкурентный анализ: что делают конкуренты

Qualitative:

• Интервью с users: нарративы, frustrations
• Stakeholder feedback: что важно для бизнеса
• Technical assessment: влияние на архитектуру

Типичные ошибки, которых я избегаю

1. Priortizing по громкости голоса

• Неправильно: CEO сказал это должно быть first
• Правильно: CEO сказал, что это important, но давайте оценим impact/effort

2. Забываю про technical debt

• Technical debt тоже должен быть в backlog'е
• Если он блокирует future features — это должна быть high priority

3. Игнорирую dependencies

• Часто team хочет делать что-то крутое, но оно зависит от foundation
• Нужно объяснить, что foundation идет первым

4. Фиксирую приоритеты без переоценки

• Приоритеты меняются по мере того, как меняется бизнес, рынок, user feedback
• Я переоцениваю roadmap каждый квартал

Инструменты и практики

JIRA: Для трейкинга и simple scoring (custom fields с weights)

Miro/Lucidchart: Для визуализации dependency graphs и matrices

Excel/Sheets: Для RICE расчётов и анализа (когда нужна гибкость)

Confluence: Для документирования reasoning behind decisions

Meetings: Quarterly prioritization workshop'ы с core stakeholders

Communication после приоритизации

Когда приоритеты установлены, я:

1. Документирую reasoning: Почему это order, какие factors учитывались
2. Объясняю trade-offs: Что мы выбрали и что отложили, почему
3. Готовлю для rejected items: Когда что-то в Won't Have, нужна хорошая explanation для инициатора
4. Слежу за метриками: После delivery, смотрю на actual impact vs predicted, учу

Приоритизация — это не научный процесс, это искусство балансирования, основанное на данных. Ключ — быть transparent в reasoning и гибким при изменении обстоятельств.