Черновик PRD
В бенчмарке моделей эту задачу сейчас лучше всех решают: 1. Claude Opus 4.8 — 9,8 · 2. Claude Fable 5 — 9,8 · 3. GLM 5.3 — 9,6
Ты — продуктовый менеджер. Помоги собрать черновик PRD — документа, с которого команда начнёт работу над фичей.
Входные данные: — продукт: [вставьте описание продукта]; — проблема: [вставьте проблему пользователей или бизнеса]; — сегмент: [вставьте сегмент пользователей]; — решение: [вставьте описание фичи или решения]; — метрики: [вставьте метрики успеха, если команда их зафиксировала].
Собери черновик по структуре:
- Проблема — что и у кого ломается, почему это стоит решать.
- Цели — чего достигаем этой фичей.
- Метрики успеха — только те, что даны во входных данных.
- Решение — как фича работает со стороны пользователя.
- Ограничения — технические, правовые и ресурсные рамки, которые видны из данных.
- Риски — что может пойти не так.
- Open questions — вопросы, на которые нужно ответить до оценки.
Ограничения: — не выдумывай метрики, сроки и бюджеты: если метрика не зафиксирована во входных данных, вынеси её в open questions; — если сроков нет, напиши «срок не определён» вместо даты; — помечай, какие разделы написаны на основе интерпретации, а не факта; — если данных для раздела не хватает, оставь его с пометкой «нужно дозаполнить», а не заполняй догадками.
Пример данных
Данные вымышлены. Замени их информацией о своей задаче.
Продукт: веб-сервис бронирования переговорных в коворкингах. Проблема: операторы коворкингов каждую неделю вручную создают одни и те же брони — постоянные встречи компаний занимают одну и ту же переговорную. Сегмент: операторы коворкингов на 50–300 рабочих мест. Решение: повторяющиеся брони. При создании брони оператор отмечает «повторять еженедельно», выбирает день недели, время и дату окончания серии. Система создаёт брони сразу на весь период, каждую бронь серии можно отменить отдельно. Метрики, которые зафиксировала команда: среднее время создания серии броней — не больше 2 минут; доля ручных повторных броней за неделю — снизить на 30%; доля операторов, создавших хотя бы одну серию, — 40% через два месяца после релиза.
Пример ответа
Один из возможных результатов. Проверь факты и адаптируй текст перед использованием.
PRD: повторяющиеся брони переговорных (черновик)
Проблема
Операторы коворкингов каждую неделю вручную создают одни и те же брони: постоянные встречи компаний занимают одну и ту же переговорную. Это факт из брифа; сколько времени уходит на ручное создание, в данных не измерено.
Цели
- Убрать ручное повторение одинаковых броней из недельной работы оператора.
- Перевести серийные брони постоянных встреч в систему, чтобы расписание не зависело от памяти оператора.
Метрики успеха
Только зафиксированные командой, других в документе нет:
- среднее время создания серии броней — не больше 2 минут;
- доля ручных повторных броней за неделю — снизить на 30%;
- доля операторов, создавших хотя бы одну серию, — 40% через два месяца после релиза.
Решение
При создании брони оператор отмечает «повторять еженедельно», выбирает день недели, время и дату окончания серии. Система создаёт брони сразу на весь период. Каждую бронь серии можно отменить отдельно.
Ограничения
Из брифа видна только рамка сегмента: операторы коворкингов на 50–300 рабочих мест. Технические, правовые и ресурсные ограничения в данных не описаны — раздел нужно дозаполнить с командой разработки. Срок релиза не определён.
Риски
- Отдельная отмена брони внутри серии может запутать расписание: как серия выглядит для клиентов коворкинга после отмены, в брифе не сказано — интерпретация.
- Ошибка при создании серии тиражируется на весь период: одна неточность — десятки броней, которые нужно снимать по одной.
- Доля ручных повторных броней может снижаться не от фичи, а по сезонным причинам: базовые значения метрик до релиза в брифе не зафиксированы.
Open questions
- Что происходит с остальными бронями серии, когда одну отменяют?
- Есть ли предел длительности серии и что с бронями за его границей?
- Как серия взаимодействует с разовыми бронями на тот же слот?
- Какие базовые значения метрик зафиксированы до релиза, чтобы измерить снижение на 30%?
Проверьте факты
- Сверить метрики с формулировками команды: в документе только три метрики из брифа.
- Срока релиза в документе нет намеренно — не добавляй дату без решения команды.
- Проверить описание решения с разработкой: поведение серии при отмене одной брони не специфицировано.
- Убедиться, что базовые значения метрик существуют, иначе цель «снизить на 30%» не измерима.
Из главы: PRD и документация