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

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

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

Что должно входить в ТЗ для сайта и почему

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

• Цель сайта. Например: «Собирать заявки», «Продавать товары», «Презентация услуг», «Обратная связь от клиентов», «Служба поддержки». Цель помогает сформировать пользовательскую модель (что делает человек, чтобы цель была достигнута). Без этого рассуждать о дизайне и структуре бессмысленно.
• Целевая аудитория. Кто будет использовать сайт? Частные клиенты, компании, партнёры, молодёжь, бухгалтеры? Люди приходят с разными сценариями — оформить заказ, найти инструкцию, сделать оплату, подать запрос в службу поддержки. Каждый сценарий важно учитывать при проектировании интерфейса.
• Функциональные требования. Здесь начинается конкретика. Сайт должен:
• использовать форму обратной связи;
• иметь корзину, каталог и фильтры (если это интернет-магазин);
• позволять пользователю авторизоваться через соцсети;
• интегрироваться с CRM (например, amoCRM или Bitrix24);
• отправлять уведомления клиенту;
• поддерживать аналитические сервисы типа Google Analytics или Яндекс.Метрика.
• Под каждую функцию рекомендуется пояснение: зачем она, как работает, какие требования к интерфейсу.
• Структура сайта (сайтмап). Какие разделы и страницы запланированы — от главной страницы до второстепенных пунктов, структуру стоит оформить как карту. Например:
• Главная
• О компании
• Услуги
• Разработка сайта
• CRM-интеграция
• Портфолио
• Контакты
• Форма обратной связи
• Если структура сложная — добавляйте схемы или таблицу взаимосвязей между страницами.
• Дизайн и фирменный стиль. Есть ли готовый брендбук? Нужен ли уникальный дизайн или можно адаптировать шаблон? Какие цвета, шрифты, логотип использовать? Ссылки на примеры сайтов, которые нравятся (или наоборот), помогают исполнителю лучше понимать визуальные ожидания.
• Контент. Уточните:
• Есть ли у вас готовые тексты;
• Нужны ли услуги копирайтинга;
• Какие изображения использовать;
• Кто отвечает за наполнение;
• Какие исходники уже есть (PDF, прайс-листы, внутренние инструкции).
• Контент влияет на дизайн и сроки. Если его нет, его будут ждать. Или — делать шаблонные заглушки.
• Адаптивность и устройства. Особенно важно обозначить: сайт должен корректно отображаться на мобильных, планшетах и десктопах. Если важны конкретные модели устройств — фиксируйте.
• Технические предпочтения. Есть хостинг? Есть домен? Нужно ли перенести сайт со старого сервера? Предпочтения по CMS: WordPress, Tilda, Bitrix, без CMS? Уточните используемые технологии, если важно: PHP, Laravel, React, Vue и т.д.
• Сроки, бюджет, этапы. Укажите:
• Желаемую дату запуска;
• Допустимые отсрочки или фиксированные дедлайны (например, выставка, событие, отчётность);
• Общий бюджет;
• Какой график доступа к материалам и лица, принимающие решения.
• Контактное лицо. Кто с вашей стороны будет отвечать на вопросы, принимать итоги этапов, согласовывать решения? Если в команде несколько человек — разделите сферы ответственности.

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

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

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

• Размытые формулировки. Фразы вроде «Сайт должен быть современным и интуитивно понятным» нельзя исполнить. Что значит «современный»? 2023 года? 2020 года? Под кого интуитивно — молодёжь, пенсионеры, закупщики?
• Бизнес-термины без интерфейсной расшифровки. Заказчик пишет: «Платформа для оптимизации B2B-логистики». Что это — таблица с графиком отгрузки? Синхронизация с 1С? Уведомления о доставке по e-mail или API-интеграция?
• Нет конкретики по результату. Исполнитель прочитает: «сайт с каталогом» — и сделает витрину. А заказчик ожидал фильтрацию по атрибутам, сравнение товаров и выгрузку из Excel. Насколько полно описан финальный функционал? Есть ли чёткий список, что входит в результат?
• Отсутствие приоритетов. Всё хочется сразу — магазин, калькулятор, интеграция, SEO, отзывчивый дизайн. Без приоритизации сложные функции вытесняют базовые. Бывает, заказчик получает красивый сайт, который не собирает заявки — потому что форма связи осталась на последнем этапе и не была должным образом перепроверена.

Хороший вопрос: прочитав это ТЗ, может ли разработчик спроектировать, реализовать и протестировать рабочий сайт? Если нет — документ нуждается в доработке.

Как составить ТЗ: пошаговая инструкция для заказчика

Если вы — заказчик (частный клиент или представитель бизнеса), ваша задача — не «сделать сайт», а передать исполнителю понимание, зачем он нужен и каким он должен быть. Вот пошаговый подход к составлению ТЗ:

