Все любят формулы. Они дают иллюзию контроля: поменял значение-другое в таблице и вот уже состав релизов как на ладони. Можно обосновать их перед руководством и инвесторами, можно повысить боевой дух команды. Однако на практике наши формулы часто отдают вкусовщиной и практически никак не учитывают риски.
В этой статье я расскажу о новом подходе к приоритизации. Это вовсе не значит, что я буду ругать остальные, напротив. Я покажу, как их можно усилить.
У любой методологии есть преимущества и недостатки. Любая из них начинает вредить, если её возвести в культ. И как же легко это сделать, когда речь заходит о приоритетах. Каждый тянет одеяло на свои инициативы, завышая impact, занижая effort и ловко манипулируя confidence. В итоге мы спорим не о проблемах пользователей и ценности для бизнеса, а о десятых долях в табличке.
Что такое PoDPR и почему это хорошо
Приоритизация продуктовых инициатив — это не только вопрос «что важнее», но и вопрос «что безопаснее и быстрее проверить». Метод Pain over Difficulty × Probability × Reversibility (PoDPR) создан именно для сравнения инициатив, для которых можно оценить выраженность проблемы, сложность реализации, вероятность эффекта и возможность отката.
PoDPR лучше всего работает внутри одного класса сопоставимых инициатив: например, продуктовых гипотез, экспериментов или альтернативных решений одной проблемы. Он не заменяет правила для security-инцидентов, регуляторных требований, договорных обязательств и стратегических ставок — это всё вообще плохо дружит с формулами.
По сути, PoDPR последовательно отвечает на четыре вопроса:
- насколько выражена проблема,
- насколько сложно её устранить,
- насколько вероятно, что выбранное решение даст эффект,
- насколько безопасно его проверять.
Такая декомпозиция не устраняет субъективность и манипуляции, но делает их заметнее: команде приходится отдельно обосновывать проблему, сложность реализации, вероятность эффекта и возможность отката. В третьей статье цикла мы подробно разберём процессные правила, которые делают эти оценки проверяемыми.
PoDPR разделяет оценку на четыре фактора, каждый из которых отвечает за отдельный аспект решения:
- PoD, Pain over Difficulty — отношение боли к трудности. Боль — это выраженность проблемы для пользователя/бизнеса. Трудность — стоимость реализации. Чем больнее и проще исправить, тем выше PoD.
- Probability (вероятность эффекта) — насколько вероятно, что изменение даст целевой результат. Это не вера и не «чую, взлетит», а сжатая оценка из данных, экспериментов и обратной связи.
- Reversibility (обратимость) — насколько легко откатить решение при провале. Чем выше обратимость, тем меньше организационный страх и тем смелее можно проверять гипотезы.
Факторы не обязаны быть статистически независимыми. Задача декомпозиции — не доказать независимость, а не смешивать в одной оценке разные причины высокого или низкого приоритета.
PoDPR оптимизирует не «красивый роадмап», а скорость безопасной проверки гипотез — реальный цикл продуктового развития. Формула прямо наказывает дорогостоящие, слабообратимые и плохо подтверждённые затеи. И наоборот, поднимает наверх дешёвые, обратимые и подтверждённые шаги, снимающие реальную боль.
В следующих статьях мы подробно разберём то, как рассчитывается каждый из показателей и что нужно делать, чтобы избежать субъективности и манипуляций. А пока давайте поговорим о других подходах и том, как PoDPR может сделать их лучше.
Немного про классические подходы и как им помогает PoDPR
Как я уже говорил, у меня нет задачи принизить значимость других методологий. Я буду честно говорить об их плюсах и минусах. Какие-то аспекты придётся упростить, так как эта статья не претендует на полное раскрытие каждого подхода. Везде будут ссылки, почитаете сами.
Ну и, разумеется, всё это лишь мнение автора, вы имеете полное право с ним не соглашаться.
MoSCoW (Must, Should, Could, Won’t)
Самый наивный, наверное, подход из всех. Я бы вообще не называл его отдельной методологией. Это просто способ оформить уже проведённую работу по расстановке приоритетов. Категории здесь — всего лишь ярлыки, а не метрики. В тот же Must часто пихаются не взвешенные решения, а «всё, что я хочу» (привет, HiPPO). Я сам однажды видел, как в Must попали одновременно критический баг в регистрации и декоративный дашборд для одного из директоров. Формально оба «обязательные», но реальная боль и уровень риска несопоставимы.
Тем не менее, MoSCoW предоставляет понятную и управляемую коммуникацию требований. Это компактный язык для общения с бизнесом, он помогает легко управлять ожиданиями.
Как дружить с PoDPR
PoDPR не должен автоматически превращать инициативу в Must. Сначала команда определяет обязательность требования по правилам MoSCoW: без Must решение не должно считаться жизнеспособным, безопасным или допустимым к выпуску.
После этого PoDPR можно использовать для двух задач:
- определить порядок реализации нескольких Must, если все они обязательны, но не могут быть выполнены одновременно;
- упорядочить сопоставимые Should и Could, где команда действительно выбирает между альтернативами.
Если вы привыкли к MoSCoW, его можно использовать как верхнеуровневую рамку, а PoDPR — для определения последовательности сопоставимых задач внутри категорий. Например, он поможет объяснить, почему одну обязательную задачу нужно выполнить раньше другой, хотя обе относятся к Must.
RICE и ICE
RICE (Reach × Impact × Confidence ÷ Effort) и ICE (Impact × Confidence × Ease) — два разных, но очень схожих подхода к приоритизации. Прозрачная логика расчёта, понятная даже вне продуктовой команды; возможность связать эффект с масштабом охвата в RICE или лёгкость реализации с влиянием в ICE — это ли не идеал? И да, и нет. Вот несколько потенциальных проблем:
- Impact легко завысить, особенно без проверяемых источников.
- Reach часто строится исключительно на прогнозных данных.
- Единый Confidence в RICE применяют и к Reach, и к Impact, хотя часто эти оценки делают разные люди на основании разных источников.
- Ease из ICE порой подменяет собой реальную сложность: команда оценивает «кажется, быстро», игнорируя зависимости, тестирование, релизные окна, безопасность, интеграции.
При этом одно из преимуществ RICE и ICE в том, что они весьма адаптивны. И вы, имея голову со здравым смыслом внутри, можете легко построить на основе любого из них свой собственный фреймворк.
Как дружить с PoDPR
В адаптированной версии RICE можно отдельно оценивать Probability — вероятность того, что выбранное решение даст ожидаемый эффект. Она работает как штрафной коэффициент: чем слабее доказательства связи между решением и результатом, тем ниже итоговый балл. Reversibility отлично справится в качестве измерения риска: легко обратимые решения автоматически будут увеличивать общий балл.
ICE из-за своей простоты может остаться черновым сортировщиком для быстрых идей. Шорт-лист по ICE отправляется в PoDPR, который делает сильно заметнее субъективность и манипуляции. И поднимает вверх те задачи, которые быстрее, обратимее и бьют по реальной боли.
Kano Model
Одна из популярных в дизайн-среде моделей. Помогает понять, какого типа ценность создаёт фича: обязательную (Must-be), важную (Performance), интересную (Attractive) или безразличную (Indifferent). Отлично подходит для приоритизации на основе пользовательских потребностей, но ничего не говорит о последовательности разработки и внедрения. Модель описывает форму ценности, но не учитывает вероятность успеха, стоимость и риск ошибок. Кроме того, опросы по Кано легко исказить выборкой и кривыми формулировками.
Как дружить с PoDPR
Через Probability и Reversibility решаем, какие Delighters можно безопасно протестировать как эксперимент, не откусывая ресурс у базовых задач. Вероятность «попадания» и обратимость легко укажут, какие вау-фичи не заслуживают высокого приоритета.
Или как с ICE: сначала используем Kano для классификации инициатив, а затем считаем PoDPR внутри сопоставимых категорий. Если нужно сравнить Must-be, Performance и Delighters между собой, дополнительно учитываем стратегию продукта: категория Kano сама по себе не определяет абсолютный приоритет.
WSJF (Weighted Shortest Job First)
Подход, получивший широкое применение в фреймворке SAFe (Scaled Agile Framework). WSJF заточен под портфельный уровень, он учитывает стоимость задержки и размеры задачи, помогает выстраивать рациональный порядок для крупных эпиков.
WSJF отлично подходит для больших объёмов, но тяжеловесен для discovery — ради быстрой проверки гипотез бессмысленно заводить такой комбайн. Местами метод сложен и абстрактен, а Business Value, Time Criticality и Risk Reduction часто оцениваются «по ощущениям руководства». При этом WSJF явно учитывает снижение риска и открытие новых возможностей как часть стоимости задержки, хотя не оценивает отдельно обратимость самого решения.
Как дружить с PoDPR
С помощью Reversibility можно выделить «одноходовые» монолиты и определить, дробим ли их на обратимые шаги или выносим в отдельный контур архитектурного решения, не конкурируя с мелкими гипотезами.
WSJF используем для отбора крупных эпиков на квартал/год. PoDPR — для того, чтобы эти эпики и сопутствующие гипотезы нарезать на последовательность быстрых, обратимых, проверяемых шагов внутри итераций.
Value vs Effort Matrix
Максимально простая и визуальная, эта матрица интуитивно понятна даже тем, кто далёк от аналитики. Легко объяснить бизнесу и стейкхолдерам, почему часть задач стоит отложить, а часть можно сделать быстро и прямо сейчас. Отлично подходит для стартового ранжирования и вовлечения не‑продуктовых участников в обсуждение приоритетов.
При этом простота подхода — его же проблема. Из-за двумерности невозможно просчитать риски, нет учёта качества данных. А быстрые победы очень часто хоронят под собой серьёзные улучшения.
Как дружить с PoDPR
Матрица остаётся удобным фасадом для диалога со стейкхолдерами. Внутри квадрантов сортируем фичи по PoDPR и объясняем выбор не вкусовщиной, а вполне конкретной формулой. Если результат PoDPR расходится с положением инициативы на матрице, возвращаемся к исходным оценкам Value и Effort и проверяем, какие предположения были завышены или упущены.
User Story Mapping
User Story Mapping помогает увидеть пользовательский путь целиком, обнаружить пробелы в бэклоге и нарезать работу на осмысленные релизы, которые создают ценность для пользователей и бизнеса. Карта также помогает обсуждать последовательность сценариев и состав релиза.
При этом у Story Mapping нет встроенной единой формулы, которая сравнивает альтернативные решения по выраженности проблемы, сложности, доказанности эффекта и обратимости. Эти вопросы команда должна решать отдельным способом.
Как дружить с PoDPR
User Story Mapping помогает выстроить пользовательские сценарии и сформировать предварительные релизные срезы. PoDPR можно применять внутри такого среза для сравнения альтернативных историй, гипотез или вариантов реализации по критерию «что проверить первым».
Применять PoDPR следует не ко всему пользовательскому пути как к одному списку, а к сопоставимым историям или вариантам решения внутри одного релизного среза.
Impact Mapping
Impact Mapping строит связь между целями, участниками, их действиями и результатами. Он помогает команде видеть стратегический контекст: не просто «какую фичу сделать», а «зачем и кому это поможет». IM часто используется в discovery и планировании крупных инициатив, чтобы показать цепочку «почему → кто → что → как».
Подход хорош в своих задачах, но он не даёт численного приоритета между ветками карты, все воздействия выглядят одинаково значимыми. Кроме того, IM не показывает вероятность эффекта и риск. Даже слабая гипотеза может выглядеть серьёзной, если «правильно» встроена в карту.
Как дружить с PoDPR
Impact Mapping сохраняет роль инструмента стратегического контекста: связывает цель, участников, ожидаемые изменения поведения и возможные deliverables. PoDPR используется ниже — для сравнения альтернативных решений или экспериментов, которые направлены на один и тот же impact.
Цель, actor, impact и deliverable не следует помещать в один рейтинг: это сущности разных уровней.
Итог
PoDPR — метод сравнительной приоритизации, который поднимает выше инициативы с выраженной проблемой, приемлемой сложностью, обоснованной вероятностью эффекта и безопасным способом проверки. Он остаётся простым и прозрачным, пока команда использует единые шкалы и осторожно добавляет новые показатели. В следующей статье разберём, когда расширение действительно уточняет модель, а когда превращает её в произвольный конструктор коэффициентов.
