```json
{
    "title": "PoDPR как расширяемая основа",
    "url": "https://sherer.pro/blog/podpr-kak-rasshiryaemaya-osnova/",
    "datePublished": "2025-11-23",
    "dateModified": "2026-07-27",
    "language": "ru-RU",
    "description": "PoDPR — это не скрижаль, высеченная в камне. Подход можно и нужно расширять под проектные и продуктовые реалии.",
    "author": "Павел Шерер",
    "publisher": "Павел Шерер"
}
```

# PoDPR как расширяемая основа

В прошлой [статье](https://sherer.pro/blog/podpr-ili-zachem-nam-eshchyo-odna-formula-prioritizacii/) мы разобрали ядро PoDPR. Теперь поговорим о возможности адаптировать метод под конкретный домен — и о рисках такой адаптации.

Сразу вас разочарую: базовая формула должна оставаться вариантом по умолчанию. Каждый новый множитель увеличивает стоимость оценки, риск двойного учёта и вероятность подгонки результата. Поэтому расширение оправдано только тогда, когда команда может показать повторяющийся дефект базового ранжирования, который нельзя устранить уточнением существующих показателей.

Но, если вы уверены, что иначе никак — погнали.

## Зачем расширять PoDPR

В разных доменах у продукта свои акценты: где-то важнее скорость реакции на рынок, где-то комплаенс, где-то технический долг. Поэтому PoDPR можно расширять модулями — аккуратно добавлять множители или фильтры, которые не ломают основную механику `Pain ÷ Difficulty × Probability × Reversibility`, а лишь уточняют её под реалии продукта.

Как я уже писал, следующая статья будет про то, как именно считать каждый из показателей, а пока давайте разберём несколько примеров расширения PoDPR.

Новый элемент модели вводится, если одновременно выполнены три условия:

1. базовая формула систематически выдаёт непригодный для домена порядок;
2. проблема повторяется на нескольких кейсах, а не на одной неудобной инициативе;
3. новый показатель не дублирует Pain, Difficulty, Probability или Reversibility.

## Встраивание Reach из RICE

Иногда важно считать охват новых фич, будь то количество затрагиваемых пользователей или потенциальная прибыль для бизнеса. Выносить **Reach **в отдельный множитель необязательно, потому что охват уже является частью выраженности проблемы. Если учитывать его отдельно и одновременно использовать при оценке **Pain**, масштаб будет посчитан дважды. Поэтому в детализированной версии **Pain** можно разложить на **Severity** (тяжесть последствий одного проявления проблемы), **Frequency **(частота её возникновения) и **Reach** (охват):

`Pain = Severity × Frequency × Reach`

![Встраивание Reach из RICE в PoDPR](https://sherer.pro/content/uploads/2025/11/podpr-rerach-scaled-1.png)

**Frequency **и **Reach** должны иметь разные операционные определения: **Frequency **показывает повторяемость проблемы у одного затронутого объекта за период, **Reach** — долю аудитории, процессов или денежного потока, затронутую хотя бы один раз.

Таким образом метрика «сколько людей затронет» превращается из отдельного множителя в компонент «боли». **Reach** становится не абстрактным числом, а измеримой частью боли, завязанной на реальные данные об аудитории или бизнес-показателях.

Например, если проблема затрагивает 5% активных пользователей, это значение переводится в коэффициент Reach по заранее зафиксированной шкале. Reach ограниченно корректирует Pain, но не делает итоговый балл пропорциональным числу пользователей.

## Учёт Effort и Confidence в Difficulty

Для сложных задач **Difficulty **можно разложить на **Effort **(полный объём явной и скрытой работы) и два поправочных коэффициента:

- **Confidence **— поправка на уверенность в оценке **Effort**;
- **Expertise** — поправка на релевантную экспертизу команды.

`Difficulty = Effort × Confidence × Expertise`

![Учёт Effort и Confidence из RICE в Difficulty](https://sherer.pro/content/uploads/2025/11/podpr-efford-scaled-1.png)

Высокий 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`.

![Встраивание фактора срочности в PoDPR](https://sherer.pro/content/uploads/2025/11/podpr-urgency.png)

> Регуляторные требования, 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`

![Встраивание фактора «радиус взрыва» в PoDPR](https://sherer.pro/content/uploads/2025/11/podpr-blast-radius.png)

Как использовать коэффициент:

- `Br = 1.0` — локальные изменения: ограниченная аудитория, минимальные риски, безопасный откат.
- `Br = 0.8` — умеренный радиус: ошибка может затронуть часть пользователей или ограниченную зону продукта, но последствия обратимы.
- `Br = 0.5` — значительный риск: потенциальный ущерб затрагивает широкую аудиторию, деньги или данные; требует песочницы или ограниченного запуска.
- `Br < 0.5` — критический радиус: инициатива не участвует в обычном сравнении до появления изолированного контура, ограниченного пилота или другого способа снизить потенциальный ущерб.

Показатель «радиуса взрыва» переносит дискуссию из разряда «это слишком рискованно» в конкретную измеримую величину. Это встроенный механизм осознанного риска: модель сама подсказывает, где стоит сузить аудиторию, добавить фича‑флаг или провести пилот до релиза.

## Учёт устойчивости и стоимости владения

Для платформенных изменений можно добавить **Sustainability** — коэффициент устойчивости и стоимости владения. Он отражает, насколько предлагаемое решение долговременно, как повлияет на поддерживаемость системы и сколько ресурсов потребует в будущем.

**Sustainability** дисциплинирует архитектурное мышление и помогает команде видеть не только краткосрочный выигрыш, но и долгосрочные последствия. Команды часто выбирают быстрые решения, которые потом превращаются в кровавые узлы поддержки. Учёт устойчивости позволяет зафиксировать этот риск: чем ниже устойчивость, тем сильнее штраф по итоговому приоритету.

Формула PoDPR с учётом устойчивости:

`PoDPR = (Pain ÷ Difficulty) × Probability × Reversibility × Sustainability`

![Встраивание фактора устойчивости в PoDPR](https://sherer.pro/content/uploads/2025/11/podpr-sustainability.png)

Как работает **Sustainability**:

- `S = 1.0` — решение не увеличивает сложность, легко поддерживается, не создаёт техдолга.
- `S = 0.9` — умеренное усложнение: появятся новые зависимости или ручные процессы, но они управляемы.
- `S = 0.8` — заметное усложнение: заметный техдолг, рост издержек на поддержку, повышение риска регрессий.
- `S < 0.8` — критическое влияние: решение ухудшает архитектуру, создаёт хрупкость и тянет за собой постоянные издержки.

Перед добавлением коэффициента команда должна явно перечислить, какие последствия исключаются из **Difficulty **и переносятся в **Sustainability**. Иначе возникнет двойной штраф.

> Sustainability не вводится для одной отдельной задачи. Он применяется ко всему сравниваемому набору и фиксируется в версии модели.

## Соответствие стратегии, Gates

Не всегда нужно добавлять новые множители или модифицировать существующие. Иногда нужно просто фильтровать — как в случае со стратегическим соответствием. Инициативы, которые не входят в стратегические фокусы на квартал, просто не попадают в шорт-лист. Это дискретное условие, а не множитель.

Такая фильтрация помогает сохранять стратегическую дисциплину и защищает команду от «приоритетных просьб», которые не связаны с целями. Ведь если добавить стратегию в формулу как вес, любой менеджер сможет легко повысить приоритет своей инициативе, просто объявив её «стратегически важной». При фильтрации же стратегический фокус остаётся бинарным порогом: фича либо соответствует стратегии, либо нет.

Как работает фильтр стратегического соответствия:

1. В начале квартала или планового периода формулируются 1–2 стратегических направления (например, рост удержания пользователей и сокращение издержек).
2. Каждая инициатива проходит предварительную проверку: поддерживает ли она хотя бы одно стратегическое направление.
3. Если нет — задача не попадает в расчёт PoDPR вообще, независимо от высоких оценок Pain или Probability.

Например, компания в этом квартале концентрируется на росте retension и устойчивости платформы. Идея добавить новый маркетинговый виджет может иметь высокий PoDPR (много жалоб, легко сделать, обратимо), но не попадает в шорт-лист, потому что не влияет на удержание и не укрепляет платформу. Это удерживает команду в рамках стратегии и помогает объяснять бизнесу, почему «не делаем прямо сейчас».

## Как работает расширяемость на практике

Кроме описанных способов, вы можете расширять метод как угодно — главное, руководствоваться здравым смыслом и вашими проектными/продуктовыми реалиями. Условия конкретного продукта можно учитывать тремя способами:

1. **Гейт** определяет, допускается ли инициатива к сравнению. Примеры: соответствие стратегии, наличие владельца, обязательный security-review.
2. **Атрибут** даёт контекст, но не меняет балл. Примеры: сегмент, зависимость, тип риска, дедлайн.
3. **Модификатор** корректирует итоговый балл в заранее заданном диапазоне.

Новый **множитель **в формулу добавляется только тогда, когда **гейта **или **атрибута **недостаточно.

> Для сохранения объяснимости в одной версии модели желательно использовать не более одного-двух дополнительных модификаторов.

> Любое изменение формулы создаёт новую версию модели. В одном цикле сравнения все инициативы должны рассчитываться по одной версии.

Кроме того, желательно следовать нескольким простым правилам:

### Фиксация множителей и фильтров

Все дополнительные множители и фильтры вводятся с учётом специфики продукта. Все они заранее согласовываются и документируются.

Такие правила описывают не только формулы, но и контекст их применения: кто оценивает, какие источники данных используются, какие артефакты должны подтверждать оценки. Это превращает PoDPR из простой формулы в полноценный процесс принятия решений.

### Фиксация значений

Значения новых множителей фиксируются в шкалах (как и базовые факторы Pain, Difficulty, Probability и Reversibility). Для каждого множителя создаются якорные уровни с описанием, примерами и проверяемыми показателями.

Например, если вводится коэффициент Urgency, то у него есть конкретные критерии: срок до дедлайна, сезонность, ограниченность окна возможностей. Для Blast Radius — конкретные признаки ущерба и аудитории. Документирование делает расчёты воспроизводимыми внутри одной команды. Сравнивать абсолютные баллы между командами можно только при общей версии формулы, одинаковых шкалах, одинаковом горизонте оценки и совместной калибровке на нескольких эталонных инициативах.

> Story points, локальные классы задач и экспертные шкалы разных команд нельзя автоматически считать эквивалентными.

### Изменение шкал

Шкалы и веса (например, 0.8-1.2 для Urgency) нельзя менять внутри текущего цикла приоритизации. После завершения цикла команда может сравнить прогнозы с фактическими результатами, откалибровать шкалы и выпустить новую версию модели.

В журнале изменений фиксируются причина, проверенные кейсы, старые и новые значения и дата начала применения новой версии.

## Итог

Расширяемость полезна, пока модель остаётся объяснимой и сопоставимой. Каждый новый множитель увеличивает стоимость оценки и риск двойного учёта, поэтому базовая формула должна оставаться вариантом по умолчанию. Расширение оправдано, когда команда может показать повторяющийся дефект базового ранжирования, определить отдельный смысл нового показателя и проверить его на нескольких завершённых кейсах.

А о том, как считать показатели, какие коэффициенты применять к каждому из них и как не выстрелить себе в ногу, будет в следующей [статье](https://sherer.pro/blog/kak-pravilno-schitat-podpr/).