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

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

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

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

Что входит в ТЗ

• цели проекта;

• пользователи и сценарии;

• границы;

• структура;

• функции;

• дизайн и контент;

• интеграции;

• SEO, аналитика, производительность, доступность и безопасность;

• критерии приемки;

• запуск и порядок изменений.

ТЗ может состоять из связанного набора: основной документ, sitemap, прототип, таблица контента, backlog и acceptance criteria.

Бриф, ТЗ, прототип и договор

Артефакт	Главный вопрос
Бриф	Кто бизнес, аудитория и задача?
ТЗ	Что реализовать и проверить?
Sitemap	Какие страницы существуют?
User flow	Как человек завершает задачу?
Прототип	Как расположены информация и действия?
Смета	Сколько стоят согласованные работы?
План	В какой последовательности выполняются?
Договор	Какие юридические условия и обязанности?

Один документ не заменяет остальные.

Кто составляет ТЗ

Заказчик предоставляет цели, продукты, аудитории, процесс продаж, юридические ограничения, контент, бренд, интеграции, бюджетные ограничения и ответственных.

Студия задает вопросы, выявляет противоречия, проектирует sitemap и flows, предлагает технический подход, описывает функции и состояния, зависимости, критерии приемки, объем и риски.

Если формат не выбран, сначала сравните лендинг и многостраничный сайт.

Когда ТЗ может быть коротким

Краткого документа достаточно для проверенного шаблона, типовой функциональности, существующей дизайн-системы, знакомой команды и низкого риска изменений. Ecommerce, кабинеты, оплаты, роли, миграции и интеграции требуют больше деталей.

1. Контекст и цель

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

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

Если канал еще не выбран, сравнение Google Ads или SEO покажет, нужны ли SEO-страницы, рекламные лендинги или оба формата.

2. Аудитории и роли

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

3. Scope и исключения

Четко укажите, что входит и не входит.

Входит: UX, UI, adaptive, CMS, формы, базовое SEO, аналитика, тестирование и запуск.

Не входит: тексты, фотосъемка, разработка CRM, постоянное SEO, перевод или полное наполнение каталога.

4. Тип сайта и технология

Определите лендинг, корпоративный сайт, каталог, магазин, портал или сервис.

Сначала опишите редактирование, масштабирование, языки, интеграции, безопасность, performance и владение данными. Затем сравните WordPress и конструкторы или custom development.

При заданной платформе укажите версии, плагины, hosting, repository, deploy, staging, browsers и update policy.

5. Информационная архитектура

Добавьте главную, услуги, категории, карточки, кейсы, блог, авторов, поиск, контакты, legal, system и error pages. Для каждой страницы укажите цель, шаблон, родителя, URL, индексацию и источник контента.

Для поискового трафика используйте SEO-аудит своими руками как базовую проверку, а для миграции создайте отдельную карту URL.

6. User flows

Описывайте путь: страница услуги, пакет, форма, validation, consent, submit, confirmation, CRM и уведомление менеджера.

Для каждого flow добавьте предусловия, основной путь, альтернативы, ошибки, empty states, permissions и result.

Материал о разнице UI и UX помогает разделить логику сценария, структуру прототипа и визуальный интерфейс.

7. Функциональные требования

Размыто	Проверяемо
Удобный каталог	Фильтрация по категории, цене и наличию; выбор сохраняется в URL
Быстрый поиск	Находит название и артикул, показывает подсказки и no-results state
Обратная связь	Валидная форма создает CRM lead, отправляет уведомление и показывает confirmation
Удобная админка	Редактор меняет цены, тексты, FAQ, SEO и порядок блоков без кода
Безопасный кабинет	Пользователь видит только собственные данные и может завершить сессию

Для магазина опишите каталог, остатки, цены, скидки, cart, checkout, оплату, доставку, статусы, возвраты и письма. Практические сценарии есть в гайде о брошенных корзинах.

8. Контент

Создайте таблицу страниц, текстов, изображений, видео, ответственных, сроков и статусов. Зафиксируйте форматы, размеры, alt, права, переводы, временный контент и migration.

Проверяйте макеты на реальных заголовках, ценах и характеристиках.

9. UI/UX, adaptive и accessibility

Опишите wireframes, clickable prototype, UI direction, desktop и mobile screens, components, states, typography, grid, images, motion и design QA.

Определите уровень WCAG, keyboard operation, focus, contrast, labels, errors и text alternatives. Согласуйте viewport ranges и поведение компонентов.

10. SEO

Минимум: metadata, H1, readable URLs, canonical, robots.txt, sitemap.xml, response codes, redirects, breadcrumbs, hreflang, structured data, alt, pagination, filters, Open Graph и Search Console.

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

Для redesign добавьте export URL, redirect mapping, metadata retention и мониторинг.

11. Performance

«Сайт должен быть быстрым» не проверяется. Укажите environment, templates, mobile и desktop profiles, изображения, lazy loading, cache, CDN, JavaScript/CSS budgets, Core Web Vitals и метод измерения.

