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

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

Статья актуальна на 17 августа 2026 года. Она предназначена собственникам и маркетологам, которые заказывают новый корпоративный сайт, личный кабинет или небольшой веб-сервис. Речь не о переносе работающего сайта и не о SEO-редизайне: здесь разбираем, как собрать требования до старта нового проекта. Цель ТЗ — не предсказать каждую строчку кода, а снять неопределённость там, где она влияет на бюджет, сроки, данные, интеграции и приёмку.

Почему «сделайте современный сайт» почти гарантирует переделки

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

Полезно отличать три уровня требований:

Не начинайте ТЗ с третьего уровня. Если сразу выбрать CMS, фреймворк или конкретный виджет, команда может оптимизировать реализацию не той задачи. Сначала зафиксируйте результат и сценарий; технический вариант выбирайте после оценки ограничений.

Цена неопределённости — не только дополнительные часы

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

С чего начать: одностраничный паспорт проекта

До подробного ТЗ соберите паспорт на одну-две страницы. Он помогает увидеть противоречия до обсуждения интерфейса.

1. Контекст. Что запускается: корпоративный сайт, сайт услуги, B2B-каталог, кабинет клиента, калькулятор или другой сервис. Укажите домен, языки, регионы и уже существующие системы.
2. Цель. Какое изменение в процессе бизнеса ожидается: больше качественных обращений, сокращение ручной обработки, самостоятельное оформление заказа, публикация базы знаний. Не обещайте в ТЗ позиции, лиды или выручку, на которые влияют рынок и каналы; фиксируйте контролируемые условия и измерения.
3. Аудитории. Не демография «мужчины 25–45», а роли и ситуации: закупщик сравнивает поставщиков, инженер ищет характеристики, клиент проверяет статус заказа, редактор обновляет кейс.
4. Приоритетные сценарии. Путь от входа до измеримого действия: изучить услугу, скачать документ, отправить заявку, записаться на демонстрацию, оплатить счёт. На первом релизе обычно достаточно трёх—пяти главных сценариев.
5. Границы. Что точно входит в релиз, что отложено, что предоставит заказчик, какие сторонние системы нельзя менять.
6. Владельцы решений. Один человек от бизнеса принимает решения о приоритетах и контенте; у интеграций и данных также должны быть владельцы. «Согласует вся команда» не является ответственностью.

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

Бизнес-требования: превращаем желания в проверяемые условия

Каждое требование полезно записывать одной карточкой: идентификатор, описание, приоритет, обоснование, владелец, критерий приёмки, зависимости и статус. Идентификатор вроде BR-04 удобен не бюрократии ради: на него можно сослаться в макете, задаче разработчика и тест-кейсе, не споря о том, «какую именно форму» обсуждают.

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

Приоритизируйте, а не составляйте список желаний

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

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

Структура и контент: это часть продукта, а не задача «на потом»

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

Для корпоративного сайта это может выглядеть так:

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

Контентные пробелы выявляйте до дизайна

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

Интеграции и данные: описывайте маршрут, а не только логотип CRM

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

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

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

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

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

Производительность и совместимость

Вместо «сайт должен быстро загружаться» укажите список критичных страниц, устройства, сеть, метод замера и целевые ориентиры. В документации web.dev актуальные Core Web Vitals включают LCP, INP и CLS; для хорошего пользовательского опыта приводятся ориентиры 2,5 секунды, 200 миллисекунд и 0,1 соответственно, с оценкой 75-го перцентиля реальных загрузок. Эти показатели зависят от устройства, сети и сценария, поэтому лабораторная проверка перед релизом не заменяет наблюдение по реальным пользователям после него.

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

Доступность

W3C публикует WCAG 2.2 как тестируемые, независимые от технологии критерии. Стандарт описывает уровни A, AA и AAA; для коммерческого сайта разумно отдельно согласовать требуемый уровень, набор страниц и способ проверки, а не заявлять абстрактную «полную доступность». Например, для приоритетных сценариев можно включить клавиатурную навигацию, видимый фокус, понятные подписи полей и сообщения об ошибках, контраст, текстовые альтернативы для содержательных изображений, корректный порядок заголовков и масштабирование на мобильных устройствах.

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

Безопасность, конфиденциальность и устойчивость

Не превращайте ТЗ в обещание «невзламываемого сайта»: такой гарантии не существует. Вместо этого зафиксируйте модель риска и минимум процессов: HTTPS, обновление зависимостей и CMS, отдельные учётные записи вместо общих, принцип минимальных доступов, резервное копирование и восстановление, журналирование важных действий, защита секретов, ограничение прав административных ролей и план реакции на инцидент.

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

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

Приёмка: как проверить продукт, а не впечатление от демо

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

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

