Техническое задание на разработку сайта: структура, пример и чек-лист

Техническое задание на разработку сайта — это не формальность и не попытка заранее описать каждый пиксель. Хорошее ТЗ фиксирует цель проекта, границы работ, обязательные функции и способ приёмки результата. Оно защищает обе стороны от ситуации, когда заказчик ожидал интернет-магазин, а исполнитель оценил обычный каталог.

Чем ТЗ отличается от брифа

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

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

1. Общая информация о проекте

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

2. Цели и показатели

Фраза «сделать современный сайт» не задаёт измеримого результата. Цель может звучать так: получать обращения на разработку, представить каталог дилерам, принимать оплату или снизить нагрузку на менеджеров.

Полезные показатели: отправленные формы, звонки, оформленные заказы, скачанные документы, заявки дилеров. Целевые значения следует считать ориентиром, поскольку результат зависит не только от разработки, но и от трафика, цены и работы отдела продаж.

3. Аудитория и пользовательские сценарии

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

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

4. Структура сайта

Составьте перечень страниц:

• главная;
• услуги или категории каталога;
• карточка услуги или товара;
• о компании;
• портфолио и кейс;
• блог и публикация;
• контакты;
• политика конфиденциальности;
• страница результата отправки формы;
• системная страница 404.

Уточните, какие типы страниц заказчик сможет создавать самостоятельно.

5. Функциональные требования

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

Пример формы обратной связи:

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

6. Контент и ответственность

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

7. Дизайн

Опишите фирменные цвета, логотип, шрифты, желаемое впечатление и ограничения. Референсы полезны, если рядом написано, что именно нравится: навигация, ритм, фотографии или подача кейсов.

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

8. SEO-требования

Включите редактируемые Title и Description, один основной H1, человекопонятные адреса, canonical, sitemap.xml, robots.txt, перенаправления при смене URL, микроразметку по реальному содержимому и корректные коды ответа.

При редизайне отдельно составляется таблица старых и новых адресов. Без неё сайт может потерять накопленную видимость.

9. Аналитика и реклама

Укажите установку Яндекс Метрики, события для форм, телефонов и мессенджеров, передачу UTM-меток и требования к электронной торговле. Счётчик должен загружаться асинхронно и не блокировать отображение страницы.

10. Производительность и доступность

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

11. Безопасность и данные

Опишите HTTPS, резервное копирование, обновления, разграничение доступов, защиту форм и хранение персональных данных. Пароли и ключи нельзя пересылать внутри самого ТЗ.

12. Этапы и приёмка

Разделите проект на аналитику, прототип, дизайн, разработку, наполнение, тестирование и запуск. Для каждого этапа определите результат, число итераций и срок обратной связи.

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

Короткий чек-лист заказчика

• Понятна ли цель сайта?
• Утверждены ли страницы и функции?
• Назначены ли ответственные за контент?
• Описана ли мобильная версия?
• Зафиксированы ли SEO и аналитика?
• Понятно ли, что считается завершённой работой?
• Определены ли поддержка, права и доступы после запуска?

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

Что ТЗ не должно делать

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

Как оформлять изменения

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

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

Пример фрагмента ТЗ для формы

Задача: пользователь отправляет заявку на расчёт проекта.

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

Проверка: номер проверяется на допустимый формат, ошибка показывается рядом с полем.

Результат: данные получает менеджер, событие фиксируется в аналитике, пользователь видит срок ответа.

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

Частые вопросы

Кто должен писать ТЗ?

Лучший результат получается совместно: заказчик даёт бизнес-контекст, а подрядчик переводит его в проверяемые требования.

Нужно ли ТЗ для лендинга?

Да, но оно может быть коротким. Достаточно структуры, содержания, формы, адаптивности, аналитики и правил приёмки.

Можно ли изменить утверждённое ТЗ?

Можно. Важно письменно согласовать влияние изменения на цену и срок.