PoDPR: логика, расчёт и антипаттерны

В предыдущих статьях цикла мы разобрали, что такое PoDPR и почему классические методы приоритизации порой недооценивают риски (кроме, пожалуй, дверей Амазона, но у них это выродилось в отдельную бюрократию). Мы также рассмотрели расширяемость подхода и его усиление.

В этой части будет практический разбор метода. Мы выясним, как считать показатели PoDPR так, чтобы они опирались на данные, а не на харизму самого громкого человека в комнате. Мы поговорим о коэффициентах и правилах, которые не позволят манипулировать цифрами (ну или сделают такие манипуляции не особо эффективными).

Напоминаю, что задача PoDPR — дать команде одну понятную шкалу для сравнения сопоставимых необязательных инициатив. Сравниваемые элементы должны находиться на одном управленческом уровне. Обязательные работы, стратегические ставки и инициативы разных уровней сначала разделяются на отдельные контуры.

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

1. Насколько сильна боль.
2. Насколько сложно её устранить.
3. Насколько вероятно, что решение сработает.
4. Насколько безопасно пробовать.

Дальше уже возможны расширения под домен: срочность, «радиус взрыва», устойчивость решений — об этом было в прошлой статье цикла. Но всё всегда начинается с ядра.

Основная логика и детализация

Прежде чем окунуться в коэффициенты и числа, давайте сперва быстренько пробежимся по основам.

Базовая формула

Формула PoDPR не сложная:

PoD × Probability × Reversibility, где PoD = Pain ÷ Difficulty.

• Pain over Difficulty — отношение выраженности проблемы к сложности её устранения. Чем серьёзнее проблема и чем доступнее проверяемое решение, тем выше PoD. Это ещё не оценка фактической пользы решения: вероятность эффекта учитывается отдельно через Probability.
• Probability — насколько мы уверены, что польза вообще будет. Подтверждается ли это какими-то исследованиями, прежним опытом или оценка ставится просто «по ощущению» — всё это влияет на итоговый балл.
• Reversibility — насколько безопасно проверить гипотезу, ничего окончательно не сломав. Если мы можем запустить фичу и, в случае провала, тут же её откатить — мы молодцы, надо пробовать. Если же цена «отката» будет высокой, то давайте поищем что-нибудь более обратимое и безопасное.

Разложение Pain и Difficulty на множители

При этом Pain и Difficulty можно разложить на отдельные показатели, чтобы быть максимально уверенными в оценках.

Декомпозиция является выбором для всего сравниваемого набора, а не для одной удобной инициативы. Если Pain рассчитывается как Severity × Frequency × Reach (об этом ниже), то одинаковая схема применяется ко всем инициативам списка. То же правило действует для Difficulty: нельзя сравнивать задачу с Pain = 4, выставленным напрямую, и задачу с Pain = 4,8, рассчитанным из дочерних коэффициентов. По крайней мере, пока шкалы не откалиброваны на общих эталонных примерах.

Декомпозиция Pain

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

• Severity — серьёзность проблемы или задачи: насколько сильно она влияет на ключевые сценарии, воронку и бизнес. Теряем ли мы конверсию, критичный шаг активации или лишь сталкиваемся с раздражающим неудобством.
• Frequency — частота возникновения проблемы. Frequency отвечает за то, насколько массово проблема проявляется во времени — разовая неприятность, проблема сегмента, регулярный сбой или системный поток обращений.
• Reach — охват: сколько людей или каких финансовых аспектов касается проблема. Reach показывает распределение боли по аудитории — это может быть узкий сегмент, большинство MAU или конкретный высокомаржинальный поток денег.

Декомпозиция Difficulty

Для крупных или сложных задач оценивать Difficulty одним показателем может оказаться опрометчиво. В таких случаях сложность можно разбить на 3 отдельных множителя:

• Effort — реальные трудозатраты. Не «кажется легко», а суммарная работа с учётом дизайна, разработки, тестирования, интеграций, релизных окон и согласований. Effort отражает не только время, но и массу скрытой работы: подготовку окружений, инфраструктуру, миграции, партнёрские ограничения.
• Confidence — уверенность в оценке Effort. Если задача знакомая, есть аналогичные выполненные работы и команда уверена в оценке — Confidence высокий. Если задача новая, много неопределённостей, нет точных данных или оценка поставлена «на ощущениях», Confidence низкий.
• Expertise — уровень компетенции команды в задачах такого типа. Команда может уметь решать одни классы задач и испытывать сложности с другими. Expertise показывает, насколько команда знакома с паттернами, типовыми граблями, сложностью тестирования и характером подобных работ.

Рекомендуемые диапазоны

