Приоритизация · Конспекты по бизнес-анализу

Что это#

Руководство BABOK® описывает приоритизацию (prioritization) как каркас, который помогает заинтересованным сторонам определить относительную важность информации бизнес-анализа: требований, функций, рисков, вариантов. Основой может служить ценность, риск, сложность реализации или любой другой критерий, важный для заинтересованных сторон. Руководство называет четыре подхода:

Группировка — распределение элементов по категориям, например высокий, средний и низкий приоритет.
Ранжирование — единый упорядоченный список от самого важного к наименее важному.
Ограничение по времени или бюджету (time boxing, budgeting) — решение о том, что поместится в фиксированный объём времени или денег.
Переговоры — достижение согласия между заинтересованными сторонами с конкурирующими интересами.

Из каких методов выбирать#

«Входит или нет». Решение «да/нет» по каждому элементу для этого релиза. Быстро для длинных списков, но не задаёт порядка среди оставленных элементов (Вигерс и Битти).
Попарное сравнение и ранжирование. Элементы сравнивают по два. Когда элементов больше нескольких десятков, метод становится громоздким, а Вигерс и Битти считают ранжирование каждого отдельного требования лишним: релизы всё равно выходят пакетами.
Важность и срочность. Сетка два на два, которую Вигерс и Битти заимствуют у Кови: важное и срочное — высокий приоритет; важное, но не срочное — средний; ни то ни другое — низкий. Элементы, которые кажутся срочными, но не важны, стоит понизить или убрать.
MoSCoW. Must have (обязательно), Should have (желательно), Could have (можно, если получится), Won’t have this time (не в этот раз). Книга BCS, опираясь на метод DSDM, привязывает категории к инкрементам: Must входят в первый инкремент, Should могут сдвинуться в следующий, Could служат буфером, а Won’t сознательно откладываются. Вигерс и Битти настроены критически: MoSCoW не задаёт порядка внутри категории, смысл Won’t неясен (в этом релизе или никогда?), а на практике метод часто сводится к противопоставлению Must и всего остального.
Метод ста баллов. Каждый участник распределяет 100 баллов между элементами. Это заставляет идти на компромиссы, но метод можно обыграть, отдав все баллы любимому элементу, и он не учитывает стоимость.
Ценность, стоимость и риск. Аналитический метод Вигерса и Битти на основе развёртывания функции качества (Quality Function Deployment, QFD): заказчики оценивают выгоду от наличия каждого элемента и ущерб от его отсутствия, а разработчики — стоимость и риск. Приоритет = ценность ÷ (стоимость + риск).

Когда применять#

Учебные таблицы связывают технику с задачами 5.3 «Приоритизация требований» и 8.5 «Рекомендация действий по увеличению ценности решения». Применяйте её всякий раз, когда запросов больше, чем возможностей: перед каждым релизом или итерацией, при поступлении запроса на изменение, при выборе улучшения, которое стоит профинансировать. Вигерс и Битти отмечают, что приоритеты относительны, поэтому начинать можно, как только у вас есть два требования; в гибкой разработке упорядочивание бэклога не прекращается никогда.

Что не нужно приоритизировать. Обязательные элементы — например, требования закона или основные функции, без которых продукт не имеет смысла, — входят по определению. Вигерс и Битти откладывают их в сторону, прежде чем применять свой аналитический метод.

Как это делать#

Договоритесь, что именно вы приоритизируете и на каком уровне: функции, пользовательские истории или отдельные требования. Вигерс и Битти предостерегают от смешения уровней в одном списке.
Договоритесь о критериях и о том, кто принимает решения. Кто отвечает за ценность? Кто оценивает стоимость и риск? Кто решает спорные случаи?
Отложите обязательные элементы.
Выберите метод с учётом числа элементов, ставок и того, насколько заинтересованным сторонам привычно работать с числами.
Соберите исходные данные: ценность — от представителей бизнеса, стоимость и риск — от команды разработки.
Проведите сессию. Ведите переговоры как фасилитатор и записывайте причины каждого решения.
Проверьте зависимости. Элемент с высоким приоритетом, который зависит от элемента с низким, застрянет. Вигерс и Битти также советуют поставлять парные функции, например отмену и повтор действия, вместе.
Не соглашайтесь с ответом «всё важно». Задайте вопросы Вигерса и Битти: можно ли удовлетворить эту потребность иначе? Что будет, если отложить? Стоит ли это того, чтобы задержать всё остальное с тем же приоритетом?
Опубликуйте и пересматривайте приоритеты при каждом релизе или всякий раз, когда меняются цели, стоимость или риски.