web.dev рекомендует оценивать LCP, INP и CLS на 75-м перцентиле реальных посещений. Инструменты можно выбрать из каталога бесплатных инструментов вебмастера, но приемочный метод зафиксируйте в ТЗ.

12. Аналитика

«Установить GA4» недостаточно. Создайте event plan с event, trigger, parameters, platform и business value. Добавьте leads, phone clicks, cart, checkout и purchase.

Опишите GTM, consent, UTM, cross-domain, referral exclusions, test traffic, CRM и владельца измерения.

После запуска важные изменения проверяйте аналитикой и, при достаточном трафике, A/B-тестированием.

13. Интеграции

Для каждой системы укажите направление, mapping, authentication, schedule, source of truth, retries, duplicates, errors, logs, test environment и owners.

«Интегрировать CRM» не объясняет создаваемую сущность, поля, возврат статуса и поведение при недоступности API.

14. Security и privacy

Опишите HTTPS, roles, least privilege, MFA, password policy, rate limiting, validation, anti-spam, secure uploads, updates, logs, backups, retention, incidents, consent, export и deletion.

Для сложных приложений OWASP ASVS подходит как основа проверяемых security requirements.

15. Админ-панель

Перечислите редактируемые страницы, меню, цены, товары, metadata, redirects, формы, FAQ, баннеры, users, roles и translations.

При необходимости добавьте draft, preview, revisions, scheduled publishing и deletion rules.

16. Локализация

Укажите языки, default, URL structure, switcher, fallback, ответственного за перевод, даты, валюты, hreflang, metadata и поведение непереведенных страниц.

17. Критерии приемки

Вместо «форма работает быстро»:

При валидных полях форма создает CRM lead с URL и UTM, уведомляет менеджера и показывает confirmation. При недоступности CRM данные сохраняются, а ошибка записывается в log.

Определите conditions, action, expected result, devices, test data, owner и evidence.

18. Тестирование

Зафиксируйте functional, cross-browser, responsive, accessibility, performance, SEO, security, analytics, content, integration, regression и UAT.

Укажите supported environments, severity и release blockers.

19. Запуск и передача

Definition of done включает production deployment, domain, SSL, DNS, analytics, Search Console, robots, sitemap, redirects, backups, accesses, licenses, repository, documentation, training, warranty и support contacts.

Открывающийся staging еще не является завершенным запуском.

20. Change request

Опишите изменение, причину, влияние на архитектуру, цену и срок, согласуйте приоритет, обновите ТЗ и backlog, затем реализуйте после подтверждения.

Минимальное ТЗ для лендинга

Цель, источник трафика, оффер, блоки, форма, success/error, CRM, UTM, events, responsive, performance, metadata, legal и acceptance criteria.

Минимальное ТЗ для корпоративного сайта

Sitemap, service templates, cases, blog, search, forms, CMS, roles, localization, SEO, analytics, integrations, migration redirects и acceptance criteria.

Минимальное ТЗ для магазина

Catalog, attributes, filters, search, product page, price, stock, cart, checkout, payment, delivery, promo, emails, statuses, returns, feeds, CRM/ERP, ecommerce events, security, performance и acceptance criteria.

10 ошибок

1. Описывать решение без бизнес-цели.

2. Использовать «современный», «удобный» и «быстрый» без теста.

3. Забыть error, empty, loading и success.

4. Не описать mobile.

5. Не назначить владельца контента.

6. Добавить SEO после дизайна.

7. Написать «CRM integration» без mapping.

8. Смешать scope и future backlog.

9. Не определить acceptance criteria.

10. Не согласовать change process.

Чек-лист перед разработкой

• бизнес-цель понятна;

• scope и exclusions записаны;

• sitemap согласован;

• critical flows описаны;

• функции включают states и errors;

• контент имеет владельцев;

• UI/UX outputs определены;

• mobile и accessibility включены;

• SEO задано;

• performance измеряется;

• analytics имеет event map;

• integrations детализированы;

• security соответствует риску;

• acceptance criteria проверяются;

• launch и handoff входят в done;

• change request согласован.

Вывод

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

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

BB STUDIO может провести discovery, спроектировать sitemap и flows, подготовить prototype, составить ТЗ и оценить разработку без скрытого объема.

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

Должен ли заказчик писать ТЗ сам?

Нет. Он предоставляет бизнес-контекст и ограничения, а студия превращает их в технические и проверяемые требования.

Можно ли оценить сайт без ТЗ?

По брифу можно дать диапазон. Надежная оценка требует структуры, функций, интеграций, дизайна и scope.

Насколько подробным должно быть ТЗ?

Настолько, чтобы обеспечить общее понимание, оценку и приемку. Лендинг требует меньше деталей, чем магазин или кабинет.

Можно ли менять его после старта?

Да, через change request с оценкой влияния на стоимость, сроки и приоритет.

Нужен ли прототип?

Обычно да. Текст задает правила, а прототип быстрее показывает структуру и путь.

Нужно ли включать SEO и аналитику?

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