В прошлой статье мы разобрали ядро PoDPR. Теперь поговорим о возможности адаптировать метод под конкретный домен — и о рисках такой адаптации.
Сразу вас разочарую: базовая формула должна оставаться вариантом по умолчанию. Каждый новый множитель увеличивает стоимость оценки, риск двойного учёта и вероятность подгонки результата. Поэтому расширение оправдано только тогда, когда команда может показать повторяющийся дефект базового ранжирования, который нельзя устранить уточнением существующих показателей.
Но, если вы уверены, что иначе никак — погнали.
Зачем расширять PoDPR
В разных доменах у продукта свои акценты: где-то важнее скорость реакции на рынок, где-то комплаенс, где-то технический долг. Поэтому PoDPR можно расширять модулями — аккуратно добавлять множители или фильтры, которые не ломают основную механику Pain ÷ Difficulty × Probability × Reversibility, а лишь уточняют её под реалии продукта.
Как я уже писал, следующая статья будет про то, как именно считать каждый из показателей, а пока давайте разберём несколько примеров расширения PoDPR.
Новый элемент модели вводится, если одновременно выполнены три условия:
- базовая формула систематически выдаёт непригодный для домена порядок;
- проблема повторяется на нескольких кейсах, а не на одной неудобной инициативе;
- новый показатель не дублирует Pain, Difficulty, Probability или Reversibility.
Встраивание Reach из RICE
Иногда важно считать охват новых фич, будь то количество затрагиваемых пользователей или потенциальная прибыль для бизнеса. Выносить Reach в отдельный множитель необязательно, потому что охват уже является частью выраженности проблемы. Если учитывать его отдельно и одновременно использовать при оценке Pain, масштаб будет посчитан дважды. Поэтому в детализированной версии Pain можно разложить на Severity (тяжесть последствий одного проявления проблемы), Frequency (частота её возникновения) и Reach (охват):
Pain = Severity × Frequency × Reach
Frequency и Reach должны иметь разные операционные определения: Frequency показывает повторяемость проблемы у одного затронутого объекта за период, Reach — долю аудитории, процессов или денежного потока, затронутую хотя бы один раз.
Таким образом метрика «сколько людей затронет» превращается из отдельного множителя в компонент «боли». Reach становится не абстрактным числом, а измеримой частью боли, завязанной на реальные данные об аудитории или бизнес-показателях.
Например, если проблема затрагивает 5% активных пользователей, это значение переводится в коэффициент Reach по заранее зафиксированной шкале. Reach ограниченно корректирует Pain, но не делает итоговый балл пропорциональным числу пользователей.
Учёт Effort и Confidence в Difficulty
Для сложных задач Difficulty можно разложить на Effort (полный объём явной и скрытой работы) и два поправочных коэффициента:
- Confidence — поправка на уверенность в оценке Effort;
- Expertise — поправка на релевантную экспертизу команды.
Difficulty = Effort × Confidence × Expertise
Высокий Confidence и высокая Expertise должны уменьшать Difficulty, поэтому пользовательская оценка преобразуется в обратный коэффициент.
| Оценка | Интерпретация Confidence/Expertise | Коэффициент Difficulty |
|---|---|---|
| 1 | очень низкая уверенность/серьёзный дефицит экспертизы | 1,2 |
| 2 | низкая | 1,1 |
| 3 | средняя | 1,0 |
| 4 | высокая | 0,9 |
| 5 | очень высокая | 0,8 |
Таким образом, если
Effort = 4,Confidence = 5иExpertise = 4, то Difficulty будет4 × 0,8 × 0,9 = 2,88, а не4 × 5 × 4 = 80.
Здесь Confidence не влияет на общую оценку напрямую, как в RICE. Напротив, показатель уверенности в оценке касается только сложности реализации, но не пользы (Impact) — для неё есть Pain и Probability. А коэффициент Expertise в явном виде указывает, сталкивалась ли команда с подобными задачами или нет (и тогда оценке нужно доверять чуть меньше).
Добавление Time Criticality из WSJF
Если время критично (сезонность, регуляторные сроки, конкурентное окно), можно ввести множитель Urgency — коэффициент срочности. Это не просто надстройка «чтобы было», это управляемый параметр, фиксируемый правилами домена. Шкала должна быть узкой (0.8–1.2), чтобы срочность не перевешивала реальные факторы боли и обратимости.
Вот несколько примеров, как это можно выразить в коэффициентах:
- ограниченное рыночное или партнёрское окно менее 30 дней —
Urgency = 1,2; - сезонный пик через две недели —
Urgency = 1,1; - инициатива без временного окна —
Urgency = 1,0; - ожидаемый эффект актуален позднее —
Urgency = 0,9; - текущее окно возможностей уже закрыто —
Urgency = 0,8.
Тогда в PoDPR множитель срочности будет выглядеть так:
PoDPR = (Pain ÷ Difficulty) × Probability × Reversibility × Urgency.
Регуляторные требования, security-инциденты и договорные обязательства не получают повышенный Urgency. Они переходят в отдельную очередь обязательных работ и не конкурируют с необязательными продуктовыми инициативами.
Почему именно так?
В классическом WSJF показатель Time Criticality входит в «стоимость задержки» и легко становится манипулятивным: все задачи вдруг «горят». В PoDPR с Urgency время влияет мягко и контролируемо. Urgency не ломает баланс модели, а только смещает приоритет в пользу тех инициатив, где цена ожидания действительно измерима. При этом правила «срочности» документируются заранее, чтобы исключить ручные корректировки: значения от 0.8 до 1.2 выбираются по таблице правил.
Если команда использует автоматизированную сортировку, Urgency может вычисляться автоматически — например, через разницу между дедлайном и прогнозной датой релиза.
Автоматический расчёт делает применение выбранной шкалы воспроизводимым и снижает возможность ручной подгонки. Но при этом качество результата всё равно зависит от тьмы факторов: обоснованности дедлайна, прогноза даты релиза и заранее принятой функции преобразования.
«Радиус взрыва» и комплаенс-ограничения
Бывает так, что одной только Reversibility (обратимости) недостаточно. Ведь даже время «от релиза до отката» может затронуть существенную аудиторию или повлиять на прибыль. Тогда часть обратимости удобнее вынести в отдельный коэффициент Blast Radius, который всегда ≤ 1 и работает как встроенный индикатор масштабности возможного ущерба. Он понижает итоговый приоритет там, где ошибка затрагивает большое количество пользователей, значимые суммы денег, чувствительные данные или критические процессы. По сути, Blast Radius помогает количественно зафиксировать страхи, которые в других моделях остаются неявными.
При этом Reversibility и Blast Radius отвечают на разные вопросы:
- Reversibility — насколько быстро, полно и дёшево можно вернуть продукт, данные и процессы в приемлемое состояние;
- Blast Radius — какой ущерб может возникнуть до обнаружения проблемы и завершения отката.
Один и тот же риск нельзя полностью учитывать в обоих показателях. Например, невозможность восстановить данные относится к Reversibility, а число пользователей, чьи данные успеют измениться до остановки эксперимента, — к Blast Radius.
PoDPR в этом случае будет выглядеть так:
PoDPR = (Pain ÷ Difficulty) × Probability × Reversibility × Blast Radius
Как использовать коэффициент:
Br = 1.0— локальные изменения: ограниченная аудитория, минимальные риски, безопасный откат.Br = 0.8— умеренный радиус: ошибка может затронуть часть пользователей или ограниченную зону продукта, но последствия обратимы.Br = 0.5— значительный риск: потенциальный ущерб затрагивает широкую аудиторию, деньги или данные; требует песочницы или ограниченного запуска.Br < 0.5— критический радиус: инициатива не участвует в обычном сравнении до появления изолированного контура, ограниченного пилота или другого способа снизить потенциальный ущерб.
Показатель «радиуса взрыва» переносит дискуссию из разряда «это слишком рискованно» в конкретную измеримую величину. Это встроенный механизм осознанного риска: модель сама подсказывает, где стоит сузить аудиторию, добавить фича‑флаг или провести пилот до релиза.
Учёт устойчивости и стоимости владения
Для платформенных изменений можно добавить Sustainability — коэффициент устойчивости и стоимости владения. Он отражает, насколько предлагаемое решение долговременно, как повлияет на поддерживаемость системы и сколько ресурсов потребует в будущем.
Sustainability дисциплинирует архитектурное мышление и помогает команде видеть не только краткосрочный выигрыш, но и долгосрочные последствия. Команды часто выбирают быстрые решения, которые потом превращаются в кровавые узлы поддержки. Учёт устойчивости позволяет зафиксировать этот риск: чем ниже устойчивость, тем сильнее штраф по итоговому приоритету.
Формула PoDPR с учётом устойчивости:
PoDPR = (Pain ÷ Difficulty) × Probability × Reversibility × Sustainability
Как работает Sustainability:
S = 1.0— решение не увеличивает сложность, легко поддерживается, не создаёт техдолга.S = 0.9— умеренное усложнение: появятся новые зависимости или ручные процессы, но они управляемы.S = 0.8— заметное усложнение: заметный техдолг, рост издержек на поддержку, повышение риска регрессий.S < 0.8— критическое влияние: решение ухудшает архитектуру, создаёт хрупкость и тянет за собой постоянные издержки.
Перед добавлением коэффициента команда должна явно перечислить, какие последствия исключаются из Difficulty и переносятся в Sustainability. Иначе возникнет двойной штраф.
Sustainability не вводится для одной отдельной задачи. Он применяется ко всему сравниваемому набору и фиксируется в версии модели.
Соответствие стратегии, Gates
Не всегда нужно добавлять новые множители или модифицировать существующие. Иногда нужно просто фильтровать — как в случае со стратегическим соответствием. Инициативы, которые не входят в стратегические фокусы на квартал, просто не попадают в шорт-лист. Это дискретное условие, а не множитель.
Такая фильтрация помогает сохранять стратегическую дисциплину и защищает команду от «приоритетных просьб», которые не связаны с целями. Ведь если добавить стратегию в формулу как вес, любой менеджер сможет легко повысить приоритет своей инициативе, просто объявив её «стратегически важной». При фильтрации же стратегический фокус остаётся бинарным порогом: фича либо соответствует стратегии, либо нет.
Как работает фильтр стратегического соответствия:
- В начале квартала или планового периода формулируются 1–2 стратегических направления (например, рост удержания пользователей и сокращение издержек).
- Каждая инициатива проходит предварительную проверку: поддерживает ли она хотя бы одно стратегическое направление.
- Если нет — задача не попадает в расчёт PoDPR вообще, независимо от высоких оценок Pain или Probability.
Например, компания в этом квартале концентрируется на росте retension и устойчивости платформы. Идея добавить новый маркетинговый виджет может иметь высокий PoDPR (много жалоб, легко сделать, обратимо), но не попадает в шорт-лист, потому что не влияет на удержание и не укрепляет платформу. Это удерживает команду в рамках стратегии и помогает объяснять бизнесу, почему «не делаем прямо сейчас».
Как работает расширяемость на практике
Кроме описанных способов, вы можете расширять метод как угодно — главное, руководствоваться здравым смыслом и вашими проектными/продуктовыми реалиями. Условия конкретного продукта можно учитывать тремя способами:
- Гейт определяет, допускается ли инициатива к сравнению. Примеры: соответствие стратегии, наличие владельца, обязательный security-review.
- Атрибут даёт контекст, но не меняет балл. Примеры: сегмент, зависимость, тип риска, дедлайн.
- Модификатор корректирует итоговый балл в заранее заданном диапазоне.
Новый множитель в формулу добавляется только тогда, когда гейта или атрибута недостаточно.
Для сохранения объяснимости в одной версии модели желательно использовать не более одного-двух дополнительных модификаторов.
Любое изменение формулы создаёт новую версию модели. В одном цикле сравнения все инициативы должны рассчитываться по одной версии.
Кроме того, желательно следовать нескольким простым правилам:
Фиксация множителей и фильтров
Все дополнительные множители и фильтры вводятся с учётом специфики продукта. Все они заранее согласовываются и документируются.
Такие правила описывают не только формулы, но и контекст их применения: кто оценивает, какие источники данных используются, какие артефакты должны подтверждать оценки. Это превращает PoDPR из простой формулы в полноценный процесс принятия решений.
Фиксация значений
Значения новых множителей фиксируются в шкалах (как и базовые факторы Pain, Difficulty, Probability и Reversibility). Для каждого множителя создаются якорные уровни с описанием, примерами и проверяемыми показателями.
Например, если вводится коэффициент Urgency, то у него есть конкретные критерии: срок до дедлайна, сезонность, ограниченность окна возможностей. Для Blast Radius — конкретные признаки ущерба и аудитории. Документирование делает расчёты воспроизводимыми внутри одной команды. Сравнивать абсолютные баллы между командами можно только при общей версии формулы, одинаковых шкалах, одинаковом горизонте оценки и совместной калибровке на нескольких эталонных инициативах.
Story points, локальные классы задач и экспертные шкалы разных команд нельзя автоматически считать эквивалентными.
Изменение шкал
Шкалы и веса (например, 0.8-1.2 для Urgency) нельзя менять внутри текущего цикла приоритизации. После завершения цикла команда может сравнить прогнозы с фактическими результатами, откалибровать шкалы и выпустить новую версию модели.
В журнале изменений фиксируются причина, проверенные кейсы, старые и новые значения и дата начала применения новой версии.
Итог
Расширяемость полезна, пока модель остаётся объяснимой и сопоставимой. Каждый новый множитель увеличивает стоимость оценки и риск двойного учёта, поэтому базовая формула должна оставаться вариантом по умолчанию. Расширение оправдано, когда команда может показать повторяющийся дефект базового ранжирования, определить отдельный смысл нового показателя и проверить его на нескольких завершённых кейсах.
А о том, как считать показатели, какие коэффициенты применять к каждому из них и как не выстрелить себе в ногу, будет в следующей статье.
