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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для Pain:

Для Difficulty:

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

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

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

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

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

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

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

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

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

Severity

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

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

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

Frequency

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

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, низкая — повышает.

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

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

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

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

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

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

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

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

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

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

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

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

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 не превращался в инструмент продавливания интересов, необходимо вводить жёсткие правила расчёта.

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

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

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

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

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

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

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

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

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

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

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

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

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

Финал

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

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

Запись PoDPR: логика, расчёт и антипаттерны первой появилась на Павел Шерер.

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

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

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

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

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

Иногда важно считать охват новых фич, будь то количество затрагиваемых пользователей или потенциальная прибыль для бизнеса. Но выносить Reach в отдельный множитель не совсем корректно, так как он будет влиять и на уверенность, и на обратимость. Тогда мы можем разложить Pain на несколько показателей и добавить к ним этот самый охват. Например, так: Pain = Severity (серьёзность задачи/проблемы) × Frequency (частота её возникновения) × Reach (охват).

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

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

Учёт Effort и Confidence в Difficulty

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

В следующей статье будут некоторые советы на этот счёт. А пока вот вам вариант, как разбить сложность на несколько показателей: Difficulty = Effort (количество ресурсов, усилие) × Confidence (уверенность в оценке) × Expertise (уровень экспертизы команды).

Здесь Confidence не влияет на общую оценку напрямую, как в RICE. Напротив, показатель уверенности в оценке касается только сложности реализации, но не пользы (Impact) — для неё есть Pain и Probability. А множитель Expertise в явном виде указывает, сталкивалась ли команда с подобными задачами или нет (и тогда оценке нужно доверять чуть меньше).

Добавление 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 может вычисляться автоматически — например, через разницу между дедлайном и прогнозной датой релиза. Таким образом, фактор срочности становится объективным и воспроизводимым.

«Радиус взрыва» и комплаенс-ограничения

Бывает так, что одной только 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 — критический радиус: ошибка недопустима, требуется полная изоляция или отдельный контур тестирования.

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

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

Для платформенных изменений можно добавить 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 в отдельный множитель помогает прозрачно фиксировать инженерные компромиссы.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Изменения в шкалах (например, 0.8-1.2 для Urgency) допустимы не чаще, чем раз в квартал — иначе есть риск превратить формулу в гибкий инструмент для политических игр. Любое изменение шкалы или весов фиксируется в changelog‑документе с обоснованием, почему было принято то или иное решение.

Итог

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

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

Запись PoDPR как расширяемая основа первой появилась на Павел Шерер.

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

У любой методологии есть преимущества и недостатки. Любая из них начинает вредить, если её возвести в культ. И как же легко это сделать, когда речь заходит о приоритетах. Каждый тянет одеяло на свои инициативы, завышая impact, занижая effort и ловко манипулируя confidence. В итоге мы спорим не о проблемах пользователей и ценности для бизнеса, а о десятых долях в табличке.

Что такое PoDPR и почему это хорошо

Приоритизация — это не только про «что важнее», это и про «что безопаснее и быстрее проверить». Метод Pain over Difficulty × Probability × Reversibility (PoDPR) рождён именно из этого принципа. Он прост в вычислении, прозрачен команде и, главное, легко расширяется под любой контекст.

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

PoDPR — это произведение независимых факторов, каждый из которых отвечает за ключевой риск приоритизации:

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

PoDPR оптимизирует не «красивый роадмап», а скорость безопасной проверки гипотез — реальный цикл продуктового развития. Формула прямо наказывает дорогостоящие, слабообратимые и плохо подтверждённые затеи. И наоборот, поднимает наверх дешёвые, обратимые и подтверждённые шаги, снимающие реальную боль.

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

Немного про классические подходы и как им помогает PoDPR

Как я уже говорил, у меня нет задачи принизить значимость других методологий. Я буду честно говорить об их плюсах и минусах. Какие-то аспекты придётся упростить, так как эта статья не претендует на полное раскрытие каждого подхода. Везде будут ссылки, почитаете сами.

MoSCoW (Must, Should, Could, Won’t)

Самый наивный, наверное, подход из всех. Я бы вообще не называл его отдельной методологией. Это просто способ оформить уже проведённую работу по расстановке приоритетов. Категории здесь — всего лишь ярлыки, а не метрики. В тот же Must часто пихаются не взвешенные решения, а «всё, что я хочу» (привет, HiPPO). Я сам однажды видел, как в Must попали одновременно критический баг в регистрации и декоративный дашборд для одного из директоров. Формально оба «обязательные», но реальная боль и уровень риска несопоставимы.

Тем не менее, MoSCoW предоставляет понятную и управляемую коммуникацию требований. Это компактный язык для общения с бизнесом, он помогает легко управлять ожиданиями.

Как дружить с PoDPR

Заменить ярлыки измеряемой логикой. Задачи с высокими PoD и Probability даже при средней Reversibility однозначно полетят в Must. PoDPR покажет, какие «Must» нужно сделать обратимыми, прежде чем запускать в проектирование и разработку.

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

RICE и ICE

RICE (Reach × Impact × Confidence ÷ Effort) и ICE (Impact × Confidence × Ease) — два разных, но очень схожих подхода к приоритизации. Прозрачная логика расчёта, понятная даже вне продуктовой команды; возможность связать эффект с масштабом охвата в RICE или лёгкость реализации с влиянием в ICE — это ли не идеал? И да, и нет. Вот несколько потенциальных проблем:

