ТЗ на разработку сайта

структура, требования и критерии приёмки

FatCat_bot 30.12.2025 - 15:27

ТЗ на разработку сайта: что включить, чтобы не было «переделок»

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

Почему переделки появляются даже у сильных команд

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

Типовые источники проблем:

• цели проекта сформулированы общими словами («сделать современно», «чтобы продавало»);

• функционал описан списком без сценариев («нужна корзина», «нужна форма»);

• контент и ответственность за него не определены;

• дизайн воспринимается как «понравится/не понравится», а не как набор правил и макетов;

• интеграции и ограничения (CRM, склад, оплата, доставка) выясняются в процессе;

• нет приёмочных критериев: что является дефектом, а что — доработкой.

Цели, аудитория и границы проекта: «зачем» и «что точно не делаем»

Начинать ТЗ стоит с короткого, но конкретного блока «контекст». Он снижает риск того, что команда сделает «правильный сайт», но не тот, который нужен бизнесу.

Что зафиксировать:

• цель сайта (лиды, продажи, запись, поддержка, презентация продукта);

• целевая аудитория и география (хотя бы 2–3 сегмента);

• ключевые действия пользователя (оставить заявку, купить, скачать, позвонить);

• конкуренты/референсы (что нравится и что раздражает, без копирования);

• границы проекта: что не входит в текущий этап (например, личный кабинет «в будущем», мультиязычность «в отдельной фазе»).

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

Вместо «увеличить продажи» лучше писать: «обеспечить возможность принять заказ и оплату», «сократить путь до заявки до 2–3 шагов», «собрать заявки из N форм в одну систему». Это не про обещание результата, а про проверяемую функциональность и логику.

Структура и логика сайта: страницы, блоки, сценарии

В ТЗ важны два уровня: структура (карта сайта) и сценарии (как пользователь проходит путь). Карта сайта отвечает на вопрос «что есть», сценарии — «как этим пользуются».

Что включить:

• список разделов и типов страниц (главная, категория, карточка товара/услуги, блог, контакты и т.д.);

• для каждого типа страницы — перечень блоков и их назначение;

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

Пример описания страницы, которое экономит часы правок

Не «страница услуги с формой», а:

• заголовок + краткое УТП (текст до 600–800 знаков);

• блок преимуществ (до 6 пунктов);

• кейсы/примеры (если есть — источник материалов);

• FAQ по услуге (5–7 вопросов);

• форма: поля, обязательность, валидация, сообщение об успешной отправке;

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

Функциональные требования: что сайт должен уметь

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

Опишите:

• формы (какие, где, поля, проверки, защита от спама, куда уходят данные);

• поиск и фильтры (по каким полям, логика сортировки, «пустая выдача»);

• каталог/корзина (если нужно): статусы, промокоды, доставка, налоги/НДС при необходимости;

• личный кабинет (если есть): роли, доступы, восстановление пароля;

• роли админки: кто что может менять, логирование изменений при необходимости.

Важно: у каждой функции должны быть ограничения

Например: «файл до 10 МБ», «не более 20 товаров в сравнении», «фильтр по 6 параметрам», «время ответа API до X секунд (если известно)». Это не бюрократия — это защита от расползания объёма.

Контент и материалы: кто готовит, в каком виде, что считается «готовым»

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

В ТЗ стоит закрепить:

• перечень материалов по страницам: тексты, фото, видео, документы, логотипы;

• требования к формату: размеры изображений, ориентация, качество, нейминг;

• кто отвечает за подготовку (заказчик/подрядчик/совместно);

• что делаем, если контента нет: используем заглушки или пишем базовый контент по брифу;

• правила редактуры: сколько итераций правок текста и в каком виде принимаются правки.

Дизайн и UX: чтобы «нравится/не нравится» не стало приговором

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

Что фиксировать:

• какие макеты делаем (минимум: главная, типовая внутренняя, карточка/услуга, форма/корзина);

• адаптивность: ключевые брейкпоинты и приоритеты на мобильных;

• состояния интерфейса: ошибка формы, пустая выдача, загрузка, успех;

• доступность: читаемость, контраст, кликабельные зоны (хотя бы базово).

Полезно заранее описать «рамки вкуса»: 3–5 референсов с пояснениями «нравится структура/типографика/подача», а не «сделайте как тут».

Технические требования: CMS, скорость, безопасность, хостинг

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

Что включить:

• выбранная CMS/фреймворк (или критерии выбора, если ещё не выбрано);

• требования к админке: какие сущности редактируются (страницы, товары, статьи, баннеры);

• скорость и производительность: базовые ожидания (оптимизация изображений, кеширование, минификация);

• безопасность: SSL, роли доступа, резервные копии, защита форм;

• хостинг/сервер: кто предоставляет, доступы, требования к окружению;

• миграции: перенос домена, почты, SSL, если планируется.

Если у вас уже есть действующий сайт, отдельно пропишите: что переносим, что оставляем, какие данные критичны (заказы, пользователи, SEO-адреса).

Интеграции и сторонние сервисы: CRM, оплаты, доставки, телефония

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

Опишите:

• список систем (CRM, 1С, МойСклад, рассылки, чат-виджеты, телефония);

