ТЗ на мобильное приложение: чек-лист, который защищает сроки и запуск в магазине

Почему запуск сдвигается

Проверка магазина занимает время, и её результат не всегда предсказуем. Модератор смотрит, работает ли приложение, есть ли политика конфиденциальности и соответствует ли описание функциям. Если чего-то нет, приложение возвращают на доработку, и цикл повторяется.

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

Если вы не уверены, с чего начать, возьмите один экран, который клиент открывает первым, и опишите его вместе с действием, которое должно произойти. Такой текст подрядчик поймёт без дополнительных встреч. Чем короче описание, тем быстрее подрядчик его уточнит. Что обычно оформляют на заказчика, разобрано в статье о доступах к сайту и боту.

Сценарий и аудитория

Первые три пункта отвечают на вопрос, зачем приложение нужно:

- главный сценарий одной фразой, например «клиент выбирает услугу и оплачивает запись»; - кто пользуется: клиенты, сотрудники, водители; - как часто возвращаются: каждый день, раз в неделю или раз в месяц.

Частота возвратов определяет форму. Если клиент приходит раз в месяц, приложение может оказаться лишним, и тогда ТЗ будет про Mini App. Если пользователей несколько ролей, понадобится отдельный кабинет или второе приложение. Эти решения принимают до разработки, потому что от них зависят состав и срок.

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

Платформы, оплата и карты

Пункты с четвёртого по шестой определяют техническую часть:

- платформы: Android, iOS или Mini App; если аудитория на одной платформе, вторую можно отложить; - оплата и выплаты: какой банк, кто получает деньги, нужны ли выплаты исполнителям; - карты и геопозиция: нужны ли адреса, маршруты и работа в фоне.

Оплата требует согласования с банком и юристом. Порядок возвратов, чеки и выплаты лучше записать подробно, потому что изменить их после разработки дорого. Геопозиция влияет и на разрешения, которые приложение запрашивает у телефона, а магазины проверяют их внимательно.

Для оплаты отметьте в ТЗ, как возвраты и отмены влияют на деньги клиента и исполнителя. Это вопрос к банку и юристу, к экрану он не относится, и ответ нужен до проектирования сервера.

Интеграции и админка

Седьмой и восьмой пункты касаются связей с другими системами и людей, которые управляют приложением.

Интеграции: CRM, 1С и внешние сервисы. Для каждой системы укажите, кто даёт доступ и в каком виде. Без доступа подрядчик не может оценить срок, и цена потом пересматривается.

То же касается админки: укажите, какие отчёты нужны в первый месяц, а какие могут подождать. Без списка отчётов подрядчик не сможет рассчитать объём работ. Подробнее о связке с учётными системами в статье про интеграцию с CRM и 1С.

Админка: кто и что делает. Для сотрудников нужен экран заказов, смены статусов и обращений. Если админки нет, команда работает в таблицах рядом с приложением. Поэтому админку записывают в ТЗ даже в первой версии.

Уведомления и магазины

Девятый и десятый пункты: о чём и когда приходят уведомления и в какие магазины публикуем.

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

Магазины: RuStore, App Store и Google Play. Проверка в каждом идёт по своим правилам, и это время в плане нужно заложить отдельно. Приложения «Везучей Трёшки» опубликованы в RuStore, поэтому магазин в ТЗ указывают прямо, сразу.

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

Аккаунты, данные и тестовый доступ

Одиннадцатый и двенадцатый пункты кажутся формальными, но именно из-за них приложение сложнее всего передать.

Срок хранения и порядок удаления данных тоже запишите в ТЗ, иначе вопрос всплывёт уже после запуска. Отдельно запишите тестовый доступ: логин и тестовый аккаунт, с которыми модератор магазина откроет приложение.

Ещё одна деталь: тестовый аккаунт должен работать без ручных действий подрядчика. Если для входа нужно звонить разработчику, модератор не сможет проверить приложение сам, и проверка затянется.

Когда хватит самому, когда звать студию

Чек-лист можно заполнить самому, и это хорошая подготовка к разговору с подрядчиком. Он увидит, что вы понимаете задачу, и ответит с планом и ценой.

Разработка первой версии с публикацией в один магазин делается за 4–6 недель и стоит от 500 000 ₽. Точный состав и цену фиксируем в договоре. Подробности на странице мобильного приложения.

Цены по рынку и чек-лист собраны в бесплатном гайде «Мобильное приложение для бизнеса» в нашем боте.