• Impact легко завысить, особенно без проверяемых источников.
• Reach часто строится исключительно на прогнозных данных.
• Единый Confidence в RICE применяют и к Reach, и к Impact, хотя часто эти оценки делают разные люди на основании разных источников.
• Ease из ICE порой подменяет собой реальную сложность: команда оценивает «кажется, быстро», игнорируя зависимости, тестирование, релизные окна, безопасность, интеграции.

При этом одно из преимуществ RICE и ICE в том, что они весьма адаптивны. И вы, имея голову со здравым смыслом внутри, можете легко построить на основе любого из них свой собственный фреймворк.

Как дружить с PoDPR

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

ICE из-за своей простоты может остаться черновым сортировщиком для быстрых идей. Шорт-лист по ICE отправляется в PoDPR, который вычищает манипуляции и поднимает вверх те задачи, которые быстрее, обратимее, и бьют по реальной боли.

Kano Model

Одна из популярных в дизайн-среде моделей. Помогает понять, какого типа ценность создаёт фича: обязательную (Must-be), важную (Performance), интересную (Attractive) или безразличную (Indifferent). Отлично подходит для приоритизации на основе пользовательских потребностей, но ничего не говорит о последовательности разработки и внедрения. Модель описывает форму ценности, но не учитывает вероятность успеха, стоимость и риск ошибок. Кроме того, опросы по Кано легко исказить выборкой и кривыми формулировками.

Как дружить с PoDPR

Через Probability и Reversibility решаем, какие Delighters можно безопасно протестировать как эксперимент, не откусывая ресурс у базовых задач. Вероятность «попадания» и обратимость легко укажут, какие вау-фичи не заслуживают высокого приоритета.

Или как с ICE: сначала используем Kano, чтобы классифицировать инициативы внутри команд. А потом считаем PoDPR внутри каждой категории и не даём Delighters перепрыгнуть через Must-be и Performance — и делаем это обоснованно.

WSJF (Weighted Shortest Job First)

Подход, получивший широкое применение в фреймворке SAFe (Scaled Agile Framework). WSJF заточен под портфельный уровень, он учитывает стоимость задержки и размеры задачи, помогает выстраивать рациональный порядок для крупных эпиков.

WSJF отлично подходит для больших объёмов, но тяжеловесен для discovery — ради быстрой проверки гипотез бессмысленно заводить такой комбайн. Местами метод сложен и абстрактен, а Business Value, Time Criticality и Risk Reduction часто оцениваются «по ощущениям руководства». При этом WSJF единственный из всех учитывает риски в своей формуле, хотя ключевой фокус подхода и не на них.

Как дружить с PoDPR

С помощью Reversibility можно выделить «одноходовые» монолиты и определить, дробим ли их на обратимые шаги или выносим в отдельный контур архитектурного решения, не конкурируя с мелкими гипотезами.

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

Value vs Effort Matrix

Максимально простая и визуальная, эта матрица интуитивно понятна даже тем, кто далёк от аналитики. Легко объяснить бизнесу и стейкхолдерам, почему часть задач стоит отложить, а часть можно сделать быстро и прямо сейчас. Отлично подходит для стартового ранжирования и вовлечения не‑продуктовых участников в обсуждение приоритетов.

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

Как дружить с PoDPR

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

User Story Mapping

User Story Mapping фокусируется на пользовательских историях и сценариях, помогает определить состав MVP и понять, какие части критичны для пользователя. Отлично работает для планирования релизов и итераций, но с перекосом в пользовательскую ценность. Бизнес здесь учитывается, но он, обычно, вторичен. А о технической реализации вообще вспоминают в последнюю очередь.

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

Как дружить с PoDPR

User Story Mapping формирует сценарии и даже предварительные планы релизов. Тогда как PoDPR помогает упорядочить их по критерию «что проверить первым»: вверх поднимаются задачи, в которых боль максимальна, вероятность подтверждена, а обратимость высокая.

Impact Mapping

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

Подход хорош в своих задачах, но он не даёт численного приоритета между ветками карты, все воздействия выглядят одинаково значимыми. Кроме того, IM не показывает вероятность эффекта и риск. Даже слабая гипотеза может выглядеть серьёзной, если «правильно» встроена в карту.

Как дружить с PoDPR

Impact Mapping остаётся инструментом стратегического видения, а PoDPR — механизмом навигации внутри карты. Сначала рисуем дерево воздействий, потом считаем PoDPR для каждого узла — и получаем последовательность безопасных проверок.

Это подход к приоритизации во имя здравого смысла. И против таблиц с весами, взятыми с потолка.

Итог

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

Запись PoDPR или зачем нам ещё одна формула приоритизации первой появилась на Павел Шерер.

Это способ сделать ваш бизнес понятным и проверяемым для аудиторий, которые дают вам деньги или возможности:

• Клиенты — им нужна ясность, чем вы полезны и почему вам можно доверять.
• Партнёры — им нужна предсказуемость: правила игры, процессы, уровень сервиса.
• Инвесторы — им нужна картина целиком: финансы, риски, права, команда.

