Как составить ТЗ на разработку сайта: шаблон из 5 вопросов

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

Хорошее техническое задание на сайт отвечает на пять вопросов: что создаем, для кого, какой результат ожидаем, что обязательно должно работать и в каких ограничениях ведется проект. Этого достаточно, чтобы подрядчик понял масштаб, задал содержательные вопросы и подготовил обоснованную оценку.

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

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

Бриф собирает исходную информацию о компании и задаче. Обычно заказчик заполняет его до первой встречи: описывает продукт, аудиторию, конкурентов, сроки и пожелания.

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

На небольшом проекте документы можно объединить. Для сложного сервиса процесс обычно выглядит так:

1. заказчик формулирует бизнес-задачу в брифе;
2. команда проводит интервью и анализирует процессы;
3. создаются прототипы и описание сценариев;
4. стороны согласуют ТЗ или спецификацию первой версии.

Не обязательно приходить к разработчику с готовым техническим решением. Задача бизнеса — описать цели, пользователей и ограничения. Выбор архитектуры, технологий и способа интеграции — ответственность команды разработки.

Вопрос 1. Что должен изменить сайт

Начните не со списка страниц, а с проблемы.

Сравните две формулировки:

Нужен современный корпоративный сайт на 20 страниц.

и

Нужен сайт, который объясняет три направления услуг, подтверждает опыт кейсами и передает квалифицированные обращения в CRM.

Во втором варианте понятна цель. Команда сможет решить, какие страницы и элементы интерфейса поддерживают ее, а какие не нужны.

В ТЗ стоит указать:

• почему компания запускает или переделывает сайт;
• что не работает сейчас;
• какое действие посетителя считается целевым;
• как заявка или заказ обрабатывается внутри компании;
• по каким показателям будет оцениваться результат.

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

Пример

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

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

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

Вопрос 2. Для кого создается сайт

Фраза «для всех клиентов» не помогает спроектировать интерфейс. Разным пользователям нужны разные аргументы, документы и действия.

Опишите основные группы:

• кто принимает решение о покупке;
• кто собирает информацию и сравнивает варианты;
• кто будет регулярно пользоваться сервисом;
• кто администрирует сайт внутри компании.

Для каждой группы ответьте:

1. С какой задачей человек приходит?
2. Что он уже знает о продукте?
3. Какие сомнения мешают принять решение?
4. Какое действие должен выполнить?
5. С какого устройства и в каких условиях он пользуется сайтом?

Например, на сайте производителя инженер ищет характеристики и документацию, закупщик — условия поставки и реквизиты, руководитель — надежность компании и реализованные проекты. Если всю информацию смешать на одной странице, каждый будет искать нужное дольше.

Вопрос 3. Что пользователь должен уметь делать

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

Не «нужен каталог», а:

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

Не «нужен личный кабинет», а:

Клиент входит по номеру телефона, видит активные заказы, скачивает документы и задает вопрос по конкретному заказу.

Такой формат показывает границы функции и позволяет оценить все связанные работы.

Что перечислить в ТЗ

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

Интеграции

Для каждой внешней системы укажите:

• название и версию сервиса;
• какие данные передаются;
• в каком направлении идет обмен;
• как часто выполняется синхронизация;
• что должно происходить при ошибке;
• есть ли доступ к API и техническая документация.

Фраза «интегрировать с 1С» может означать отправку одного заказа или сложный двусторонний обмен каталогом, ценами, остатками, клиентами и статусами. Без расшифровки оценка будет приблизительной.

Вопрос 4. Какие материалы и ограничения уже есть

Разработка зависит от готовности контента не меньше, чем от функций.

Укажите, кто предоставляет:

• логотип и фирменный стиль;
• тексты;
• фотографии и видео;
• характеристики товаров;
• юридические документы;
• переводы;
• данные для переноса со старого сайта.

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

Технические ограничения

Зафиксируйте известные требования:

• домен и хостинг;
• существующая CMS или технологический стек;
• корпоративные требования к безопасности;
• необходимость размещения данных в России;
• поддерживаемые браузеры и устройства;
• планируемая нагрузка;
• доступность для пользователей с ограничениями;
• языковые версии;
• требования к SEO и аналитике.

Не стоит самостоятельно выбирать технологию только потому, что ее использует знакомая компания. Опишите ограничения и ожидаемый результат — разработчик предложит подходящий стек и объяснит выбор.

Вопрос 5. Как принимается результат

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

Примеры:

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

В ТЗ или договоре также указывают:

• этапы и сроки;
• порядок согласования;
• количество итераций правок;
• способ передачи замечаний;
• правила оценки дополнительных работ;
• состав материалов при сдаче: код, дизайн-макеты, инструкции, доступы.

Готовая структура ТЗ на сайт

Ниже — шаблон, который можно скопировать в документ и заполнить.

1. Общая информация

• Название компании и проекта.
• Контактные лица со стороны заказчика.
• Краткое описание продукта или услуги.
• Причина запуска или обновления сайта.

2. Цель и показатели

• Бизнес-задача.
• Целевые действия пользователей.
• Текущие проблемы.
• Метрики результата.

3. Пользователи

• Основные группы.
• Их задачи и сомнения.
• Устройства и контекст использования.
• Роли в системе.

4. Структура

• Список разделов.
• Типы страниц.
• Навигация.
• Связи между материалами.

5. Функциональные сценарии

• Что делает пользователь на каждом ключевом шаге.
• Какие данные вводит и получает.
• Какие проверки и статусы предусмотрены.
• Что видит при ошибке.

6. Интеграции

• CRM, ERP, 1С, платежи, доставка, телефония, аналитика.
• Состав и направление обмена.
• Доступы и документация.
• Поведение при сбоях.

7. Контент и дизайн

• Фирменный стиль.
• Референсы с объяснением, что именно нравится.
• Состав текстов и медиа.
• Ответственные за подготовку и загрузку.

8. Нефункциональные требования

• Производительность.
• Безопасность.
• Резервное копирование.
• Браузеры и устройства.
• SEO, аналитика и доступность.

9. Приемка и передача

• Проверяемые критерии.
• Тестовая среда.
• Порядок фиксации замечаний.
• Состав передаваемых файлов, доступов и документации.

10. Развитие после запуска

• Гарантийный период.
• Формат технической поддержки.
• Функции следующей очереди.

Частые ошибки в техническом задании

Копировать функции конкурента без контекста

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

Описывать внешний вид вместо поведения

«Красная кнопка справа» — дизайнерское решение. «Кнопка должна быть заметна после выбора тарифа и вести к оплате» — требование к сценарию.

Пытаться предусмотреть все будущие функции

Слишком большой документ замедляет старт и фиксирует гипотезы, которые еще не проверены. Выделите первую версию и отдельно составьте список развития.

Не назначать одного ответственного

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

Не описывать работу после формы

Кнопка «Отправить» — не конец сценария. Важно определить, куда попадает заявка, кто получает уведомление, как фиксируется источник и что видит пользователь.

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

Кто должен писать ТЗ — заказчик или подрядчик?

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

Можно ли начать без готового ТЗ?

Можно начать с предпроектного этапа: брифа, интервью, аудита и прототипа. Начинать полноценную разработку без согласованных границ рискованно.

Нужно ли указывать бюджет?

Бюджет помогает выбрать реалистичный состав первой версии. Это не приглашение потратить всю сумму, а ограничение для поиска решения.

Что делать, если требования меняются?

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

Главное

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

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