Техническое задание на сайт: от задачи бизнеса до приёмки

Зачем сайту техническое задание

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

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

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

Согласуйте ограничения и состав первого выпуска

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

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

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

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

Составьте карту страниц по задачам посетителей

Опишите группы посетителей через их задачи: новый клиент выбирает услугу; покупатель ищет товар по артикулу; партнёр скачивает документ. Так проще определить страницы и действия. Возраста и пола аудитории для проектирования интерфейса недостаточно.

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

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

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

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

Опишите функции через данные и состояния

Каталог и поиск

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

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

Формы и подтверждение отправки

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

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

Личный кабинет и права

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

Определите обмен данными и ответственность сторон

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

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

Опишите нештатные ситуации: сервис недоступен, ответ не пришёл вовремя, запись уже существует, часть полей не принята. Нужны правила повторной попытки и обнаружения дублей, место для журнала ошибок и ответственный за разбор. Отдельно разберите случай, когда сайт принял заявку, но CRM не ответила: где сохранится обращение и кто узнает об ошибке?

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

Задайте требования к скорости, адаптивности и поиску

Вместо «сайт быстро работает» выберите страницы, устройства, сеть и показатели. Порог согласуйте после оценки исходных данных. Укажите число повторов и порядок сравнения: случайно удачный замер не должен становиться основанием для приёмки.

В Web Vitals различаются загрузка, отзывчивость и визуальная стабильность. Свяжите выбранные показатели с важными сценариями: появлением основного содержимого, открытием меню или фильтра.

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

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

Для поисковой оптимизации опишите адреса, заголовки и метаданные, правила индексации служебных страниц, карту сайта и внутренние ссылки. При замене действующего сайта подготовьте соответствие старых и новых URL. Google Search Central рекомендует планировать постоянные перенаправления и обновление ссылок при изменении адресов. Эти работы нужно включить в состав проекта до запуска.

Как записать критерии приёмки

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

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

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

Соберите документ по рабочей структуре

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

1. Паспорт проекта. Название, ответственные, версия документа, цель и ограничения.
2. Состав выпуска. Обязательные функции, отложенные задачи и открытые вопросы.
3. Аудитория и сценарии. Кто приходит, откуда начинает и какой результат получает.
4. Карта и шаблоны страниц. Адреса, блоки, связи и нестандартные состояния.
5. Функции и данные. Поля, правила, поиск, формы, роли и права.
6. Интеграции. Направления обмена, источники данных, ошибки и ответственные.
7. Материалы и управление. Кто готовит тексты, изображения и переводы; как их обновляют.
8. Качество. Скорость, адаптивность, доступность и требования к поисковой оптимизации.
9. Приёмка. Сценарии, тестовые данные, подтверждения и порядок работы с замечаниями.
10. Запуск и передача. Развёртывание, резервная копия, возврат, доступы и инструкции.

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

Согласуйте материалы, изменения и порядок запуска

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

Новое пожелание записывают, оценивают влияние на функции, сроки и стоимость, затем согласуют новую версию ТЗ. Даже одно поле может затронуть CRM, выгрузку и права доступа.

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

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

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

Чтобы начать составление ТЗ, достаточно собрать текущие страницы, задачи пользователей и список ограничений. Если нужна помощь с разработкой или обновлением сайта, обсудите этот набор с командой ШТАБ ИТ. По этим материалам можно уточнить спорные пункты ТЗ и оценить разработку.