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

«Нам нужен современный сайт, как у конкурентов, только лучше» — так начинается немало первых разговоров с клиентами. Мы понимаем, что стоит за этой фразой: владелец хорошо знает свой бизнес, но не обязан знать, из чего состоит сайт. Проблема в том, что каждый участник проекта представляет этот «современный сайт» по-своему. Дизайнер видит анимации, программист — каталог с фильтрами, а владелец — просто удобную форму заявки и номер телефона в шапке. Через два месяца все трое разочарованы, хотя каждый честно сделал свою часть.

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

Зачем ТЗ, если можно договориться на словах

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

• Точная оценка. Без списка страниц и функций любая цена — это угадывание. Подрядчик либо закладывает запас «на неизвестное», либо называет низкую цифру, а потом выставляет дополнительные счета.
• Общий язык. Слово «каталог» для одного означает список с фото, для другого — фильтры, сравнение и избранное. В ТЗ мы записываем, что именно имеется в виду.
• Контроль границ проекта. Новые идеи появляются всегда. ТЗ позволяет честно отделить «это входило в договорённость» от «это новая задача, давайте оценим отдельно».
• Приёмка работ. Если в документе есть критерии, в конце не нужно спорить, «готов ли сайт». Мы просто проходим требования по пунктам.

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

Бриф и ТЗ: в чём разница и кто что пишет

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

	Бриф	Техническое задание
Кто заполняет	Клиент, иногда вместе с менеджером	Аналитик или проектный менеджер вместе с клиентом
Язык	Язык бизнеса: цели, клиенты, конкуренты	Язык требований: страницы, функции, правила, критерии
Объём	1–3 страницы	От 5 до 30+ страниц в зависимости от проекта
Для чего	Понять задачу и сориентироваться в бюджете	Точно оценить, выполнить и принять работу

Может ли клиент написать ТЗ сам? Может, и для небольшого сайта-визитки это вполне нормально. Но мы советуем другое распределение ролей: вы отвечаете за бизнес-часть (цели, аудитория, процессы, контент), а техническую часть составляет подрядчик и согласовывает с вами. Владелец не обязан знать, что такое кеширование или hreflang. Зато только он знает, как на самом деле обрабатываются заявки и что отвечает менеджер на звонок.

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

Структура ТЗ: десять разделов, которые мы заполняем всегда

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

1. Общая информация и цели

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

2. Аудитория и сценарии

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

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

Список всех страниц и шаблонов с вложенностью: главная, разделы, услуги, каталог, карточки, блог, контакты, служебные страницы (политика конфиденциальности, 404, благодарность после заявки). Для каждой страницы — её назначение одним предложением.

4. Описание страниц и блоков

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

5. Функционал

Формы и что происходит после отправки, поиск, фильтры, корзина, личный кабинет, калькуляторы, мультиязычность. Каждую функцию описываем через поведение, а не через название (об этом ниже).

6. Контент

Кто готовит тексты, фото, видео, переводы, в каком формате и к какому сроку. Сколько товаров или статей наполняет студия, а сколько — клиент.

7. Дизайн

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

8. Технические требования

CMS, хостинг, поддерживаемые браузеры и устройства, требования к скорости, безопасности, резервному копированию, доступам администратора.

9. SEO-требования и интеграции

Перенос старых URL, редиректы, мета-теги, микроразметка, аналитика. Связи с внешними системами: CRM, оплата, доставка, учёт, рассылки, мессенджеры.

10. Этапы, сроки и приёмка

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

От структуры к прототипу

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

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

Прототип — это чёрно-белая схема страницы: блоки, их порядок и примерное содержание, без цветов и картинок. На прототипе легко договориться о главном. Нужен ли калькулятор на первом экране? Где стоит форма? Сколько товаров в ряду на смартфоне? Правка прототипа занимает минуты, правка готового дизайна — дни.

Ещё один практический совет: прототипы мы делаем сразу и для десктопа, и для смартфона. Большинство посетителей сегодня приходит с телефона, и поисковые системы оценивают сайт прежде всего по мобильной версии. Поэтому мобильная версия в ТЗ — это не строка «сайт должен быть адаптивным», а отдельные схемы главных шаблонов. Подробнее — в материале «Как достичь успеха в mobile-first index».

Как формулировать требования: плохо и хорошо

Главное правило: каждое требование можно проверить. Если два человека могут по-разному ответить на вопрос «выполнено или нет», требование сформулировано плохо. Слова «удобный», «современный», «быстрый», «стильный», «простой» сами по себе ничего не значат. Их нужно раскрывать через конкретные действия, числа или примеры.

Размыто	Конкретно
Сайт должен быстро загружаться	На мобильном LCP главных шаблонов до 2,5 с по данным PageSpeed Insights
Удобная форма заявки	Поля: имя, телефон, комментарий (необязательный). После отправки — страница благодарности, письмо менеджеру и запись в CRM
Каталог с фильтрами	Фильтры по бренду, цене, размеру и наличию; несколько значений одновременно; счётчик товаров возле каждого значения
Админка должна быть простой	Менеджер без программиста добавляет товар, меняет цену, баннер на главной и статью в блоге
Сайт должен быть оптимизирован под SEO	Отдельные title, description и H1 для каждой страницы; редиректы со старых URL по таблице; XML-карта сайта; разметка BreadcrumbList
Как у конкурента	Ссылка на страницу и список, что именно взять: структуру блока цен и калькулятор, но не анимации

