PRD для мобильного приложения: что описать до разработки

PRD и техническое задание — не одно и то же

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

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

Что должно быть на первой странице

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

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

Простой шаблон PRD

Как описывать функции простым языком

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

Такой способ сразу показывает скрытую работу. Функция редко бывает только экраном. За ней могут стоять серверная логика, права доступа, уведомления, ошибки, события аналитики, админ-панель и поддержка. Если PRD это показывает, оценка становится спокойнее.

Что важно именно для мобильного приложения

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

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

Сколько деталей достаточно

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

В проектах Appfyl понятный PRD помогает определить уровень первой версии. Для российского рынка мы обычно используем такие плановые диапазоны: MVP начинается примерно от 1-1,5 млн рублей, средний проект — от 1,5-3,5 млн рублей, крупный продукт с несколькими ролями, интеграциями или сложными рисками — от 3,5-6 млн рублей.

Кто должен писать PRD

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

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

Частые ошибки

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

Третья ошибка — прятать неопределенность. Открытые вопросы нормальны, если они видны: “платежный сервис не выбран”, “интеграция с CRM зависит от API клиента”, “медицинский сценарий нужно проверить с юристом”, “режим без интернета можно оставить на второй этап”. Видимый риск можно оценить. Скрытый риск обычно превращается в переделку.

Как мы используем это в Appfyl

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

Если уже есть прототип, черновой дизайн или старое приложение, PRD может быть короче, но точнее. Мы сравниваем то, что есть, с тем, что должно измениться, и отдельно отмечаем дизайн, переработку, перенос данных, тестирование и публикацию.

Посмотрите, как Appfyl превращает объем работ в запущенные продукты. Смотреть кейсы Appfyl.

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