Техническое задание на разработку сайта: что в нём должно быть

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

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

Зачем нужно ТЗ и кто его пишет

Мы предлагаем сразу определить, что войдёт в первую версию сайта, что откладывается и что ещё предстоит выяснить. Тогда предложения подрядчиков можно сопоставлять по одному составу работ: каталог с ручным наполнением и каталог с обменом из 1С — разные задачи.

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

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

Когда уместен ГОСТ 34.602-2020

ГОСТ 34.602-2020 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы» действует с 1 января 2022 года вместо ГОСТ 34.602-89. Он устанавливает состав, содержание и правила оформления ТЗ на создание, развитие или модернизацию автоматизированной системы. Это более широкий предмет, чем оформление страниц сайта: в область применения входят системы автоматизации разных видов деятельности.

К формату стандарта стоит обратиться, если сайт входит в состав большой автоматизированной системы или такой порядок документации предусмотрен условиями проекта. В тексте ГОСТ, пункте 4.1, перечислены десять обязательных разделов:

• общие сведения;
• цели и назначение создания системы;
• характеристика объектов автоматизации;
• требования к системе;
• состав и содержание работ по созданию системы;
• порядок разработки;
• порядок контроля и приёмки;
• требования к подготовке объекта автоматизации к вводу системы в действие;
• требования к документированию;
• источники разработки.

Для небольшого корпоративного сайта или каталога мы рекомендуем более компактное ТЗ, если условия проекта допускают такой формат. Оно охватывает реальные страницы, данные, подключения и проверки. Заимствовать полезную логику стандарта можно; называть произвольно сокращённый шаблон «ТЗ по ГОСТ» не следует.

При оформлении по стандарту раздел без требований сохраняют с соответствующей записью (примечание к пункту 4.1). Пункт 4.2 допускает изменение состава подразделов.

Для любого рабочего ТЗ полезен принцип пункта 3.4: каждое требование должно быть единичным, непротиворечивым, актуальным, выполнимым, проверяемым и однозначным. Поэтому вместо «сайт удобный» опишем конкретное действие и его результат. Приведённое далее оглавление — авторский шаблон для сайта, а не воспроизведение структуры ГОСТ.

Пример оглавления технического задания

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

1. Общие сведения: название проекта, участники, версия ТЗ и связанные материалы.
2. Цели, аудитория, пользовательские задачи и границы первой версии.
3. Карта страниц, типовые шаблоны, навигация и прототипы.
4. Функциональность каждой страницы и общих компонентов.
5. Контент: состав, источники, подготовка, перенос и наполнение.
6. Интеграции: 1С, CRM, оплата и другие внешние системы.
7. CMS и админка: редактирование, роли и права.
8. SEO: адреса, метаданные, индексирование и перенос старых страниц.
9. Адаптивность, совместимость, доступность и производительность.
10. Хостинг, безопасность, резервное копирование и окружения.
11. Этапы, результаты, порядок согласования и изменения требований.
12. Критерии приёмки, запуск, документация и передача доступов.

Цели, аудитория и структура: начать с задач посетителя

Цель «получать больше продаж» уточните до действия, которое поддерживает сайт. Например: закупщик находит оборудование по характеристикам, сравнивает подходящие модели и отправляет запрос на подбор. Это учебный пример для B2B-каталога, который будем использовать дальше; реальный состав функций определяется вашим бизнесом.

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

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

Карта страниц и прототипы

Составьте карту адресов и перечень шаблонов. Несколько страниц услуг могут использовать один шаблон, но требовать разного наполнения. Укажите, какие страницы исполнитель создаёт и заполняет к запуску, а какие заказчик добавит позже. Одного пункта «разработать шаблон услуги» для понимания объёма наполнения мало.

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

Яндекс рекомендует чёткую ссылочную структуру и доступ к страницам по обычным ссылкам. Поэтому навигацию стоит описывать уже в ТЗ. Подробнее о выборе разделов — в материале про структуру сайта для SEO.

