Техническое задание на разработку сайта: что подготовить заказчику

Представим: два подрядчика получили одну просьбу: «Нужен сайт компании с каталогом и заявками». Один оценил несколько страниц с формой, другой — каталог с фильтрами, переносом материалов и передачей обращений в CRM. Цены отличаются, но пока неизвестно, сколько в этой разнице стоимости работы, а сколько разного понимания задачи.

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

Что сайт должен менять в работе компании

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

Возьмём условную компанию, которая поставляет оборудование. Посетителю нужно найти подходящую категорию, посмотреть характеристики, выбрать модель и отправить запрос с количеством. Менеджер должен получить выбранный товар и контакт, а затем продолжить работу в CRM. В первой версии нет онлайн-оплаты и автоматического расчёта доставки. Такая граница сразу исключает часть неверных предположений.

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

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

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

Какие страницы и материалы нужны

Составьте структуру через задачи посетителя. Для условного поставщика это могут быть категории, страницы оборудования, услуги, проекты, сведения о компании и контакты. Затем определите типы страниц: карточек товаров много, но они могут использовать один согласованный шаблон. Количество шаблонов и объём заполнения — разные пункты работы.

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

Уточните, кто пишет тексты, подбирает или создаёт изображения, обрабатывает фотографии, переносит старые материалы и загружает карточки. Фраза «контент предоставляет заказчик» не отвечает, в каком виде, в каком объёме и когда он будет готов. Нехватка материалов может изменить график запуска, даже если сама разработка идёт по плану.

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

Как описать функции и интеграции

Функцию удобно описывать через действие и результат. Рассмотрим форму запроса оборудования. Посетитель открывает её с карточки товара. Форма сохраняет выбранную модель, предлагает указать количество, контакт и комментарий. После отправки человек получает понятное подтверждение, а менеджер — обращение с этими сведениями.

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

Для функции нужны входные данные, результат и понятное поведение при ошибке.

Для связи с CRM укажите данные, направление и подтверждение передачи. Менеджер должен понимать, откуда пришло обращение и какой товар выбрал посетитель. Если передача не сработала, сведения должны сохраниться в предусмотренном месте, а ответственный — увидеть проблему. Обещание «все заявки будут приходить» без описания ошибки неполно.

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

Список интеграций должен содержать ответственных с обеих сторон. Исполнитель сайта не всегда имеет доступ к CRM или учёту. Заранее выясните, кто предоставляет тестовое окружение, настройки и контрольные данные, а кто принимает итог обмена.

Как описать качество и передачу результата

Качество проверяют на действиях. Посетитель со смартфона должен суметь открыть карточку, прочитать характеристики, выбрать нужный вариант и отправить запрос. Редактор — изменить данные и увидеть их на странице. Менеджер — получить и обработать обращение. Красивого изображения главной страницы для такой проверки недостаточно.

Согласуйте перечень поддерживаемых устройств, браузеров и размеров экранов, на которых проверяются основные сценарии. Опишите важные условия: читаемый текст, доступные элементы управления, понятные подписи и сообщения об ошибках, управление формой с клавиатуры. Конкретный объём требований зависит от проекта и аудитории.

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

Для аналитики перечислите нужные события: отправка заявки, успешное оформление, переход к контакту. Определите, кто получает доступ и кто проверяет получение событий. Установленный счётчик сам по себе ещё не подтверждает, что компания увидит нужное действие.

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

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

Как проверить, что ТЗ выполнимо

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

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

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

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

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