Приведи пример документации которую создавал

Приведи пример документации которую создавал

Как BA я создавал разные типы документации. Приведу реальный пример: PRD (Product Requirements Document) для мобильного приложения доставки.

Контекст

Стартап хочет создать приложение для заказа еды и доставки (как Яндекс.Еда или Uber Eats). Я (BA) должен написать полное описание требований для разработчиков и дизайнеров.

---

# ДОКУМЕНТ: PRD — Приложение "FoodHero"

1. ОБЗОР ПРОДУКТА

Что это?

Мобильное приложение (iOS и Android) для заказа еды с доставкой. Пользователь выбирает ресторан → выбирает блюда → платит → получает доставку.

Целевая аудитория

• Основная: люди 18-40 лет, живущие в городе, заняты работой
• Вторичная: студенты, офисные сотрудники
• География: Москва (первая фаза), потом СПб, Казань

Размер рынка и потенциал

Москва: 1.5M людей в целевой аудитории
Если 5% будут пользователями: 75K пользователей
Если 2 заказа в месяц на пользователя: 150K заказов
Средний чек: 500 руб
Ревенью (если 15% комиссия): 11.25M руб/месяц

Конкуренция

• Яндекс.Еда (доминирует, 40% рынка)
• Uber Eats (25%)
• 2GIS (10%)
• Маленькие локальные приложения (25%)

Наше преимущество: быстрее доставляет в соседних районах (локальный фокус), дешевле комиссия для ресторанов (10% vs 15-20%)

---

2. ОСНОВНЫЕ ФУНКЦИИ (MVP)

2.1 Аутентификация

Регистрация

Пользователь может зарегистрироваться через:
- Номер телефона (SMS-код)
- Email + пароль
- Google/Apple Sign-In

Обязательные поля:
- Имя
- Номер телефона
- Адрес доставки (с автодополнением)

Опциональные:
- Фото профиля
- Дата рождения

Вход

Для зарегистрированного пользователя:
- Номер телефона + SMS-код
- Email + пароль
- Биометрия (Face ID, Touch ID)

Для гостей:
- Могут смотреть рестораны, но не заказывать
- После добавления в корзину → предложить зарегистрироваться

2.2 Просмотр ресторанов

Главный экран

Структура:
1. Поиск (Search bar вверху)
2. Категории: All, Пицца, Суши, Блюда, Напитки (горизонтальный скрол)
3. Список ресторанов:
   - Фото (1 большое)
   - Название
   - Рейтинг (4.5 ⭐️, 120 отзывов)
   - Время доставки (45 мин)
   - Стоимость доставки (бесплатно, если > 500)
   - Статус (Open, Closed, Delivery only)

При прокрутке вниз → загрузить ещё ресторанов (бесконечный скрол)

Поиск

Когда пользователь вводит в поиск:
- Real-time подсказки (рестораны по названию)
- Фильтры: категория, рейтинг, время доставки
- История поиска (сохранить последние 10)

Профиль ресторана

При клике на ресторан открывается:
1. Фото ресторана (большое, свайпаемое)
2. Название, рейтинг, адрес
3. Часы работы
4. Минимальный заказ (если есть)
5. Стоимость доставки
6. Меню (категории):
   - Салаты
   - Основное
   - Напитки
   - Десерты
   
7. Каждое блюдо:
   - Фото
   - Название
   - Описание (ингредиенты, вес)
   - Цена
   - Кнопка "+ Add" (добавить в корзину)

2.3 Корзина и оформление заказа

Корзина

Показывает:
- Выбранные блюда
- Количество каждого
- Цена каждого
- Кнопка удаления для каждого
- Промежуточная сумма
- Комиссия приложения (если > 3%)
- Сумма доставки
- ИТОГО
- Кнопка "Checkout"

Оформление заказа

1. Проверка адреса доставки
   - Показать на карте
   - Возможность изменить
   - Валидация (адрес в зоне доставки?)

2. Выбор способа доставки
   - Стандартная (45-60 мин)
   - Быстрая (20-30 мин) — дороже
   - Когда нужна (выбрать время, от 20 мин)

3. Комментарий к заказу
   - "Текст поля: Например: без лука, не сладко"

4. Способ оплаты
   - Карта (сохранённая или новая)
   - Apple Pay / Google Pay
   - Наличные (если ресторан предоставляет)
   - Кошелёк приложения (если баланс достаточно)

5. Кнопка "Place Order"
   - После клика → экран "Order Confirmed"

2.4 Отслеживание заказа

Статусы заказа

1. Confirmed (заказ подтверждён рестораном)
2. Preparing (готовят)
3. Ready (готов, ждёт курьера)
4. On the way (доставляется)
5. Delivered (доставлен)
6. Cancelled (отменён)

Для каждого статуса показывать:
- Примерное время до доставки
- На карте (если On the way): позиция курьера (в реальном времени)
- Номер телефона курьера (для связи)
- Кнопка "Track on map"

История заказов

Полный список всех заказов:
- Дата и время
- Ресторан
- Сумма
- Статус
- Кнопка "Reorder" (повторить заказ)

2.5 Профиль пользователя

1. Личные данные
   - Фото
   - Имя
   - Email
   - Номер телефона
   - Редактирование

2. Адреса доставки
   - Дом (по умолчанию)
   - Работа
   - Другое (+ кнопка добавить)
   - Удаление адреса