Дисклеймер: универсальных методологий тут быть не может. Кто-то делит упаковку на маркетинговую (рекламную) и инвестиционную (предпринимательскую). У стартапа и крупного бизнеса упаковка будет сильно отличаться. Поэтому призываю вас рассматривать этот текст не как набор правил или этапов, а как перечень рекомендаций, которые вы должны адаптировать под реалии своего бизнеса.

Исходная точка: диагностика

Сначала фиксируется реальность, текущее положение дел. В этот момент частенько возникает желание что-то приукрасить: ну да, сейчас у нас не очень с проектными процессами, но вот-вот выйдет проджект, и всё будет ок. Значит, можно писать, что процессы уже внедрены. Спойлер: нет, нельзя.

Что стоит фиксировать в этой самой исходной точке:

• Продукт или продукты. В идеале, с минимальным функциональным описанием.
• Продуктовые и другие метрики, если они есть. Потом пригодятся.
• Выручка и динамика по ней. Даже если она отрицательная. Даже если за неё пока стыдно.
• Базовая юнит‑экономика и всё, от чего она выстраивалась: от исследований до предположений. Сюда же финмодель.
• Каналы продаж и их базовые особенности: региональность, отличия аудиторий, юридические ограничения и прочее.
• Состав команды, текущие проектные процессы, их состояние с соблюдением.
• Технологическая платформа. Если возможно, с указанием программных и интеграционных решений.
• Юридическая форма, состав инвестиций и прочие лигал-темы.
• Обязательства перед клиентами и партнёрами.
• Ключевые риски: от операционных до финансовых и технологических.

Кто-то скажет: «Да это уже полноценная упаковка, мало какой продукт на ранних стадиях обладает всей этой информацией». И да, и нет. Да — потому что мало кто обладает. Нет — потому что это ещё даже близко не упаковка. Если чего‑то из этого списка нет, прямо пишем «не знаю». А рядом ставим: когда и у кого узнаём. Если таких «не знаю» будет много, не пугайтесь: для стартапов на самых ранних стадиях достаточно минимального набора данных (например, описание продукта, целевая аудитория, гипотезы о каналах продаж).

Отдельно формулируется проблема роста: узкие горлышки, сильнее всего тормозящие масштабирование, целевое состояние на 6–12 месяцев с явными ограничениями по времени, бюджету и ресурсам (специалистам, технологиям, оборудованию и тп).

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

Семь слоёв упаковки

Ниже я приведу довольно большой перечень разнообразных продуктов, систем и артефактов. Часть из них у вас наверняка окажется на этапе самодиагностики. Если же каких-то нет, то не факт, что они вам нужны. Отталкивайтесь от задач бизнеса, особенностей рынка, аудитории и других факторов. Используйте здравый смысл.

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

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

Публичный слой: бренд и маркетинг

Бренд‑платформа. Это не презентация в PowerPoint, а документ, который отвечает на три простых вопроса: кто мы, зачем мы и чем отличаемся от соседей по рынку. Там же — иерархия сообщений: главный зонтик («мы решаем проблему X»), 3–4 ценностных опоры и конкретные доказательства. Добавьте тон голоса (говорим ли мы как «умный друг» или как «суровый консультант») и визуальные правила.

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

Кейсы. Пишите их как короткие истории: контекст → проблема → решение → результат (с цифрами до/после) → сложности, с которыми справились → отзыв клиента. Это не реклама, а рабочая доказательная база.

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

Маркетинг и дистрибуция. Рисуем карту каналов (SEO, статьи, ивенты, реферальные программы, платная реклама, партнёрские сети), считаем CAC по каждому каналу и планируем контент‑календарь на три месяца вперёд. Без этих чисел разговор про маркетинг превращается в гадание.

Коммерческий слой: инструменты продаж

ICP и персоны. Это портреты ваших клиентов: роли, боли, критерии, по которым они квалифицируются. Красные флаги, по которым вы сразу понимаете, что это не ваш клиент (например, негативные персоны).

Playbook продаж. Настольная книга менеджера: скрипт discovery (какие вопросы задать, чтобы раскрыть боль и ценность), сценарий демо (3–5 сцен, каждая закрывает конкретный риск или боль клиента), готовые ответы на 10 самых частых возражений и чек‑лист того, что должно быть закрыто в договоре.

Материалы. One‑pager для быстрых рассылок, battlecards для борьбы с возражениями/конкурентами, калькулятор ROI/TCO, тарифные карты, SLA/OLA, шаблоны КП и договора. Это рабочий пакет, без которого продавец каждый раз изобретает велосипед.

Продукт и операции

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

Outcome‑roadmap. Это дорожная карта, где вместо «сделаем фичу» записано «закроем проблему клиента и увидим рост конкретной метрики». И сразу связка с North Star Metric (но здесь нужно быть осторожным, можно попасть в «ловушку одной метрики», выставляйте сторожевые).

Поддержка и клиентский успех. Уровни поддержки, цели по времени ответа и решения, база знаний, сценарии онбординга и регулярных обзоров ценности (QBR). Всё это должно жить и обновляться.

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

Карта фичей и сравнений. Зачем каждая функция существует, её текущий статус и какой эффект она даёт. И честная таблица «мы vs конкуренты» без маркетинговой воды.

Финансы и риски

Финмодель. Полный комплект: P&L, Cash Flow, Balance. Драйверы выручки по сегментам, маржинальность и операционные расходы.