Функционал мы описываем через сценарии: кто, что делает и что в результате. Например, вместо «онлайн-запись» пишем: «Клиент выбирает услугу, специалиста и свободное время; видит только незанятые слоты; после подтверждения получает письмо и SMS; администратор видит запись в календаре и может её перенести». Такое описание сразу показывает разработчику, что нужен календарь занятости, уведомления и права администратора, то есть позволяет честно оценить работу.

Полезно также прописывать, что происходит в нестандартных ситуациях: товара нет в наличии, оплата не прошла, пользователь ввёл телефон без кода страны, форма отправилась дважды. Именно эти «краевые случаи» чаще всего забывают, а потом они съедают неделю на доработках.

Техническая часть: что зафиксировать, даже если вы не технарь

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

• CMS и владение кодом. На чём сделан сайт и сможете ли вы передать его другому подрядчику. Мы советуем распространённые системы и полные доступы для клиента: к хостингу, домену, админке, аналитике.
• Хостинг и домен. На кого оформлены. Домен, зарегистрированный на подрядчика, — одна из самых неприятных историй, с которыми к нам приходят.
• Скорость. Целевые показатели Core Web Vitals для главных шаблонов и условия проверки. Как мы подходим к этой задаче, описано на странице оптимизации сайта.
• Безопасность и бэкапы. SSL, регулярные резервные копии со сроком хранения, обновления CMS и плагинов, защита форм от спама.
• SEO при запуске. Если сайт уже существует и имеет позиции, в ТЗ обязательно есть таблица соответствия старых и новых URL с 301-редиректами. Базовые требования к тегам и структуре мы разбирали в статье «Внутренняя SEO-оптимизация сайта».
• Аналитика. Какие события отслеживаются: отправка форм, клики на телефон и мессенджеры, покупки. Без этого после запуска вы не будете знать, работает ли сайт.

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

Этапы и приёмка: как не застрять в правках

Больше всего нервов в проектах стоит не разработка, а согласование. Дизайн «висит» неделю, потому что директор в отпуске. Правки приходят от трёх человек и противоречат друг другу. Сайт почти готов, но каждый день появляется ещё одно «маленькое пожелание». Всё это можно предусмотреть в ТЗ заранее.

Мы делим проект на этапы и для каждого записываем три вещи: что сдаём, сколько дней у клиента на ответ и сколько раундов правок включено. Типичная последовательность такая:

1. Структура и прототипы — согласовываем список страниц и схемы главных шаблонов.
2. Дизайн — главная и ключевые внутренние страницы, затем остальные шаблоны.
3. Вёрстка и программирование — рабочая версия на тестовом домене.
4. Наполнение — тексты, фото, товары, переводы.
5. Тестирование и запуск — проверка по критериям, перенос на боевой домен, редиректы, аналитика.

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

Критерии приёмки формулируем так же конкретно, как требования. Например: все страницы из структуры открываются без ошибок; формы отправляют заявки на указанную почту и в CRM; сайт корректно отображается в последних версиях Chrome, Safari, Firefox и Edge на смартфоне и компьютере; показатели скорости соответствуют целевым; настроены события аналитики. Если все пункты выполнены — этап принят, а новые идеи переходят в следующую итерацию.

Типичные ошибки в ТЗ

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

1. ТЗ скопировано из интернета. Шаблон «для любого сайта» содержит десятки пунктов, которые вам не нужны, и не содержит того, что важно именно для вашего бизнеса.
2. Описание решений вместо задач. «Нужен слайдер на главной» вместо «нужно показать три основные услуги на первом экране». Задачу можно решить лучше, чем задумано, решение — только выполнить.
3. Оценочные слова без расшифровки. «Красиво», «удобно», «быстро» — каждый понимает по-своему, и проверить невозможно.
4. Забытый контент. Дизайн согласован, вёрстка готова, а текстов и фото нет. Запуск откладывается на месяцы. О том, как готовить тексты заранее, читайте в статье «Как готовить контент для сайта».
5. Нет процесса после заявки. Форма есть, но не описано, куда уходит заявка, кто её видит и как быстро отвечает.
6. Игнорирование старого сайта. Новый сайт запускают с другими адресами без редиректов, и органический трафик, накопленный годами, исчезает.
7. Нет критериев приёмки. В конце проекта начинается бесконечный цикл «ещё чуть-чуть поправить».
8. ТЗ, которое никто не обновляет. В ходе работы решения меняются, а документ остаётся старым. Через полгода никто не помнит, что актуально.

Как это выглядит на практике

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

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

Короткий чек-лист перед отправкой ТЗ

• Цели сайта сформулированы через действия посетителя, и понятно, что считаем конверсией.
• Есть список всех страниц и шаблонов, включая служебные.
• Для главных шаблонов есть прототипы для десктопа и смартфона.
• Каждая функция описана сценарием, включая нестандартные ситуации.
• Нет оценочных слов без расшифровки.
• Понятно, кто, когда и в каком формате готовит контент.
• Домен, хостинг и доступы оформлены на вас.
• Для существующего сайта есть таблица редиректов.
• Описаны интеграции и аналитика.
• Есть этапы, сроки согласования и критерии приёмки.

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

Сколько времени занимает подготовка ТЗ?

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

Платная ли подготовка ТЗ?

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

Можно ли менять ТЗ в ходе работы?

Можно и даже нужно, если появились новые данные. Важно лишь фиксировать каждое изменение: что изменилось, как это влияет на сроки и бюджет, кто согласовал. Тогда документ остаётся актуальным.

Что делать, если я вообще не знаю, что мне нужно?

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

Итог

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

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