Функциональность: описать страницы и состояния

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

Пример одного проверяемого требования

Форма запроса оборудования. Посетитель открывает форму из карточки. Название и артикул выбранной модели попадают в заявку автоматически. Состав контактных полей и правила их проверки перечислены в приложении. После принятия заявки сайт показывает подтверждение и передаёт её в CRM с указанием страницы обращения.

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

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

Контент и админка: что должно быть готово к запуску

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

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

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

Требования к системе управления

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

В документации 1С-Битрикс описаны SEO-настройки элемента и наследование из раздела или инфоблока. Но состав полей зависит от настроек. Поэтому наличие CMS не заменяет требование показать конкретные операции на вашем проекте.

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

Для форм согласуйте с ответственным за персональные данные состав полей, основание обработки и необходимые документы. Статья 6 закона № 152-ФЗ предусматривает разные основания обработки. Если используется согласие, статья 9 требует оформлять его отдельно от иной информации и документов, которые человек подтверждает или подписывает. В ТЗ опишите согласованный механизм и фиксацию получения согласия.

Интеграции с 1С, CRM и оплатой

Запись «интеграция с 1С и CRM» не задаёт состав обмена. Для каждого подключения нужны название системы, версия или используемый интерфейс, доступные данные, направление передачи и ответственные с обеих сторон. Отдельно перечислите работы на сайте и работы в подключаемой системе.

В курсе 1С-Битрикс описаны обновление товаров, цен и остатков по расписанию и получение заказов в 1С (курс описывает обмен с «1С:Управление торговлей» редакций 10.3 и 11.1). Из этого не следует совместимость любого обмена с любой конфигурацией: в ТЗ фиксируют именно вашу связку.

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

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

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

SEO-требования: заложить в структуру и шаблоны

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

• Структура и адреса: согласованная карта страниц, правила формирования URL, меню и внутренние ссылки.
• Метаданные: редактирование title и description, заголовка H1, шаблоны для типовых страниц и возможность индивидуальной настройки.
• Изображения: возможность задать описательный alt там, где он нужен по содержанию.
• Индексирование: правила для открытых и служебных страниц, формирование robots.txt и Sitemap, проверка настроек после переноса.
• Дубли: согласованное поведение фильтров, сортировок и вариантов адреса, настройка canonical там, где она предусмотрена проектом.
• Старый сайт: таблица соответствия старых и новых адресов, перенаправления и проверка важных страниц после запуска.
• Разметка и аналитика: нужные проекту типы структурированных данных, события и способы проверки их передачи.

Измените поля в админке и проверьте итоговый HTML на согласованной выборке страниц каждого типа. О назначении заголовков — в статье про заполнение метаданных.

Для тестовой площадки предусмотрите ограничение доступа, например парольную защиту. У Google файл robots.txt управляет обходом и не гарантирует исключения адреса из поиска. Правила обхода и исключения из индекса согласуйте отдельно для Яндекса и Google. Практические детали — в материале о robots.txt и Sitemap.

Адаптивность, скорость и хостинг: указать условия проверки

На каких устройствах сайт должен работать

В ТЗ перечислите браузеры, устройства и диапазоны ширины, которые входят в проверку. Запись «все устройства» не задаёт обозримого набора испытаний. Назовите проверяемые версии браузеров и порядок обновления списка, если разработка длительная.

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

Google использует мобильное содержимое для индексирования и ранжирования. Поэтому проверьте, что характеристики, описание услуги и другие основные сведения доступны и на телефоне. Компоновка может отличаться; смысловое содержание не должно теряться ради короткого экрана.

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

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

Ориентиры хорошего пользовательского опыта по web.dev: LCP (загрузка) — не более 2,5 секунды, INP (отклик на действия) — не более 200 миллисекунд, CLS (стабильность макета) — не более 0,1. Их оценивают на 75-м процентиле отдельно для мобильных устройств и компьютеров. CLS не имеет единицы измерения; это показатель сдвигов макета.

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