Unit‑экономика. В разрезе сегментов и динамике по кварталам. Ключевые ориентиры: LTV/CAC и срок окупаемости.

CAPEX/OPEX, runway и burn. Сценарии развития (базовый, оптимистичный, консервативный) и чёткие триггеры, когда нужно пересматривать стратегию.

Риски. Стратегические, продуктовые, финансовые, юридические и операционные. Делайте матрицу Вероятность х Влияние и прописывайте план BCP/DR с целевыми RTO/RPO.

Комплаенс. Всё, что связано с законами и безопасностью: GDPR/152‑ФЗ, политики ИБ и реагирования на инциденты, минимальный набор контролей (IAM, журналирование, бэкапы, privacy notice и тд), а для зрелых — сертификация ISO 27001 или SOC.

Команда

Оргструктура. Как сейчас устроена команда и к чему хотите прийти. Кто за что отвечает.

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

Консультанты и адвайзеры. Кто помогает, в какой роли и с какой частотой участвует.

Культура. Ценности команды, подход к решению конфликтов и механизмы обратной связи внутри компании.

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

Юридический блок

IP, интеллектуальная собственность. Права на код и бренд, лицензии, патенты или заявки, товарные знаки, пользовательские соглашения.

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

Data Room

В идеале, все эти данные и документы должны быть упорядочены и собраны в одном месте. Я часто встречал ситуации, когда, вроде, всё есть, но одни документы в ИБ, другие у продажников, третьи в репозитории на гитлабе.

Последний вариант про репозиторий, кстати, довольно неплохой (если допускается централизованный доступ ко всем документам). Обычно у меня получается подобная структура папок, но вы можете придумать свою:

• 0_Executive
• 1_Corporate
• 2_Financials
• 3_Product
• 4_Sales_Marketing
• 5_Legal
• 6_Team
• 7_Customers
• 8_Intellectual_Property
• 9_Security_Compliance

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

Как это сделать за 6–8 недель

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

1. Аудит (1 неделя). Это момент правды: собрать все факты, вытащить цифры и документы, посмотреть на реальное состояние процессов и рисков. Здесь задача не «сделать красиво», а честно понять, где мы находимся и что мешает.
2. Стратегия (1 неделя). Вторая неделя про смысл и фокус. Формулируем, куда мы идём, какие сегменты важны, какие гипотезы роста проверяем в первую очередь. Определяем NSM, целевые KPI, строим картину каналов и подход к рынку.
3. Производство (2–3 недели). Дальше — ручная работа: собираем материалы, формулируем истории успеха, описываем процессы и считаем экономику. Это не про полировку дизайна, а про перевод стратегии в конкретные рабочие документы и инструменты.
4. Внедрение (1-2 недели). Здесь мы вшиваем всё собранное в реальные процессы: подключаем аналитику, налаживаем лид-менеджмент, обучаем команду, готовим пространство для инвестора или партнёра. Суть этапа в том, чтобы артефакты перестали быть файликами и стали частью работы.
5. Замер и правки (1 неделя). На этом этапе проверяем, работает ли новая конструкция. Прогоняем воронки, смотрим на отклики, тестируем ключевые гипотезы. И сразу же правим то, что не летает. Это не финал, а первый цикл обратной связи.

Фреймворки от вкусовщины

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

• Value Proposition Canvas. Фиксирует соответствие «боли/выгоды» клиента и вашего предложения. Помогает сверять фичи с ценностью и доказательствами.
• Jobs To Be Done (JTBD). Смотрим на «работы» клиента, контекст и триггеры выбора. Используем job stories в демо и продуктовых решениях.
• Opportunity Solution Tree (OST). Дерево от цели к возможностям и экспериментам; дисциплинирует приоритизацию и формулировку исследовательских вопросов.
• RICE‑приоритизация. Быстрое ранжирование бэклога: Reach x Impact x Confidence / Effort.
• Kano‑модель. Помогает различать базовые ожидания (must‑have), характеристики, напрямую влияющие на удовлетворённость (performance), и «вау‑факторы» (delighters).
• AARRR (Pirate Metrics). Скелет воронок роста: Acquisition → Activation → Retention → Revenue → Referral.
• OKR. Связка целей и измеримых результатов, цикл квартальной фокусировки.
• Wardley Maps. Карта ценностной цепочки и стадий эволюции компонентов — помогает принимать архитектурные и продуктовые решения.
• Business Model Canvas. Быстрый способ описать бизнес‑логику: сегменты, ценность, каналы, отношения, доходы/издержки, ресурсы и партнёры.

Итог

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

Запись Упаковка бизнеса: от диагностики до метрик и артефактов первой появилась на Павел Шерер.

Команда учится делать не «лучше», а «правильнее». Развитие продукта замирает, потому что «в системе так не принято». Это и есть ДС-тюрьма: удобно сторожам, плохо заключённым.

Признаки проблемы

Если вы нашли у себя хотя бы 2-3 из указанных ниже симптомов, то эта статья для вас:

