Постановка продуктовой задачи и PRD

Зачем нужна явная постановка задачи

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

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

Сильный problem statement

Ядро документа — problem statement: короткое описание проблемы в терминах пользователя и бизнеса, без зашитого решения. Хороший problem statement отвечает на четыре вопроса:

• Кто сталкивается с проблемой (сегмент, а не «все»).
• Что именно не получается и в какой ситуации.
• Почему это важно — какая боль у пользователя и какая цена у бизнеса.
• Почему сейчас — что изменилось или какой триггер делает задачу приоритетной.

Признак того, что в постановке спрятано решение: фраза вида «нам нужна кнопка X». Это уже ответ. Вернитесь на шаг назад — какую работу пользователя кнопка должна продвинуть (см. JTBD).

Цель и метрики успеха

Задача без измеримого критерия успеха недоказуема: любой результат можно объявить победой задним числом. Поэтому в PRD заранее фиксируют:

• Цель — какое поведение или результат мы хотим изменить.
• Метрику успеха и порог — что и насколько должно сдвинуться (по возможности — действенная метрика, а не vanity).
• Контр-метрику (guardrail) — что не должно деградировать ради этой цели.

Метрики связывают PRD с продуктовой аналитикой: формулировку успеха удобно проверять экспериментом, а сами показатели брать из набора продуктовых метрик.

Scope, не-цели и рабочая структура PRD

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

1. Контекст и problem statement — проблема, сегмент, почему сейчас.
2. Цель и метрики успеха — критерий и guardrail.
3. Scope и не-цели — что входит и что осознанно нет.
4. Требования / пользовательские сценарии — что система должна позволять сделать.
5. Открытые вопросы и риски — что ещё не решено и что проверяем.

Хороший PRD умещается на одну–две страницы. Длина — не показатель качества; ясная постановка ценнее исчерпывающей.

Шаблон и частые анти-паттерны

Простой шаблон, который можно скопировать: «Проблема: [кто] в ситуации [когда] не может [что], из-за чего [боль/цена]. Почему сейчас: [триггер]. Цель: [желаемое изменение]. Успех: [метрика] вырастет на [порог], при этом [guardrail] не упадёт. В scope: […]. Не-цели: […]. Открытые вопросы: […]».

• Решение вместо проблемы. PRD начинается с описания экрана, а не задачи.
• Нет метрики успеха. Непонятно, как отличить успех от провала.
• Размытый сегмент. «Для всех пользователей» обычно значит «ни для кого конкретно».
• Документ-кирпич. Чем длиннее PRD, тем меньше его читают; важна не полнота, а однозначность.

Частые вопросы

Чем problem statement отличается от описания фичи?

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

Насколько подробным должен быть PRD?

Достаточно подробным, чтобы команда поняла задачу однозначно, и не более. Обычно это одна–две страницы: проблема, цель и метрика успеха, scope и не-цели, ключевые сценарии и открытые вопросы. Объём не равен качеству — ценится ясность.

Нужен ли PRD в маленькой команде?

Формат может быть лёгким, но сама постановка нужна всегда. Даже несколько строк с проблемой, сегментом и критерием успеха резко снижают риск построить не то. В маленькой команде PRD экономит самый дорогой ресурс — время на переделку.