Где разместить сайт и кто им управляет

Укажите выбранную CMS и редакцию, требования к серверному окружению, плановый объём данных и нагрузку. Для 1С-Битрикс сверяйте окружение с официальными требованиями продукта. Описанный там тест совместимости хостинга дополняйте испытаниями самого сайта.

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

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

Критерии приёмки: как доказать, что требование выполнено

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

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

Чек-лист готовности к передаче

• Согласованные страницы наполнены; временные тексты и изображения заменены.
• Основные и ошибочные сценарии пройдены на утверждённых данных и устройствах.
• Проверены интеграции, формы, доставка уведомлений и права пользователей.
• Выполнены согласованные проверки SEO и производительности.
• Настроено резервное копирование; проверка восстановления задокументирована.
• Владелец получил доступы, исходные материалы и перечень лицензий и сервисов.
• Переданы инструкции редактору, описание интеграций и порядок дальнейшего обслуживания.

Этапы и изменения: чем заканчивается каждая часть работы

Для этапа укажите результат, согласующего, срок ответа и условия перехода дальше. Ниже — пример последовательности; часть работ может идти параллельно.

1. Обследование и ТЗ. Результат — согласованные требования, перечень открытых вопросов и состав первой версии.
2. Структура и прототипы. Результат — карта страниц, схемы шаблонов и пользовательские сценарии.
3. Дизайн. Результат — макеты согласованных шаблонов и их состояний для нужных размеров экрана.
4. Разработка и подключения. Результат — работающий тестовый сайт, настройки управления и интеграции.
5. Наполнение и испытания. Результат — согласованный контент, выполненные проверки и перечень исправлений.
6. Запуск и передача. Результат — сайт на рабочем адресе, доступы, документация и согласованный порядок сопровождения.

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

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

Частые ошибки в ТЗ: плохо и хорошо

Сравним формулировки на учебных примерах. Вариант «хорошо» показывает нужную конкретику; перечни данных, сроки и пределы проверок всё равно предстоит заполнить под проект.

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

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

Частые вопросы

Нужно ли ТЗ для небольшого сайта?

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

Заказчик обязан написать документ сам?

Распределение работ нужно согласовать с исполнителем. Заказчик может подготовить бизнес-задачи и материалы, а аналитик — превратить их в технические требования. В любом случае подтвердить правила продаж, источники данных и приоритеты должен уполномоченный представитель заказчика.

Можно ли ограничиться ссылкой на понравившийся сайт?

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

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

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

Как понять, что ТЗ уже можно согласовывать?

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

Источники

Первичные документы и официальная документация проверены 27 октября 2026 года. Оглавление, роли, таблицы требований и сценарии приёмки — практические рекомендации автора, а не универсальные нормативы или кейсы студии.

• ГОСТ 34.602-2020: статус и область применения — официальная карточка Росстандарта; текст пунктов 3.4, 3.5, 4.1 и 4.2 — правовая база ГАРАНТ.
• Навигация и адреса — Яндекс Вебмастер, «Структура сайта».
• Основы технической и содержательной подготовки к поиску — Google Search Central, SEO Starter Guide.
• Мобильное содержимое — Google Search Central, Mobile-first indexing best practices.
• Назначение robots.txt и его ограничения — Google Search Central, Introduction to robots.txt.
• Метрики и ориентиры пользовательского опыта — Philip Walton, web.dev, Web Vitals, обновление от 31.10.2024.
• Возможности обмена с учётной системой — 1С-Битрикс, курс «Интеграция с 1С», «Введение», редакция от 01.04.2026.
• Поля и наследование SEO-настроек — 1С-Битрикс, создание и редактирование элемента инфоблока.
• Совместимость окружения — 1С-Битрикс, технические требования продукта.
• Основания обработки персональных данных и согласие — Федеральный закон № 152-ФЗ, статья 6 и статья 9, действующий текст в КонсультантПлюс, редакция закона от 26.07.2026.