МК

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

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

13 мин чтения

Бриф — это первый документ, от которого зависит успех проекта. Плохой бриф = неточная оценка, размытые ожидания, бесконечные переделки и перерасход бюджета на 30-50%. Хороший бриф = точная оценка (±15%), единое понимание задачи, предсказуемый результат.

Проблема: 70% клиентов, которые приходят к нам за разработкой, не знают, что писать в брифе. «Нам нужен сайт» — это не бриф. «Нам нужен интернет-магазин на 500 товаров с интеграцией 1С, мобильной версией и бюджетом до 800К» — это уже бриф. В этой статье — 12 разделов, которые должны быть в каждом брифе, с примерами хороших и плохих формулировок.

30-50%
перерасход бюджета при плохом брифе
12 разделов
в правильном брифе
2-4 часа
время на составление качественного брифа

Зачем нужен бриф

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

Что даёт бриф заказчику

Точная оценка. Подрядчик не гадает, а считает на основе конкретных требований. Разброс оценки: ±15% вместо ±50%.
Сравнение предложений. Когда 3-5 подрядчиков оценивают один и тот же бриф — можно объективно сравнить цены и подходы.
Фиксация ожиданий. «Мы же договаривались!» — бриф — это письменная фиксация того, о чём договаривались.
Экономия на переделках. 80% конфликтов с подрядчиком — из-за расхождения ожиданий. Бриф снижает этот риск на 70%.

Что даёт бриф подрядчику

— Понимание задачи до начала работы (а не в процессе)
— Основа для технического задания (ТЗ)
— Возможность оценить сроки и стоимость
— Материал для планирования команды

Бриф — не финальный документ. Он не заменяет ТЗ (техническое задание). Бриф — это «что хотим», ТЗ — «как будем делать». Бриф пишет заказчик, ТЗ — подрядчик на основе брифа. Подробнее о ТЗ — в отдельной статье.

12 разделов брифа

Раздел 1: О компании

Кто вы, чем занимаетесь, какие продукты/услуги предлагаете. Не для формальности — подрядчику важно понять контекст.

Плохо: «Мы — компания».

Хорошо: «Производитель мебели, B2B и B2C, 15 лет на рынке, 3 шоурума в Москве, 2000+ SKU, оборот 200 млн/год. Текущий сайт на Битриксе, 10К посетителей/мес».

Раздел 2: Цель проекта

Зачем вам сайт/приложение? Какую бизнес-задачу решаете?

Плохо: «Нам нужен новый сайт».

Хорошо: «Цель — увеличить онлайн-продажи с 5 млн до 15 млн/мес. Текущий сайт не конвертирует: скорость загрузки 6 секунд, нет мобильной адаптации, корзина устарела. Нужен новый интернет-магазин с фокусом на конверсию и мобильный трафик».

Ключевое. Цель — всегда бизнес-метрика, а не технология. Не «сделать на React», а «увеличить конверсию с 1% до 2,5%». Технологию выберет подрядчик — его работа разбираться в стеках.

Раздел 3: Целевая аудитория

Кто будет пользоваться продуктом? Возраст, роли, задачи, проблемы.

Плохо: «Все люди».

Хорошо: «1) Розничные покупатели: женщины 28-45, доход средний+, покупают мебель для квартиры. 2) Дизайнеры интерьера: заказывают оптом, нужен B2B-прайс с авторизацией. 3) Корпоративные клиенты: закупка для офисов, тендерная документация».

Раздел 4: Тип проекта

Что именно нужно: сайт, приложение, система, бот?

— Лендинг (1-5 страниц)
— Корпоративный сайт (10-30 страниц)
— Интернет-магазин
— Веб-приложение (SaaS, CRM, ERP)
— Мобильное приложение (iOS, Android, кроссплатформа)
— Telegram-бот / Mini App
— Портал / маркетплейс
— Редизайн / миграция существующего проекта

Раздел 5: Функциональные требования

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

Плохо: «Обычный интернет-магазин со всем необходимым».

Хорошо:

«Каталог: 2000 товаров, 5 уровней категорий, фасетные фильтры (размер, цвет, материал, цена), поиск с автодополнением.
Карточка товара: фото (4+ ракурсов, зум), характеристики (таблица), отзывы, "с этим покупают".
Корзина: добавление без авторизации, промокоды, расчёт доставки.
Оплата: ЮKassa (карты, СБП), безналичный расчёт для юрлиц.
Доставка: интеграция СДЭК + собственная курьерская.
Личный кабинет: история заказов, отслеживание, возвраты.
B2B-раздел: авторизация по ИНН, оптовые цены, акт сверки».

Совет

Не знаете, какие функции нужны? Составьте user story: «Как [роль], я хочу [действие], чтобы [результат]». Пример: «Как покупатель, я хочу фильтровать товары по размеру, чтобы быстро найти подходящий». 20-30 user stories = полный бриф.

