Техническое задание на сайт: шаблон для бизнеса

1. Контекст проекта

• Что делает бизнес и почему сайт меняется сейчас.
• Кто принимает решение и кто будет поддерживать результат.
• Главные аудитории, языки и география.
• Измеримый результат и исходная точка.
• Ограничения по сроку, бюджету, бренду и инфраструктуре.

2. Объём и карта URL

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

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

Отдельно укажите языковые версии и страницы, которые сознательно не индексируются.

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

1. Опишите исходную ситуацию пользователя.
2. Укажите точку входа и необходимую информацию.
3. Зафиксируйте основное действие и альтернативу.
4. Опишите успешный результат, ошибку и повторную попытку.
5. Назначьте событие аналитики и объект в CRM.

4. Контент и ответственность

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

5. Интеграции и данные

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

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

6. SEO, скорость и доступность

• Уникальные metadata, H1, canonical и индексируемый HTML.
• Sitemap, robots, редиректы и hreflang для реальных переводов.
• Core Web Vitals и бюджет веса ключевых шаблонов.
• Клавиатурная навигация, контраст, alt и субтитры.
• Структурированные данные только для видимого содержания.

7. Критерии приёмки

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

Изменения объёма после утверждения проходят отдельную оценку влияния на срок и бюджет. Такой change request защищает обе стороны от бесконечного расширения задачи под видом мелкой правки.

1. Проверить согласованный список URL и коды ответа.
2. Пройти сценарии на поддерживаемых устройствах и браузерах.
3. Проверить формы, CRM, письма и аварийные случаи.
4. Сверить аналитику, consent и события.
5. Передать доступы, исходники, документацию, резервную копию и регламент релиза.

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

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

Состав первой версии: главная, каталог, категории, карточки моделей, страница о компании, контакты и политика обработки данных. В карточке есть характеристики, документы и кнопка запроса КП. При нажатии выбранная модель автоматически добавляется в заявку. Менеджер видит модель, контакты и источник обращения в CRM; клиент получает подтверждение отправки. Цена оборудования в каталоге не публикуется, если её всегда согласуют индивидуально.

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

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

Первичные источники и документация

• Google Search Central: SEO для разработчиков
• OWASP: Application Security Verification Standard
• W3C WAI: основы доступности изображений

Следующий шаг

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

По теме

Если решаете связанную задачу, продолжите с конкретным сценарием:

• Контент для сайта: что подготовить до дизайна и разработки
• Как выбрать разработчика сайта в Ташкенте: вопросы и критерии
• Этапы создания сайта для бизнеса: от брифа до запуска
• Как принять готовый сайт у подрядчика: чек-лист владельца
• Сроки разработки сайта: от чего зависят и почему сдвигаются
• Структура корпоративного сайта: страницы и путь к заявке