Решал ли бизнес какой приоритет у задач

Да, решал, и это одна из ключевых частей процесса управления проектом. Приоритизация задач — это инструмент выбора в условиях ограниченных ресурсов. Без приоритетов проект превращается в хаотичный набор задач, где работа над неважным может блокировать критически важное. Навык определения и защиты правильных приоритетов — это навык управления самой ценной ресурсом проекта: временем и вниманием команды.

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

Стратегические Фреймворки для Приоритизации

Сначала мы определяем "что важно" в масштабах всего продукта или проекта, согласуя это с бизнес-целями.

• Канбан или матрица приоритетов: Самый частый инструмент в IT. Мы совместно с бизнесом и разработкой используем простую систему: Блокер (Blocker) → Высокий (High) → Средний (Medium) → Низкий (Low). Критерии для каждого уровня четко определены. Например:

  // Пример критериев (часто визуализируется в виде таблицы):
  // Blocker: Полностью блокирует работу системы или ключевой процесс для клиентов.
  // High: Необходим для достижения ближайшей бизнес-цели (например, запуск новой фичи к дате маркетинга).
  // Medium: Улучшает опыт или эффективность, но не является обязательным.
  // Low: Долгосрочные улучшения, багфикс без серьезного влияния.
  

    Эти критерии создаются вместе с бизнес-заказчиком и Tech Lead.

• WSJF (Weighted Shortest Job First) из SAFe: Для продуктов с постоянным потоком новых требований. Мы оцениваем каждую фичу или задачу по формуле: (Бизнес-ценность + Уровень риска + Срочность) / Длительность реализации. Это превращает приоритизацию в почти математический процесс, где задача с меньшим сроком реализации, но высокой ценностью получает преимущество. Это мощный инструмент против "paralysis by analysis" — ситуации, когда все задачи кажутся важными.

  # Концептуальный пример расчета WSJF (обычно делается в таблицах):
  # Все параметры (Value, Risk, Urgency, Duration) оцениваются по относительной шкале (например, 1-10).
  def calculate_wsfj(value, risk, urgency, duration):
      cost_of_delay = value + risk + urgency
      return cost_of_delay / duration
  # Задача с WSJF = 15 будет выше в приоритете, чем задача с WSJF = 5.
  

• ICE Score или RICE Score: Часто используется в продукт-менеджменте. ICE = Impact * Confidence * Effort. RICE = Reach * Impact * Confidence / Effort. Эти модели помогают сравнивать задачи разного типа (новые фичи, улучшения, технический долг) на единой шкале. Мы используем их на уровне планирования квартала или крупного релиза.

Операционные Инструменты для Управления Приоритетами

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

• Очередь в бэклог: В Jira, Asana или любого другого инструмента бэклог всегда должен быть приоритизирован. "Верхние" 20-30 задач — это наш план на ближайшие спринты или месяц. Ниже — всё остальное. Эта очередь — живой документ, который мы пересматриваем на каждом планировании.

• Спринт Planning и "Capacity Allocation": Во время планирования спринта мы не просто берем задачи сверху бэклога. Мы соотносим их с доступной производительностью (capacity) команды и их текущим контекстом. Иногда "важная" стратегическая задача требует участия ключевого разработчика, который сейчас занят устранением Blocker — тогда мы можем временно поставить стратегическую задачу ниже, чтобы устранить блокер.

• Система для обработки срочных запросов и багов: Это отдельный, критически важный процесс. У нас всегда есть четкое правило:

    *   **Баг, нарушающий core functionality или безопасность** (Blocker/Severity 1) — исследуется немедленно, часто в обход текущего спринта.
    *   **Срочный бизнес-запрос от руководства** — оценивается вместе с командой на предмет реальной срочности и влияния. Если он действительно критичный, мы используем механизм **swap**: вынимаем из спринта задачу равного объема работы и заменяем её на срочную. Это дисциплинирует бизнес, потому что они видят цену срочности — отложенная другая работа.

Как бизнес участвует в процессе

Бизнес — не просто источник требований, а ключевой участник системы приоритетов.

1. Представитель бизнеса (Product Owner, Stakeholder) владеет критериями для уровней приоритета (High/Medium/Low). Я регулярно провод workshops, чтобы эти критерии были свежими и соответствовали текущим бизнес-целям.
2. В регулярных совещаниях по планированию (Quarterly Planning, Sprint Planning) бизнес присутствует, чтобы подтвердить или корректировать приоритеты в верхней части бэклога на основе новых данных (например, изменение рынка).
3. Бизнес уважает установленный процесс для срочных запросов. Если нет процесса, команда постоянно переключается между задачами, и эффективность падает. Я всегда объясняю эту взаимосвязь: хаос в приоритетах → низкая скорость реализации → упущенные бизнес-возможности.

Пример из практики (Приоритизация технического долга vs новых фич)

Одна из самых сложных дилемм. Бизнес естественно хочет новых фич. Команда указывает на растущий технический долг, который снижает скорость и повышает риск. Моя роль здесь — быть переводчиком и медиатором.

• Мы создаем отдельную категорию в бэклоге для "Tech Debt & Refactoring".
• Я вводил правило "20% capacity на улучшение": в каждый спринт команда выделяет ~20% времени не на новые фичи, а на улучшение кода, инфраструктуры, устранение самых болезненных долгов. Это правило согласовывается с бизнесом на уровне квартального планирования.
• Чтобы показать ценность, мы измеряем и сообщаем метрики: "После рефакторинга модуля X, время разработки новой фичи в этой области сократилось с 5 дней до 2". Это превращает технические задачи в бизнес-инвестиции в будущую скорость.

Итог: Приоритизация — это непрерывный процесс совместного принятия решений, основанный на четких правилах, данных и взаимном понимании целей. Моя задача как PM — создать, поддерживать и защищать эту систему, чтобы команда работала на самом важном, а бизнес видел четкую связь между своими целями и работой команды.