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