Приоритизация требований на практике
Коротко Приоритизация решает, что создавать первым и от чего отказаться, когда не хватает времени или денег. Вигерс и Битти сравнивают несколько техник, критикуют некоторые популярные и для спорных решений советуют расчёт по ценности, стоимости и риску.
По материалам: К. Вигерс, Дж. Битти, «Разработка требований к программному обеспечению», 3-е изд. (Microsoft Press, 2013), гл. 16.
На этой странице
Главные идеи#
Зачем и когда#
Приоритеты позволяют разумно тратить ограниченные ресурсы и заранее знать, чем пожертвовать. Приоритет относителен, поэтому начинать можно, как только у вас есть два требования. В гибких проектах приоритизация бэклога не прекращается никогда.
Ссылаясь на Дэвиса, авторы перечисляют, что нужно знать: потребности заказчиков, насколько каждое требование важно для заказчиков, в каком порядке должны появляться возможности, зависимости, группы требований, которые имеют смысл только вместе, и стоимость каждого требования.
Игры с приоритетами#
Если пустить дело на самотёк, заказчики пометят большинство требований как «высокие». Если всё оказалось на одном уровне, приоритизации не было. Обращайте внимание на: - придуманные шкалы без «низкого» («высокий, очень высокий, критичный»); - фразу «раз это в спецификации, мы это сделаем», которая ничего не говорит о том, когда; - приоритет по громкости (кто громче кричит) или по угрозе (у кого больше власти).
Чтобы было проще сказать «низкий», спросите: есть ли другой способ удовлетворить эту потребность? Что будет, если исключить или отложить это требование? Стоит ли оно того, чтобы задерживать всё остальное на том же уровне? Авторы приводят данные Standish Group, согласно которым значительной частью поставленной функциональности пользуются редко или никогда, — довод в пользу смелых сокращений.
Пять техник, от простой к сложной#
| Техника | Как работает | Для чего подходит | Осторожно |
|---|---|---|---|
| Входит или нет | «Да» или «нет» для этого релиза | Длинные списки, быстрые решения | Нет ранжирования среди вошедших |
| Попарное сравнение | «Если бы существовали только эти два, что важнее?» | Небольшие наборы, например атрибуты качества | Неуправляемо, если элементов больше нескольких десятков |
| Важность × срочность | Важно и срочно — высокий; важно, но не срочно — средний; ни то ни другое — низкий | Большинство проектов | То, что лишь кажется срочным, уходит в низкий или исключается |
| MoSCoW | Must, Should, Could, Won’t | Команды, которые к ней привыкли | Авторы её не рекомендуют (см. ниже) |
| 100 долларов | Каждый распределяет 100 баллов | Приучить думать о компромиссах | Легко подыграть себе; стоимость не учитывается |
Сетка «важность × срочность» взята у Кови. Для больших наборов применяйте её в несколько проходов: если группа «высокий» слишком велика, разделите только её на три подуровня и повторите. Ранжировать каждое требование по отдельности незачем: продукты выпускают релизами, а не по одному требованию.
Вигерс и Битти отвергают MoSCoW: она не даёт ранжирования внутри категории, а Won’t двусмысленно (не сейчас или никогда?). На практике всё обычно сводится к «Must против всего остального», потому что люди быстро усваивают: то, что ниже Must, редко реализуют. Родственник техники «100 долларов» — цепочка целей (objective chain) Битти и Чена: она оценивает реальный денежный вклад каждой функции в бизнес-цель вместо воображаемых денег.
Ценность, стоимость и риск#
Для спорных решений авторы советуют табличный метод, выведенный из развёртывания функции качества (Quality Function Deployment, QFD). Он оказался лучшим в сравнении 17 техник, которое провели Кукреджа (Kukreja) и коллеги и на которое ссылаются авторы. Представители заказчика оценивают выгоду от наличия каждой функции и ущерб от её отсутствия; разработчики оценивают стоимость и риск. Взвешенная сумма выгоды и ущерба даёт ценность, и:
приоритет = ценность % ÷ (стоимость % + риск %)
Применяйте метод только к необязательным элементам. Юридические обязательства и ключевые бизнес-функции обязательны и в расчёте не участвуют.
Как применять#
- Договоритесь о бизнес-целях и о том, кто принимает окончательное решение.
- Сравнивайте элементы одного уровня абстракции: функции, варианты использования или функциональные требования, но никогда не вперемешку.
- Вынесите обязательные элементы отдельно.
- Для основной массы используйте «входит или нет» или «важность × срочность»; расчёт по ценности, стоимости и риску оставьте для спорных случаев.
- Проверьте зависимости: элемент, который зависит от низкоприоритетного, на самом деле не высокий.
- Держите парные операции (сохранение и загрузка, отмена и повтор) в одном релизе.
- Если приоритеты равны, отдавайте предпочтение потребностям самых важных классов пользователей.
Пример#
«Мастерская», вымышленная сеть веломастерских, считает онлайн-запись обязательной. За место в первом релизе борются ещё четыре функции. Оценки — от 1 до 9. В этом примере команда даёт выгоде вес 2, ущербу — вес 1, а стоимость и риск не взвешивает. Каждый процент — доля элемента в сумме по столбцу.
| Функция | Выгода | Ущерб | Стоимость | Риск | Ценность, % | Стоимость, % | Риск, % | Приоритет |
|---|---|---|---|---|---|---|---|---|
| Уведомления о статусе по электронной почте | 5 | 3 | 2 | 1 | 20,3 | 11,8 | 7,1 | 1,07 |
| Уведомления о статусе по SMS | 8 | 6 | 4 | 3 | 34,4 | 23,5 | 21,4 | 0,77 |
| Подсказки по дозаказу запчастей | 7 | 5 | 6 | 6 | 29,7 | 35,3 | 42,9 | 0,38 |
| Загрузка фото клиентом | 4 | 2 | 5 | 4 | 15,6 | 29,4 | 28,6 | 0,27 |
Электронная почта выигрывает у SMS, потому что это дёшево и малорискованно, поэтому команда сначала выпускает уведомления по почте, а SMS — следующими. У подсказок по запчастям высокая ценность, но и высокий риск; короткий технический эксперимент (spike) может снизить оценку риска до следующего раунда. Воспринимайте числа как способ структурировать разговор, а не как приговор.
Подводные камни#
- Согласиться с «всё высокое» → потребуйте разброса или проведите ещё один проход по верхней группе.
- Смешивать эпики с мелкими требованиями → сравнивайте на одном уровне.
- Позволить решать самой громкой заинтересованной стороне → привязывайте каждый приоритет к бизнес-цели.
- Считать приоритеты постоянными → пересматривайте их в каждом релизе.
Источники и что почитать#
- K. Wiegers, J. Beatty. Software Requirements, 3rd ed. Microsoft Press, 2013. Рус. изд.: К. Вигерс, Дж. Битти. Разработка требований к программному обеспечению, 3-е изд. М.: Русская редакция; СПб.: БХВ-Петербург, 2014. Гл. 16 (включая ссылки авторов на Дэвиса, Кови, Битти и Чена, Кукреджу и соавторов и Standish Group).