Как заполнить бриф на разработку мобильного приложения и почему без него нельзя приступать к работе

Обычно инициатива на заполнение брифа исходит от подрядчика. Здесь есть два варианта взаимодействия. Первый — подрядчик отправляет клиенту анкету с вопросами, и тот заполняет её самостоятельно. Второй — подрядчик назначает встречу, задаёт вопросы в формате интервью и фиксирует ответы в документе. На практике чаще используется второй вариант, потому что в процессе «живого» общения удаётся получить более полные и развёрнутые ответы, а также сделать необходимые уточнения по ходу.

Проведение брифа — важный этап в любом проекте. Он позволяет:

Уточнить детали. Бриф позволяет собрать основные сведения по проекту на этапе пресейла. Чёткое понимание всех аспектов на старте позволяет снизить риски в будущем.

Конкретизировать задачи. У компаний не из мира IT часто нет внутренних специалистов, которые могут корректно и однозначно сформулировать задачи. Иногда они представлены в виде абстрактных идей. Брифинг помогает снять неопределённость. Заказчик объясняет, какую проблему он хочет решить с помощью мобильного приложения. На основе этого исполнитель декомпозирует глобальную цель на конкретные задачи, оценивает, сколько времени займёт их выполнение и какие понадобятся ресурсы. Например, чтобы увеличить продажи, потребуется разработать e-commerce приложение с каталогом товаров и подключить к нему платёжные системы.

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

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

Универсального шаблона брифа не существует — содержание документа зависит от масштаба и специфики проекта. Однако есть общие разделы, которые актуальны для большинства digital- и IT-проектов. Разберём, что писать в каждом из них и поделимся примерами.

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

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

В данном блоке рассказывают, какие потребности бизнеса должен закрывать продукт и чем он будет полезен для пользователей. Описывают идею и ключевые особенности будущего сервиса. А чтобы исполнитель лучше понял ожидания и предпочтения заказчика, прикладывают референсы — примеры, на которые можно ориентироваться в разработке.

Например, заказчик хочет разработать корпоративное приложение для сотрудников, которое поможет оптимизировать рабочие процессы. Запрос понятен в общих чертах, но нужно уточнить детали. Рассказать, с какими рутинными задачами сталкиваются сотрудники и как их можно оптимизировать. А также уточнить, потребуется ли интеграция с CRM и другими системами.

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

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

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

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

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

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

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

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

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

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

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

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

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

Чтобы подрядчик мог точно оценить объём работ и составить график реализации проекта, клиент предоставляет ему следующую информацию:

Сроки реализации проекта. Заказчик устанавливает дедлайн, когда ему нужно готовое мобильное приложение и объясняет, почему именно в эти сроки. Например, релиз к определенной дате может быть важен, потому что начинается сезон продаж и запланированы маркетинговые активности.

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

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

Делимся шаблоном брифа, который MobileUp применяет на присейлах. Он поможет вам чётко сформулировать идею мобильного приложения, а разработчикам — погрузиться в задачу и воплотить проект в жизнь.

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