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

• Все статьи цикла:
• PoDPR или зачем нам ещё одна формула приоритизации
• PoDPR как расширяемая основа
• PoDPR: логика, расчёт и антипаттерны (вы здесь)
• Примеры приоритизации с PoDPR (coming soon)
• Конфигуратор PoDPR (coming soon)
• Безболезненное внедрение PoDPR (coming soon)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для Pain:

Для Difficulty:

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

От 1 до 5 — основная оценка. Может быть больше пяти, если не просто указывается, а вычисляется из дочерних.

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

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

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

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

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

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

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

2.1. Severity

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

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

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

2.2. Frequency

Регулярность и массовость проявления проблемы во времени. Один раз упало — не Frequency. Раз в неделю ломается массовый сценарий — это Frequency. Ежедневные сбои на критическом шаге — это максимальный Frequency.

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

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

2.3. Reach

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

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

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

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

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

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

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

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

3.1. Effort

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

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

3.2. Confidence

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

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

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

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

3.3. Expertise

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

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

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

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

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

Высокая Probability означает, что есть:

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

Низкая Probability — когда мы не знаем, «выстрелит» ли идея, или когда сигналов слишком мало.

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

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

Способность безопасно проверить идею и откатить её без больших потерь.

Высокая обратимость — это когда:

• есть флаг или экспериментальный режим;
• обновление приводит к «мягким» интерфейсным изменениям;
• сценарий не затрагивает данные или бизнес-процессы.

Низкая обратимость — это:

• миграции данных;
• изменение контрактов API;
• переписывание ключевых алгоритмов;
• любая работа без возможности быстрого отката.

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

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

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

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.

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

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

Чтобы PoDPR не превращался в инструмент продавливания интересов, необходимо вводить жёсткие правила расчёта.

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

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

Effort оценивается минимум двумя людьми. Это снижает оптимистичные искажения и уменьшает шанс случайной недооценки.

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

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

Любая «слишком выгодная» задача пересматривается повторно. Если что-то выглядит слишком хорошо, почти всегда это ошибка в Pain или Difficulty.

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

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

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

Задачи без гипотез. Технические обновления библиотек, security-патчи, обязательные регуляторные изменения — всё это вне PoDPR. Здесь нет Probability и Reversibility в привычном смысле.

«Просто надо сделать». Если задача — это долг, риск или обязательство перед партнёром, её приоритизация производится в других моделях.

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

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

9. Финал

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

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

• Все статьи цикла:
• PoDPR или зачем нам ещё одна формула приоритизации
• PoDPR как расширяемая основа
• PoDPR: логика, расчёт и антипаттерны (вы здесь)
• Примеры приоритизации с PoDPR (coming soon)
• Конфигуратор PoDPR (coming soon)
• Безболезненное внедрение PoDPR (coming soon)