Раздел 6: Интеграции

С чем должен работать продукт?

— 1С (какая конфигурация: УТ, ERP, Бухгалтерия?)
— CRM (amoCRM, Битрикс24, RetailCRM)
— Платёжные системы (ЮKassa, Тинькофф, CloudPayments)
— Доставка (СДЭК, Boxberry, DPD, собственная)
— Аналитика (Яндекс.Метрика, GA4)
— Email/SMS (Unisender, Sendsay)
— Маркетплейсы (Ozon, Wildberries — синхронизация остатков)
— Телефония (Mango, OnlinePBX)

Раздел 7: Дизайн

Какие ожидания по дизайну?

— Есть ли брендбук / гайдлайн?
— Примеры сайтов, которые нравятся (и почему)
— Примеры, которые не нравятся (и почему)
— Нужен ли дизайн «с нуля» или редизайн текущего?
— Мобильная версия: адаптивная или mobile-first?

Плохо: «Красивый и современный».

Хорошо: «Минималистичный, как Muji.com. Много белого пространства, крупные фото товаров, акцент на типографике. Не нравится: перегруженные интерфейсы как у DNS. Брендбук прилагается».

Раздел 8: Контент

Кто подготовит контент (тексты, фото, видео)?

— Тексты: заказчик / копирайтер подрядчика / нужен SEO-контент
— Фото товаров: есть в высоком качестве / нужна фотосъёмка
— Видео: есть / нужна видеопродакшн
— Наполнение каталога: кто загружает 2000 товаров?

Частая ловушка. Разработка завершена, сайт готов — а контент не готов. Запуск откладывается на 1-3 месяца. Заложите контент-подготовку в план проекта с первого дня.

Раздел 9: SEO-требования

— Нужна ли SEO-оптимизация?
— Какие ключевые запросы важны?
— Есть ли текущие позиции, которые нужно сохранить при редизайне?
— Нужна ли микроразметка (Schema.org)?
— Мультиязычность (региональные версии)?

Раздел 10: Технические ограничения

— Предпочтения по технологиям (если есть)
— Хостинг: облако (какое?), выделенный сервер, хостинг подрядчика
— Требования к безопасности (152-ФЗ, сертификация)
— Ожидаемая нагрузка (посетители/день, транзакции/мин)
— Требования к SLA (допустимый downtime)

Раздел 11: Бюджет и сроки

Да, озвучивайте бюджет. Это не «слабость переговорной позиции» — это экономия времени.

Плохо: «Бюджет обсудим. Назовите вашу цену».

Хорошо: «Бюджет: 500-800К. Дедлайн: запуск к 1 сентября 2026. Готовы увеличить бюджет до 1 млн при обоснованной необходимости».

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

Раздел 12: Критерии успеха

Как вы поймёте, что проект успешен? Конкретные, измеримые метрики.

— Конверсия сайта > 2,5%
— Скорость загрузки < 2 секунд (Core Web Vitals — green)
— 100% мобильная адаптация
— Интеграция с 1С: синхронизация остатков за < 5 минут
— Органический трафик > 50К/мес через 6 месяцев

Примеры хороших и плохих формулировок

1
Плохо: «Нам нужен удобный сайт». Хорошо: «Каталог с фасетными фильтрами: пользователь находит товар за < 3 клика, поиск с автодополнением, время загрузки страницы < 2 секунд».
2
Плохо: «Должен работать на телефоне». Хорошо: «Mobile-first дизайн. 68% трафика — мобильный. Корзина и оформление заказа оптимизированы под мобильные (1 экран — 1 шаг, крупные кнопки, автозаполнение)».
3
Плохо: «Интеграция с 1С». Хорошо: «Двусторонняя синхронизация с 1С:УТ 11.5. Из 1С → сайт: товары, остатки, цены (обновление каждые 15 минут). Из сайта → 1С: заказы, оплаты (мгновенно через webhook)».
4
Плохо: «Красивый дизайн». Хорошо: «Минималистичный дизайн в стиле скандинавских интерьерных брендов. Референсы: Muji.com, HAY.dk. Нет: перегруженные баннеры, кричащие акции. Есть: много воздуха, крупные фото, акцент на продукте».

Чек-лист перед отправкой брифа

Проверьте бриф перед отправкой подрядчикам:

— Описана цель проекта (бизнес-метрика, а не «сделать сайт»)
— Описана целевая аудитория (кто, зачем, в каком контексте)
— Перечислены все функции (или user stories)
— Указаны интеграции с конкретными системами и версиями
— Есть примеры дизайна (нравится / не нравится)
— Указан бюджет (вилка)
— Указан дедлайн (желаемый срок)
— Описан контент-план (кто готовит, когда)
— Есть критерии успеха (измеримые)
— Документ структурирован и читаем (не стена текста)

