В начале своего истока по разработке мобильного приложения для вашего бизнеса, зачастую IT-компании запрашивают бриф или ТЗ (о техническом задании мы уже рассказали в этой статье). Существует много споров о необходимости и даже нужности создания брифа на создание мобильного приложения. В любом случае – информирован, значит вооружен. Поэтому мы не можем пройти эту тему мимо и поделимся важной и нужной информацией, как обещали.

Итак, что же такое Бриф? Зачастую под этим словом подразумевают краткий документ, изложенный в письменной форме, который описывает основные параметры будущего проекта.

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

Бриф, достаточно усредненный документ с вопросами, но формулировку и креативность составления выбирает и создает сама компания-разработчик. Однако, насколько бы не был полезен и даже интересно составлен бриф, клиенту, по обычаю, лень его заполнять. Заказчик считает, что проще встретиться лично или созвониться и задать свои вопросы разработчикам. Безусловно, никто не будет оспаривать значимость личного интервьюирования, но и заполнение брифа тоже несет в себе важную роль. Бриф позволяет привести в порядок мысли и идеи заказчика, а разработчикам, при изучении брифа, подготовить аргументированные ответы с цифрами (дедлайн, бюджет и т.д.).

Про значимость брифа уже карты открыты. Теперь про сами вопросы. В самые типовые брифы по созданию мобильного приложения обязательно входят следующие части:

• Контактная информация

- Наименование компании (возможно описание ее сферы деятельности кратко).

- ФИО контактного менеджера, с кем будет производиться контакт по разработке мобильного приложения. Также в данном случае подразумевается кто непосредственно составляет бриф.

- Ваши контактные данные (те актуальные каналы связи, по которым будет производиться коммуникация по проекту).

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

- Функциональное приложение.

- Приложение для внутреннего сервиса.

- Игра.

- Другое (иногда бывают отклонения, поэтому при составлении брифа всегда есть дополнительное поле, которое можно заполнить самостоятельно, а не просто поставить галочку напротив необходимого).

• Типы платформ

- Android

- iOS

• Типы устройств

- Смартфоны.

- Планшеты.

- Смарт-часы.

При выборе одновременно двух платформ, желательно указывать, будет ли разрабатываться параллельно, либо сначала создается мобильное приложение на одной платформе (и на какой именно), а потом на второй. И какой промежуток времени подразумевается между двумя разработками.

Как правило, вопросы про платформы и типы устройств заказчика не ставят в тупик, ведь это способ монетизации и выгоды, которую в идеале клиент просчитал. Другой вопрос – имеется ли серверная часть. Приложениям чуть сложнее калькулятора необходимо откуда-то брать информацию и далеко не все, желающие заказать разработку в курсе, что создание серверной части может составлять до 90% работы над проектом. Именно отсюда и повышенные бюджеты на разработку мобильного приложения. Также следует понимать и обговаривать, как будут обновляться данные приложения, возможно это будет производиться вручную, а не через серверную часть.

Вопрос про серверную часть зачастую отсутствует, ведь это техническая часть, которая обсуждается уже после общих вопросов, но знать о нем важно и нужно.

• Дополнительный функционал

- Наличие уведомлений (пуш-уведомления или/и смс).

- Наличие личного кабинета у пользователя.

- Будет ли авторизация через соц.сети и т.д.

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

• Сроки и бюджет

- Желаемый дедлайн по разработке мобильного приложения со стороны заказчика.

- Планируемый бюджет.

• Дополнительно

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

- Также здесь можно указать примеры приложений, которые нравятся заказчику, чтобы разработчики понимали на что ориентироваться (по дизайну, по интерфейсу и т.д.).

- В данном пункте можно указать кто будет размещать приложение в маркетах (если таковое необходимо), т.е. есть ли у клиента собственный аккаунт (и нужна ли помощь в размещении) или релиз будет производиться с аккаунта компании-разработчика.

 - Также стоит заглянуть в будущее и указать как часто планируются доработки и обновление приложения и планируются ли вообще.

***

Безусловно, мы указали общие пункты для брифа, который используется для разработки мобильных приложений. Каждая компания вносит что-то свое. В данной статье мы изложили общие пункты, для того, чтобы клиент не боялся слова «бриф» и понимал его значение.