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