1. Функциональные. Сценарии пользователя, формы, расчёты, роли, фильтры, ошибки.
2. Интеграционные. Передача данных, дубликаты, недоступность внешнего сервиса, корректность прав и уведомлений.
3. Качество. Адаптивность, браузеры, доступность, производительность, безопасность в согласованном объёме.
4. Операционные. Доступы, инструкции, резервное копирование, мониторинг, передача исходников и порядок поддержки.

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

Изменения после утверждения ТЗ

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

Практический шаблон ТЗ на сайт

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

1. Паспорт проекта
   Название, владелец, цель, дата, версия, каналы связи, границы релиза.

2. Бизнес-контекст и метрики
   Для кого продукт, какие сценарии приоритетны, что измеряем, где смотрим данные.

3. Роли и сценарии
   Роль → задача → путь → ожидаемый результат → исключения.

4. Структура и контент-модель
   Разделы, типы страниц, поля сущностей, редакционные роли, готовность материалов.

5. Функциональные требования
   ID, описание, приоритет, владелец, зависимости, критерии приёмки.

6. Интеграции и данные
   Системы, триггеры, поля, форматы, доступы, ошибки, тестовый сценарий.

7. Нефункциональные требования
   Адаптивность, браузеры, доступность, производительность, безопасность, резервные копии.

8. Аналитика и маркетинг
   Счётчики, события, UTM, цели, конверсии, владельцы доступа, проверка тестовой заявкой.

9. Приёмка и запуск
   Среда, тест-кейсы, критичность дефектов, критерии готовности, план отката и мониторинг.

10. Исключения, допущения и управление изменениями
    Что не входит, что предоставит заказчик, как согласуются изменения и версии.

Ошибки, из-за которых ТЗ не защищает бюджет

Смешать цель, дизайн и технологию в одном абзаце

«Нужен быстрый сайт на X с современным дизайном» не говорит, какие сценарии важны и как измерить успех. Разделите задачу, пользовательский путь и способ реализации.

Описать только счастливый путь

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

Оставить контент «потом»

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

Принять интеграцию по сообщению «данные ушли»

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

Не назвать критерий окончания проекта

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

Чек-лист перед утверждением ТЗ

• Есть одна измеримая цель и владелец проекта.
• Описаны три—пять приоритетных пользовательских сценариев и исключения.
• Для функций есть приоритеты, границы релиза и критерии приёмки.
• Контент-модель содержит поля, источники, владельцев и статус готовности материалов.
• По каждой интеграции понятны триггер, поля, доступы, ошибка и тест.
• Аналитика описывает события и проверку тестовой заявки, а не только установку счётчика.
• Согласованы требования к мобильным устройствам, браузерам, доступности и производительности.
• Указаны безопасность, резервные копии, доступы и процедура восстановления в нужном для проекта объёме.
• Есть единый журнал замечаний, порядок изменений, дата контентной заморозки и критерии запуска.
• Заказчик понимает, что нужно предоставить до начала работ: материалы, доступы, решения, согласия.

FAQ

Нужен ли подробный ТЗ для небольшого сайта?

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

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

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

Можно ли начать с прототипа, а ТЗ оформить потом?

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

Как не задушить проект согласованиями?

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

Достаточно ли написать «соответствие WCAG» и «защита по OWASP»?

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

Нужен сайт, который можно принять по понятным критериям?

ClickShot помогает связать бизнес-задачу, структуру, контент, разработку, интеграции и аналитику в один рабочий контур. Перед стартом разработки сайта разберём ключевые сценарии, составим карту требований и проверок, выделим риски и подготовим реалистичный объём первого релиза. Это не обещает заданный трафик или выручку, но снижает число решений, которые иначе всплывут слишком поздно.

Источники и материалы для проверки

Все источники проверены 17 августа 2026 года.

1. W3C: Web Content Accessibility Guidelines (WCAG) 2.2 — тестируемые критерии доступности и уровни соответствия.
2. W3C WAI: Evaluating Web Accessibility Overview — сочетание методов оценки доступности.
3. W3C WAI: Involving Users in Evaluating Web Accessibility — почему пользовательская оценка дополняет проверку по чек-листу.
4. OWASP Application Security Verification Standard — ориентир для проверяемых требований к безопасности приложений.
5. OWASP Top 10 Web Application Security Risks — распространённые классы рисков веб-приложений.
6. NIST Privacy Framework — управление рисками приватности.
7. web.dev: Web Vitals — актуальные метрики Core Web Vitals, полевые и лабораторные измерения.
8. NIST SP 800-63B: Digital Identity Guidelines — справочный материал по управлению цифровой идентичностью и аутентификацией.