Ответ

Рассмотрение приоритетов — одна из самых сложных задач в деятельности бизнес-аналитика. В начале аналитик собирает полный перечень требований от каждого стейкхолдера. Затем он определяет критерии для приоритизации: бизнес-ценность, риски, срочность, издержки, влияние на пользователя, техническая реализуемость. Для систематизации часто используется матрица MoSCoW (Must/Should/Could/Won’t) и методики Weighted Shortest Job First (WSJF), RICE и др.

Многокритериальный анализ помогает объяснить стейкхолдерам, почему требования одного участника уходят в реализацию, а другого — переносятся. В результате проводится согласование — создаётся “карта приоритетов:”

| Требование    | Стейкхолдер | Влияние | Приоритет | Ожидаемый релиз |
|---------------|-------------|---------|-----------|-----------------|
| Интеграция X  | КОМАНДА_А   | Высокое | High      | 1.0             |
| Функция Y     | КОМАНДА_Б   | Среднее | Medium    | 1.1             |

Аналитик аргументирует выбор на основе критериев, вовлекает куратора проекта для эскалаций.

Ключевые особенности:

• Применение прозрачных подходов к приоритизации с пояснением причин.
• Акцент на достижении компромисса между бизнес- и техническими требованиями.
• Открытое обсуждение приоритетов со всеми группами заинтересованных лиц.

Вопросы с подвохом.

Можно ли полагаться только на мнение самого влиятельного стейкхолдера?

Нет. Одностороннее следование мнению одного стейкхолдера ведёт к проигрышу в других важных направлениях проекта и потенциальным конфликтам.

Стоит ли приоритизировать только по срочности задачи?

Нет. Срочность — только один из параметров, нужно оценивать совокупное влияние на цели, стоимость, риски.

Является ли итоговая карта приоритетов статичной на всём протяжении проекта?

Нет, приоритеты должны гибко пересматриваться по мере изменения бизнес-целей, появления новых ограничений или информации.

Типовые ошибки и анти-паттерны

• Необоснованное принятие требований в работу без анализов и аргументов.
• Игнорирование прозрачной процедуры для пересмотра приоритетов.
• Недостаточная коммуникация с командами при появлении противоречий.

Пример из жизни

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

Плюсы: Повысили лояльность одного стейкхолдера Минусы: В итоге снизился общий уровень удовлетворённости, выросли издержки на доработки

Положительный кейс: Аналитик инициировал совещание: по матрице MoSCoW вместе с руководителями функциональных блоков выработали сбалансированный лист задач.

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