Техническое задание на сайт: что обязательно включить и как не переплатить подрядчику

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

Без ТЗ подрядчик оценивает проект по собственным допущениям. Один заложит готовый шаблон, другой — уникальный дизайн и разработку с нуля. Цены различаются в 3–5 раз, а сравнить их невозможно.

Вот что чаще всего происходит, когда ТЗ нет или оно написано в одну страницу:

• Размытая смета. Подрядчик указывает «разработка сайта» одной строкой, а детали всплывают позже как дополнительные работы.
• Бесконечные правки. Без зафиксированных макетов и сценариев каждое «мне кажется, тут не то» превращается в спор.
• Срыв сроков. Недостающие данные и поздние согласования сдвигают запуск на недели.
• Проблемы с поддержкой. Нет документации, и менять подрядчика дорого: новая команда разбирается в чужом коде вслепую.

Важно понимать и обратную сторону. ТЗ на 80 страниц, которое никто не читает, тоже не помогает. Для лендинга достаточно 3–5 страниц, для корпоративного сайта — 10–20, для интернет-магазина с интеграциями — 25–40. Объём должен соответствовать сложности проекта.

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

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

1. Общие сведения. Компания, описание бизнеса, продукты, география, текущий сайт (если есть) и его проблемы.
2. Цели и задачи проекта. Что сайт должен дать бизнесу в цифрах.
3. Целевая аудитория и сценарии. Кто приходит, зачем и что должен сделать.
4. Структура сайта. Карта разделов и страниц, типы шаблонов страниц.
5. Дизайн и UX. Референсы, брендбук, требования к адаптивности, прототипы.
6. Функциональные требования. Формы, каталог, поиск, личный кабинет, калькуляторы.
7. Интеграции. CRM, аналитика, платёжные системы, 1С, мессенджеры.
8. SEO-требования. Метаданные, URL, скорость, разметка, редиректы.
9. Технические требования. CMS, хостинг, безопасность, браузеры, нагрузка.
10. Этапы, сроки и приёмка. План работ, критерии готовности, гарантия.

Приведём короткий пример формулировки в разделе целей: «Увеличить количество заявок с сайта с 40 до 100 в месяц за 6 месяцев после запуска при текущем трафике 5 000 визитов. Конверсия формы — не менее 2%». Такая запись понятна и подрядчику, и вам: по ней можно измерить результат.

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

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

Цели формулируйте по принципу измеримости. Вместо «повысить узнаваемость» пишите «выйти на 3 000 органических визитов в месяц к концу шестого месяца». Вместо «больше продаж» — «обеспечить 150 заказов в месяц при среднем чеке 4 500 ₽». Два-три приоритетных показателя лучше десяти размытых пожеланий.

Аудиторию описывайте через задачи и ситуации, а не через возраст и пол. Для B2B-сайта это может быть так: «Руководитель отдела закупок выбирает поставщика, сравнивает 3–4 компании, ищет прайс, сроки и кейсы, хочет получить КП в течение дня».

Для каждого сегмента зафиксируйте:

• с какого устройства и канала человек приходит (поиск, реклама, рассылка);
• какой вопрос у него возникает на первом экране;
• какое целевое действие вы от него ждёте;
• какие возражения мешают это действие совершить.

Затем опишите ключевые сценарии. Сценарий — это путь от входа до цели: «Пользователь из поиска попадает на страницу услуги → смотрит цены и кейсы → оставляет заявку в форме из трёх полей → получает подтверждение на почту и в мессенджер». Достаточно 3–6 основных сценариев.

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

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

Например, вместо «форма заявки» напишите: «Форма с полями имя, телефон (маска +7), комментарий. Валидация на стороне клиента и сервера. После отправки — сообщение об успехе, письмо менеджеру и создание сделки в CRM. Защита от спама: скрытое поле и reCAPTCHA». Разница в трудозатратах между этими двумя формулировками может составлять несколько часов, а то и дней.

Типовой набор функциональных блоков:

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

Интеграции — главный источник скрытых расходов. Укажите каждую систему, направление обмена данными и частоту: «Выгрузка остатков из 1С раз в 15 минут, передача заказов в 1С сразу после оплаты». Для магазинов это критично, подробнее о специфике можно прочитать на странице разработки интернет-магазинов.

SEO-требования нужно закладывать в ТЗ до дизайна, а не после запуска. Минимальный список: ЧПУ-адреса, уникальные title, description и H1 для каждой страницы, управление ими из админки, файлы robots.txt и sitemap.xml, канонические адреса, микроразметка (Organization, Product, FAQ, хлебные крошки), настройка 301-редиректов со старых URL. Добавьте измеримые требования к скорости: например, LCP не более 2,5 секунды, оценка в PageSpeed Insights не ниже 80 для мобильной версии.

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

Когда ТЗ готово, отправьте его 3–5 исполнителям одновременно. Так вы получите сопоставимые предложения, а не набор разных интерпретаций. Попросите разбить смету по этапам: аналитика, дизайн, вёрстка, программирование, интеграции, тестирование, наполнение, запуск.

Что проверять в предложениях:

1. Соответствие объёму. Каждый пункт ТЗ должен иметь отражение в смете. Пропущенные позиции — повод для вопросов, а не для радости от низкой цены.
2. Почасовая или фиксированная стоимость. Для чётко описанного проекта выгоднее фикс, для развивающегося продукта — гибкая модель с лимитом.
3. Состав команды. Кто будет работать: дизайнер, разработчик, аналитик, тестировщик, менеджер.
4. Гарантия и поддержка. Срок бесплатного исправления ошибок обычно 1–3 месяца.
5. Права и доступы. Исходный код, дизайн-макеты и административные доступы передаются вам.

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

На приёмке ориентируйтесь на чек-лист из ТЗ. Проверьте работу форм и отправку данных в CRM, отображение на реальных устройствах (минимум iOS, Android, Chrome, Safari), корректность метаданных и редиректов, скорость загрузки, работу админ-панели. Принимайте работу поэтапно и подписывайте акты только после устранения замечаний. Для сложных проектов, таких как корпоративный сайт, заложите отдельную фазу тестирования на 1–2 недели.