Техническое задание на сайт: требования и приемка
Техническое задание описывает, как должен работать сайт и по каким признакам команда примет результат. Его удобно строить вокруг страниц, сценариев посетителя и правил обмена данными. Покажем структуру ТЗ и пример требований к форме заявки.
Содержание статьи
Чем ТЗ отличается от брифа
Бриф отвечает на вопросы о бизнесе, аудитории и задаче проекта. ТЗ переводит эти сведения в проверяемые требования. «Клиенты должны легко связаться с нами» — цель. «На каждой странице услуги есть форма с выбором направления и подтверждением отправки» — уже описание поведения.
Технические решения можно уточнять поэтапно. Если неизвестно, позволяет ли учетная система отдавать нужные остатки, сначала нужно исследовать обмен. Не стоит выдавать предположение о возможности интеграции за согласованное обязательство разработчика.
Укажите статус документа, версию и ответственных за согласование. Команде должно быть понятно, по какой редакции она работает и куда попадают новые требования.
Структура документа для небольшого проекта
| Раздел | Что фиксировать | Зачем это нужно |
|---|---|---|
| Назначение сайта | Аудитории, задачи и первый выпуск | Определить приоритеты |
| Страницы | Типы страниц, содержание, переходы | Оценить структуру и шаблоны |
| Сценарии | Действия посетителя и результат | Проверить работу функций |
| Данные | Поля, источники и владельцы | Предотвратить расхождения |
| Интеграции | События обмена, ошибки, повторы | Обработать сбои |
| Интерфейс | Состояния и адаптация | Проверить разные устройства |
| SEO | Адреса, метаданные, индексация | Подготовить доступные поиску страницы |
| Приемка | Условия проверки и исправлений | Определить готовность |
| Передача | Доступы, материалы, инструкции | Обеспечить дальнейшую работу |
Таблицу можно прокрутить вправо
Степень детализации зависит от проекта. Для сайта из нескольких страниц часть требований можно разместить в одной таблице. Для магазина с обменом остатками понадобится отдельное описание интеграции.
Описывайте сценарий от начала до результата
Возьмем форму запроса на расчет. В ТЗ нужно указать, где она расположена, какие сведения обязательны и что происходит после отправки. Согласование сообщения об успехе не заменяет проверку получения заявки.
Документация Tilda об ошибках форм прямо описывает сбой доставки данных в сервис приема, который может оставаться незаметным для посетителя. Поэтому приемочный сценарий должен заканчиваться проверкой записи в целевой системе.
Учебный фрагмент требований:
| Условие | Ожидаемое поведение | Как проверить |
|---|---|---|
| Обязательное поле пустое | Видна понятная подсказка у поля | Попытаться отправить форму |
| Данные заполнены | Посетитель получает подтверждение | Отправить тестовую заявку |
| Заявка принята | В CRM есть контакты, услуга и страница | Сверить поля записи |
| Посетитель нажал кнопку повторно | Команда понимает правило обработки дубля | Проверить согласованный сценарий |
| Сервис приема недоступен | Сбой обнаруживается ответственным | Проверить предусмотренный способ контроля |
| Соединение оборвалось | Интерфейс не обещает подтвержденный результат без основания | Проверить потерю связи в тестовой среде |
Таблицу можно прокрутить вправо
Конкретный способ обработки повторов и сбоев зависит от платформы. Если выбранный сервис не поддерживает требуемое поведение, это нужно выяснить до утверждения решения и согласовать доступный вариант.
Определите владельца каждого типа данных
Для каталога запишите, откуда приходят цена, остаток, название и фотография. Если цену меняют и в учетной системе, и в редакторе сайта, возникает конфликт. Правило приоритета должно быть однозначным.
В требованиях к обмену укажите частоту обновления, ключ сопоставления товара, обработку удаленных позиций и доступный способ увидеть ошибку. Отдельно разберите частичные данные: у товара появилась цена, но еще нет фотографии; заказ оплачен, а подтверждение в учетную систему задержалось.
Проверьте несколько конкретных объектов с разными свойствами. Успешная передача одного простого товара не доказывает корректность вариантов размера, нескольких складов или скидок. Состав тестовой выборки лучше согласовать заранее.
Что проверить в интерфейсе
В ТЗ перечислите поддерживаемые устройства и браузеры с учетом аудитории проекта. Формулировка «адаптивная версия» сама по себе не описывает поведение длинного меню, таблицы или карточки товара.
Проверьте узкий экран, длинные заголовки, отсутствие изображения, пустую выдачу поиска, ошибки заполнения и увеличение текста. Для интерактивных элементов нужны понятные состояния: обычное, фокус клавиатуры, ожидание, ошибка, успех.
Задайте способ проверки производительности: какие страницы, устройство и условия сети используются. Одна абстрактная оценка скорости без условий плохо подходит для приемки. Тяжелые изображения, внешние сервисы и аналитические скрипты стоит учитывать еще при проектировании.
SEO при создании и переносе сайта
Для типов страниц определите правила заголовков, описаний, основных H1 и канонических адресов. Решите, какие страницы должны попадать в поиск, а какие являются служебными. Проверьте внутренние ссылки, карту сайта и доступность контента без обязательного действия пользователя.
При редизайне составьте список существующих адресов. Для измененных URL подготовьте карту соответствий и постоянные перенаправления, где они применимы. Сохраняйте полезные страницы и ссылки на них; случайная смена адресов может нарушить путь посетителя из поиска.
Наличие SEO-полей не гарантирует позиции. В ТЗ можно зафиксировать корректность технической подготовки, но нельзя обещать место в выдаче как результат одной настройки сайта.
Как согласовать приемку и изменения
Свяжите существенные требования с проверками. Например: требование Ф-03 — передача услуги в CRM; проверка — тестовая заявка с конкретным значением и сверка созданной записи. Такая связь помогает быстро понять, что готово и где есть дефект.
Новые пожелания записывайте отдельно с причиной, влиянием на сроки и решение о включении. Ошибка относительно согласованного требования и новая функция требуют разного обсуждения. Спорные случаи разбирайте по актуальному документу и условиям проекта.
До запуска проверьте работу на опубликованном домене, настройки приема обращений и служебные уведомления. Тестовые заявки должны быть обозначены для сотрудников, чтобы они не попадали в обычную обработку продаж.
Что получить при передаче сайта
Зафиксируйте владельцев домена и аккаунтов, порядок предоставления доступов, состав исходных материалов и инструкцию по типовым изменениям. Пароли передавайте согласованным защищенным способом, отдельно от общедоступного ТЗ.
Назначьте ответственного за обновления и контроль форм после запуска. В небольшом проекте достаточно короткой инструкции: как изменить услугу, где проверить заявку и к кому обратиться при сбое. Передача считается полезной, когда команда клиента может выполнить эти действия самостоятельно.
Продолжить разбор
Источники и материалы
Обсудить задачу с командой: Разработка сайтов.