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

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

Сильное ТЗ помогает согласовать ожидания ещё до макетов и программирования. В нём разделяются обязательные требования и пожелания, указываются способы оплаты, сроки, ответственные стороны и критерии приёмки. Так команда может оценить объём работ, а заказчик — проверить результат по объективным признакам, а не по личному вкусу. Документ также разделяет зоны ответственности: заказчик предоставляет контент и утверждает решения, команда отвечает за проектирование и техническую реализацию. Если требование невозможно проверить, его лучше уточнить до подписания.

Ниже разобран пример для компании из Астаны и приведён шаблон, который можно адаптировать к услугам, корпоративному сайту, лендингу или интернет-магазину. Отдельно отмечены детали, которые важны при запуске продаж, подключении домена, аналитики и рекламы в Google Ads. Такой подход подходит и для небольшого лендинга, где важно быстро запустить рекламу, и для сложного сервиса с личным кабинетом и интеграциями. Главное — начать с целей и пользовательских сценариев, а технические детали последовательно уточнять до начала разработки.

Что должно содержать рабочее ТЗ

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

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

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

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

Как сформулировать требования

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

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

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

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

Пример заполнения для интернет-магазина

Заказчик продаёт в Астане кофейное оборудование для небольших кафе. Цель проекта — создать каталог, который показывает характеристики, цены и условия доставки, а также принимает заявки на подбор. Целевая аудитория — владельцы кофеен, бариста и управляющие; приоритетный результат — заявка с именем, телефоном, типом оборудования и комментарием.

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

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

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

Готовый шаблон документа

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

• Название проекта, заказчик, контактное лицо и ответственный подрядчик.
• Бизнес-задача, целевая аудитория, география и ожидаемый результат.
• Референсы сайтов, брендбук, желаемый стиль и примеры понравившихся страниц.
• Карта страниц, тип каждой страницы, её цель, обязательные блоки и приоритет.
• Тексты, изображения, видео, цены, акции и ответы на частые вопросы; ответственный за предоставление материалов.
• Требования к дизайну: цветовая схема, шрифты, сетка, иллюстрации, адаптивность и мобильная версия.
• Функции сайта: формы, каталог, фильтры, поиск, корзина, личный кабинет, блог или другие нужные разделы.
• Поведение форм, поля, валидация, уведомления, обработка ошибок и передача заявок.
• Интеграции с платёжными системами, доставкой, складом, системой учёта клиентов, мессенджерами, почтой и сервисами аналитики.
• Домен, хостинг, SSL, карта сайта для поисковых систем, редактор, роли пользователей, резервные копии и обновления.
• Поисковая оптимизация: метаданные, структура адресов страниц, robots.txt, карта сайта, микроразметка и требования к контенту.
• Аналитика: счётчики, цели, события, параметры, доступ к отчётам, целевые действия и отчётность.
• Скорость, безопасность, доступность, поддержка браузеров, локализация языков и доступные версии сайта.
• Тестовый сценарий, критерии приёмки, сроки исправлений, форма приёмки и гарантийный период.
• Этапы, состав поставок, стоимость, порядок оплаты, документы и ответственность сторон.

Готовый шаблон можно разделить на обязательные и дополнительные поля. В обязательные попадают цели, карта страниц, сценарии пользователя, интеграции и критерии приёмки; в дополнительные — пожелания по анимации, расширенные фильтры или нестандартные виджеты. Такое разделение помогает быстро оценить стоимость и сроки, не превращая каждый комментарий в обязательную часть разработки. Для оценки каждой позиции полезно сразу назначить ответственного и указать предполагаемый результат.

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

Как проверить готовность документа

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

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

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

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

Передать проект в работу

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

Для бизнеса в Астане Kazdev.kz может создать лендинг или корпоративный сайт, подобрать домен и хостинг, настроить инструменты управления и добавить функции, связанные с продажами. Агентство также настраивает и ведёт кампании Google Ads по поиску и медийной сети, привлекая целевой трафик и заявки на услуги или продукты. Работы проводятся в пакетах с фиксированной ценой; доступна рассрочка через Kaspi Bank и Alfa Bank.

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

Оставьте заявку на сайте Kazdev.kz с описанием задачи, желаемых сроков и примеров сайтов, которые нравятся. Команда уточнит детали, предложит структуру и формат оплаты, а затем подготовит понятное ТЗ для согласования до начала разработки.