| name | requirements_prioritize |
| description | Скилл BABOK 5.3 — Приоритизация требований. Используй этот скилл когда BA хочет расставить приоритеты требований по методу MoSCoW, WSJF или Impact/Effort, разрешить конфликты между стейкхолдерами или обосновать порядок реализации. Триггеры: «приоритизация», «prioritize requirements», «MoSCoW», «WSJF», «что делать сначала», «конфликт приоритетов», «важность требований», «backlog».
|
| project | AI-powered Platform AInalyst (AI Платформа AIналитик) |
| copyright | Copyright (c) 2026 Anatoly Chaussky. Licensed under AGPL v3. Commercial licensing: chaussky@gmail.com |
SKILL: BABOK 5.3 — Prioritize Requirements
Задача: приоритизация требований и дизайнов — определение их относительной важности для стейкхолдеров.
MCP-сервер: requirements_prioritize_mcp.py
References: references/methods_guide.md, references/conflict_resolution.md
Суть задачи
5.3 — не разовое мероприятие, а непрерывный процесс. Приоритеты живут вместе с проектом.
Что делает BA в 5.3:
- Выбирает метод приоритизации под контекст проекта
- Собирает оценки стейкхолдеров (у каждого свой взгляд на ценность)
- Агрегирует оценки, выявляет конфликты и dependency violations
- Фасилитирует разрешение конфликтов
- Фиксирует итоговые приоритеты в репозитории
Что 5.3 НЕ делает:
- Не создаёт новые требования (это 4.2/4.3)
- Не формально согласовывает требования со стейкхолдерами (это 5.5)
- Не оценивает изменения/CR (это 5.4)
- Не принимает решения за стейкхолдеров — только помогает BA структурировать процесс
Выход 5.3: приоритизированные требования → уходят в 6.3 (Оценка рисков).
Входы из других задач
| Задача | Что даёт |
|---|
| 5.1 | Граф зависимостей → автоматическая проверка dependency violations |
| 5.2 | Стабильность требований → нестабильные флагируются как рискованные для высокого приоритета |
| 4.2 | Реестр стейкхолдеров → influence-веса для агрегации, список участников сессии |
| 4.3 | Подтверждённые требования → список для приоритизации |
| 3.2 | Governance rules → кто принимает финальное решение по конфликтам |
Когда активируется этот скилл
- Перед планированием спринта/релиза — нужно определить что войдёт
- После завершения выявления (4.3) — первичная приоритизация
- После получения оценок от разработчиков — пересмотр с учётом стоимости
- После Change Request (5.4) — пересмотр затронутых требований
- При изменении бизнес-контекста — полная переоценка
- Регулярно (раз в спринт/этап) — поддержание актуальности приоритетов
Три метода — краткая шпаргалка
MoSCoW
Must / Should / Could / Won't — категориальная расстановка.
Быстро, понятно стейкхолдерам. Не учитывает стоимость и time criticality.
Подробнее: references/methods_guide.md → «Метод 1»
WSJF (Weighted Shortest Job First)
WSJF = (BV + TC + RR) ÷ Job Size — числовое ранжирование.
Объективно, учитывает время и риски. Требует оценок от разработчиков.
Подробнее: references/methods_guide.md → «Метод 2»
Impact/Effort Matrix
Два критерия: ценность vs усилия → 4 квадранта → настраиваемый маппинг в приоритет.
Визуально, хорошо для воркшопов. Маппинг настраивает BA под проект.
Подробнее: references/methods_guide.md → «Метод 3»
Пять режимов работы
Режим A — Открыть сессию приоритизации
Когда: начало новой сессии (первичная или повторная приоритизация).
Алгоритм:
- Определить контекст: какая итерация? какой скоуп требований?
- Выбрать метод (если не выбран):
- Нет оценок стоимости → MoSCoW или Impact/Effort
- Есть оценки + Agile-проект → WSJF
- Для WSJF: выбрать шкалу (Fibonacci или 1–10) и установить эталонное требование
- Для Impact/Effort: настроить маппинг квадрантов
- Вызвать
start_prioritization_session
Результат: список требований готовых к оценке.
⚠️ Нестабильные требования (stability = Volatile) — помечаются автоматически.
⚠️ Требования из Must-кандидатов с зависимостями — помечаются для проверки.
Режим B — Собрать оценки стейкхолдеров
Когда: после открытия сессии, для каждого стейкхолдера отдельно.
Алгоритм:
- Для каждого стейкхолдера (из реестра 4.2) провести оценку
- Для MoSCoW: каждое требование → Must/Should/Could/Won't
- Для WSJF: оценить BV, TC, RR для каждого требования (JS — от разработчиков)
- Для Impact/Effort: оценить Impact и Effort для каждого требования
- Вызвать
add_stakeholder_scores для каждого стейкхолдера
📌 Важно: BA вызывает add_stakeholder_scores по одному разу на стейкхолдера.
Оценки накапливаются в снапшоте сессии, агрегация — только в Режиме C.
Режим C — Агрегировать и выявить конфликты
Когда: все оценки собраны, готовы к расчёту.
Алгоритм:
- Вызвать
run_aggregation
- Изучить результат:
- Итоговые приоритеты по каждому требованию
- 🔴 Конфликты стейкхолдеров — требуют разрешения
- ⚠️ Dependency violations — логические противоречия
- 🟡 Нестабильные в высоком приоритете — риск переделок
- Для каждого конфликта — выбрать тактику (Режим D)
- Если конфликтов нет — переходить к Режиму E
Справка по тактикам конфликтов: references/conflict_resolution.md
📌 Если >60% требований в Must — признак Must Inflation.
Рекомендация: провести повторную сессию с техникой «фиксированного бюджета».
Режим D — Разрешить конфликт
Когда: после агрегации выявлен конфликт.
Алгоритм:
- Определить тип конфликта:
- Межстейкхолдерский (расхождение оценок)
- Dependency violation (Must зависит от Won't)
- Priority inflation (>60% Must)
- Применить тактику (см.
references/conflict_resolution.md)
- Вызвать
resolve_conflict — зафиксировать решение и rationale
- Критические конфликты (Must vs Won't, High/High influence) → связать с Decision Log (4.5)
Режим E — Зафиксировать результат
Когда: все конфликты разрешены, приоритеты согласованы.
Алгоритм:
- Проверить что все конфликты помечены resolved
- Вызвать
save_prioritization_result
- Инструмент:
- Записывает поле
priority в репозиторий 5.1
- Сохраняет снапшот в
{project}_prioritization.json
- Генерирует Markdown-отчёт для стейкхолдеров
MCP-инструменты
| Инструмент | Режим | Что делает |
|---|
start_prioritization_session | A | Открыть сессию, выбрать метод, получить список требований |
add_stakeholder_scores | B | Добавить оценки одного стейкхолдера |
run_aggregation | C | Агрегировать оценки, найти конфликты и violations |
resolve_conflict | D | Зафиксировать решение по конфликту |
save_prioritization_result | E | Финализировать, обновить репозиторий 5.1 |
Mapping из 5.2 — стабильность как фактор
Перед сессией инструмент start_prioritization_session автоматически проверяет стабильность требований:
| Stability (из 5.2) | Версия | Поведение в 5.3 |
|---|
Stable | < 1.3 | Без ограничений |
Volatile | 1.3–1.3 | 🟡 Предупреждение при Must |
Volatile (критично) | ≥ 1.4 | 🔴 Флаг: «высокий риск переделок при Must» |
Unknown | — | 🟡 Рекомендация: уточнить стабильность перед финализацией |
Mapping из 5.1 — зависимости
run_aggregation автоматически проверяет dependency violations:
- Для каждого требования с итоговым приоритетом Must/Should
- Ищет в репозитории 5.1 все связи типа
depends
- Проверяет: все upstream-зависимости имеют приоритет ≥ текущего?
- Если нет — флагирует как dependency violation
Типы связей, которые проверяются: только depends.
Связи derives, satisfies, verifies — не являются dependency violations.
Типичные вопросы BA
«Стейкхолдер поменял мнение после первой оценки — как обновить?»
Вызвать add_stakeholder_scores повторно для того же стейкхолдера.
Новые оценки заменяют предыдущие в текущей сессии.
«Надо ли вызывать приоритизацию для дизайнов (не только требований)?»
Да — BABOK явно включает Дизайны как входную информацию 5.3.
Дизайны добавляются в репозиторий 5.1 как отдельные узлы типа design.
Приоритизируются по той же схеме.
«Как часто проводить повторную приоритизацию?»
Правило: при любом из триггеров выше (получены оценки, CR принят, контекст изменился).
Каждая сессия — отдельный снапшот с историей.
