«Нужен удобный сайт с каталогом и формой» помогает начать разговор, но оставляет слишком много вопросов. Какие товары попадут в каталог? Как работает поиск? Куда уходит обращение? Мы в «Гуси-Лебеди» предлагаем превращать пожелания в понятные требования и сразу определять, как их проверить. Ниже разберём структуру технического задания на сайт и покажем учебные примеры формулировок.
Для чего нужно техническое задание на сайт
Техническое задание на разработку сайта описывает ожидаемое поведение, состав и ограничения проекта. Оно помогает заказчику, дизайнеру, разработчику и проверяющему говорить об одном результате. Условие «в форме есть телефон» гораздо уже, чем «посетитель может отправить заявку и узнать, принята ли она».
Не путайте ТЗ с брифом. Бриф собирает исходные сведения и пожелания. ТЗ уточняет, что именно нужно сделать. Прототип показывает структуру экрана и переходы; макет задаёт визуальное решение. Эти материалы дополняют друг друга, поэтому в задании полезно указать их версии и связь с требованиями.
Не все детали можно знать до обследования. Неопределённые вопросы вынесите в отдельный список: например, наличие API у учётной системы или порядок обновления остатков. Не превращайте неизвестную возможность в обязательство без проверки.
Для небольшого проекта документ может быть коротким. Важнее, чтобы он охватывал существенные сценарии и позволял принять работу. Для сложного каталога потребуется больше подробностей. О составе проекта рассказываем в статье о планировании корпоративного сайта.
Кто готовит ТЗ и какие сведения собирает
Заказчик объясняет предложение, аудиторию, процессы и ограничения. Исполнитель помогает перевести эти сведения в структуру и проверяемое поведение. Полезно привлечь тех, кто будет пользоваться административной частью и принимать работу: их требования могут отличаться от ожиданий человека, который обсуждал только дизайн.
Соберите описание задач, список услуг или товаров, материалы бренда, действующие документы и сведения об интеграциях. Для существующего сайта нужны важные страницы, рабочие адреса и текущие сценарии. Не переносите старое содержание автоматически: сначала уточните, что актуально.
Отдельно договоритесь, кто предоставляет тексты, фотографии и переводы, кто проверяет достоверность условий и кто загружает материалы. Фраза «наполнение сайта» не определяет объём работы. Запишите типы материалов, ответственных, формат передачи и согласованный этап готовности.
Если решение ещё не выбрано, сначала проведите прототипирование страниц и сценариев. Так проще обнаружить противоречия в требованиях до разработки. Цена и сроки подготовки ТЗ зависят от обследования и детализации, универсальную оценку без состава проекта мы не приводим.
Что включить в структуру технического задания
Используйте шаблон как список вопросов, а не как текст для механического копирования. Для каждого раздела уточните, применим ли он к проекту, что известно и какие решения ещё предстоит принять.
| Раздел | Что описать | Что приложить |
|---|---|---|
| Задачи и границы | Для кого сайт, какие действия нужны, что входит в проект | Согласованный список работ |
| Структура и содержание | Разделы, типы страниц, материалы и связи | Карту страниц и перечень материалов |
| Функции | Поиск, фильтры, формы и состояния ошибок | Описание сценариев |
| Дизайн и адаптивность | Компоненты и поведение на разных экранах | Прототипы и макеты с версиями |
| Техника и интеграции | CMS, обмен данными, роли и ограничения | Описание систем и полей |
| Приёмка и запуск | Условия проверки и передачи проекта | Перечень проверок и ответственных |
Для CMS опишите редакционные действия: что сотрудник создаёт, меняет и публикует без разработчика. Название платформы само по себе не подтверждает эти возможности. Прежде чем закреплять решение, полезно разобраться, как выбрать CMS под задачи сайта.
В технической части определите поддерживаемые браузеры и устройства, условия проверки производительности, доступы, резервное копирование и ответственность за обновления. Требования к данным и доступам обсуждайте с ответственными за соответствующие процессы. Не копируйте настройки чужого проекта без оценки применимости.
Для SEO согласуйте структуру адресов, доступность содержания, метаданные, внутренние ссылки, Sitemap и правила обработки удалённых страниц. При переработке существующего ресурса нужен план сохранения или изменения адресов. Подробнее разбираем это в статье про подготовку редизайна и проверку запуска.
Как написать проверяемые требования
Удобная схема формулировки: кто выполняет действие, при каком условии, что делает система и как проверить результат. Слова «быстро», «красиво», «современно» и «интуитивно» могут обозначать пожелание, но без уточнений не дают общего критерия приёмки.
Учебный пример: вместо «поиск должен работать» запишите: «Посетитель вводит название товара, получает результаты с переходами в карточки; при отсутствии совпадений видит понятное сообщение и может изменить запрос». Затем определите, по каким полям выполняется поиск и как обрабатываются особенности написания.
Для дизайна перечислите фирменные материалы, ключевые компоненты и согласованные состояния. Референс поясняйте: нравится порядок содержания, расположение карточек или характер иллюстраций? «Сделать как на этом сайте» оставляет слишком много несовпадающих трактовок.
Для скорости укажите страницы, инструмент, устройство, сеть и условия сравнения. Один показатель без условий может дать разные результаты при повторной проверке. Не связывайте приёмку разработки с гарантированным количеством продаж: на него влияют и факторы за пределами интерфейса.
Пример требований к форме обращения и интеграции
Рассмотрим условную форму запроса консультации. Это пример для адаптации, не описание клиентского проекта. Сначала перечислите поля и определите, какие обязательны. Затем опишите проверку ввода, отправку, ошибку и подтверждение.
Названия полей должны оставаться понятными. В руководстве W3C по подписям элементов формы разобрана связь поля с его названием. Подсказка внутри поля не должна быть единственным способом понять, что требуется.
При ошибке посетитель должен узнать, что исправить. При успешной отправке нужно понятное подтверждение. Эти состояния описаны в рекомендациях W3C по уведомлениям. В ТЗ можно отдельно закрепить сохранение введённых значений при исправлении ошибки.
Интеграция требует собственных условий: куда отправляются данные, какие поля передаются, кто предоставляет доступ и что происходит, если принимающая система недоступна. Не считайте появление сообщения в браузере доказательством доставки заявки.
Приёмочный сценарий может включать отправку согласованных тестовых данных и проверку записи в целевой системе ответственным сотрудником. Дополнительно согласуйте поведение повторной отправки и журналирование ошибки. Конкретные правила выбираются под процесс проекта.
Как согласовать ТЗ, изменения и приёмку
Перед началом работ пройдите документ вместе: нет ли требований, которые противоречат друг другу, неизвестных зависимостей и функций без способа проверки. Укажите актуальную версию и место хранения. Участники должны видеть, по какому набору требований ведётся разработка.
| Ситуация | Что зафиксировать | Что проверить |
|---|---|---|
| Добавлена новая функция | Изменение объёма, оценки и этапов | Связь с остальными сценариями |
| Изменена интеграция | Систему, поля и ответственность | Условия доступа и доставки данных |
| Началась приёмка | Версию и перечень требований | Результат каждой проверки |
| Проект опубликован | Передачу материалов и доступов | Работу на публичном домене |
Новая просьба может затронуть уже согласованные макеты, данные и интеграции. Обсудите последствия до реализации и обновите требования. Это помогает сохранить понятные границы проекта, даже когда задачи меняются.
Проверяйте не только наличие элементов, но и результат действий. После запуска повторите существенные проверки на рабочем домене. Договоритесь, кто исправляет найденные ошибки и кто отвечает за дальнейшую поддержку.
Планируя разработку сайта по согласованным требованиям, начните с задач и критериев результата. Мы в Гуси-Лебеди предлагаем писать ТЗ так, чтобы его понимал человек, который будет пользоваться сайтом и принимать работу, а не только автор документа.