Приоритизация требований
Как аналитик ранжирует объём и режет бэклог в условиях ограничений — MoSCoW, RICE, Kano, взвешенная оценка, кумулятивное голосование и разрешение конфликтов приоритетов между стейкхолдерами.
9 вопросов
JuniorТеорияОчень частоКакие методы приоритизации требований вы знаете и зачем вообще приоритизировать?
Какие методы приоритизации требований вы знаете и зачем вообще приоритизировать?
Приоритизируют, потому что время, бюджет и люди ограничены — всё сразу не построить, поэтому работу упорядочивают по ценности против затрат и первыми поставляют самые ценные срезы. Частые методы: MoSCoW, RICE, модель Kano, взвешенная оценка и WSJF.
Типичные ошибки
- ✗Считать приоритизацию необязательной, когда бэклог превышает ёмкость
- ✗Упорядочивать только по затратам или трудоёмкости, игнорируя ценность
- ✗Путать метод приоритизации с техникой оценки
Уточняющие вопросы
- →Когда вы смените MoSCoW на численный метод вроде RICE?
- →Кто должен быть в комнате при приоритизации бэклога?
MiddleДизайнОчень частоЕдиный бэклог команды держит и новые функции, и входящие баг-репорты, и каждый спринт они борются за одну ёмкость. Продукт хочет и дальше поставлять функции; поддержка эскалирует поток дефектов — часть косметических, часть блокирует оформление заказа для доли пользователей. Отдельного бюджета на баги нет, и стейкхолдеры спорят, важнее ли конкретный баг запланированной функции. Опишите, как вы приоритизируете исправление багов против функций в одном упорядоченном бэклоге: какие входные данные собираете по багу (серьёзность, охват пользователей, частота, наличие обходного пути, SLA или регуляторная угроза, выручка под риском), как делаете баг и функцию сопоставимыми на одной шкале, как держите ровный поток исправлений, не стопоря роадмап, и как обосновываете каждое решение о порядке продукту и поддержке, чтобы ни одна сторона не чувствовала себя проигнорированной.
Единый бэклог команды держит и новые функции, и входящие баг-репорты, и каждый спринт они борются за одну ёмкость. Продукт хочет и дальше поставлять функции; поддержка эскалирует поток дефектов — часть косметических, часть блокирует оформление заказа для доли пользователей. Отдельного бюджета на баги нет, и стейкхолдеры спорят, важнее ли конкретный баг запланированной функции. Опишите, как вы приоритизируете исправление багов против функций в одном упорядоченном бэклоге: какие входные данные собираете по багу (серьёзность, охват пользователей, частота, наличие обходного пути, SLA или регуляторная угроза, выручка под риском), как делаете баг и функцию сопоставимыми на одной шкале, как держите ровный поток исправлений, не стопоря роадмап, и как обосновываете каждое решение о порядке продукту и поддержке, чтобы ни одна сторона не чувствовала себя проигнорированной.
Кладут баги и функции в один бэклог и оценивают оба по тем же осям — ценность против затрат. По багу собирают серьёзность, охват, частоту, обходной путь и риск по выручке или SLA, затем ранжируют его ценность против трудоёмкости как у функции. Резервируют ёмкость под фиксы.
Типичные ошибки
- ✗Огулом ставить все баги выше всех функций или наоборот
- ✗Оценивать баги и функции на разных, несопоставимых шкалах
- ✗Не резервировать ёмкость, из-за чего исправления не выходят
Уточняющие вопросы
- →Как быть с косметическим багом, что крупный клиент постоянно эскалирует?
- →Когда повторяющийся баг оправдывает паузу в роадмапе функций?
MiddleТеорияЧастоЧто такое модель Kano, какие категории функций она задаёт и как опросить пользователей?
Что такое модель Kano, какие категории функций она задаёт и как опросить пользователей?
Модель Kano классифицирует функции по влиянию на удовлетворённость: Basic (ожидаемые; отсутствие злит), Performance (больше — лучше, линейно) и Delighters (неожиданный восторг, по ним не скучают). Опрашивают парой вопросов — функциональным и дисфункциональным.
Типичные ошибки
- ✗Путать Delighters (неожиданные) с Basic (ожидаемыми) функциями
- ✗Считать, что больше Basic-функции всё выше поднимает удовлетворённость
- ✗Опрашивать одним вопросом вместо пары функциональный/дисфункциональный
Уточняющие вопросы
- →Почему сегодняшние Delighters превращаются в завтрашние ожидания Basic?
- →Какой размер выборки нужен, прежде чем результатам Kano можно доверять?
MiddleТеорияЧастоЧто такое MoSCoW, что значат его четыре корзины и в чём ловушка корзины Won't have?
Что такое MoSCoW, что значат его четыре корзины и в чём ловушка корзины Won't have?
MoSCoW сортирует объём на Must have (без чего релиз проваливается), Should have (важное, не жизненное), Could have (срезают первым) и Won't have (вне объёма сейчас). Ловушка: Won't have значит отложено, а не отвергнуто — зафиксированное решение об объёме.
Типичные ошибки
- ✗Забивать всё в Must have, что обесценивает метод
- ✗Читать Won't have как окончательный отказ, а не отсрочку
- ✗Считать MoSCoW численной оценкой, а не категориальными корзинами
Уточняющие вопросы
- →Как возражать, когда бизнес помечает каждый элемент как Must have?
- →Где фиксировать Won't-have, чтобы они всплыли в следующем релизе?
MiddleТеорияЧастоКак метод приоритизации RICE считает оценку и что каждый фактор меняет в ранжировании?
Как метод приоритизации RICE считает оценку и что каждый фактор меняет в ранжировании?
RICE = Reach × Impact × Confidence ÷ Effort. Reach — пользователи за период; Impact — движение цели на пользователя; Confidence снижает оценку за шаткие данные; Effort — человеко-время. Первые три поднимают оценку, а Effort делит её вниз.
Типичные ошибки
- ✗Складывать факторы вместо деления на Effort
- ✗Забывать Confidence, из-за чего доминируют оптимистичные догадки
- ✗Считать RICE категориальными корзинами, а не численной оценкой
Уточняющие вопросы
- →Как держать Reach и Impact на сопоставимых шкалах между командами?
- →Что мешает людям подтасовывать собственные оценки Confidence?
SeniorДизайнЧастоНа сессии MoSCoW бизнес помечает каждый элемент бэклога как Must have — нет ни Should, ни Could, ни Won't. Они настаивают, что релиз не выйдет без всего этого, а ёмкость команды покрывает от силы половину. Простое возражение, что нельзя получить всё, один раз уже провалилось и подорвало доверие. Опишите по шагам, как вы ломаете тупик: как переопределяете, что на деле значит Must have (без чего релиз проваливается), какими вопросами и техниками вынуждаете реальные компромиссы, как делаете цену «всё — Must» наглядной, как приводите группу к переранжированию так, чтобы никто не чувствовал себя продавленным, и что делаете, если они всё равно отказываются как-либо разделять список.
На сессии MoSCoW бизнес помечает каждый элемент бэклога как Must have — нет ни Should, ни Could, ни Won't. Они настаивают, что релиз не выйдет без всего этого, а ёмкость команды покрывает от силы половину. Простое возражение, что нельзя получить всё, один раз уже провалилось и подорвало доверие. Опишите по шагам, как вы ломаете тупик: как переопределяете, что на деле значит Must have (без чего релиз проваливается), какими вопросами и техниками вынуждаете реальные компромиссы, как делаете цену «всё — Must» наглядной, как приводите группу к переранжированию так, чтобы никто не чувствовал себя продавленным, и что делаете, если они всё равно отказываются как-либо разделять список.
Переопределяют Must have как «без чего релиз проваливается», и по этой планке большинство отпадает. Показывают ёмкость против объёма и спрашивают, что выйдет при половине. Применяют форс-ранжирование или бюджет Must have, эскалируя, лишь если разделять отказываются.
Типичные ошибки
- ✗Принимать список, где всё Must have, и поглощать перерасход
- ✗Переранжировать молча, вместо того чтобы вести бизнес к выбору
- ✗Упорядочивать по дешевизне, а не по реальному статусу must-have
Уточняющие вопросы
- →Какой один вопрос лучше всего заставляет Must-have элемент проявить себя?
- →Как фиксированный бюджет ёмкости под Must have меняет разговор?
SeniorДизайнЧастоИдёт планирование спринта. Инженерная команда хочет весь спринт на техдолг — хрупкий модуль, что ломается еженедельно и тормозит любое изменение. Владелец от бизнеса хочет ту же ёмкость под клиентскую функцию, обещанную крупному клиенту в этом квартале. Оба непреклонны, ёмкости хватает лишь на одно, и то, что вы отложите, будет ощущаться задвинутым. Вам надо принять решение и защитить его. Опишите, как вы приоритизируете техдолг против доходной функции: как переводите долг в бизнес-термины, которые владелец может взвесить, как оцениваете cost of delay с обеих сторон, как через оценку или взгляд «ценность против трудоёмкости» сравниваете их на одной шкале и как обосновываете итоговое решение, чтобы и инженеры, и бизнес его приняли, а не сочли себя продавленными.
Идёт планирование спринта. Инженерная команда хочет весь спринт на техдолг — хрупкий модуль, что ломается еженедельно и тормозит любое изменение. Владелец от бизнеса хочет ту же ёмкость под клиентскую функцию, обещанную крупному клиенту в этом квартале. Оба непреклонны, ёмкости хватает лишь на одно, и то, что вы отложите, будет ощущаться задвинутым. Вам надо принять решение и защитить его. Опишите, как вы приоритизируете техдолг против доходной функции: как переводите долг в бизнес-термины, которые владелец может взвесить, как оцениваете cost of delay с обеих сторон, как через оценку или взгляд «ценность против трудоёмкости» сравниваете их на одной шкале и как обосновываете итоговое решение, чтобы и инженеры, и бизнес его приняли, а не сочли себя продавленными.
Переводят долг в бизнес-термины — хрупкий модуль стоит скорости поставки и инцидентов — чтобы он конкурировал как ценность, а не «просьба технарей». Ставят оба на одну шкалу: оценивают cost of delay обеих сторон и считают ценность против трудоёмкости. Решают числа и аппетит владельца к риску.
Типичные ошибки
- ✗Оставлять долг «просьбой технарей», которую бизнес не может взвесить
- ✗Сравнивать двоих на разных шкалах вместо одной общей
- ✗Решать по тому, кто громче спорит, а не по cost of delay
Уточняющие вопросы
- →Как выразить числом стоимость откладывания техдолга?
- →Когда таймбоксенный частичный срез долга лучше принципа «всё или ничего»?
MiddleТеорияИногдаКак работает взвешенная оценка и как выбрать критерии, чтобы результат нельзя было подтасовать?
Как работает взвешенная оценка и как выбрать критерии, чтобы результат нельзя было подтасовать?
Взвешенная оценка оценивает элемент по нескольким критериям (ценность, затраты, риск, соответствие), умножает каждую оценку на вес критерия и суммирует в одно число. Против подтасовки: фиксируют критерии и веса до оценки, держат их немногими и независимыми и оценивают группой.
Типичные ошибки
- ✗Задавать веса после того, как увидели оценки, что открывает путь подтасовке
- ✗Использовать много пересекающихся критериев, дважды считающих одно и то же
- ✗Позволять оценивать одному человеку вместо кросс-функциональной группы
Уточняющие вопросы
- →Как быть с критерием, что измеряется в разных единицах для разных элементов?
- →Когда взвешенная оценка добавляет больше накладных расходов, чем стоит?
MiddleТеорияИногдаЧто такое WSJF и cost of delay и когда этот метод лучше MoSCoW?
Что такое WSJF и cost of delay и когда этот метод лучше MoSCoW?
WSJF (Weighted Shortest Job First) ранжирует работу по cost of delay, делённому на размер задачи; первыми идут дорогие в отсрочке, но быстрые задачи. Cost of delay — ценность, теряемая за время ожидания. Метод лучше MoSCoW, когда всё — Must have и нужен численный критерий.
Типичные ошибки
- ✗Умножать на размер задачи вместо деления на него
- ✗Читать cost of delay как уже потраченные деньги, а не потерю ценности во времени
- ✗Считать WSJF категориальным как MoSCoW, а не численным
Уточняющие вопросы
- →Как оценить cost of delay, когда влияние на выручку неясно?
- →Почему WSJF поощряет дробление крупного элемента на мелкие?