1. Унификация ради унификации. Понятно, почему нельзя, непонятно — зачем.
2. Любая, даже самая мелкая, фича сначала упирается в дизайн-систему. Маркетинговые лендинги-однодневки не создаются на скорую руку по гайдам, а вынуждены проходить полноценную верификацию.
3. Метрики и эксперименты застревают, потому что гипотезы ждут внедрения в ДС дольше, чем живёт бизнес-задача.
4. Часто звучит «в системе так не предусмотрено», и на этом обсуждение заканчивается.
5. Команда обходит систему втихаря, если ДС не помогает, а мешает. В итоге создаются костыли и подпольные клоны библиотек.
6. Медиана времени от «хочу» до «запустили» растёт месяц за месяцем. ДС начинают воспринимать не как инструмент, а как бюрократию.
7. Уходят лучшие практики: упор делается на контроль и одинаковость, а про доступность или производительность забывают.
8. Дизайнеры и разработчики начинают дублировать работу вне ДС, тратя двойные усилия.
9. Дизайн ради дизайна: решения принимаются для красоты системы, а не для пользы продукта.
10. Люди перестают воспринимать ДС как источник ценности: обновления видятся как «еще одна миграция».

Конечно, бывает по-разному. Например, для маленькой команды некоторые признаки «токсичности» могут быть нормой, а не проблемой, потому что ресурсов мало. В энтерпрайзе же признаки вроде «медианы времени до изменения UI» могут быть искажены внешними факторами (такими как compliance с регуляциями). Но в целом, это десяток чётких показателей того, что с ДС есть какие-то проблемы.

Корни проблемы

Чтобы понять, почему так происходит, давайте разберём типичные причины токсичности дизайн-систем.

Подмена цели

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

Решение: пересобрать цель ДС и зафиксировать её в понятной форме. Главный показатель — скорость и надёжность работы. Одинаковость интерфейсов должна быть лишь средством, а не самоцелью.

Ошибка уровня абстракции

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

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

Полицейская модель управления

Вместо поддержки Design Ops начинает работать как надзорный орган. Любое отклонение воспринимается как нарушение, решения проверяются по букве гайдлайна. Это убивает инициативу, рождает страх ошибиться и стимулирует команды обходить систему тайком.

Решение: перевести Design Ops в сервисную модель. Ввести сроки ответов, понятную поддержку и чёткую роль «помощников», а не «надзирателей».

Недостаток обратной связи

ДС-команда редко общается с продуктовой командой и разработчиками. В результате её решения оторваны от реальных задач и проблем пользователей.

Решение: наладить регулярные встречи, показывать новые компоненты до внедрения, собирать обратную связь через чаты и опросы.

Замороженные токены

Равно как и отсутствие версионности. Базовые цвета, шрифты и отступы застывают навсегда. Даже небольшое изменение превращается в длинную и болезненную миграцию, которая блокирует работу продукта. Из-за этого обновления откладываются месяцами, а интерфейсы устаревают.

Решение: ввести простую систему версий и сроков поддержки. Старые варианты объявлять «устаревающими» заранее, давать автоматические инструменты для перехода и выпускать обновления по расписанию.

Отсутствует экспериментальный контур

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

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

Недостаток прозрачности

Участники не понимают, кто и на основе каких критериев принимает решения о дизайн-системе, отклонении или принятии инициатив. Это рождает недоверие и ощущение произвола.

Решение: сделать процесс открытым. Публиковать заявки и критерии оценки, вести видимый статус инициатив.

Гейткипинг без SLA

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

Решение: ввести фиксированные сроки для рассмотрения (например, 3 дня), назначать ответственных для каждой инициативы.

Отсутствие приоритизации

В дизайн-систему пытаются внести всё подряд, не разделяя на must-have и nice-to-have. Это перегружает команду, размывает ценность и создаёт ощущение работы без реального результата.

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

Игнорирование локальных контекстов

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

Решение: предусматривать слой настроек под контексты. Разрешать локальные изменения через понятные механизмы, а не через подпольные костыли.

Отсутствие SLA и метрик самой ДС

Никто не замеряет, ускоряет ли система работу, снижает ли затраты и повышает ли качество. Без данных невозможно понять, приносит ли ДС пользу или только создаёт нагрузку. Всё происходит или «по ощущениям» или «по принуждению».

Решение: ввести набор простых показателей. Замерять их регулярно и менять процессы по результатам. Ниже — примеры таких показателей.

Метрики токсичности дизайн-системы

На самом деле, измерить эффективность ДС вообще не сложно. Вот вам несколько типовых метрик (важно понимать, что их нужно адаптировать и дополнять под реалии своей команды/процессов/продукта).

median time to ui change Среднее время (желательно медиана) до изменения UI. Работает, если есть какие-то исторические данные. Просто сравните показатель до внедрения ДС и после, чтобы понять, реально ли система ускоряет работу.

% blocked PR Процент запросов (например, product request), заблокированных аргументом «не соответствует ДС». Доля задач, которые останавливаются не по сути, а из-за формальных правил.

number of forks & overrides Количество (да и вообще наличие) форков от репозитория с ДС и локальных override’ов. Сколько команд вынуждены городить обходные решения вместо использования ядра.

adoption rate Какие продукты реально подключены к ядру ДС и используют его обновления, а какие живут на клон-сборках и по сути поддерживают собственные версии.

number of experiments Количество экспериментов по сравнению с прошлым периодом. Если гипотезы стали запускать реже — система мешает развитию. Тут могут быть и другие причины, поэтому на этот показатель нужно опираться осторожно.