3. Способы оплаты
   - Сохранённые карты
   - Добавить новую
   - Удалить карту

4. Избранные рестораны
   - Список рестораны, которые пользователь лайкнул

5. Настройки
   - Уведомления (push, email)
   - Язык (RU/EN)
   - Версия приложения
   - О приложении
   - Выход из профиля

---

3. ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ

3.1 Платформы

• iOS 13+ (iPhone)
• Android 8+ (Kotlin + Android Studio)
• Оба приложения должны иметь фичность паритет (одинаковые фичи)

3.2 Backend API

Базовый URL: api.foodhero.ru/v1

Основные endpoints:

АУТЕНТИФИКАЦИЯ
POST /auth/register
POST /auth/login
POST /auth/verify-code
GET /auth/me
POST /auth/logout

РЕСТОРАНЫ
GET /restaurants (список)
GET /restaurants/{id} (детали)
GET /restaurants/{id}/menu (меню)

ПОИСК
GET /search?query=pizza (поиск)

КЕРЗИНА И ЗАКАЗЫ
POST /orders (создать заказ)
GET /orders/{id} (детали заказа)
GET /orders (мои заказы)
POST /orders/{id}/cancel (отменить)
GET /orders/{id}/track (отслеживание)

ПРОФИЛЬ
GET /profile
PUT /profile (обновить)
GET /profile/addresses
POST /profile/addresses
DELETE /profile/addresses/{id}

3.3 База данных

Основные таблицы:

- users (пользователи)
- restaurants (рестораны)
- menu_items (блюда)
- orders (заказы)
- order_items (блюда в заказе)
- payments (платежи)
- reviews (отзывы)
- addresses (адреса доставки)

3.4 Интеграции

- Google Maps API (карта, геокодирование, маршруты)
- Twilio (SMS для верификации кода)
- Stripe (обработка платежей)
- Firebase Cloud Messaging (push-уведомления)
- Sentry (мониторинг ошибок)

---

4. ПОКАЗАТЕЛИ УСПЕХА (KPI)

1. User Acquisition
   - Целевой показатель: 1000 пользователей в месяц (месяц 1-3)
   - Метрика: Total Signups

2. Engagement
   - DAU / MAU (Daily/Monthly Active Users) > 30%
   - Retention на 7-й день > 25%
   - Средний заказов на пользователя > 1 в месяц

3. Revenue
   - ARPU (Average Revenue Per User) > 100 руб/месяц
   - Средний заказ > 400 руб

4. Quality
   - App rating > 4.2 в App Store
   - Crash rate < 0.5%
   - API response time < 500ms

5. Satisfaction
   - NPS (Net Promoter Score) > 40
   - Delivery success rate > 98%

---

5. ROADMAP

Phase 1 (MVP, 2 месяца)

- Регистрация и вход
- Просмотр ресторанов
- Заказ
- Отслеживание
- Профиль

Phase 2 (Месяц 3, улучшения)

- Отзывы и рейтинги
- Программа лояльности (бонусы за заказы)
- Избранные рестораны
- Расширение на СПб

Phase 3 (Месяц 4-5)

- Подписка FoodHero+ (бесплатная доставка)
- Рекомендации (ML based)
- Забронировать столик в ресторане

---

6. РИСКИ И ОТКРЫТЫЕ ВОПРОСЫ

Риски

1. Логистика: сложно управлять курьерами
   Решение: начать с 1 логистического партнёра

2. Конкуренция: Яндекс снизит цены
   Решение: фокус на локальных ресторанах

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

Открытые вопросы

1. Как мы будем привлекать рестораны? (sales активность)
2. Сколько курьеров нужно в день 1? (логистика)
3. Какой стартовый бюджет маркетинга? (финансы)

---

7. ЛАЙAУТ И СКРИНШОТЫ

[Figma ссылка на дизайн]
https://www.figma.com/file/...

Там содержится:
- Все экраны приложения
- Все переходы и взаимодействия
- Стиль-гайд (цвета, шрифты, иконки)
- Компоненты для разработчиков

---

8. ИСПОЛЬЗОВАНИЕ

Для дизайнеров: Этот документ + Figma для детализации

Для backend разработчиков:

• API endpoints из раздела 3.2
• Database schema из раздела 3.3
• Отдельный документ с полной спецификацией API

Для mobile разработчиков:

• Экран-по-экрану из Figma
• Flow диаграммы

Для PM: KPI и Roadmap для отслеживания прогресса

Для CEO: Executive Summary (выше) + KPI

---

9. ВЕРСИОНИРОВАНИЕ

Версия 1.0 — создано 01.01.2025
Автор: Ivan Petrov (BA)
Одобрено: CEO, CTO

После изменений:
Версия 1.1 — 15.01.2025
- Добавлена фичу "Сохранённые карты"
- Изменён API endpoint для поиска

---

Почему эта документация хороша?

1. Структурирована

• Обзор → Функции → Технические требования → KPI → Roadmap
• Легко найти информацию

2. Полная

• Всё, что нужно для разработки
• Нет неопределённостей

3. Связана с другими документами

• Ссылки на Figma (дизайн)
• Ссылки на спецификацию API
• Всё в одной экосистеме

4. Живой документ

• В Confluence, версионирование
• История изменений
• Комментарии от команды

5. Ориентирована на разные роли

• Дизайнер читает Функции + Figma
• Разработчик читает Технические требования
• CEO смотрит KPI и Roadmap