В статье узнаете:
- что предпринимателю подготовить до обращения к разработчику;
- чем ТЗ отличается от брифа;
- какие разделы важны для сложного сайта;
- как описывать CMS, формы, роли и интеграции простым языком;
- что можно не знать заранее;
- как не превратить ТЗ в бесполезный документ.
Короткий ответ
ТЗ на сложный сайт должно помогать бизнесу контролировать результат. В нем нужно описать цель сайта, аудитории, ключевые сценарии, страницы, контент, CMS, формы, заявки, роли пользователей, интеграции, аналитику, SEO-требования, этапы и критерии приемки.
Главное – не написать "сделать удобный современный сайт", а зафиксировать, что сайт должен делать. Для клиники это может быть запись к врачу и страницы услуг. Для производства – каталог возможностей, форма с файлом и передача заявки менеджеру. Для учебного центра – расписание, оплата и заявки на курсы. Для B2B-сервиса – роли пользователей, личный кабинет и отчеты.
Если готового ТЗ нет, проект все равно можно начинать. Но сначала нужен разбор задачи, а не дизайн. Иначе важные решения всплывут в середине работ, когда уже потрачены деньги и время.
Ситуация: сайт нужен, а готового ТЗ нет
Предприниматель часто приходит с понятной бизнес-задачей, но без технического документа:
- старый сайт устарел;
- нужен сайт под новое направление;
- заявки должны попадать в CRM;
- клиентам нужен личный кабинет;
- услугу сложно объяснить на одной странице;
- маркетолог хочет SEO-структуру и блог;
- команда хочет обновлять контент без разработчика.
Это нормальный старт. Проблема начинается, когда все сразу переходят к макетам. Тогда позже выясняется, что нужны роли пользователей, фильтры, редактируемые блоки, дополнительные формы, передача UTM-меток, редиректы, интеграция с CRM или отдельные шаблоны для статей.
ТЗ нужно не для бюрократии. Оно защищает предпринимателя от фразы "это не входило в работу".
Чем ТЗ отличается от брифа
Бриф помогает начать разговор. ТЗ помогает принять результат.
| Документ | Для чего нужен | Пример вопроса |
|---|---|---|
| Бриф | понять задачу и контекст | зачем нужен сайт |
| Структура | разложить страницы и сценарии | куда попадет пользователь |
| ТЗ | зафиксировать работу сайта | что должно работать и как проверяем |
| План этапов | не перегрузить первый запуск | что делаем сейчас, а что позже |
Если подрядчик просит бриф – это нормально. Если после брифа сразу начинает рисовать дизайн сложного сайта без уточнения логики, это риск.
Что предпринимателю подготовить сначала
Для первого этапа не нужен идеальный документ. Достаточно честных вводных.
1. Зачем бизнесу сайт
Опишите результат, который нужен после запуска:
- получать больше заявок;
- повысить доверие;
- объяснить сложную услугу;
- заменить старый сайт;
- запустить новое направление;
- собрать SEO-трафик;
- дать клиентам доступ к данным;
- автоматизировать часть продаж или поддержки.
Если целей несколько, выберите главную. Она будет влиять на структуру, бюджет и сроки.
2. Кто будет пользоваться сайтом
Опишите не абстрактную ЦА, а ситуации:
- собственник сравнивает подрядчиков;
- маркетолог ищет аргументы для выбора платформы;
- клиент хочет посмотреть статус заказа;
- менеджер должен быстро получить заявку;
- редактор будет добавлять статьи;
- партнеру нужен закрытый раздел.
Так становится понятно, какие страницы и роли нужны.
3. Какие действия должен совершить пользователь
Перечислите целевые действия:
- оставить заявку;
- позвонить;
- написать в Telegram;
- скачать документ;
- зарегистрироваться;
- оплатить;
- войти в личный кабинет;
- выбрать услугу;
- отправить файл;
- подписаться на обновления.
Для каждого действия потом проектируются кнопки, формы, уведомления и аналитика.
4. Какие материалы уже есть
Соберите:
- список услуг;
- тексты или черновики;
- кейсы;
- фотографии;
- отзывы;
- документы;
- логотип и фирменные элементы;
- юридические данные;
- примеры сайтов, которые нравятся и не нравятся.
Если материалов нет, это тоже важно зафиксировать. Тогда в проект нужно включить сбор структуры и написание текстов.
Что должно быть в ТЗ на сложный сайт
Страницы и их задача
Для каждой важной страницы нужно понять, зачем она нужна. Не просто "главная", "услуги", "контакты", а:
- главная быстро объясняет, кто вы и чем полезны;
- страница услуги отвечает на вопросы клиента и ведет к заявке;
- кейс доказывает опыт;
- статья закрывает вопрос выбора или риска;
- контакты помогают быстро связаться;
- личный кабинет решает повторяющийся сценарий клиента.
Если у страницы нет задачи, возможно, она не нужна.
CMS и редактирование
Предпринимателю важно заранее понять, что команда сможет менять без разработчика.
Например:
- услуги;
- кейсы;
- статьи;
- FAQ;
- цены или факторы стоимости;
- изображения;
- контакты;
- SEO-title и description;
- блоки на главной.
Фраза "будет админка" слишком общая. Нужно уточнять, какие именно блоки редактируются.
Формы и заявки
Опишите путь заявки:
- где стоит форма;
- какие поля обязательны;
- какие данные скрыто передаются;
- куда приходит заявка;
- кто получает уведомление;
- попадает ли заявка в CRM;
- сохраняются ли UTM-метки;
- что видит пользователь после отправки;
- что происходит при ошибке.
Для бизнеса это один из самых важных разделов. Сайт может быть красивым, но если заявка потерялась, он не выполнил задачу.
Роли пользователей
Роли нужны не только для личного кабинета. Они могут быть и внутри CMS.
| Роль | Что делает |
|---|---|
| владелец | принимает ключевые решения |
| маркетолог | обновляет страницы и смотрит аналитику |
| редактор | добавляет статьи и кейсы |
| менеджер | получает заявки |
| клиент | входит в личный кабинет |
| администратор | управляет настройками |
Если роли не описать, потом возникают вопросы доступа, ответственности и безопасности.
Интеграции
Не пишите только "подключить CRM". Лучше описать простыми словами:
- какие данные уходят из формы;
- в какую систему они попадают;
- кто становится ответственным;
- какой статус получает заявка;
- что делать, если передача не сработала;
- нужны ли уведомления в Telegram;
- нужно ли передавать оплату, документы, товары или статусы.
Даже если технические детали уточнит подрядчик, бизнес-сценарий должен быть понятен предпринимателю.
SEO и старые URL
Если сайт новый, нужно заложить структуру под поисковый спрос. Если сайт старый, нужно сохранить важные адреса или настроить редиректы.
В ТЗ стоит указать:
- какие страницы важны для SEO;
- кто готовит title и description;
- какие URL сохраняются;
- какие страницы переезжают;
- нужен ли блог;
- кто добавляет мета-теги в CMS;
- как проверяется индексация.
Аналитика
Предпринимателю нужно видеть, работает сайт или нет. Поэтому заранее опишите события:
- отправка формы;
- клик по телефону;
- переход в Telegram;
- скачивание файла;
- регистрация;
- вход в кабинет;
- оплата;
- ключевой шаг в сервисе.
Если аналитику вспомнить после запуска, часть важных действий уже будет невидимой.
Критерии приемки
Приемка должна быть проверяемой:
- страницы открываются;
- формы отправляются;
- заявки доходят;
- мобильная версия работает;
- CMS редактирует нужные блоки;
- мета-теги заполнены;
- старые URL не ведут на 404;
- роли работают корректно;
- интеграции протестированы;
- доступы переданы.
Это защищает обе стороны: бизнес понимает, что проверять, а подрядчик понимает, что считается готовым.
Что можно не знать заранее
Предприниматель не обязан заранее знать:
- точную архитектуру;
- технический способ интеграции;
- все поля API;
- структуру базы данных;
- детали верстки;
- названия плагинов;
- все сценарии ошибок.
Это зона ответственности команды разработки. Но предприниматель должен описать бизнес-логику: что должно произойти, кто получает данные, где возникает ценность и что нельзя сломать.
Частые ошибки
Писать ТЗ как набор пожеланий
"Сделать красиво", "удобная админка", "современный дизайн" – это не требования. Нужно расшифровать, что именно должно работать и как это проверить.
Копировать чужой шаблон
Шаблон помогает не забыть разделы, но он не знает ваш бизнес. ТЗ для лендинга, корпоративного сайта, личного кабинета и сервиса с оплатой будет разным.
Не назначать ответственного за контент
Если никто не отвечает за тексты, кейсы, фото и согласования, запуск задерживается. Контент – часть проекта.
Не разделять первый запуск и будущие идеи
В сложном проекте легко захотеть все сразу. Лучше выбрать первый рабочий сценарий и отдельно записать, что пойдет во второй этап.
Не описывать заявки
Многие подробно описывают дизайн и почти не описывают форму. Для бизнеса это ошибка: форма и обработка заявки часто важнее декоративных блоков.
Мини-чек-лист для предпринимателя
Перед разговором с подрядчиком подготовьте:
- Главную бизнес-цель сайта.
- Список услуг или продуктов.
- Аудитории и реальные ситуации пользователей.
- Целевые действия на сайте.
- Материалы, которые уже есть.
- Что должно редактироваться в CMS.
- Куда должны приходить заявки.
- Какие системы нужно подключить.
- Есть ли старый сайт и важные URL.
- Что обязательно должно войти в первый запуск.
- Что можно отложить.
- Кто принимает решения со стороны бизнеса.
Этого достаточно, чтобы начать проект предметно.
Когда стоит привлекать специалиста
Если сайт простой, предприниматель может сам подготовить короткое ТЗ по чек-листу. Если сайт связан с CMS, SEO, CRM, личным кабинетом, оплатой, ролями или несколькими аудиториями, лучше делать ТЗ вместе с командой.
Специалист поможет перевести бизнес-задачу в структуру, сценарии, данные, этапы и критерии приемки. Это дешевле, чем исправлять проект после того, как дизайн уже нарисован и часть разработки сделана.
Соберем структуру, дизайн, CMS и интеграции под задачу бизнеса. Посмотрите формат услуги и базовый порядок работы.
Часто задаваемые вопросы
Нужно ли готовое ТЗ, чтобы обратиться в студию
Нет. Достаточно задачи, вводных и понимания, что сайт должен изменить в бизнесе. Хорошая команда поможет превратить это в структуру и техническое задание.
Чем техническое задание на сайт отличается от структуры
Структура показывает страницы и путь пользователя. ТЗ дополнительно описывает, как сайт работает: CMS, формы, роли, данные, интеграции, SEO, аналитика и приемка.
Можно ли использовать шаблон ТЗ
Можно как подсказку, но не как готовый документ. Шаблон нужно адаптировать под вашу задачу, иначе в нем останутся формальные пункты без пользы.
Кто должен писать ТЗ
Лучше вместе: предприниматель или команда клиента описывает бизнес, подрядчик помогает перевести это в структуру, технические требования и этапы.
Что делать, если появляются новые требования
Записывать их отдельно и оценивать влияние на сроки, бюджет и первый запуск. Не каждую идею нужно добавлять сразу.
Нужно ли включать SEO в ТЗ
Да, если сайт должен получать поисковый трафик или если переделывается старый сайт. Важно учесть структуру URL, мета-теги, заголовки, блог, редиректы и редактирование SEO-полей.
Вывод
ТЗ на сложный сайт нужно предпринимателю, чтобы контролировать результат, а не писать документ ради документа. Оно помогает заранее договориться о страницах, данных, заявках, CMS, ролях, интеграциях, SEO и приемке.
Если готового ТЗ нет, это не повод откладывать проект. Но нужно начать с разбора задачи. Чем понятнее бизнес опишет цель, аудиторию, действия и ограничения, тем меньше риск переплатить за переделки.