time to review Среднее время на ревью и согласование изменений в ДС. Если этот процесс занимает недели, значит система тормозит.

contribution success rate Доля предложений в дизайн-систему, которые дошли до внедрения. Если большинство инициатив отбрасывается или зависает, то ДС становится барьером.

update lag Задержка между выпуском новой версии ядра ДС и фактическим обновлением продуктов. Большие лаги показывают, что миграции слишком болезненны.

a11y & performance coverage Процент компонентов, проверенных на доступность и производительность. Если метрика не растёт, ДС концентрируется на унификации, а не на качестве.

user satisfaction Удовлетворённость продуктовых команд работой с ДС (например, через регулярные опросы).

Если исторических данных нет, можно использовать альтернативы: опросы, журналы использования (например, в Figma Library Analytics можно анализировать использование компонентов за последний год).

Не доверяйте только одной метрике, делайте связки, кросс-чек. Если медиана времени растёт, но adoption высокий — проблема не в ДС, а в процессах (например, гейткипинг).

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

Один показатель (например, рост экспериментов) может быть из-за сезонного пика, а не из-за качества ДС. Комбинируйте с бизнес-метриками (ROI, time-to-market) для полной картины.

Итог

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

Запись Дизайн-система как тюрьма первой появилась на Павел Шерер.

Давайте разбираться. И копнём аж до начала прошлого века.

Исторический контекст

Gantt, 1910-1918

Когда ещё не было даже намёков на современный проджект-менеджмент, инженер Генри Гантт впервые рисует «Gantt charts» для Baltimore & Ohio RR и корабельных верфей. Простейшие полоски-задачи + календарная шкала оказываются чудом наглядности. Минобороны США нанимает Гантта, чтобы распланировать переброску корпуса во Францию. Так больше века назад рождаются первые серьёзные инструменты для управления проектами.

Brand Man, 1931

Спустя больше десяти лет Нил Макэлрой в Procter & Gamble требует выделить отдельную позицию «brand men», отвечающую за прибыль конкретного мыла, которым торговала компания. Именно этот шаг принято считать зарождением продакт-менеджмента (хотя в тот момент это была история больше про бренд, чем про продукт в его современном смысле).

Lean, 1940+

В 1940х Тайити Оно и инженеры Toyota собрали конвейер, который тянет детали «под заказ» вместо того, чтобы гнать их на склад: принцип Just-in-Time стал ядром Toyota Production System (TPS). Философия свелась к борьбе с любым «мусором» — лишними операциями, запасами, дефектами и простоями — и к непрерывному улучшению (кайдзен).

К 1978ому TPS оформилась в книгу Оно, а западный менеджмент получил словарь Lean и идею, что скорость достигается не сокращением сроков, а плавным потоком ценности.

CPM, 1957

Инженер Морган Уокер (DuPont) и математик Джеймс Келли (Remington Rand Univac) за два с небольшим года собирают алгоритм Critical Path Method: вычисляем цепочку задач с нулевым запасом, накладываем на неё график — и видим, где сгорают деньги. Первый пилот прошёл в DuPont летом 1957го, технология мгновенно улетела в строительство и оборонку.

PERT, 1958+

ВМС США (да-да, снова оборонка), разрабатывая ракету Polaris, создаёт PERT — предка большинства инструментов проектного управления. Program Evaluation and Review Technique (метод оценки и анализа программ) помогал определить последовательность задач, оценить время выполнения каждой и построить критический путь проекта. Родившееся как решение для военпрома, очень скоро PERT (как и CPM) перекочевали в строительные компании, где также требовалась чёткая и единая методология планирования.

PMI, 1969+

Пятеро энтузиастов регистрируют Project Management Institute в Пенсильвании. Спустя некоторое время им ещё предстоит формализовать профессию Project Manager (PjM), но тогда PMI только зарождается. Активную работу над стандартами они начнут позже, в 80ых. А уже в 1996ом выпустят первое издание PMBOK Guide и формально кристаллизуют те самые 9 (на тот момент) областей знаний.

Program Manager, 1984

В команде MS Excel появляется первая должность Program Manager (Джейб Блументаль): человек пишет 300-страничную спеку, общается с юзерами, торгуется с девелоперами и по сути владеет «что и зачем» продукта, оставляя «как» инженерам. Такой PM сидит в «триаде» вместе с Dev & Test и гонит фичи короткими релизами.

Почти оновременно Microsoft выпускает Microsoft Project 1.0 — дешёвый Gantt-конкурент для PC, который быстро приучает менеджеров к сетевому плану и критическому пути. Шаблон «Program Manager + внутренняя тулза для графиков» разлетится по всей индустрии и станет базой для современных Product/Program Management.

CMM, 1988+

Уортс Хамфри, ветеран IBM (в которой гигантские мэйнфрейм-проекты требовали железной дисциплины) оформляет свои наработки в идею Capability Maturity Model — пятиступенчатую «лестницу зрелости» процессов, родившую моду на метрики, peer-review и PM-офисы. Параллельно корпорация активно внедряет Integrated Product Development и к середине 1990-х уже учит тысячи инженеров единому языку рисков и базовых KPI проекта.

Итог: если Microsoft сделал PM «хозяином продукта», то IBM закрепила за PM роль «сторожа процесса и качества», а их сочетание и сформировало то самое гибридное понимание Project/Product/Program Management, которым мы с вами пользуемся сегодня.