Совет

Отправьте бриф 3-5 подрядчикам. Сравните не только цены, но и вопросы, которые они задают. Хороший подрядчик задаёт 10-20 уточняющих вопросов. Тот, кто сразу называет цену без вопросов — либо не читал бриф, либо «впишет всё потом».

Бриф vs ТЗ: в чём разница

Часто путают. Разница принципиальная:

1
Бриф — пишет заказчик. «Что хотим получить». Бизнес-язык. 3-10 страниц. Время: 2-4 часа. Цель: получить оценку и выбрать подрядчика.
2
ТЗ — пишет подрядчик. «Как будем делать». Технический язык + прототипы. 20-100 страниц. Время: 2-4 недели. Цель: зафиксировать требования для разработки. Подробнее — в статье про техническое задание.

Процесс: Бриф → Оценка → Выбор подрядчика → ТЗ → Разработка. Бриф — входная точка. ТЗ — рабочий документ.

Частые ошибки в брифах

Ошибка 1: Слишком общий бриф

«Нам нужен сайт для продажи товаров». Это не бриф — это запрос. Подрядчик не может оценить проект без деталей. Результат: либо завышенная оценка (подстраховка), либо заниженная (а потом допродажи).

Ошибка 2: Технические требования вместо бизнес-задач

«Сделать на Next.js с PostgreSQL и Redis». Стек — дело подрядчика. Вы описываете задачу, он — решение. Возможно, для вашей задачи Битрикс подходит лучше, чем Next.js. Или наоборот.

Ошибка 3: Скрытый бюджет

«Бюджет обсудим после вашей оценки». Результат: подрядчик не знает, в какой диапазон целиться. Предложит решение за 3 млн, а у вас бюджет 500К. Или наоборот — урежет решение до 300К, хотя вы готовы на 1 млн. Потрачено время обеих сторон.

Ошибка 4: «Сделайте как у [конкурента]»

Вы не знаете, сколько конкурент потратил на разработку (скорее всего, в 5-10 раз больше вашего бюджета). Используйте конкурентов как референс дизайна и функций, но не как ТЗ.

Ошибка 5: Нет приоритетов

50 функций одинаковой важности. Подрядчик не знает, что делать первым. Разделите на: Must Have (без этого не запускаемся), Should Have (важно, но не критично), Nice to Have (если останутся ресурсы). MoSCoW-метод.

FAQ: частые вопросы о брифе на разработку

Сколько времени нужно на составление брифа?

2-4 часа для простого проекта (лендинг, небольшой сайт). 1-2 дня для сложного (интернет-магазин, приложение, система). Время окупается: хороший бриф экономит недели переговоров и месяцы переделок.

Может ли подрядчик помочь составить бриф?

Да, многие подрядчики проводят бесплатный (или платный) брифинг: 1-2 часовая встреча, на которой помогают структурировать требования. Это нормальная практика — не стесняйтесь попросить.

Обязательно ли указывать бюджет?

Не обязательно, но крайне рекомендуется. Бюджетная вилка (от-до) — оптимальный вариант. Подрядчик предложит решение, которое укладывается в бюджет, а не «космическое» за пределами.

Что если я не знаю, какие функции нужны?

Начните с пользовательских сценариев: опишите, как клиент будет использовать продукт. «Клиент заходит на сайт → ищет товар → добавляет в корзину → оплачивает → получает уведомление». Подрядчик переведёт сценарии в функции.

Бриф нужен для каждого проекта?

Для проектов от 100К — да. Для мелких доработок (добавить страницу, поменять кнопку) — достаточно письма с описанием задачи. Чем крупнее проект — тем важнее бриф.

Можно ли менять бриф после отправки?

До подписания договора — свободно. После начала разработки — через change request (запрос на изменение). Каждое изменение требований после старта = дополнительное время и деньги. Поэтому лучше потратить время на бриф до начала работ.

Какой формат брифа лучше?

Google Docs / Word — удобно комментировать и редактировать. Notion — для структурированных данных. PDF — для финальной версии. Excel — только для таблиц (прайсы, матрица функций). Не используйте презентации (PowerPoint) — текст важнее визуала.

Об авторах

Команда «Мартовский Код»

Мы — студия разработки из Краснодара. Помогаем бизнесам переводить процессы в цифру: строим веб- и мобильные приложения, автоматизируем рутину, внедряем ИИ туда, где он действительно нужен.

За это время реализовали более 20 проектов — от MVP для стартапов до сложных SaaS-платформ и enterprise-решений. Среди клиентов — гостиничный бизнес, e-commerce, логистика, образование. Каждый проект для нас — это не просто код, а продукт, который должен работать на результат.

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

Нужна разработка?

Расскажите о задаче — оценим сроки и бюджет за один звонок. Без обязательств.

Обсудить проект