Как составить ТЗ на сайт: цели, страницы, функции и критерии приёмки

Что должно быть в ТЗ

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

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

1. Начните с бизнес-цели и аудитории

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

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

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

2. Составьте карту страниц и шаблонов

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

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

3. Опишите функции как сценарии

Формулировка «подключить CRM» скрывает много решений. Какая форма создаёт лид, какие поля передаются, кому назначается обращение, что происходит при повторе и сбое? Хорошее требование описывает поведение, а не только название инструмента. Для каждой функции полезен собственный номер: FORM-01, CRM-01, SEARCH-01.

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

4. Зафиксируйте контент и ответственность

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

• Разделите подготовку текста, перевод, загрузку и последующее обновление.
• Укажите, кто предоставляет фото, логотипы и право на их использование.
• Для товаров согласуйте обязательные характеристики и формат импорта.
• Смысловым изображениям задайте описание и alt; декоративным не приписывайте лишний смысл.
• Назначьте одного человека, который собирает согласованные замечания команды.

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

5. Согласуйте техническое качество и SEO

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

Для SEO предусмотрите отдельный Title и Description, один основной H1, логичные H2/H3, понятные URL, canonical и соответствующие языковые версии. Укажите, кто готовит метаданные и проверяет их после публикации. На старом сайте нужен список прежних адресов и план перенаправлений. В помощь — чек-лист SEO перед запуском; сложные ошибки разбираются в рамках технического SEO.

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

6. Превратите требования в критерии приёмки

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

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

7. Разделите первую версию, изменения и поддержку

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

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

После запуска поддержка сайта может включать согласованный объём обновлений и проверок. Не считайте её автоматически включённой навсегда: период, часы, каналы и ответственность нужно описать отдельно.

8. Короткий шаблон ТЗ для начала работы

Скопируйте структуру ниже в общий документ. Если ответ неизвестен, так и напишите: «нужно определить на проектировании». Открытый вопрос лучше выдуманного требования. Перед заказом сайта в Кишинёве, другой части Молдовы или для зарубежного рынка состав документа остаётся тем же; меняются аудитория, языки и рабочие условия.

1. Контекст: продукт, аудитория, рынки, проблема текущего процесса.
2. Цель: основное действие посетителя и способ проверки его прохождения.
3. Объём: карта страниц, шаблоны, языки и ограничения первой версии.
4. Функции: сценарии, поля, интеграции, повторы и ошибки.
5. Материалы: тексты, фото, данные, сроки и ответственные.
6. Качество: мобильная версия, SEO, доступность, безопасность и измерение скорости.
7. Приёмка: тесты, критичность дефектов, согласующий и порядок исправления.
8. Передача: доступы, обучение, документация и условия поддержки.

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

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

Нужно ли готовое ТЗ до первого разговора со студией?

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

Чем бриф отличается от ТЗ?

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

Можно ли требовать определённые продажи как критерий сдачи?

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