Как написать ТЗ на разработку сайта: подробное руководство с примером

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

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

Зачем продуманное ТЗ на разработку сайта выгодно всем участникам проекта

Рабочее техзадание — это зафиксированный список договорённостей: что должно быть сделано, в каком объёме и как вы поймёте, что результат достигнут. Это не обязательно толстый документ: иногда достаточно 5–7 страниц, если в них чётко прописываются цели, функциональные требования и условия приёмки.

Основные выгоды для заказчика и исполнителя:

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

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

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

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

Первый блок — общие сведения о проекте. Здесь коротко описываются:

• — Цели: лиды, продажи товаров, заявки на услуги, поддержка клиентов, личный кабинет, сбор отзывов, новости компании.
• — Тип проекта: лендинг, корпоративный сайт, интернет‑магазин, портал, образовательный сервис, CRM‑модуль, внутренний инструмент.
• — Краткое описание бизнеса и целевой аудитории: B2B или B2C, средний чек, география, устройства, с которых приходят пользователи (мобильные, планшеты, десктоп).

Второй блок — функциональные требования. Это ядро техзадания.

• — Составьте списком основные разделы и сценарии: «Главная», «Каталог», «Карточка товара», «Корзина», «Оплата», «Личный кабинет», «Отзывы», «Новости», «Контакты», «Карта с офисами» и т.п.
• — Описывайте функции через действия пользователя: не «простая корзина», а «пользователь может добавить товар, изменить количество, удалить, применить промокод, оформить заказ без регистрации или с регистрацией».
• — Отдельно отметьте, что обязательно для первого запуска (MVP), а что можно сделать позже: например, «отложенные товары» или сложные фильтры.

Третий блок — требования к дизайну и UX. Заказчик часто не знает терминов, но понимает ощущения.

• — Укажите стиль: «строгий корпоративный», «минимализм», «ярко, много изображений», «без перегруженной анимации».
• — Пропишите приоритет устройств: мобильная версия не «дополнение», а основной способ использования для многих ниш.
• — Отразите особенности аудитории: крупный шрифт, высокая контрастность, много видеоинструкций, если пользователи не любят читать длинные тексты.
• — Сложные UX‑карты и прототипы можно делегировать расшифровке студии, но ожидания по удобству (скорость выполнения ключевых действий, количество шагов до заявки) стоит обозначить.

Четвёртый блок — технические требования. Вопросы, которые чаще всего ищут в Google и Яндекс: «какую CMS выбрать», «какой хостинг нужен», «какая скорость загрузки нормальная».

• — Уточните, есть ли предпочтения по системе управления: Open Source (например, WordPress), SaaS‑платформа или кастомное решение.
• — Пропишите интеграции: CRM (Bitrix24, amoCRM и др.), платёжные сервисы, SMS‑шлюзы, почтовые сервисы, сервисы аналитики (Яндекс Метрика, Google Analytics/GA4).
• — Опишите минимальные нефункциональные требования: время загрузки страниц, поддерживаемая нагрузка по пользователям, резервное копирование.

Пятый блок — контент и наполнение.

• — Кто готовит тексты, изображения, видео, документы (политика конфиденциальности, условия использования, описания товаров).
• — Нужны ли шаблоны страниц, чтобы команда клиента сама добавляла новые услуги, новости, статьи блога.
• — Минимальная SEO‑подготовка: структура URL, мета‑описания, заголовки, человекопонятные адреса страниц, микроразметка для товаров и отзывов, если нужна.

Шестой блок — сроки, этапы и приёмка результата.

• — Пропишите этапы: аналитика и прототипы → дизайн → вёрстка → программирование → тестирование → запуск.
• — Для каждого этапа опишите артефакты: интерактивные прототипы, дизайн‑макеты, доступы к тестовому серверу, инструкция по админке.
• — Согласуйте, как фиксируются изменения: новая редакция ТЗ, допсоглашения к договору, отдельные заявки на изменения через таск‑трекер.

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

ТЗ на разработку сайта: образец и пример формулировок требований

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

1. 1. Цель: увеличить количество заявок с сайта минимум на 30% за 6 месяцев за счёт упрощённой формы заявки, понятной структуры услуг и акцентных кнопок «Оставить заявку».
2. 2. Тип проекта: корпоративный сайт с блогом, страницей «Кейсы», разделом «Отзывы», блоком FAQ и формой подписки на новости.
3. 3. Функциональные требования: форма обратной связи с полями «Имя», «Телефон», «Email», «Комментарий»; обязательная проверка телефона и email; после отправки — письмо менеджеру, SMS‑уведомление, сообщение пользователю о результате отправки.
4. 4. Интеграции: передача заявок в CRM (сущность «Сделка»), фиксация источника через utm‑метки, передача данных аналитики для дальнейшего подсчёта продаж по каналам.
5. 5. Администраторский функционал: возможность редактировать тексты и изображения на всех страницах, добавлять кейсы и новости списком, управлять меню, менять ссылки на внешние сервисы без участия разработчика.

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

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

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

Как проверить качество ТЗ и что стоит делегировать студии разработки

Перед тем как отправлять техзадание в агентство или отдельному исполнителю, пройдитесь по короткому чек‑листу.

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

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

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

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