PRD: требования к продукту, как писать

PRD (product requirements document, документ требований к продукту) — это документ, который описывает, что за продукт или функцию команда собирается создать и, главное, зачем. PRD фиксирует проблему пользователя, цель, требования к решению и метрики успеха — то есть отвечает на вопросы «что мы строим» и «почему», оставляя вопрос «как именно реализовать» дизайну и разработке. Его пишет продакт-менеджер, чтобы вся команда одинаково понимала задачу до начала работы. Ключевое отличие PRD от классического технического задания в том, что PRD фокусируется на проблеме и цели, а не на детальном техническом описании решения, — он оставляет команде свободу найти лучший способ.

Что такое PRD и зачем он нужен

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

Но PRD — не про бюрократию. Его ценность не в толщине, а в ясности мышления: пока вы формулируете проблему, цель и границы, вы сами обнаруживаете дыры в собственной идее. Часто самый полезный эффект PRD — это вопросы, которые всплывают, пока вы его пишете.

Хороший PRD рождается из product discovery: сначала проверяют, что задачу стоит решать, и только потом описывают, что именно строить. PRD без предшествующего исследования рискует красиво зафиксировать никому не нужную идею.

Из чего состоит PRD

Жёсткого стандарта нет, но рабочий PRD обычно включает такие разделы:

• •Проблема и контекст. Какую проблему пользователя или бизнеса мы решаем и почему сейчас. Это фундамент — без ясной проблемы всё остальное повисает.
• •Цели и метрики успеха. Чего хотим достичь и как поймём, что получилось. Конкретные измеримые показатели, а не «улучшить опыт».
• •Целевая аудитория. Для кого это. Роли, сегменты, сценарии использования.
• •Требования. Что продукт должен делать. Обычно в виде пользовательских историй или списка функций, приоритизированных по важности.
• •Границы (scope). Что входит в работу и, отдельно, что сознательно НЕ входит. Второе не менее важно.
• •Открытые вопросы и риски. Что ещё не решено, какие есть неизвестные и допущения.
• •Метрики и аналитика. Как будем измерять эффект после запуска.

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

Метрики успеха: как поймём, что получилось

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

Метрики должны быть заданы заранее и конкретно. Плохо: «повысить удобство». Хорошо: «увеличить долю пользователей, завершивших онбординг, с 30% до 45% за два месяца». Такая формулировка проверяема: через два месяца вы однозначно скажете, сработало или нет.

Хорошая практика — привязать метрику к ключевому показателю продукта. Если функция не влияет ни на одну значимую метрику, это повод задуматься, стоит ли её вообще делать.

Чем PRD отличается от ТЗ

Классическое техническое задание (ТЗ) и PRD часто путают, но у них разная философия:

• •ТЗ отвечает на вопрос «как». Детально описывает техническую реализацию: что и каким образом должно быть сделано, вплоть до конкретных решений. Оставляет исполнителю минимум свободы. Это подход инженерный и договорной — по ТЗ принимают работу.
• •PRD отвечает на вопрос «что и зачем». Описывает проблему, цель и требования к результату, но оставляет способ реализации команде. Это подход продуктовый и гибкий.

Разница не косметическая. ТЗ уместно там, где решение известно заранее и важна точность исполнения (например, подрядчик делает по заказу). PRD уместен там, где лучшее решение ещё предстоит найти, и жёстко зашивать его вредно — команда, ближе всех знающая технологии, часто предложит вариант лучше первоначального.

Разница между ТЗ и PRD — это разница между «сделай ровно так» и «реши эту проблему». Первое подходит, когда решение известно. Второе — когда вы доверяете команде найти его лучше вас.

Как писать PRD: пошагово

Типичные ошибки

• •Решение вместо проблемы. PRD начинается с «сделаем такую-то фичу», а проблема не сформулирована. Тогда никто не может оспорить идею по существу.
• •Нет метрик успеха. Описали, что строить, но не то, как измерить результат. Запустили и не знаете, удалось ли.
• •PRD как ТЗ. Продакт расписывает техническую реализацию до кнопки, лишая команду свободы найти решение лучше.
• •Роман на 40 страниц. Чем толще PRD, тем меньше вероятность, что его прочтут. Ценность в ясности, а не в объёме.
• •Границы не заданы. Не написано, что НЕ входит, — и объём тихо расползается по ходу работы.
• •Документ-памятник. Написали, согласовали, забыли. Реальность ушла вперёд, а PRD висит устаревший, и им перестают пользоваться.

Итог

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