Чтобы уменьшить субъективность, все факторы живут в фиксированных диапазонах, которые не изменяются без существенных причин.

Показатель	Диапазон	Описание
Pain	1-5	Без чрезмерной детализации, показатель должен быть сравнимым между задачами.
Difficulty	1-5	Сложность должна оставаться в одном ряду с Pain, чтобы не взрывать итоговую формулу.
Probability	0.1-1	Оценка вероятности только снижает итоговый балл, а не повышает его.
Reversibility	0.1-1	Чем ниже обратимость, тем выше риск. Планка 0.1 показывает полную необратимость.

Probability и Reversibility — сильные штрафные коэффициенты. Каждый из них может уменьшить результат до десяти раз, а вместе — до ста раз. Это сознательное свойство модели: слабо доказанные и плохо обратимые инициативы резко опускаются в рейтинге.

После нескольких циклов команда должна проверить модель на завершённых инициативах. Если Probability и Reversibility почти всегда перекрывают различия Pain и Difficulty, диапазоны следует откалибровать и выпустить новую версию шкалы.

Если план отката не описан, Reversibility получает заранее определённое консервативное значение, например 0,3. Минимальное значение 0,1 используется только для изменений, необратимость которых подтверждена: например, невосстановимой миграции данных или юридически необратимого обязательства.

Дочерние показатели для Pain и Difficulty, если они применяются, будут также иметь собственные диапазоны. Для них схема всегда одинаковая: один основной показатель и два поправочных коэффициента.

Для Pain:

Показатель	Диапазон	Описание
Severity	1-5	Шкала 1–5 отражает глубину боли и последствия для продукта, сохраняя сопоставимость между задачами.
Frequency	0.8-1.2	Корректирующий показатель — чтобы проблема не превращалась в «боль №1» только из-за её «серьёзности».
Reach	0.8-1.2	Reach учитывается как корректировка, а не как отдельная ось. Это отражает масштаб, но не доминирует над всей «болью».

Для Difficulty:

Показатель	Диапазон	Описание
Effort	1-5	Основная шкала трудоёмкости. Может указываться вручную или высчитываться автоматически (например, из story points).
Confidence	0.8-1.2	Уверенность должна лишь слегка корректировать оценку, но не доминировать над Effort.
Expertise	0.8-1.2	Наличие опыта снижает сложность, отсутствие — увеличивает, но без взрывных эффектов.

Таким образом, в подходе есть три типа диапазонов:

От 1 до 5 — основная оценка. Декомпозированный результат может выйти за диапазон 1–5, но это допустимо только при одинаковой схеме расчёта для всего списка.

От 0.1 до 1 — фактор. Оценка вероятности «попадания» и обратимости, снижает итоговый балл, если с этими показателями всё грустно.

От 0.8 до 1.2 — ограничитель. Поправочный коэффициент дочерних диапазонов, по умолчанию равен единице и изменяется только при необходимости.

Чтобы не путаться в десятеричных числах, диапазон 0.8-1.2 при оценке можно показывать как 1-5, а 0.1-1 как 1-10 — и уже в итоговой таблице применять нужные коэффициенты (формулами или функциями)

В таблице расчёта необходимо фиксировать версию схемы: например, base или decomposed.

Pain: как честно измерять боль

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

1. Влияние на ключевую метрику (конверсия, активация, деньги).
2. Масштаб последствий (сколько пользователей или денег затрагивает).
3. Интенсивность проявления (насколько это «сейчас болит» для бизнеса).

Команда ставит итоговую оценку Pain по шкале 1–5, опираясь на эти три фактора одновременно. Такой подход работает, когда команда достаточно опытна или проблема очевидна, и позволяет не тратить время на формальные множители — но при этом всё равно избегать интуитивного хаоса.

Но если хочется углубиться, то вот:

Severity

Глубина удара по продукту и бизнесу. Мы не оцениваем «неприятность», мы оцениваем последствия. Потеря денег, срыв критического шага активации, падение конверсии на ключевом экране — всё это высокий Severity. Раздражение, но без прямых потерь, — низкий.

В идеале, Severity должен опираться на метрики: воронки, отказоустойчивые сценарии, SLA, продуктовые KPI. Если их нет, то на исследовательские данные: интервью, рекламации. И только в крайнем случае — на экспертную оценку.

Ключевой принцип: мы оцениваем факт воздействия, а не яркость эмоций стейкхолдера.

Frequency

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

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

Frequency хорошо считается из аналитики: частота ошибок, количество обращений в поддержку, пульсация событий. Важно не путать Frequency с Reach: проблема может возникать часто, но бить только по маленькой группе пользователей.

Frequency — корректирующий множитель. Он не должен раздувать боль просто потому, что «сбой частый»: если проблема не критична, частота не превращает её в ультра-приоритет.

