Бриф — это не формальность. Это документ, который определяет, получите ли вы точную оценку за 3 дня — или будете 2 недели переписываться с подрядчиком, уточняя «а что именно вы имели в виду». Плохой бриф = оценка с точностью ±100%. Хороший бриф = оценка с точностью ±20-30%.
В этой статье — готовый шаблон брифа с 12 разделами, примерами заполнения и объяснением, зачем нужен каждый пункт. Используйте как чек-лист — и подрядчику будет что оценивать, а не гадать.
с брифом и без
в хорошем брифе
качественного брифа
Зачем нужен бриф
Три конкретных причины:
1. Точная оценка. Без брифа подрядчик закладывает максимальные риски — и оценка получается x2-3 от реальной. С брифом подрядчик понимает объём и может дать вилку ±20-30%. Разница для проекта за 1.5 млн: оценка «от 800К до 3 млн» (без брифа) vs «1.3-1.8 млн» (с брифом).
2. Сравнение подрядчиков. Если вы отправляете одинаковый бриф 3-5 подрядчикам — можете сравнивать оценки «яблоки с яблоками». Без брифа каждый понимает задачу по-своему — и оценки несопоставимы.
3. Защита от «расползания» проекта. Бриф фиксирует scope. Если подрядчик через 2 месяца говорит «а вот это не было в оценке» — проверяете по брифу. Если было — их проблема. Если не было — ваша (и это повод обновить бриф для следующих проектов).
Раздел 1: О компании
Подрядчику важно понять контекст. Приложение для стартапа и для банка — разные требования к безопасности, дизайну, процессу.
Что указать:
— Название компании и сфера деятельности
— Размер (сколько сотрудников, оборот — хотя бы порядок)
— Есть ли IT-команда в штате (и какая)
— Контактное лицо для обсуждения (CEO, CTO, product manager)
Пример: «Компания LogiTrack. Логистика, 50 сотрудников, 30 водителей. IT-отдела нет, есть 1С-администратор. Контакт: CTO Алексей Петров».
Раздел 2: Цель приложения
Самый важный раздел. «Зачем?» определяет всё: функциональность, дизайн, стек, бюджет.
Что указать:
— Какую бизнес-проблему решает приложение
— Какой результат вы хотите получить (в цифрах)
— Как сейчас решается эта задача (без приложения)
Плохо: «Нам нужно мобильное приложение для бизнеса».
Хорошо: «Водители получают маршруты по телефону от диспетчера. Это занимает 30-40 минут утром + ошибки + нет контроля выполнения. Нужно приложение, которое автоматически распределяет маршруты, отслеживает GPS и показывает статус доставки в реальном времени. Цель: сократить время планирования с 40 мин до 5, снизить ошибки в маршрутах на 80%».
Раздел 3: Целевая аудитория
Кто будет пользоваться приложением? Это определяет UX, платформу, тон коммуникации.
Что указать:
— Основные группы пользователей (роли)
— Их техническая грамотность
— Устройства (бюджетные Android, флагманы, iPhone)
— Контекст использования (офис, «в полях», на ходу)
— Примерное количество пользователей (на старте и через год)
Пример: «Две роли: 1) Водители (30 человек на старте, до 100 через год). Бюджетные Android-смартфоны, низкая техническая грамотность, используют на ходу с перчатками. 2) Диспетчеры (3 человека). Десктоп + планшет, средняя техническая грамотность, используют в офисе 8 часов/день».
Раздел 4: Платформы
Что указать:
— Android, iOS или обе платформы
— Минимальная версия ОС (Android 8+? iOS 15+?)
— Нужна ли веб-версия (админ-панель, дашборд)
— Есть ли предпочтения по технологии (Flutter, React Native, нативная)
Пример: «Android обязательно (все водители на Android). iOS — на втором этапе. Веб-панель для диспетчеров — обязательна. Технология — на усмотрение подрядчика, главное — одна кодовая база для обеих платформ».
Подробнее о выборе стека — в нашей статье о разработке Android-приложений и сравнении Flutter и React Native.
Раздел 5: Функциональность
Ядро брифа. Опишите, что приложение должно делать — по экранам или по user stories.
Способ 1: По экранам
Перечислите все экраны и что на каждом:
— Экран авторизации: вход по телефону + SMS-код. Запоминать авторизацию.
— Главный экран (водитель): список заказов на сегодня, отсортированных по маршруту. Статус каждого (новый / в пути / доставлен).
— Карточка заказа: адрес, контакт получателя, комментарий, кнопка «Навигация» (открывает Яндекс.Навигатор), кнопка «Позвонить», кнопка «Доставлено» (с фото подтверждением).
— Карта: маршрут на день с точками доставки. GPS-трекинг.
Способ 2: По user stories
«Как [роль], я хочу [действие], чтобы [результат]»:
— Как водитель, я хочу видеть маршрут на карте, чтобы не вводить каждый адрес вручную.
— Как водитель, я хочу сфотографировать доставку, чтобы подтвердить получение.
— Как диспетчер, я хочу видеть GPS-позиции всех водителей на карте, чтобы контролировать маршруты в реальном времени.
— Как диспетчер, я хочу получать уведомление, если водитель задерживается более 30 минут, чтобы предупредить клиента.
Не нужно описывать каждую кнопку. Опишите сценарии — подрядчик предложит оптимальное решение. Но чем подробнее — тем точнее оценка. Золотая середина: по 2-4 предложения на каждый основной экран.
Раздел 6: Интеграции
С чем приложение должно «общаться»? Каждая интеграция — отдельная статья расходов (30-200К).
Что указать:
— Существующие системы (1С, CRM, ERP, сайт)
— Платёжные системы (ЮKassa, CloudPayments, SBP)
— Карты и навигация (Яндекс.Карты, Google Maps, 2ГИС)
— Мессенджеры (Telegram-бот, WhatsApp)
— Аналитика (Яндекс.Метрика, Firebase, Amplitude)
— Push-уведомления (Firebase Cloud Messaging)
— SMS-шлюз (для авторизации)
Пример: «Обязательно: 1С (двусторонняя синхронизация заказов), Яндекс.Карты (маршрут + GPS), Firebase (push + аналитика), SMS-шлюз (авторизация). Желательно: Telegram-бот (уведомления диспетчеру)».
Раздел 7: Дизайн
Что указать:
— Есть ли брендбук / гайдлайны (логотип, цвета, шрифты)
— Примеры приложений, которые нравятся (и чем именно)
— Уровень дизайна: стандартный (UI-кит) или кастомный
— Важна ли анимация / микровзаимодействия
— Нужна ли тёмная тема
Пример: «Брендбук есть (приложим). Нравится Яндекс.Доставка (простой, чистый, большие кнопки — водители работают в перчатках). Стандартный дизайн на базе Material Design, без сложных анимаций. Тёмная тема не нужна».
Раздел 8: Контент и локализация
Что указать:
— Языки интерфейса (только русский? + английский?)
— Кто готовит контент (тексты, иконки, фото)
— Есть ли готовый контент или его нужно создавать
Пример: «Только русский язык. Контент (тексты интерфейса) готовим мы. Иконки и иллюстрации — на подрядчике. Фото для маркетинговых материалов (скриншоты в сторах) — на подрядчике».
Раздел 9: Безопасность
Что указать:
— Какие данные хранит приложение (персональные, платёжные, медицинские)
— Требования к авторизации (SMS, 2FA, биометрия)
— Нужно ли шифрование данных на устройстве
— Регуляторные требования (152-ФЗ, PCI DSS, HIPAA)
— Где должны храниться данные (Россия / не важно)
Пример: «Персональные данные водителей и клиентов. Авторизация по SMS. Шифрование не требуется (нет платёжных данных). 152-ФЗ: серверы в России. GPS-данные водителей — хранить 90 дней».
Раздел 10: Сроки и бюджет
Подрядчику важно знать ваши ограничения — чтобы предложить реалистичный план.
Что указать:
— Желаемая дата запуска (или дедлайн)
— Бюджет (хотя бы вилку: «до 1 млн», «1-2 млн», «бюджет не ограничен»)
— Готовы ли на MVP-подход (сначала базовая версия, потом расширение)
— Предпочтительная модель оплаты (фикс, T&M, помесячная)
Пример: «Дедлайн: запуск MVP к 1 сентября 2026. Бюджет: 800К-1.3 млн на MVP. Готовы на MVP-подход: сначала Android + веб-панель, iOS — на втором этапе. Оплата: 30/30/30/10 по этапам».
Указывайте бюджет. Я знаю, что «не хочется показывать карты». Но без бюджета подрядчик либо завысит оценку (риски), либо предложит решение, которое вам не по карману. Указывайте хотя бы порядок — это сэкономит время обеим сторонам.
Раздел 11: Поддержка после запуска
Что указать:
— Нужна ли поддержка от подрядчика после запуска (и на какой срок)
— Планируете ли развивать приложение (новые фичи) или только поддерживать
— Есть ли своя команда для поддержки (или нужна от подрядчика)
— Требования к SLA (время реакции на баги)
Раздел 12: Приложения
Всё, что поможет подрядчику понять задачу:
— Скетчи / wireframes (даже от руки на бумаге — лучше, чем ничего)
— Брендбук / гайдлайны
— Примеры конкурентов (с комментариями: что нравится, что нет)
— Техническая документация к API (если интеграции с вашими системами)
— Существующие документы (ТЗ, если есть; презентации; бизнес-план)
Типичные ошибки в брифах
1. «Приложение как Uber, только для [ниша]». Uber разрабатывали 500+ инженеров. Ваш бюджет — 1 млн. Не ориентируйтесь на гигантов. Опишите конкретный функционал, который нужен вам.
2. Список фич без приоритетов. 50 пунктов, все «обязательные». Подрядчик оценивает всё — бюджет x3. Разделите на «must have» (MVP), «should have» (версия 2) и «nice to have» (когда-нибудь).
3. Фокус на технологии, а не на задаче. «Нужен микросервисный бэкенд на Go с GraphQL» — это не бриф, это требования архитектора. Опишите задачу — подрядчик предложит оптимальный стек.
4. Забыли про админку. Приложение без админ-панели — как автомобиль без руля. Кто будет управлять контентом, пользователями, настройками? Опишите, что нужно в админке.
5. Нет бюджета и сроков. Подрядчик не телепат. Без бюджета — он не понимает, предлагать MVP за 400К или enterprise-решение за 5 млн. Без сроков — не может спланировать команду.
Если вы составляете бриф впервые — ознакомьтесь с нашим гайдом по ТЗ на мобильное приложение, он поможет детализировать требования.
Наш подход: от брифа к оценке за 3 дня
В March Code мы оцениваем проект за 2-3 рабочих дня после получения брифа. Вот что вы получаете:
Подробнее о процессе работы — на странице мобильной разработки.
FAQ
Бриф и ТЗ — это одно и то же?
Нет. Бриф — описание задачи на языке бизнеса (что нужно и зачем). ТЗ — техническая спецификация (как реализовать). Бриф составляет заказчик. ТЗ — подрядчик (или совместно) на основе брифа. Бриф: 3-10 страниц. ТЗ: 20-80 страниц. Подробнее о ТЗ — в нашем гайде.
Можно ли отправить бриф нескольким подрядчикам?
Да, и нужно. Рекомендуем 3-5 подрядчиков. Одинаковый бриф позволяет сравнивать оценки корректно. Сравнивайте не только цену, но и: детализацию оценки (подрядчик, который дал одну цифру — не понял задачу), вопросы (хороший подрядчик задаёт 10-20 вопросов, плохой — ноль), предложенный стек и подход.
Что если я не знаю технические детали?
Это нормально. Бриф — не техническое задание. Пишите на языке бизнеса: что должно происходить, для кого, какой результат. Технические решения — задача подрядчика. «Мне нужно, чтобы водитель видел маршрут на карте» — достаточно. Не нужно писать «использовать Yandex Maps SDK v3.1 с кластеризацией маркеров».
Сколько времени нужно на составление брифа?
2-4 часа для типового проекта. Если у вас сложный проект с множеством ролей и интеграций — 1-2 дня. Не торопитесь. Каждый час, потраченный на бриф, экономит 5-10 часов на переписке с подрядчиком и 50-100К на переделках.
Нужно ли указывать конкурентов?
Да. 3-5 примеров приложений из вашей ниши (или смежных) с комментариями: что нравится, что нет. Это экономит часы на объяснение «а мы хотим вот так». Скриншоты ещё лучше — приложите с пометками «вот эта навигация — отлично, а вот этот checkout — ужасен».
Что делать после отправки брифа?
Ждите вопросов (1-3 дня). Хороший подрядчик вернётся с 10-20 уточняющими вопросами. Это хороший знак — значит, он вник в задачу. Подрядчик, который сразу назвал цену без вопросов — либо переоценил (заложил риски), либо не понял задачу (и цена вырастет позже).
Можно ли менять бриф после отправки?
Да. Бриф — живой документ. Но каждое изменение после начала работы — это пересчёт сроков и бюджета. Поэтому лучше потратить больше времени на бриф до старта, чем менять требования в процессе. Изменения до подписания договора — бесплатны. После — зависит от масштаба.