• какие данные передаём (поля, обязательность, форматы);

• куда и когда отправляем (с какой формы, при каком событии);

• обработка ошибок (что видит пользователь, что видит администратор);

• кто выдаёт доступы и где хранятся ключи/API.

SEO и аналитика: чтобы не чинить «после запуска»

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

Что включить:

• ЧПУ и правила URL (транслит, дефисы, без дублей);

• мета-теги: где редактируются Title/Description/H1;

• 301-редиректы со старых страниц (если перенос);

• sitemap.xml и robots.txt;

• микроразметка (по необходимости: организация, товары, статьи);

• требования к индексации (noindex для техразделов, пагинации и т.п.);

• подключение аналитики и событий (цели, отправки форм, клики).

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

Критерии приёмки и тестирование: что считаем «сделано»

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

Что зафиксировать:

• список поддерживаемых браузеров и устройств (минимальный набор);

• чек-лист приёмки по страницам и функциям;

• что считается дефектом (не работает, ломает верстку, неверные данные);

• что считается доработкой (изменение требований, новые блоки, иной сценарий);

• порядок исправлений и повторной проверки.

Полезная практика: «матрица приёмки»

Сделайте таблицу: функция → сценарий → ожидаемый результат → статус. Это дисциплинирует обе стороны и снимает эмоциональные споры.

Управление изменениями: как добавлять новое без конфликтов

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

Рекомендуемый регламент:

• любое изменение фиксируется письменно (задача/заявка/документ);

• для изменения описываются причина и эффект на сроки/бюджет/архитектуру (без обязательных цифр, если не принято);

• изменение считается согласованным только после подтверждения обеими сторонами;

• отдельный список «хотелок» в бэклог, чтобы не мешать текущему этапу.

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

Как выбрать подрядчика и проверить, что ТЗ «реально прочитали»

Хороший маркер — подрядчик задаёт вопросы не про «цвет кнопки», а про сценарии, данные, интеграции и приёмку. Ещё лучше, если он предлагает уточнить риски и зависимые места до начала работ.

На что смотреть в ответе подрядчика:

• разложил ли он работу по этапам и результатам (артефактам);

• указал ли допущения (что предоставляете вы, что делает команда);

• заметил ли спорные места (контент, интеграции, перенос SEO-адресов);

• предложил ли критерии готовности и порядок приёмки;

• обозначил ли, где в ТЗ не хватает данных и какие решения возможны.

Если вы делаете сайт «с нуля», удобно, когда команда не просто «берёт ТЗ в работу», а помогает структурировать требования под разработку сайтов и проверяет их на реализуемость ещё до старта.

Практический чек-лист ТЗ, который снижает риск переделок

Ниже — минимальный набор, который стоит проверить перед подписанием ТЗ:

1. Цели и аудитория описаны конкретно, без общих лозунгов.

2. Есть карта сайта и список типов страниц.

3. Для ключевых страниц описаны блоки и сценарии.

4. Функционал задан через «пользователь → система», с ограничениями.

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

6. Дизайн: перечень макетов, адаптивность, состояния ошибок/успеха.

7. Техническая часть: CMS, админка, безопасность, хостинг, бэкапы.

8. Интеграции: какие системы, какие поля, события, обработка ошибок.

9. SEO и аналитика: URL, редиректы, мета-теги, карты/robots, события.

10. Приёмка: чек-лист, устройства/браузеры, критерии дефекта и доработки.

11. Регламент изменений: как добавляем новое и как согласуем.

Типовые ошибки в ТЗ и как их избежать

Ошибка 1. «Сделать как у конкурента»

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

Ошибка 2. «Функционал без сценариев»

Список «нужна форма/корзина/чат» почти не помогает. Сценарий («какие поля», «куда уходит заявка», «что видит пользователь») превращает хотелку в задачу.

Ошибка 3. Не договорились про контент

Если тексты и фото появятся поздно, заложите это в ТЗ: либо этап «контент», либо правила работы с заглушками и объёмом правок после замены.

Ошибка 4. Нет границы «дефект vs доработка»

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

Часто задаваемые вопросы (FAQ)

Вопрос: ТЗ обязательно должно быть большим документом на десятки страниц?

Нет. Объём не так важен, как конкретика: цели, структура, сценарии, интеграции и приёмка. Иногда 8–12 страниц с приложениями (карта сайта, прототипы) работают лучше, чем 40 страниц общих фраз.

Вопрос: Можно ли начать без готового контента?

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

Вопрос: Что важнее — прототипы или ТЗ текстом?

Лучше вместе. Прототипы показывают структуру и логику, а текст фиксирует детали: поля, события, интеграции, ограничения и критерии приёмки.

Вопрос: Как понять, что подрядчик не «додумывает» за вас?

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

Вопрос: Нужно ли включать SEO в ТЗ, если продвижение будет позже?

Как правило, да — хотя бы техническую основу: URL, редиректы при переносе, управление мета-тегами, sitemap/robots, базовую разметку и аналитику. Это дешевле предусмотреть сразу, чем перестраивать позже.

Вопрос: Что делать, если требования меняются по ходу проекта?

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

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

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

Заключение

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