Что такое бриф на разработку сайта и приложения

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

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

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

Чем бриф отличается от технического задания

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

Формулировка брифа «покупатель видит остатки по городам» превращается в ТЗ после уточнений: какой город выбран по умолчанию, откуда поступают остатки, что происходит при смене города и недоступности системы. Структуру следующего документа разбираем в статье «Техническое задание на разработку: как написать». Здесь задача другая: подготовить ответы до этого этапа.

Когда нужен бриф и какой вариант выбрать

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

Бриф на разработку сайта

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

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

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

Общий бриф на сайт и приложение

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

Какие вопросы включить в бриф

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

1. Задача бизнеса

Что происходит сейчас и что должно измениться? Как компания получает выручку или обслуживает пользователей? Почему нужен новый продукт? Вместо «увеличить продажи» опишите наблюдаемую проблему: покупатели звонят, чтобы проверить наличие; менеджеры повторно вводят заказы; сотрудники ищут документы в нескольких системах.

2. Аудитория и сценарии

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

3. Функции первой версии

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

4. Интеграции и данные

Какие системы уже хранят товары, цены, остатки, клиентов и заказы? Укажите название, версию, ответственного и наличие документации. Для каждой связи опишите данные и направление обмена. Фраза «интеграция с 1С» не объясняет, нужно ли получать остатки, передавать заказы или обновлять цены. Подготовка такой связи разобрана на странице интеграции с учётными системами.

5. Ограничения и материалы

Какие страны, языки, валюты и города поддерживает продукт? Какие роли доступа нужны? Что следует сохранить при переходе с действующей системы? Приложите фирменный стиль, ссылки на продукт, обезличенные примеры данных и требования к инфраструктуре. Отдельно перечислите доступы, которые ещё предстоит получить. Пароли и данные покупателей в бриф не вставляйте.

6. Бюджет и сроки

Какой диапазон вложений компания готова обсуждать и что в него включено? Назовите дату запуска и её причину: начало сезона, окончание договора, открытие направления. Отделите обязательную дату от желаемой. Укажите, предусмотрены ли регулярные расходы на обслуживание, внешние сервисы и развитие.

7. Критерии успеха

Как вы поймёте, что проект решил задачу? Запишите исходный показатель, источник данных, желаемое изменение, период наблюдения и ответственного. Техническую приёмку отделите от результата бизнеса: возможность оформить заказ проверяется до запуска, доля заказов без помощи оператора — после начала использования.

Пример заполненного брифа интернет-магазина

Рассмотрим учебный проект магазина товаров для дома. Название, бюджет, сроки и показатели условные; это пример ответов, а не бриф клиента и не предложение на разработку. Магазин уже принимает заказы на сайте, но повторная покупка часто требует звонка менеджеру.

Такой ответ позволяет задать предметные вопросы. Что делать, если товар из старого заказа исчез? Как учитывать новую цену и выбранный город? Можно ли повторить часть заказа? Решения согласуют при подготовке требований. Цель 55% останется гипотезой бизнеса: выполнение функций само по себе не обеспечивает этот показатель.

Как заполнить и согласовать бриф

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

Шаг 1. Соберите исходные материалы

Шаг 2. Согласуйте цель внутри компании

Шаг 3. Расставьте приоритеты функций

Шаг 4. Подтвердите данные и ограничения

Шаг 5. Зафиксируйте версию для обсуждения

Стоимость подготовки брифа и бюджет проекта

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

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

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

Как требования выглядят в проектах Finn Flare и «Сатурн»

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

Два рынка и наличие по городам

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

Услуги, склады и заказ для организации

В проекте «Сатурн» есть колеровка, распил, региональные склады, обмен с 1С и оформление заказа на юридическое лицо. Поэтому «приложение строительного магазина» нужно раскрыть вопросами: какие услуги покупатель выбирает к товару, как задаёт параметры, откуда поступают остатки, как выбирается склад и какие реквизиты нужны организации.

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

Что проверить перед передачей подрядчику

Команда должна понять задачу и увидеть вопросы, которые предстоит решить. При выборе подрядчика попросите объяснить, какие сведения нужны для предварительной оценки, какие требуют исследования и какой документ будет согласован перед разработкой. Сравнивайте предложения по составу работ и допущениям.

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

Более широкий порядок обращения к команде — в чек-листе заказа разработки приложения. Он пригодится после подготовки исходной анкеты.

Итог: бриф как основа разговора о проекте

Заполненный бриф связывает бизнес-задачу, пользователей и ограничения проекта. Оптимальный результат этого этапа — согласованное описание с понятными приоритетами и отмеченными неизвестными. Подробные решения и критерии приёмки команда подготовит следующим шагом.

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

Часто задаваемые вопросы

Ольга ДьяконоваРуководитель отдела аналитики

Поделиться статьей