Техническое задание на сайт: состав и проверяемые примеры
Структура ТЗ и проверяемые требования от страницы до сохранённой заявки.
Содержание статьи
Техническое задание на сайт фиксирует конкретные страницы, действия посетителя, источники данных, обязанности сторон и способ проверки результата. Начните с одной таблицы: задача, требование, пример содержимого, критерий приёмки, ответственный. Затем опишите спорные состояния форм, каталога и интеграций. Ниже приведена структура документа и формулировки, которые можно перенести в свой проект после замены учебных данных.
С каких сведений начать, если документа ещё нет
Заказчику достаточно подготовить сведения о продукте и процессе продажи: кому продают, что человек должен понять на сайте, какое действие совершить, какие ограничения нельзя скрывать. Исполнитель превращает это в карту страниц и технические сценарии. Участники вместе проверяют, одинаково ли понимают каждое требование. Автором файла может быть любой из них; важны согласование и возможность выполнить проверку.
Например, компания оказывает три вида обслуживания оборудования. Для первого обращения ей нужны город, тип оборудования и контакт. Если это записано, можно обсудить форму и приём заявок. Если написано только «сайт должен продавать», исполнитель не узнает, чем отличается обращение из другого города от подходящего запроса. Приложите актуальные документы, пример заявки и вопросы, которые менеджеры задают перед расчётом. Личные данные реальных клиентов в общий документ переносить не требуется.
Разделите обязательную первую версию и гипотезы развития. Строка «личный кабинет позже» не должна превращаться в часть текущей приёмки. Для отложенной функции укажите причину, от которой зависит решение, и данные, которые уже сейчас нужно не потерять. Например, будущий каталог влияет на выбор структуры и системы управления, хотя карточки ещё не создаются.
| Поле задания | Что записать | Чем проверить |
|---|---|---|
| Задача посетителя | «Выбрать обслуживание и запросить расчёт» | Посетитель находит условия и рабочую форму |
| Граница услуги | Города, тип оборудования, порядок осмотра | Сведения видны до отправки контакта |
| Объём первой версии | Три услуги, общая форма, без кабинета | Список URL и функций совпадает со сметой |
| Ответственный | Кто даёт цены, фото, доступы, согласование | У каждого материала есть владелец и срок передачи |
Как описать структуру без списка из сотни одинаковых страниц
Укажите карту разделов и шаблоны. URL является адресом конкретной страницы; шаблон задаёт её тип и поведение. Тридцать услуг могут использовать один шаблон, но содержимое каждой услуги нужно подготовить отдельно. В смете и ТЗ считайте обе величины. Иначе подрядчик может включить один экран дизайна, а заказчик ожидать тридцать готовых текстов.
Для каждого шаблона запишите обязательные поля. Страница услуги: заголовок, состав, ограничения, факторы стоимости, этапы, вопросы и форма. Карточка товара: название, характеристики, варианты, наличие, документы и действие. Статья: заголовки, иллюстрации, таблицы и связанные страницы. Для каждого типа укажите один заполненный пример на реальном содержании; заглушка не показывает, выдерживает ли макет длинную цену, таблицу или предупреждение.
Добавьте правила адресов: какой URL остаётся у существующего сайта, как формируются новые адреса, кто утверждает удаления. Если создаётся сайт взамен старого, сохраните важные статьи и документы. Смена адресов оформляется отдельной картой старого и нового URL. Перенос домена детально разобран в плане переезда; в ТЗ достаточно указать объём переноса и способ приёмки.
Функция описывается действием, ответом сайта и ошибкой
Фраза «добавить форму» оставляет открытыми все решения. Укажите поля, обязательность, допустимый формат контакта, способ отправки, место сохранения, получателя уведомления и сообщение человеку. Для каждого шага запишите альтернативу: пустое поле, неверный телефон, медленная сеть, повторное нажатие, недоступная внешняя система. Отправка считается успешной после выбранного в проекте подтверждения приёма, которое можно проверить.
Пример требования к заявке
На странице услуги посетитель вводит имя, телефон и выбирает вид работ. После корректной отправки сервер сохраняет обращение с идентификатором, возвращает подтверждение, а страница показывает результат. При ошибке обязательного поля данные сохраняются в форме и рядом с полем появляется объяснение. При недоступности сервера человек видит возможность повторить попытку. При повторе одной отправки с тем же идентификатором запроса сервер возвращает уже созданный результат и не создаёт вторую запись. Это учебный вариант правила против дублей; механизм идентификатора и срок его хранения согласуют для конкретной формы. Тестовая заявка находится по времени и идентификатору в системе приёма.
Пример строки ТЗ F-01 для копирования
Условие: страница ремонта, услуга выбрана, телефон заполнен. Действие: отправить форму, затем повторить тот же идентификатор запроса. Ожидаемый результат: одна запись с услугой и идентификатором, подтверждение после сохранения. Ошибка: пустой телефон оставляет введённые данные и не создаёт запись. Доказательство: время теста, снимок сообщения и одна запись в системе приёма без реального контакта клиента.
Уточните, что происходит после сохранения. Контакт может существовать в журнале, хотя уведомление в почте или мессенджере не пришло. В ТЗ задайте отдельный статус доставки и порядок повторной отправки уведомления. Так разработчик может показать, где пропала заявка, а менеджер не принимает надпись на экране за доказательство получения контакта. Если заявка передаётся в систему управления клиентами, сокращённо CRM, назовите систему и состав полей.
Справка Яндекс Метрики предупреждает, что автоматическая цель отправки формы при определённой реализации может учитывать безуспешную попытку. Поэтому в задании разделяйте «нажал», «сервер принял» и «менеджер получил». Событие аналитики должно соответствовать выбранному определению обращения. Само событие не заменяет запись в системе приёма.
Что написать об интеграциях до оценки
Для каждой внешней системы сделайте карточку: название и применимая версия, владелец доступа, направление обмена, поля, частота, обработка повторов и ошибок, тестовая среда, ответственный за обслуживание. «Подключить CRM» может означать передачу телефона, а может включать товары, статусы, историю и обратные уведомления. Разница меняет работу и цену; её нельзя решать после утверждения сметы.
Для каталога уточните источник цены и остатка: сотрудник меняет их в админке или они приходят из учётной системы. Что делать, если обмен не прошёл? Сайт показывает последний известный остаток с датой, временно скрывает покупку или даёт возможность уточнить наличие? Ответ зависит от бизнеса. У оплаты укажите успешный, неуспешный и повторный ответ платёжной системы; для возврата и частичной оплаты может понадобиться отдельный сценарий.
Нарисуйте направление данных обычными словами: «из формы сайта в CRM», «из учётной системы в каталог», «из заказа в сервис доставки». Если обмен двусторонний, назовите, где находится источник истины при конфликте. Затем попросите оценить интеграции раздельно. Цена сервиса, доступ к программному интерфейсу (API) и работа специалиста сторонней системы могут оплачиваться отдельно; это фиксируется в составе предложения.
Кто готовит тексты, изображения и данные
Сделайте таблицу материалов: страница, требуемые сведения, источник, автор, проверяющий, срок передачи, статус права использования. Для страницы услуги это может быть описание процесса от специалиста, фотографии собственной работы и утверждённые условия. Для карточки товара нужны характеристики из надёжного источника. Не копируйте чужой каталог. Если текст и фото поставляет заказчик, укажите формат файлов и того, кто обрабатывает изображения.
Макет на временных фразах нельзя принять как окончательно наполненную страницу. Длинное наименование, разные единицы измерения и реальная таблица меняют высоту и поведение на телефоне. Попросите проверить минимум один сложный пример каждого шаблона. Если материалы задерживаются, разделите приёмку шаблона и наполнение: запишите, какая работа объективно готова и что ещё зависит от сведений заказчика.
Отдельно определите права на исходники дизайна, фотографии, иконки и шрифты. При передаче сайта владельцу нужны доступы и разрешённые для дальнейшего использования материалы. Наличие картинки в макете ещё не подтверждает право публиковать её. Список внешних сервисов поможет проверить, не исчезнет ли изображение или шрифт после прекращения подписки.
Как согласовать дизайн и мобильное поведение
Ссылки на понравившиеся сайты полезны, если подписано, что именно нужно перенести: плотность информации, размер шрифта, поведение меню, способ показать цену, оформление формы. Требование «как у конкурента» не сообщает, какие части нужны и уместны. Приложите прототип ключевых шаблонов с реальным содержимым, затем согласуйте состояния, которые нельзя показать одной красивой картинкой.
Для мобильного экрана опишите порядок блоков, длину заголовка, вид таблицы, поведение меню и доступность формы. Проверьте портретный телефон, узкий телефон и широкий экран. Если есть модальное окно, опишите закрытие с клавиатуры и возвращение к тому месту, откуда его открыли. Уточните, какие браузеры важны по аудитории проекта. Абстрактное «работает на всех устройствах» не задаёт воспроизводимых условий.
После утверждения макета проведите мини-приёмку пути: человек попадает на страницу из объявления, узнаёт цену или условия, открывает форму, исправляет ошибку и отправляет запрос. Если на макете нет места для ограничения услуги, не откладывайте решение до вёрстки. Исправление структуры на этом этапе дешевле, но сумму экономии без проекта назвать нельзя.
Как записать требования к скорости, поиску и доступности
Укажите страницы для проверки производительности и метод измерения: мобильный лабораторный тест, реальные данные при их наличии, состояние сторонних скриптов и дату. Число в баллах без этих условий нестабильно. Для текущего сайта исходный замер делают до изменений; для нового сайта проверяют согласованные страницы после публикации. Смысл показателей LCP (время появления крупнейшего элемента), INP (задержка отклика) и CLS (сдвиги макета), а также порядок исправления приведены в статье о скорости сайта.
Для поисковой доступности задайте управление заголовком и описанием страницы, корректный адрес, обычные внутренние ссылки, статус ответа сервера, карту сайта и правила индексирования. Запишите, какие страницы не должны появляться в поиске: личные данные, тестовый стенд, служебный поиск. Для переноса существующего сайта добавьте сверку старых и новых адресов. Это техническая готовность. Место в выдаче из неё не следует.
Для доступности и взаимодействия определите базовые действия: текст читается без горизонтальной прокрутки страницы, форма доступна с клавиатуры, ошибка названа словами, изображение несёт смысл через подпись или альтернативный текст, анимация учитывает системное уменьшение движения. Проверьте эти действия на реальном шаблоне. Одной отметки «адаптивно» недостаточно для всего проекта.
Какие технические данные нужны для запуска и восстановления
Согласуйте владельца домена, хостинга, системы управления, аналитики и внешних сервисов. Назначьте роли доступа, чтобы редактор не получал права администрировать сервер без необходимости. Зафиксируйте, кто обновляет компоненты, кто замечает сбой и как восстанавливается сайт. Резервная копия полезна, когда известны её состав, место хранения и проверен способ возврата.
Для сайта с базой данных копия файлов не обязательно содержит статьи, товары и заявки. В задании опишите, какие данные сохраняются и с какой частотой, кто проверяет восстановление, как не затереть новые обращения при возврате интерфейса. Конкретный порядок зависит от технологии. Не требуйте раскрывать пароли в общем ТЗ; укажите ответственного и безопасный способ передачи доступов при запуске.
Если проект меняет работающий сайт, подготовьте план переключения: резервная копия, проверенная новая версия, окно запуска, контроль форм и контактов, условия отката. Критерии отката должны быть наблюдаемыми, например массовые ошибки сервера или невозможность принимать обращения. Смена домена и изменение базы имеют разные процедуры восстановления; их не стоит смешивать в одной команде «вернуть всё».
Как превратить ТЗ в план приёмки
Для каждого требования определите доказательство. Страница проверяется опубликованным URL и содержимым; форма контрольным обращением и записью в системе; импорт сравнением количества и выборочной сверкой полей; скорость отчётом с датой и условиями; передача проекта действующими доступами и проверкой восстановления. Указывайте исполнителя проверки и место результата. Список галочек без артефактов быстро становится спорным.
Пример одной строки приёмки
Требование: «Заявка с мобильной страницы ремонта сохраняется с выбранной услугой». Исходные данные: тестовый телефон, услуга «ремонт», время отправки. Действие: отправить форму с мобильного соединения и повторить тот же запрос. Ожидаемое: одна запись с правильной услугой и идентификатором; подтверждение на странице появляется после сохранения. Проверка ошибки: при пустом телефоне запись не создаётся и введённые данные остаются. Это учебный пример. Действующий сайт по нему не измерен.
Запишите перечень критических дефектов, при которых публикация не принимается: неработающая форма, потеря важных страниц при переносе, ошибки оплаты, открытый тестовый стенд. Косметические замечания можно вести отдельно с датой исправления. Такая граница помогает выпустить работоспособный сайт и не называть скрытую поломку «мелкой правкой».
После приёмки получите список действующих URL, исходники в согласованном объёме, инструкцию редактора, права доступа и перечень сервисов с ответственными. Проведите тест обычной редакторской операции: сотрудник меняет текст услуги, публикует страницу и при необходимости возвращает предыдущую версию. Если эта задача входит в ожидаемую работу команды, без неё нельзя считать передачу завершённой.
Что добавить в ТЗ интернет-магазина
Для магазина перечислите источники данных о товарах, вариант товара, правило наличия, цену и скидку, оформление заказа, оплату, доставку и возврат в той мере, в какой они относятся к проекту. Укажите, где именно меняют карточку: в системе управления сайтом (CMS) или в учётной системе. Если данные приходят по обмену, зафиксируйте частоту и поведение при сбое. «Каталог на тысячу товаров» без качества исходной таблицы, вариантов и правил импорта не позволяет надёжно оценить работу.
Проверьте крайние состояния. У товара нет фотографии; вариант закончился; цена в источнике изменилась во время оформления; платёж прошёл, но страница подтверждения не открылась; покупатель нажал кнопку дважды. Для каждого случая запишите ожидаемое действие сайта и где менеджер видит заказ. Объём таких сценариев зависит от бизнеса, поэтому нельзя копировать универсальную форму ТЗ и считать все строки обязательными. Но если магазин принимает деньги, путь потери или дублирования заказа должен быть описан до запуска.
У каталога без онлайн-оплаты требования другие. Посетитель выбирает позиции, отправляет запрос и ждёт расчёт. Тогда проверьте состав отправляемого списка, возможность изменить количество и сохранение контекста выбранных товаров. Не требуйте корзину с оплатой только потому, что подрядчик назвал сайт магазином. Результат теста: менеджер получил именно те позиции и варианты, которые выбрал посетитель.
Как связать требование, смету и тест
Добавьте к требованиям короткие идентификаторы. Это помогает говорить об одной функции в ТЗ, оценке и акте проверки, даже если текст документа менялся. Например, F-01 относится к сохранению заявки, C-02 к импорту каталога, M-03 к карте старых адресов. Идентификатор сам ничего не доказывает; рядом должны стоять ожидаемый результат и артефакт проверки.
| Требование | Работа в оценке | Проверка |
|---|---|---|
| F-01: сохранить заявку с услугой | Форма, обработчик, место хранения | Тестовый контакт виден с выбранной услугой |
| C-02: обновить цену из источника | Обмен и сопоставление товара | Изменённая цена видна после согласованного обновления |
| M-03: сохранить важные URL | Опись и правила перенаправления | Старые адреса ведут к соответствующим новым |
Если в смете нет работы для обязательного требования, задайте вопрос до подписания. Если тест не показывает результат, перепишите критерий приёмки. Например, «интеграция работает» нужно заменить набором наблюдаемых проверок: отправить запись, увидеть поля, повторить запрос, обработать ошибку. Такая связь помогает отличить настоящую дополнительную функцию от исправления уже согласованного поведения.
Как проверить почти готовое ТЗ
Прочитайте документ глазами трёх участников. Посетитель должен понимать, где найдёт условия и как завершит действие. Редактор должен знать, как обновляет сведения и кто их утверждает. Разработчик должен видеть исходные данные, ошибочные состояния, интеграции и критерий сдачи. Если одна роль отсутствует, найдите конкретную задачу, которая остаётся без ответа. Например, форма описана технически, но никому не поручено проверять и отвечать на полученные контакты.
Затем сопоставьте список страниц со сметой. Для каждого шаблона есть хотя бы один заполненный пример? Понятно, кто готовит тексты и фото? Указано, какие старые адреса сохраняются? У форм есть проверка сохранения и уведомления? Есть перечень доступов, резервирования и способа возврата после ошибки? Ответ «будет сделано при запуске» годится только с владельцем задачи и проверяемым результатом.
Последний проход касается слов «быстро», «удобно», «надёжно», «современно» и «полностью». Замените их действием или измерением с условиями. «Удобно на телефоне» превращается в сценарий с шириной экрана, читаемым текстом и доступной кнопкой. «Быстро» превращается в список URL и метод замера. Не заменяйте неопределённость произвольной цифрой; если исходных данных нет, запишите этап измерения и решение после него.
Что делать с новой идеей во время разработки
Новое требование описывают отдельной записью: зачем оно нужно, к каким страницам относится, что меняется в данных и интерфейсе, как будет принято, влияет ли на согласованную смету и последовательность работ. Если функция заменяет прежнюю, укажите, что исключено. Команда должна видеть актуальную версию ТЗ и историю решений; отправленный в чате комментарий без переноса в документ легко потерять.
Перед согласованием последней редакции проведите короткую репетицию сдачи. Возьмите наиболее важное действие, например заявку по услуге, и пройдите его по документу без устных пояснений. Достаточно ли сведений, чтобы собрать форму, показать ошибку, сохранить запись и найти её у менеджера? Затем повторите для публикации материала редактором и для восстановления после сбоя. Если кто-то должен «догадаться на месте», допишите правило или назначьте решение на конкретный этап.
Проверьте взаимные зависимости. Аналитическое событие не должно вызываться до подтверждения приёма заявки. Платёж нельзя тестировать без тестового товара и понятного статуса заказа. Миграцию адресов нельзя принять без старой карты URL. Если нужные материалы предоставляет заказчик, запишите дату и формат передачи. Эти зависимости помогают составить порядок работ и не обещать запуск в день, когда ещё нет исходных данных.
Законченный документ доступен тем, кто будет принимать результат: владельцу продукта, редактору, разработчику и человеку, который обрабатывает обращения. Их замечания могут касаться разных частей сайта. Сверьте актуальную версию задания со сметой и протоколом проверки перед публикацией. После запуска сохраните её вместе с доступами и инструкцией, чтобы будущая команда понимала, почему функция устроена именно так.
Для небольшого сайта документ может оставаться коротким. Полноту проверяйте по рискам. Длина файла этого не показывает: форма и доставка, содержание и права, важные URL, мобильные состояния, интеграции, запуск и передача. Если раздел не относится к проекту, запишите это в рабочем составе. Не копируйте чужой шаблон с требованиями к оплате и каталогу, когда сайт только принимает запрос на услугу.
Перед оценкой покажите подрядчикам один и тот же документ. Тогда различия в предложениях можно объяснить составом работ и исключениями. Метод сравнения смет помогает проверить цену, а выбор между лендингом и сайтом помогает уточнить набор страниц. Если нужно подготовить реализацию, на странице разработки сайтов удобно обсуждать именно список требований и критерии приёмки.
Документация и источники
Редакция Webclub. Опубликовано 2026-10-03, обновлено 20.10.2026.
Обсудим задачу вашего сайта?
Пришлите адрес и опишите, что хотите исправить. Согласуем состав работ и порядок проверки.
ПОСМОТРЕТЬ СОСТАВ РАБОТ
