Как составить ТЗ на сайт

Что должно делать техническое задание

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

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

Раздел 1. Контекст и бизнес-задача

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

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

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

Раздел 2. Аудитории и их вопросы

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

Раздел 3. Пользовательские сценарии

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

1. 01

   Указать точку входа

   Поиск, реклама, прямая ссылка, письмо, QR-код или переход из внутренней системы.

2. 02

   Описать ожидаемый результат

   Не «посетить страницу», а получить ответ, отправить данные, скачать документ или завершить операцию.

3. 03

   Перечислить основные шаги

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

4. 04

   Добавить отклонения

   Ошибочные данные, отсутствие доступа, повторное действие, отмена, таймаут внешнего сервиса.

5. 05

   Назначить приоритет

   Отделить критические сценарии первой версии от улучшений.

В сложных продуктах сценарии предотвращают недооценку. Nexora AI объединяет каталог, заказы, оплату, выдачу и поддержку. Название каждого модуля само по себе не показывает связи и состояния. Только последовательность действий объясняет, что должно произойти до и после платежа, кто вмешивается при исключении и какие данные сохраняются.

Раздел 4. Структура и контент

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

• Название и цель каждой страницы.
• Основной запрос или вопрос посетителя.
• Ключевые смысловые блоки и действие.
• Владелец исходных материалов.
• Статус контента: готов, требует редакции, исследования или создания.
• Связи с услугами, кейсами и соседними материалами.

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

Раздел 5. Данные, формы и интеграции

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

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

Раздел 6. Нефункциональные требования

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

• Перечень поддерживаемых классов устройств и актуальных браузеров.
• Поведение сетки, навигации, форм и таблиц на мобильном экране.
• Управление клавиатурой, видимый фокус, подписи полей, контраст и альтернативный текст.
• Требования к метаданным, canonical, sitemap, robots.txt и структурированным данным.
• Правила авторизации, ролей, хранения персональных данных и журналирования критичных действий.
• Порядок резервного копирования, мониторинга ошибок и восстановления.
• Требования к редактору контента и процессу публикации.

Раздел 7. Критерии приёмки и запуск

Критерий приёмки описывает наблюдаемый результат. Вместо «сделать удобную форму» напишите: обязательные поля имеют подписи, ошибки показаны рядом с полями, после успешной отправки пользователь видит подтверждение, а CRM получает одну запись с URL страницы и параметрами источника. Такой критерий можно воспроизвести.

1. 01

   Функциональная проверка

   Критические сценарии проходят с корректными, ошибочными и повторными действиями.

2. 02

   Контентная проверка

   Утверждены тексты, контакты, ссылки, юридические сведения и изображения.

3. 03

   Техническая проверка

   Проверены адаптивность, метаданные, индексируемость, формы, интеграции и коды ответов.

4. 04

   Подготовка запуска

   Назначены домен, сертификат, резервная копия, аналитика и план отката.

5. 05

   Проверка после публикации

   Команда повторяет основные сценарии на рабочем сайте и фиксирует ответственных за наблюдение.

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

Короткий шаблон ТЗ

• Контекст компании и причина проекта.
• Цель сайта и основной результат для пользователя.
• Аудитории, ситуации входа, вопросы и барьеры.
• Приоритетные пользовательские сценарии и исключения.
• Карта страниц и назначение каждого раздела.
• План подготовки и утверждения контента.
• Формы, данные, роли, статусы и интеграции.
• Визуальные ориентиры и обязательные элементы бренда.
• Доступность, производительность, SEO и безопасность.
• Критерии приёмки, порядок запуска и поддержки.
• Что явно не входит в текущий этап.
• Порядок согласования изменений.

Этот шаблон можно заполнить коротко перед первой встречей, а затем уточнять вместе с командой. Неизвестные пункты допустимо помечать как вопросы. Это честнее, чем придумывать решение без исследования. Главное — не оставлять критическую неопределённость незаметной в момент оценки.

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