Reach

Распределение боли по людям или по деньгам. Это может быть процент MAU, сегмент высокой ценности, B2B-клиенты с дорогими контрактами или конкретный денежный поток.

Reach помогает отделить «массовую, но мелкую» боль от «узкой, но дорогой».

Важно: Reach — это не основной показатель Pain, а корректирующий. Он помогает избежать перекоса в сторону «всё для всех» и держать приоритет на тех сценариях, где действительно важна ценность (или деньги).

Difficulty: почему это не просто «усилия»

Difficulty — не только часы разработчиков. Это вся системная сложность доведения инициативы до обратимого результата: зависимости, релизные окна, тестирование, безопасность, инфраструктура.

Источники для оценки:

• медианный lead time для задач похожего класса;
• количество внешних и внутренних зависимостей;
• наличие готовых блоков (дизайн‑система, SDK, шаблоны миграций);
• требования к тестированию (регресс, нагрузочное, безопасность);
• ручные этапы (compliance, юристы, партнёры).

Опять же, если хочется углубиться:

Effort

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

Effort — это сумма скрытой и явной работы. Оценку этого показателя лучше строить на аналогиях, данных прошлых задач и экспертной калибровке. Если оценка ставится «на глазок», Effort неизбежно станет инструментом манипуляции.

Confidence

Уверенность команды в корректности оценки Effort. Задача может казаться простой, но если команда никогда не делала ничего подобного, показатель должен быть низким.

Высокий Confidence означает, что:

• есть референсы;
• есть опыт подобных задач;
• есть понятная архитектура;
• нет критичных неопределённостей.

Низкий Confidence — это сигнал, что риски недооценены. В PoDPR он увеличивает Difficulty, сдерживая чрезмерный оптимизм.

Expertise

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

Expertise — не про людей в целом, а про знание конкретного домена: интеграции, форматы данных, алгоритмы, типовые фейлы.

Высокая Expertise снижает Difficulty, низкая — повышает.

Итог

Confidence и Expertise можно показывать оценщику по привычной шкале 1–5, но перед расчётом они преобразуются в обратные коэффициенты Difficulty.

Оценка	Confidence	Expertise	Difficulty
1	уверенность очень низкая	существенный дефицит экспертизы	1,2
2	низкая	ниже необходимой	1,1
3	средняя	достаточная с оговорками	1,0
4	высокая	хорошая	0,9
5	очень высокая	подтверждённая опытом	0,8

В базе данных или формуле следует хранить именно коэффициент, а не исходную оценку 1–5. Это устраняет неоднозначность направления.

Probability: уверенность в попадании

Probability показывает, насколько мы уверены, что решение вообще даст результат. Это не вера в команду — это вера в гипотезу. Число, фиксирующее то, насколько обоснована причинная связь между предлагаемым решением и ожидаемым результатом.

Данные о существовании, частоте и масштабе проблемы обосновывают Pain. Для высокой Probability нужны доказательства именно выбранного решения:

• результат тестирования прототипа;
• пилот на ограниченной аудитории;
• A/B-тест;
• подтверждённый аналог в сопоставимом контексте;
• ранее наблюдавшийся механизм изменения поведения;
• несколько независимых сигналов, связывающих решение с целевой метрикой;
• редко, очень редко: экспертиза команды.

Проблема может быть доказана очень хорошо, а Probability конкретного решения при этом оставаться низкой.

Аналитика достоверно показывает высокий процент незавершённых оплат — это усиливает Pain. Предположение, что видеоинструкция устранит проблему, пока не проверено — Probability решения остаётся низкой.

Низкая Probability — когда мы не знаем, «выстрелит» ли идея, или когда сигналов слишком мало. Важно: показатель только уменьшает итоговый балл. Это встроенная защита от фантазий «давайте сделаем, а там посмотрим».

Reversibility: обратимость и риск

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

При оценке учитываются:

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

Фича-флаг повышает обратимость только тогда, когда его отключение действительно прекращает последствия изменения. Если откат возможен, но до него может возникнуть большой ущерб, это дополнительно учитывается через Blast Radius в расширенной версии модели.

Reversibility защищает от гипотез, которые «могут быть полезны», но слишком опасны в проверке.

Короткий пример расчёта

Для начала рассмотрим намеренно простой пример, чтобы проверить механику расчёта и определить порядок проверки трёх сопоставимых инициатив:

A) Добавить автосохранение черновиков формы оплаты.
B) Переделать онбординг с видеоанимацией.
C) Добавить промо‑баннер на главной для новой акции.

Pain