Пример#

«Мастерская», вымышленная сеть из 12 веломастерских, выбирает из шести функций-кандидатов для первого релиза. Согласие на маркетинговые рассылки — требование закона, поэтому оно входит без оценки. Остальные оценены по шкале от 1 до 9 (значения условные):

Функция	Выгода	Ущерб	Ценность	Стоимость	Риск	Приоритет
Уведомления о статусе по SMS	8	6	14	3	2	2,80
Одобрение доп. работ по фото	6	3	9	3	2	1,80
Онлайн-запись	9	7	16	6	4	1,60
Предзаказ запчастей при бронировании	7	4	11	7	6	0,85
Личные кабинеты клиентов с историей	4	2	6	5	3	0,75
Скидки за лояльность	3	1	4	4	2	0,67

У онлайн-записи самая высокая ценность, но она оказывается на третьем месте, потому что дорогая и рискованная; уведомления дают много при малых усилиях. Команда берёт первые три функции в релиз 1. Проверка зависимостей подтверждает, что для предзаказа запчастей нужны данные о велосипеде из формы бронирования, поэтому он уходит в релиз 2 — с понятной причиной, которую владелец может объяснить управляющим мастерскими.

Частые ошибки#

Всё «высокое» → Вигерс и Битти замечают: если у всех элементов примерно одинаковый приоритет, вы не приоритизировали. Задайте распределение принудительно или ещё раз разделите группу «высокий».
Приоритет по громкости или должности того, кто просит → используйте согласованные критерии и записывайте причины.
Только ценность → учитывайте стоимость и риск от команды разработки.
Смешение уровней → сравнивайте функции с функциями, истории с историями.
Зависимости не учтены → проверьте их до публикации.
Субъективные оценки → учебные таблицы предупреждают, что без метрик и KPI приоритизация становится субъективной; привяжите ценность к бизнес-целям.
Предвзятость команды → в учебных таблицах отмечено, что проектная команда может влиять на приоритеты, намеренно или нет. Пусть за ценность отвечают представители бизнеса, а процесс остаётся прозрачным.
Заинтересованные стороны отказываются выбирать → учебные таблицы отмечают и это; покажите компромисс явно, например через фиксированный бюджет или временные рамки.
Приоритизация один раз → пересматривайте регулярно.

Шаблон#

Шаблон

| ID | Элемент | Обязательный? | Выгода (1–9) | Ущерб (1–9) | Ценность | Стоимость (1–9) | Риск (1–9) | Приоритет = Ценность / (Стоимость + Риск) | Зависит от | Решение и причина |
|----|------|------------|---------------|---------------|-------|------------|------------|----------------------------------|------------|---------------------|
|    |      |            |               |               |       |            |            |                                  |            |                     |

Источники и что почитать#

IIBA. A Guide to the Business Analysis Body of Knowledge (BABOK® Guide), version 3. International Institute of Business Analysis, 2015. Рус. изд.: Руководство к своду знаний по бизнес-анализу (Руководство BABOK®), версия 3.0. Техника 10.33 «Приоритизация».
Watermark Learning. BABOK v3 Study Tables. 2016 (учебное пособие к Руководству BABOK). Разд. 10.33.
K. Wiegers, J. Beatty. Software Requirements, 3rd ed. Microsoft Press, 2013. Рус. изд.: К. Вигерс, Дж. Битти. Разработка требований к программному обеспечению, 3-е изд. М.: Русская редакция; СПб.: БХВ-Петербург, 2014. Гл. 16 (методы приоритизации и их подводные камни).
D. Paul, D. Yeates, J. Cadle (eds.). Business Analysis, 2nd ed. BCS, The Chartered Institute for IT, 2010. Гл. 9–10 (MoSCoW и инкременты).