Scrum, 1993+

В 1995ом на конференции OOPSLA Джефф Сазерленд и Кен Швабер презентуют Scrum. В нём закрепляются роли Scrum Master и Product Owner.

Это не «дата рождения» скрама, скорее дата его первой формализации. До этого он уже жил в коридорах Easel Corporation: Сазерленд, Скумниоталес и МакКенна за несколько лет до этого докрутили идеи Такаути и Нонаки, собрали первую скрам-команду и начали итеративно выпускать программные тулзы.

Стоит отметить, что роль Product Owner в оригинальном Scrum была скорее про ответственность за ценность продукта, чем за детальный бэклог, как это часто понимают сегодня.

Agile, 2001

Cемнадцать практиков (Кент Бек, Мартин Фаулер, Джим Хайсмит и другие), устав от тяжеловесных процессов в их компаниях, заперлись в лыжном домике в Юте. В результате такого заточения родился Agile Manifesto: четыре коротких ценности (люди и взаимодействия, работающий софт, сотрудничество с заказчиком, готовность к изменениям) и двенадцать принципов. Ключевая мысль: лучше непрерывно доставлять маленькие порции ценности и общаться вживую, чем тонуть в документах, планах и контрактах.

Манифест мгновенно поколебал иерархию «Project Manager — процесс — документация». Команды получили моральное право ставить ценность продукта выше сроков, а менеджеры — экспериментировать с ролями PM, PO, PjM.

Именно после Agile Manifesto взлетели Scrum-гайды, Kanban-доски и подходы Discovery/Delivery: теперь задача менеджера была в том, чтобы убрать препятствия и помочь команде быстро учиться на фидбэке, а не просто «выполнить план по Гантту».

Kanban, 2004-2007

Картонные канбан-карточки, которыми Toyota в 1950х синхронизировала поставки, в 2004ом перенёс в софт-разработку Дэвид Андерсон. Канбан-доска с колонками «To Do — Doing — Done» и жёстким лимитом параллельных задач дала командам прозрачный поток без ломки оргструктуры.

С 2007го метод разлетелся по Agile-сообществу: сроки и риски теперь выводят из статистики цикла, а роль проджекта смещается к Flow/Delivery Manager, который охраняет WIP-лимиты и lead-time. В итоге Kanban стал легковесной альтернативой спринтам и вписался даже в ML-пайплайны, где важнее стабильный поток, чем фиксированные итерации.

Inspired, 2008-2018

Но на этом история не заканчивается. В конце десятых Марти Каган публикует культовую книгу «Inspired». В ней Product Manager сравнивается с «мини-CEO» продукта и ставится выше Product Owner’а. Тысячи пятых точек мгновенно воспламеняются — и этого огня хватает, чтобы осветить путь нового подхода в Долине. Да так мощно, что переиздание выходит аж через 10 лет после первой версии книги.

SAFe, 2011

Организация Scaled Agile формализует фреймворк SAFe, где Product Manager управляет общим бэклогом, а PO — бэклогом команды. SAFe создаётся как альтернатива классическому скраму с его гиперсамостоятельностью отдельных команд и призван выстраивать и поддерживать зависимости в кросс-командных или кросс-платформенных продуктах.

AI & Data PM, 2020+

Появляются специализации AI Product Manager и Data Product Manager, акцентирующие владение данными, ML-моделями и этичной эксплуатацией искусственного интеллекта. Потихоньку они начинают вносить коррективы в устоявшиеся роли — и об этом мы тоже поговорим позже.

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

Пять школ управленческого Дао

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

Silicon Valley

В стартапах Кремниевой Долины PM задаёт стратегию, а PO её реализуют. Тут во всей красе расцветают идеи Кагана. Логика проста: рынок быстрый, а для быстрого рынка нужна единая визия (чтобы внутренние и связанные продукты не разорвало, как того хомячка от капли никотина).

PM: Формирует продуктовую стратегию и roadmap, основываясь на рынке и данных пользователей. Проводит discovery, определяет метрики и координирует нескольких PO. Решает, какие фичи войдут в продукт, а какие на помойку. Влияет на бюджет (но не управляет им).

PO: Детализирует бэклог, переводит стратегию в задачи. Впахивает с разработчиками, аналитикам и дизайнерами, обеспечивает выполнение спринтов. Приоритизирует задачи команды, решает, что готово для релиза.

PjM: Редко встречается, может координировать ресурсы или зависимости. Полномочия PjM здесь ограничены логистикой, в продукт он не лезет.

Чистый Scrum

Здесь PO — единственный владелец ценности внутри команды, мать, отец и мотивационная морковка. PM (если он вообще есть) остаётся вне проектных процессов. В скраме основная ставка на автономность и скорость.

PM: Если есть, собирает инсайты о рынке, проводит исследования, изредка — формирует стратегию. Влияет на приоритеты через рекомендации, но не вмешивается в дела команды и продукта.

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

PjM: Отсутствует, его функции выполняет Scrum Master.

SAFe

PM ведёт Agile Release Train (ART, огроменный поезд всех спринтов и зависимостей), а PO управляет одним небольшим вагончиком своей команды. Такая двухэтажная модель нужна, когда Agile раскатан на десятки людей и нужно общее PI-планирование (за которое тоже кто-то должен отвечать).

