Бриф и ТЗ на разработку сайта: что подготовить до старта

Автор: Group-S

Бриф объясняет задачу бизнеса, а техническое задание описывает будущий сайт и способ его проверки. Чтобы начать разработку, не нужно знать программирование: достаточно подготовить сведения о компании и вместе с исполнителем уточнить результат. Ниже — короткий шаблон брифа и учебный пример конкретных требований.

Чем бриф отличается от ТЗ на разработку сайта?

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

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

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

Что написать в брифе на разработку сайта?

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

Скопируйте вопросы ниже и ответьте обычными словами:

1. Что продаём? Услуги или товары, приоритетные направления и то, чем компания не занимается.
2. Кому? Тип клиента, регион работы и вопросы перед покупкой.
3. Как посетитель обращается? Звонит, запрашивает расчёт, записывается или оплачивает заказ.
4. Что есть сейчас? Действующий сайт, его полезные разделы и проблемы, которые нужно устранить.
5. Какие материалы готовы? Логотип, тексты, фотографии, характеристики и документы. Кто подготовит недостающее?
6. С чем связать сайт? Система учёта заявок, оплата, склад или другой сервис. Кто предоставит доступ?
7. Какие ограничения? Бюджет, необходимая дата запуска, ответственный за согласования и обновления.

Пример полезного ответа: «Поставляем оборудование организациям. Закупщик сравнивает характеристики и запрашивает предложение. Онлайн-оплата пока не нужна». По такому описанию уже можно обсуждать структуру и состав работ.

Как выглядит конкретное требование в ТЗ?

Описывайте действие посетителя, результат и поведение при ошибке. Требование «сделать удобную форму» слишком расплывчато: стороны могут понимать удобство по-разному.

Учебный пример для вымышленного поставщика оборудования. На карточке есть кнопка «Запросить расчёт». Посетитель указывает имя и телефон; комментарий необязателен. Вместе с контактом в систему учёта заявок — CRM — передаются модель и адрес карточки.

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

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

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

Что ещё включить в техническое задание?

Зафиксируйте структуру сайта, объём наполнения и действия администратора. Отдельно перечислите функции, которые откладываете: так первая версия не будет незаметно разрастаться.

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

Требование к управлению: сотрудник добавляет карточку по общему шаблону, меняет характеристики и PDF, скрывает товар без редактирования кода. При приёмке он самостоятельно обновляет одну карточку по инструкции.

Укажите, кто пишет тексты, проверяет характеристики и загружает материалы. «Разработка каталога» и «заполнение двадцати карточек» — разные задачи. Если заменяете существующий сайт, перечислите важные адреса и материалы, которые нужно сохранить.

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

Кто составляет документы и согласует изменения?

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

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

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

Например, добавить передачу заявки в новую CRM — изменение объёма. Передать в уже согласованную CRM пропущенное название модели — исправление. Такое различие помогает обсуждать правки предметно.

Что проверить перед началом разработки?

Проверьте, что обе стороны одинаково понимают результат, обязанности и способ приёмки. Большой документ не спасает проект, если существенные пункты остаются неопределёнными.

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

Готовый перечень функций поможет сравнить сметы на одинаковый сайт. А порядок работы обсудите по критериям выбора разработчика.

Вывод

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

Нужна помощь с подготовкой задачи? Расскажите о проекте Group-S: обсудим состав разработки и дальнейшую работу с сайтом.