Как составить ТЗ на разработку сайта (с шаблоном)

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

Зачем составлять ТЗ на разработку сайта

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

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

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

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

Правило из практики: если требование нельзя проверить по факту, его нужно переписать конкретнее.

С чего начать: цель, бизнес-задача и аудитория

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

Фраза «нужен сайт для компании» не помогает оценить проект. Рабочая формулировка выглядит иначе: «сайт должен презентовать услуги по ремонту коммерческих помещений в Алматы и собирать заявки на расчёт сметы». Для магазина добавьте количество товарных групп, примерный ассортимент и способ обработки заказов.

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

• Какие услуги или товары приносят бизнесу больше всего денег?
• Кто принимает заявку и за какое время отвечает клиенту?
• Какие вопросы человек задаёт до обращения?
• Почему клиент выбирает вас, а не альтернативу?
• Какие города нужно обслуживать: только Алматы, Астана или весь Казахстан?
• Нужны ли переходы в Kaspi, WhatsApp, Instagram, 2GIS или другие сервисы?

Опишите два-три сценария пользователя. Например: человек из Алматы ищет услугу в поиске, открывает страницу, смотрит портфолио, проверяет адрес в 2GIS и оставляет номер. Другой пользователь уже знает компанию, заходит с телефона и хочет быстро найти прайс или написать менеджеру в WhatsApp.

Какие разделы и страницы включить в шаблон ТЗ

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

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

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

Если структура пока неясна, приложите к ТЗ список вопросов, которые задают менеджерам. По ним часто видны будущие страницы: «какие документы нужны?», «есть ли доставка в Астану?», «можно ли оплатить через Kaspi?», «сколько длится монтаж?». Сайт должен отвечать на реальные вопросы, а не только рассказывать историю компании.

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

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

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

• Форма обратного звонка и заявка на консультацию.
• Кнопка звонка и переход в WhatsApp с мобильного устройства.
• Каталог с категориями, поиском, сортировкой и фильтрами.
• Корзина, доставка, промокод и выбор способа оплаты.
• Интеграция с CRM, почтой, Telegram или другой системой обработки лидов.
• Онлайн-карта с адресами и ссылкой на карточку компании в 2GIS.
• Админка для редактирования цен, текста, фотографий и товаров.

Для оплаты не пишите просто «подключить Kaspi». Уточните, какой сценарий нужен: ссылка на оплату, QR, перевод после подтверждения заказа или интеграция с платёжным сервисом. Подрядчику понадобятся данные о поставщике оплаты, статусах заказа, возвратах и том, кто отвечает за сверку платежей.

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

Дизайн, мобильная версия и контент в ТЗ

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

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

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

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

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

SEO и технические требования: что зафиксировать заранее

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

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

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

Не стоит вписывать в ТЗ конкретную технологию только потому, что её назвали в другой статье. Для бизнеса важнее результат: сайт быстро открывается, редактируется, корректно работает на телефоне и поддерживается после запуска. Мы используем Next.js и React там, где нужны скорость, гибкая структура и удобная админка, но выбор зависит от задачи.

Сроки, бюджет и критерии приёмки

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

Это ориентиры нашей студии, а не универсальный прайс рынка. Домен .kz, хостинг и SSL на первый год входят в стоимость разработки; для хостинга мы рекомендуем hoster.kz. Поддержка и доработка после запуска оформляются отдельно - от 50 000 ₸ в месяц.

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

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

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

Типичные ошибки и признаки плохого ТЗ

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

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

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

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

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

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

• Нужно ли писать ТЗ самому? Если проект небольшой, можно начать с шаблона и списка задач. Подрядчик должен проверить документ, задать вопросы и превратить его в согласованный план работ.
• Сколько страниц должно быть в ТЗ? Универсального объёма нет. Для простого лендинга хватит нескольких страниц с блоками и функциями, для магазина понадобится подробное описание каталога, заказа, оплаты и админки.
• Можно ли менять требования после согласования? Можно, но изменение может повлиять на цену и срок. Новую задачу лучше оформить отдельным пунктом с письменным подтверждением обеих сторон.
• Нужно ли указывать конкретную CMS или технологию? Только если есть техническая причина: существующая система, требования интеграции или внутренний специалист. В остальных случаях лучше зафиксировать ожидаемый результат и ограничения.
• Кто готовит тексты и фотографии? Это нужно прямо указать в ТЗ. Если материалы делает подрядчик, добавьте объём, формат, число страниц и порядок согласования.
• Что проверить перед запуском? Формы, мобильную версию, ссылки, оплату, заявки, аналитику, SEO-настройки, доступы и резервную копию. Тестируйте не только главную, но и основные сценарии клиента.

Что делать дальше

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

Если требования пока разрознены, мы можем помочь структурировать их на брифе и оценить проект для бизнеса в Алматы или другом городе Казахстана. В Pozhidayev разрабатываем сайты на Next.js и React, закладываем SEO-структуру с первого дня и передаём удобную админку. Начать можно со списка страниц, функций и материалов.