Приоритизация требований
Когда пожеланий больше, чем времени, спор «что важнее» без правил выигрывает тот, кто громче. Здесь разберём метод MoSCoW, как обосновывать выбор ценностью и риском и как отвечать «нет» и «потом», не срывая договорённости.
Приоритизация нужна потому, что ресурсы команды ограничены, а пожелания приходят от разных людей и каждое кажется срочным. Без явных правил приоритет решают давлением и громкостью, а не ценностью для бизнеса.
Кейс: шесть пожеланий на один релиз
Владелец «Узелка» принёс список из шести пожеланий на ближайший релиз: оплата картой, отмена заказа с причиной, поиск по списку заказов, подарочная упаковка, тёмная тема и push-уведомления. Команда успеет сделать не всё. Если брать в работу всё подряд, релиз сдвинется, а оплата картой, без которой нет продаж, может оказаться недоделанной ради мелочей. (Список и выводы условные: мы взяли их для иллюстрации.)
Здесь нужна общая шкала, по которой все участники могут сравнить пожелания. Такую шкалу даёт MoSCoW.
Четыре категории MoSCoW
MoSCoW делит требования на четыре группы:
- Must have - критично, без этого результат провалится.
- Should have - важно, но есть обходной путь.
- Could have - ценно, но не необходимо.
- Won't have (this time) - сознательно не включаем в этот раз.
Тест для Must простой: может ли результат состояться без этого. Если не может, это Must. Если может, но с обходным путём, это Should.
В слове «Won't» сидит «this time»: значит не «никогда», а «не в этот раз». Это помогает честно говорить «нет»: пожелание не выброшено, а отложено.
Ценность и риск: как обосновать категорию
Категорию без причины против неё легко оспорить. Поэтому каждому пожеланию задают три вопроса:
- Ценность. Кому и что это даёт, что потеряем, если не сделаем.
- Риск. Что случится, если сделаем плохо или не сделаем вовсе: сложность, влияние на другие задачи, неизвестные данные.
- Усилия. Сколько работы нужно: статья об оценке задач 02-23.
В кейсе оплата картой попала в Must, потому что без неё нет продаж. Отмена с причиной попала в Should: причину можно спросить в поддержке, то есть обходной путь есть. Тёмная тема не влияет на цель релиза и уходит в Won't.
Как говорить «нет» и «потом»
Отказ без пояснения воспринимается как отказ человеку, а не пожеланию. Помогает схема из трёх частей: что мы решили, почему и когда вернёмся к вопросу. Например: «Тёмную тему в этот релиз не включаем: она не влияет на цель запуска. Вернёмся к ней при планировании следующего релиза».
Решение о приоритетах записывают вместе с причинами в журнале решений. Тогда при следующем разговоре об этом же пожелании не нужно спорить заново.
Как делят усилия между категориями
Если всё объявить обязательным, категории перестают работать. Принятый ориентир: не больше 60% усилий на Must, около 20% на Should и около 20% на Could. Речь идёт об усилиях, а не о числе требований. При угрозе срокам Could отбрасывают первыми, потом Should, а Must остаются под гарантией.
Это ориентир, а не правило для всех проектов.
Где это встречается в работе
- Планирование релиза: что входит, что отложено.
- Разбор бэклога с владельцем продукта (статья 02-23 про оценку задач).
- Решение, что убрать из релиза, когда сроки под угрозой.
- Обсуждение запросов на изменение (статья 02-20).
- Связь приоритета требования с планом тестов: сначала проверяют Must.
Итог
MoSCoW делит требования на Must, Should, Could и Won't. Категорию обосновывают ценностью, риском и усилиями, а проверяют вопросом «может ли результат состояться без этого». «Нет» звучит как «не в этот раз» и записывается с причиной. Усилия по категориям оценивают с ориентиром 60, 20 и 20 процентов.
Что дальше
Дальше разберём трассировку требований (статья 02-22) и декомпозицию с оценкой задач (статья 02-23).
5 вопросов