Разработка сайта чаще срывается не из-за сложной технологии, а из-за неясных ожиданий. Заказчик представлял одну главную страницу, дизайнер — другую, а программист не знал, что форма должна передавать заявки в CRM. Хорошее техническое задание на сайт сокращает количество таких сюрпризов, но не обязано быть документом на сто страниц.
Начните с задач бизнеса и аудитории
Запишите, зачем компании сайт: получать обращения, показывать каталог, принимать заказы, объяснять сложную услугу или обслуживать действующих клиентов. Для каждой цели укажите целевое действие — отправку формы, звонок, запрос расчёта, регистрацию. Затем опишите две-три группы посетителей и вопросы, на которые сайт должен им ответить.
Например, для промышленного поставщика часто важнее фильтрация продукции, технические характеристики и удобный запрос счёта, чем большая анимация. Для компании услуг — аргументы доверия, кейсы и понятный путь до обращения. Формат будущего корпоративного сайта выбирается из этих потребностей, а не наоборот.
Структура и функции: конкретика вместо общих слов
Составьте карту разделов: главная, услуги, карточки, кейсы, о компании, контакты, документы. Отдельно опишите нестандартные элементы: фильтры, поиск, личный кабинет, импорт каталога, интеграции с CRM или складской системой. Для каждой функции нужен простой сценарий: что делает человек, что видит в ответ и какая информация сохраняется.
Фраза «удобная форма заявки» недостаточна. Лучше написать: поля имени и контакта, согласие на обработку данных, защита от спама, понятное сообщение об успешной отправке и доставка обращения на рабочую почту. При наличии CRM — указать, какие поля туда передаются.
Материалы и ответственность сторон
Одно из самых частых узких мест — контент. Определите, кто готовит тексты, фотографии, логотипы, описания товаров и переводы. Если материалов нет, их создание нужно включить в план и смету. Не стоит запускать разработку с предположением, что «тексты потом кто-нибудь напишет».
Сразу согласуйте, кто предоставляет доступы к домену и хостингу, кто утверждает макеты и сколько времени занимает обратная связь. Это помогает избежать ситуации, когда техническая часть готова, а запуск откладывается из-за отсутствующих материалов или решений.
Как определить, что сайт готов
В ТЗ должны быть проверяемые критерии: корректность мобильной версии, работа форм, открытие всех разделов, метатеги, аналитика, скорость в разумных пределах, доступы редактора и резервные копии. Нельзя требовать безусловные 100 баллов PageSpeed на любом устройстве: результат зависит и от условий тестирования.
Чек-лист для старта:
- Цель сайта и главный сценарий посетителя.
- Список страниц, функций и интеграций.
- Кто готовит каждый тип контента.
- Правила согласования изменений и приёмки.
- Условия поддержки после запуска.
Итог: хорошее ТЗ описывает результат и ограничения, а не диктует разработчику каждую строчку кода. Если требований пока мало, начните с проектирования сайта и короткого брифа — их можно развивать по мере уточнения задачи.