• A = 4 (падение конверсии + жалобы);
• B = 1 (жалоб нет, только вкусовые пожелания);
• C = 2` (маркетинг хочет, но боли немного).

Difficulty

• A = 2 (2 дня работы, 1 зависимость);
• B = 4 (2 недели, согласования, дизайн, фронт, мобилка);
• C = 1 (пара часов).

Probability

• A = 0.7 (анализ логов и прототип на 5% трафика);
• B = 0.3 (только «ощущение», без данных);
• C = 0.5 (по аналогам и прошлым акциям было неплохо).

Reversibility

• A = 0.8 (фича‑флаг, убирается моментально);
• B = 0.2 (встроено в основной поток без флага);
• C = 0.9 (баннер легко выключить).

PoD

• A: 4/2 = 2.0
• B: 1/4 = 0.25
• C: 2/1 = 2.0

PoDPR

• A: 2.0 × 0.7 × 0.8 = 1.12
• B: 0.25 × 0.3 × 0.2 = 0.015
• C: 2.0 × 0.5 × 0.9 = 0.9

Итоговый приоритет очевиден: сперва делаем A, затем C, и только потом — B.

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

Важно

Балл PoDPR — сравнительный индекс, а не объективная стоимость инициативы. Значение 1,12 не означает, что задача A на 24% ценнее задачи C с баллом 0,9. Формула помогает выявить крупные различия и причины расхождений, но небольшая разница не должна автоматически определять решение.

Баллы имеют смысл только внутри одного набора инициатив, рассчитанных в один момент, по одной версии формулы и одинаковым шкалам.

Когда непонятно

Для каждой спорной оценки измените значение на один шаг вверх и вниз и пересчитайте верхнюю часть рейтинга:

• если порядок не меняется, результат относительно устойчив;
• если лидер меняется от небольшого изменения одного коэффициента, инициативы следует считать близкими по приоритету;
• в нестабильном случае нужно собрать дополнительные данные, провести RAT, прототипирование или ограниченный эксперимент, а не выбирать победителя по сотым долям.

Анти-манипуляционные правила

Ни одна формула не исключает политические интересы и субъективность. Задача правил — зафиксировать происхождение оценок и сделать изменения проверяемыми. Чтобы PoDPR не превращался в инструмент продавливания интересов, необходимо вводить жёсткие правила расчёта.

Ниже — немного о коэффициентах и процессных правилах, которые делают основания оценок видимыми и усложняют незаметную подгонку результата.

Нельзя менять диапазоны под задачу. Как только команда начинает «подкручивать» шкалы, метод превращается в RICE с его бесконечными творческими трактовками Reach.

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

• нет подтверждения проблемы или её масштаба — пересматривается Pain;
• нет подтверждения конкретного решения — снижается Probability;
• неизвестен объём реализации — снижается Confidence и повышается Difficulty;
• не описан откат — снижается Reversibility.

на Effort должен опираться исторические данные сопоставимых задач или независимые оценки минимум двух участников. Оценщики сначала выставляют значения отдельно, после чего обсуждают только существенные расхождения.

Reversibility получает минимальное значение по умолчанию. Если никто не может объяснить, как будем откатывать, значит, откатывать будет сложно.

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

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

Где PoDPR не подходит

PoDPR не серебряная пуля. Есть ситуации, где метод либо даёт искажение, либо вообще не нужен.

Стратегические ставки с дальним горизонтом. Pain и Difficulty могут оставаться полезными, но не отражают опциональность, сценарии рынка, позиционирование и долгосрочные ограничения. Такие решения требуют стратегического анализа, а PoDPR может применяться только к отдельным экспериментам внутри выбранной стратегии.

Обязательные работы. Security-патчи, регуляторные изменения, договорные обязательства и критические инциденты не должны конкурировать с необязательными продуктовыми инициативами. Для них используется отдельная очередь с учётом срока, обязательности и потенциального ущерба.

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

Решения с неоценимой реализацией. Pain может быть хорошо известен, даже если решение пока непонятно. Если нельзя надёжно оценить Difficulty и Probability, сначала нужны исследование, технический spike, прототип или RAT.

Нормативные и этические ограничения. Формула не может отменить закон, безопасность, этические принципы или принятые обязательства.

Техническая задача может оцениваться через PoDPR, если она сформулирована как сопоставимая проверяемая инициатива с ожидаемым эффектом. Сам технический характер задачи не выводит её за пределы метода.

Финал

PoDPR не пытается объективно измерить ценность каждой инициативы. Он разделяет обсуждение на четыре вопроса: насколько выражена проблема, сколько стоит её проверка, почему выбранное решение должно сработать и как ограничить последствия ошибки.

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

А в следующей статье мы детально рассмотрим несколько примеров того, как PoDPR решает вопросы приоритизации.