PM: Управляет program backlog (приоритизированный список фич для ART), задаёт стратегию, согласовывает её с бизнесом. Участвует в PI-планировании. Решает, какие фичи войдут в Program Increment, влияет на ресурсы.

PO: Детализирует бэклог команды, работает с разработчиками, обеспечивает выполнение задач в рамках ART. Приоритизирует задачи команды, определяет степень готовности фич.

PjM: Координирует зависимости между командами, следит за сроками PI. Контролирует риски и сроки, но не продуктовые решения.

PMI/Waterfall

В PMI роль Project Manager (PjM) старше всех: он отвечает за «срок-бюджет-скоуп» и регулярно докладывает заинтересованным сторонам. Продуктовые роли тут, по большей части, консультирующие.

PM: Определяет границы продукта, консультирует по требованиям, проводит исследования рынка. Влияет на требования, но подчиняется PjM.

PO: Обычно отсутствует или уточняет требования как аналитик.

PjM: Планирует этапы, распределяет ресурсы, контролирует риски, отчитывается перед steering committee.

FMCG

Компании типа Fast Moving Consumer Goods исторически больше про офлайн, поэтому PM здесь — владелец P&L (бабла, по факту) и бренда. PO часто отсутствует или входит в digital-подразделения как Digital PM, ведь основное IT-направление в таких компаниях — маркетинговое.

PM: Отвечает за стратегию бренда, маркетинг, ценообразование. В digital управляет цифровыми продуктами (например, loyalty apps или e-commerce). Шарит за стратегию, бюджеты и приоритеты digital-продуктов.

PO: Детализирует бэклог для цифровых продуктов, работает с командами разработки. Приоритизирует задачи digital-продукта в рамках стратегии PM.

PjM: Управляет проектами (например, запуск кампаний), координирует ресурсы. Контролирует сроки, но не стратегию.

Не всё так просто

Как я уже писал, роли миксуются. Где-то это осознанное решение, продиктованное продуктовыми, рыночными и бизнес-реалиями. А где-то PO и PM перепутаны просто по тупости и незнанию. Вот вам парочка примеров, когда классические подходы работают не совсем так, как были задуманы:

• Когда у вас двойной трек discovery & delivery, то даже при связке «PM выше PO» стратегия и тактика бегут параллельно. PM генерит гипотезы, PO быстро проверяет их с командой и говорят PM, куда генерить дальше.
• Матричные компании типа SAP или Siemens часто держат PM и PjM на одном уровне, решая спорные вопросы коллегиально. Это заложено в саму суть их оргструктуры.
• В банках, фарме и подобных направлениях регуляция и специфика отрасли толкает PjM наверх даже при Agile: сроки релизов настолько жёстко привязаны к аудиту и сертификации, что визионерство тихонечко курит в сторонке.

Как меняют рынок AI PM & Data PM

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

Общее проникновении AI заставляет менеджеров организовывать чёткую петлю обратной связи модели: без доменной экспертизы продукта ИИ-агенты учатся крайне неффективно и не приносят столько прибыли, сколько могли бы. McKinsey в своём недавнем отчёте указали, что AI PM должны развивать навыки работы с low-code платформами и агентскими фреймворками. Без этого не получится координировать сложные AI-системы и ускорять продуктовые циклы.

Но работа с готовыми моделями ещё не всё. Нужно, чтобы кто-то курировал сквозной жизненный цикл датасета и культуру «data-as-a-product»: качество схем, метаданные, соблюдение privacy-ограничений и прочее. Так потихоньку рождается роль Data Product Manager: человека, без которого консистентность данных (и, как следствие, всего остального) фактически недостижима.

Так что если вы снова запутались, расслабьтесь: дальше будет только хуже.

Пара слов в защиту здравого смысла

Но давайте вернёмся к знакомым PO с PM и PjM. Как быть-то? Кому верить, какой школе? А никакой. Верьте реалиям бизнеса/продукта и здравому смыслу.

Считайте команды. Если у вас одна кросс-функциональная — один человек легко совместит роли PM и PO. Три-семь команд? PM ставьте на стратегию, PO — в каждую команду. Контракт с фиксированным объёмом и датой? Вам не нужны визионеры, вам нужен сильный PjM.

Давайте власть тому, кто держит метрику. Если PO отвечает за NPS, он должен иметь право отменить любой фич-реквест. Если квартальная премия PM зависит от LTV клиента, странно не давать ему на это влиять.

Забейте на регалии. Сначала обязанности и метрики, и только потом титулы. То, что должен делать человек — намного важнее того, как называется его роль в оргструктуре.

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

• PM: Шарит за экономику, стратегию, продуктовые границы и визионирует как не в себя.
• PO: Меняет приоритет без бюрократии, раскатывает релизы, выстраивает коммуникации.
• PjM: Парится о сроках и процессах, подсвечивает риски и организует всё, что ещё не организованно.

Итого

Я не рассказал про тьму аспектов. Про культурные различия (США, Европа, СНГ, Азия), про всякие LeSS, Prince2 и прочее. Но от этого суть статьи не меняется.

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

Запись PO, PM, PjM: кто такие и при чём тут мыло, ракеты и застройщики первой появилась на Павел Шерер.