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