1. Опишите, кто вы и что делаете. Максимально простыми словами. Пример: «Мы — студия цветов, работаем по Новосибирску. Специализируемся на букетах под мероприятия, корпоративных поставках и доставке по городу». Это важно — потому что сайт студии в Москве и она же, но в регионе, — два совершенно разных подхода.
2. Сформулируйте цель сайта. Пример: «Нужен сайт, чтобы клиенты могли быстро заказать букет на праздник. Хочу: 3–4 готовых варианта, кнопка происхода к оплате, подтверждение через СМС или почту».
3. Распишите поведение пользователей. Что они делают, чего ожидают. Пример: «Человеку нужно найти подходящий вариант, выбрать дату/время, оплатить. Желательно без звонка. Если есть вопросы — должен быть чат или форма обратной связи».
4. Нарисуйте карту страниц (можно вручную): главная, каталог, карточка букета, корзина, страница «спасибо», контакты. Это даст понимание структуры сайта и взаимосвязей интерфейсов.
5. Приложите визуальные ориентиры. Найдите 2–3 сайта, которые вам близки по дизайну или логике. Укажите, что конкретно нравится: цветовая палитра, простота, крупные кнопки, наличие фильтров, адаптация под телефон. Это поможет избежать «не такой стиль, как думал».
6. Смоделируйте процесс работы. Как пользователь заходит? Через телефон или Google? Куда он попадает? Что видит на главной? Сколько кликов до покупки, куда нажать, как оплатить — всё это важно для UX-разработки.
7. Уточните имеющиеся ресурсы. Есть ли логотип, тексты, фотографии, брендбук? Или нужно всё разрабатывать с нуля?
8. Согласуйте сроки и этапность. Например:

• Этап 1: Прототип + карта сайта — 7 дней
• Этап 2: Дизайн + правки — 10 дней
• Этап 3: Верстка, подключение CMS, тест — 10 дней

1. Это приблизительно, но уже даёт понимание продолжительности.
2. Пройдитесь по документу — понятен ли он человеку со стороны? Если дать этот файл другому подрядчику — сможет ли он начать работу, не задавая 50 уточняющих вопросов?

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

Полное ТЗ vs краткое — когда достаточно простого описания

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

Полное ТЗ подходит, если:

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

Краткое ТЗ будет достаточно, если:

• задача — реализовать лендинг, визитку, простой магазин без индивидуальных разработок на готовом решении (Tilda, WordPress, Shopify);
• контент и структура уже есть, интерфейсы понятны: «хотим, как здесь»;
• сроки жёсткие — и вы готовы работать по адаптированному прототипу;
• исполнитель — студия с внутренним менеджером, который сам проделает детализацию и сопровождает весь процесс;
• бюджет ограничен, и важно сэкономить на подготовительном этапе без ущерба для результата.

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

Готовые шаблоны ТЗ для сайта: можно ли использовать?

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

Но тут есть важное «но»: шаблон — не подмена анализа задач. Например, шаблон ТЗ для интернет-магазина может предлагать раздел «Отзывы о товарах» или «Похожие товары», но для B2B-сегмента (оптовики, тендеры, партнёры) эти блоки не только не нужны, но могут нарушать ux-логику.

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

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

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

Кто должен составлять ТЗ: заказчик, менеджер или подрядчик?

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

• ТЗ от заказчика — если он понимает бизнес-процесс и технически грамотен (или есть опытный менеджер внутри компании). Такой подход чаще встречается у digital-агентств, IT-команд или маркетинговых отделов, которые сами нанимают узкопрофильных подрядчиков.
• ТЗ от подрядчика после брифа — если задача типовая (например, лендинг, сайт услуг, магазин) и заказчик не имеет чёткого понимания всех нюансов. Тогда исполнитель проводит бриф, собирает вводные и составляет ТЗ сам, сверяя с клиентом каждый шаг. Это снижает риск иконок и блоков «не туда» и повышает ответственность подрядчика за финальный дизайн и функциональность.
• Аналитик (предпродажная проработка) — если проект нестандартный, есть интеграции, нестандартные сценарии, сложные роли или внешние системы. Тогда формируется отдельный этап: аудит и составление технической документации. Иногда это платный этап (например, 10–15% от общей стоимости проекта), который переходит в реализацию после утверждения. Применимо для: b2b-систем, систем лояльности, маркетплейсов, образовательных платформ, SaaS-сервисов.

Пример из практики: заказчик просит «кабинет для клиентов». Подрядчик уточняет: «какие функции должен выполнять кабинет?». Ответ: «чтобы клиенты видели свои заказы». На деле может оказаться, что под этим понимаются:

• История заказов;
• Отслеживание доставки;
• Скачивание документов / счетов;
• Повтор заказа одним кликом;
• Обработка заявок через менеджера;
• Отзывы, диалоговая форма, сохранённые адреса.

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

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

Чек-лист перед отправкой ТЗ исполнителю

Проверьте, всё ли вы учли, прежде чем передать ТЗ на разработку:

• Цель будущего сайта сформулирована;
• Определена целевая аудитория и понимаются её сценарии поведения;
• Указан список всех основных функций и модулей;
• Приложены примеры сайтов, предпочтения по дизайну;
• Дано указание по адаптивности (мобильная версия и т.д.);
• Фиксированы особенности CMS и технические предпочтения;
• Описаны сроки, бюджет, этапы взаимодействия;
• Назван контактный представитель со стороны заказчика;
• Документ структурирован, понятен стороннему специалисту — можно использовать как рабочую документацию на всех этапах проекта.

Итог

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

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

Если вы разрабатываете интернет-магазин, корпоративный сайт, CRM-систему или веб-сервис, первым шагом к результату будет не «поиск разработчика», а создание понятной, живой и функциональной ТЗ-документации. Именно она позволяет выбрать адекватного исполнителя (а значит, сэкономить время на модификации и пересогласовании), наладить продуктивное общение, внедрять изменения с минимальным риском и запускать проект точно в срок.

Подводя короткий итог, вы можете руководствоваться следующими ориентирами:

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

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

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

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