Как составить техническое задание на создание сайта

Зачем сайту техническое задание

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

Фраза «нужен современный корпоративный сайт» не определяет объём проекта. За ней могут скрываться пять информационных страниц или каталог на тысячи позиций, личный кабинет, обмен с 1С и десятки региональных разделов. Пока эти различия не зафиксированы, любая оценка будет приблизительной.

ТЗ полезно обеим сторонам:

1. Заказчик понимает, что именно получит.
2. Студия видит границы работ и зависимости.
3. Дизайнер проектирует реальные сценарии, а не абстрактный макет.
4. Разработчик заранее учитывает интеграции и ограничения.
5. SEO-специалист может заложить правильную структуру до запуска.
6. Приёмка проводится по списку требований, а не по субъективному впечатлению.

ТЗ не должно описывать каждую техническую мелочь понятным только программисту языком. Его задача — убрать неопределённость там, где она влияет на результат, сроки и стоимость.

Начните с целей, аудитории и целевых действий

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

Далее опишите основные группы посетителей. Для производственной компании это могут быть закупщики, проектировщики, дилеры и частные заказчики. Им нужны разные аргументы, документы и маршруты по сайту. Если объединить их в образ «клиента вообще», структура получится слишком общей.

Для каждой аудитории полезно зафиксировать:

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

Например, кнопка «Оставить заявку» сама по себе ничего не объясняет. Для одного проекта целевым действием будет запрос коммерческого предложения, для другого — подбор комплектации, запись на консультацию или загрузка технического задания.

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

Опишите структуру страниц и требования к контенту

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

Отдельно распределите ответственность за тексты, фотографии, видео, цены и документы. Если материалы предоставляет заказчик, установите формат и срок передачи. Если контент готовит студия, определите объём, источники информации и порядок согласования.

Структуру лучше проверять на реальных сценариях. Может ли посетитель за два-три понятных шага найти нужную услугу? Видит ли он следующий шаг после прочтения? Не спрятан ли важный ассортимент в одном общем разделе?

Если сайт будет продвигаться, зафиксируйте участие SEO-специалиста до дизайна. Исправлять структуру после вёрстки дороже, чем сразу разделить спрос на подходящие посадочные страницы. Подробнее об этом — в материале «Как спроектировать структуру сайта для SEO».

Перечислите функции, роли и интеграции

Для каждой функции опишите не только название, но и ожидаемый сценарий. «Интеграция с CRM» может означать простую передачу формы или двусторонний обмен статусами, товарами и ценами. Это совершенно разный объём работ.

Проверьте, нужны ли проекту:

• формы с разными наборами полей;
• каталог, поиск, фильтрация и сравнение;
• корзина, оплата и расчёт доставки;
• личный кабинет и история заказов;
• импорт товаров или прайс-листов;
• обмен с CRM, 1С, складом или телефонией;
• мультирегиональность и несколько языков;
• генерация документов;
• роли редакторов и разграничение прав;
• уведомления по электронной почте или в рабочий канал;
• передача целей в аналитику.

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

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

Зафиксируйте технические требования и приёмку

В ТЗ должны быть проверяемые требования к качеству:

• адаптация под основные размеры экранов;
• корректная работа в актуальных браузерах;
• защищённое соединение HTTPS;
• понятные адреса страниц;
• редактируемые Title, Description и заголовок H1;
• канонические адреса и карта сайта;
• страница 404;
• защита и валидация форм;
• подключение аналитики и целей;
• базовая оптимизация изображений;
• резервное копирование и порядок восстановления;
• соблюдение требований к персональным данным.

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

Опишите этапы приёмки: прототип, дизайн, тестовая версия, контент, перенос на основной домен. Для каждого этапа установите срок проверки и способ передачи замечаний. Практичнее собирать их одним списком от ответственного сотрудника, а не получать противоречивые сообщения от нескольких участников.

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

Какие ошибки делают ТЗ бесполезным

Копирование чужого документа. Требования большого маркетплейса не подходят сайту небольшой компании и создают лишнюю стоимость.

Описание только внешнего вида. Референсы полезны, но не заменяют цели, сценарии и функции.

Отсутствие приоритетов. Если всё обозначено как обязательное, первую версию невозможно сократить без конфликта.

Неучтённый контент. Проект технически готов, но запуск откладывается из-за фотографий, переводов или сотен незаполненных карточек.

SEO после запуска. Новая структура может потребовать переделки меню, URL и шаблонов.

Нет критериев готовности. Стороны спорят о слове «современно», хотя нужно проверять конкретные экраны и действия.

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