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