Техническое задание на сайт нужно не для того, чтобы заранее описать каждую кнопку канцелярским языком. Его задача — зафиксировать общее понимание результата: какую проблему решает продукт, кто им пользуется, какие сценарии обязательны и по каким признакам работа будет принята. Хорошее ТЗ снижает неопределённость, но оставляет команде пространство для профессиональных решений.
Без такого документа заказчик и разработчик могут одинаково произносить слова «каталог», «личный кабинет» или «интеграция с CRM», представляя совершенно разный объём. Чем раньше эти различия становятся видимыми, тем точнее оценка и спокойнее разработка. Ниже — структура, которую можно адаптировать и для небольшого лендинга, и для многостраничного корпоративного сайта.
Чем ТЗ отличается от брифа
Бриф собирает исходную информацию о компании, аудитории, продукте, конкурентах и пожеланиях. Он помогает начать разговор, но часто содержит ответы на уровне идеи: «нужен современный сайт», «хотим получать больше заявок», «нужна синхронизация». Техническое задание переводит эти пожелания в проверяемые требования.
Например, фраза «форма должна отправляться в CRM» ещё не описывает интеграцию. В ТЗ нужно указать, какие поля передаются, когда создаётся или обновляется сделка, как определяется ответственный, что видит пользователь при успехе и ошибке, что происходит при недоступности внешнего сервиса. Не каждую деталь обязан придумать заказчик: подрядчик может выявить её на этапе аналитики и зафиксировать согласованное решение.
ТЗ также не заменяет прототип и дизайн. Документ отвечает на вопросы «что должно работать» и «при каких условиях», а макеты показывают расположение элементов и состояние интерфейса. Вместе они образуют более надёжную основу, чем любой из этих материалов по отдельности.
1. Контекст, цель и границы проекта
Начните с краткого описания бизнеса и причины запуска. Не ограничивайтесь формулировкой «создать сайт компании». Укажите, что должно измениться после запуска: появится самостоятельный канал заявок, клиентам станет проще выбирать услугу, менеджеры перестанут вручную пересылать документы или компания сможет публиковать материалы без разработчика.
Полезно разделить цели бизнеса и действия пользователей. Бизнес хочет получать квалифицированные обращения, а пользователь хочет понять условия и запросить расчёт. Бизнес хочет сократить нагрузку на поддержку, а пользователь — быстро найти инструкцию. Эта связка помогает проверить необходимость каждой страницы и функции.
В том же разделе зафиксируйте границы. Что точно входит в первую версию? Что осознанно отложено? Нужны ли перенос старого контента, настройка домена, аналитика, обучение редакторов и поддержка после запуска? Явное «не входит» защищает проект не хуже подробного списка работ.
2. Аудитория и пользовательские сценарии
Описание аудитории полезно только тогда, когда влияет на продукт. Вместо абстрактного «мужчины и женщины от 25 лет» укажите роль, контекст и задачу: владелец компании сравнивает подрядчиков с телефона; закупщик проверяет документы; действующий клиент скачивает инструкцию; кандидат изучает вакансии.
Для каждой важной роли опишите короткий маршрут:
- откуда пользователь приходит;
- какую информацию ищет сначала;
- что помогает ему принять решение;
- какое действие он выполняет;
- какое подтверждение получает;
- что происходит с запросом внутри компании.
Сценарии выявляют требования, которые легко пропустить в списке страниц. Например, после отправки заявки может потребоваться письмо клиенту, уведомление менеджеру и сохранение источника обращения. Для пользователя это одно действие, а для системы — несколько связанных операций.
3. Структура сайта и назначение страниц
Карта сайта перечисляет разделы и показывает их иерархию. Но одного названия страницы недостаточно. Рядом стоит записать её задачу, целевую аудиторию, основной контент и действие пользователя. Это помогает не создавать разделы «потому что они есть у всех».
| Страница | Задача | Ключевой контент | Основное действие |
|---|---|---|---|
| Главная | Объяснить предложение и направить дальше | Направления, преимущества, подтверждения компетенций | Выбрать услугу или оставить заявку |
| Услуга | Ответить на вопросы по конкретному решению | Результат, состав работ, процесс, ограничения | Запросить обсуждение |
| Проект | Показать подход на реальном материале | Задача, решение, изображения, проверяемый результат | Перейти к похожей услуге |
| Контакты | Дать удобные способы связи и реквизиты | Каналы связи, адрес, время ответа | Связаться |
Если часть страниц повторяется, опишите шаблон один раз и перечислите изменяемые поля. Для карточки проекта это могут быть название, отрасль, задача, описание решения, галерея, технологии и ссылка. Такой подход заранее формирует модель контента и упрощает будущую редактуру.
4. Контент и ответственность за материалы
В ТЗ важно указать не только блоки, но и источник содержимого. Кто пишет тексты, подбирает изображения, готовит переводы, проверяет юридические формулировки и передаёт реквизиты? В каком формате материалы поступают команде и кто утверждает финальную версию?
Для динамического контента перечислите поля и правила. Например, у статьи есть заголовок, адрес, обложка, текст, автор, дата и статус публикации. У изображения должны быть допустимый формат, размер и альтернативное описание. Если редактор может менять порядок блоков, это тоже является функциональным требованием.
Не используйте реальный персональный контент в макетах без необходимости. Для проектирования достаточно обезличенных примеров, а финальные данные можно загрузить после утверждения структуры и правил обработки.
5. Функциональные требования
Функцию лучше описывать через поведение системы, а не название технологии. Для каждой формы перечислите поля, обязательность, проверку данных, согласие на обработку, защиту от спама, получателей, сообщение об успехе и действия при ошибке. Для поиска — где он работает, по каким данным ищет, как отображает пустой результат. Для личного кабинета — роли, доступные операции и состояния.
Учитывайте не только идеальный путь. Что произойдёт, если пользователь загрузит неподдерживаемый файл, дважды нажмёт кнопку, откроет устаревшую ссылку или потеряет соединение? Необязательно описывать все технические исключения, но критичные ошибки и сообщения должны быть согласованы.
Если сайт включает административную панель, перечислите, какие сущности редактируются, кто имеет к ним доступ и какие действия требуют подтверждения. Формулировка «удобная админка» непроверяема; список операций делает ожидания конкретными.
6. Интеграции и данные
Для каждой внешней системы укажите её владельца, назначение и направление обмена. Сайт только отправляет лиды в CRM или получает оттуда статусы? Каталог загружается из учётной системы или редактируется на сайте? Как часто обновляются данные? Что считается источником истины при расхождении?
Полезно зафиксировать доступность документации и тестового окружения, ограничения внешнего сервиса, способ авторизации и ответственность за получение доступов. Секретные ключи и пароли не следует помещать в само ТЗ: документ может передаваться широкому кругу участников. Достаточно описать процедуру безопасной передачи.
Отдельно определите поведение при сбое. Заявка не должна бесследно исчезать из-за временной недоступности CRM. Система может сохранить запрос, повторить отправку или уведомить ответственного — конкретный механизм выбирает команда, но ожидаемый результат нужно обозначить.
7. Нефункциональные требования
Эти требования описывают качество работы сайта, а не отдельные функции. Обычно стоит рассмотреть следующие области:
- адаптивность: поддерживаемые диапазоны экранов и важные мобильные сценарии;
- производительность: правила оптимизации изображений, скриптов и шрифтов, проверка на согласованных страницах;
- доступность: клавиатурная навигация, контраст, подписи полей и альтернативные описания;
- SEO: редактируемые title и description, человекопонятные адреса, canonical, sitemap, robots.txt и структурированные данные там, где они уместны; отдельный чек-лист технического SEO-аудита поможет сформулировать критерии проверки;
- безопасность: разграничение прав, защита форм, обновление зависимостей, резервное копирование и безопасное хранение секретов;
- совместимость: актуальные браузеры и устройства, на которых проверяются основные сценарии;
- аналитика: события, цели, правила согласия и исключение чувствительных данных из систем аналитики.
Фраза «PageSpeed 100 на всех устройствах» не является хорошим требованием: результат теста зависит от страницы, среды и сторонних сервисов. Лучше зафиксировать метод проверки, набор страниц, условия и перечень допустимых исключений.
8. Критерии приёмки
Критерий приёмки должен позволять однозначно проверить результат. «Форма работает корректно» лучше заменить сценарием: обязательные поля проверяются, валидная заявка сохраняется и передаётся получателю, пользователь видит подтверждение, а при недоступности интеграции данные не теряются.
Удобно группировать проверки по пользовательским маршрутам, шаблонам страниц, ролям и интеграциям. Для каждого пункта укажите ожидаемый результат и среду проверки. Визуальное соответствие оценивается по утверждённым макетам с учётом адаптивного поведения, а не по совпадению каждого пикселя на произвольном экране.
Также определите, что считается дефектом, как фиксируются замечания и сколько циклов проверки предусмотрено. Новое пожелание, которого не было в согласованных материалах, следует оценивать как изменение, а не маскировать под исправление ошибки.
9. Порядок работы с изменениями
ТЗ не обязано быть неизменным. Во время прототипирования могут появиться новые знания об аудитории или ограничениях интеграции. Надёжный процесс позволяет обновлять решение управляемо: сформулировать изменение, оценить его влияние на сроки и объём, согласовать приоритет и зафиксировать новую версию.
Для крупных проектов полезен журнал решений: что изменили, почему, кем согласовано и какие требования затронуты. Это сохраняет контекст и предотвращает возвращение к уже закрытым обсуждениям.
Практический шаблон ТЗ
- Описание бизнеса, продукта и причины проекта.
- Цели бизнеса и ожидаемые действия пользователей.
- Границы первой версии и явно исключённые работы.
- Роли аудитории и ключевые пользовательские сценарии.
- Карта сайта и назначение каждой страницы.
- Типы контента, поля и ответственные за материалы.
- Функции с состояниями успеха, ошибки и пустых данных.
- Интеграции, направления обмена и источники истины.
- Требования к адаптивности, скорости, SEO, доступности и безопасности.
- Аналитические события и правила обработки данных.
- Критерии приёмки и порядок тестирования.
- Этапы, результаты каждого этапа и процедура изменений.
- Передача доступов, документации, исходных материалов и обучение.
Хорошее ТЗ описывает не количество блоков, а согласованный результат и способ его проверить.
Если у вас есть идея, заметки или черновой бриф, передайте их Stackvibe. Мы поможем превратить исходные требования в понятную структуру проекта и основу для точной оценки.