В поиске «техзадание на сайт пример» чаще всего вбивают после первого неудачного опыта: сайт сдали, а он «не такой». Виноваты обычно не руки разработчика, а договорённости на словах. Этот текст — рабочий шаблон ТЗ, который мы выработали на 120 проектах, и список ошибок, которые видим в чужих техзаданиях каждую неделю.
Зачем нужно ТЗ на разработку сайта
ТЗ — это не бюрократия, а три практические функции. Во-первых, общая система координат: «современный дизайн» для вас и для дизайнера — разные картинки, а «страница каталога с фильтром по цене и бренду» — одна и та же. Во-вторых, основа сметы: цена считается от объёма работ, и стоимость сайта под ключ без зафиксированного объёма — гадание. В-третьих, юридическая защита обеих сторон: при споре «входило ли это в работу» арбитром выступает документ, а не память переписки.
Есть и обратная сторона: ТЗ на 40 страниц для лендинга за 300 тысяч — перерасход сил. Глубина документа должна соответствовать масштабу: для визитки хватит структурированного брифа, для портала или мобильного приложения нужен полноценный дискавери-этап с проектной документацией.
ТЗ, бриф и КП — в чём разница
Три документа постоянно путают, хотя роли у них разные:
| Документ | Кто пишет | Что отвечает |
|---|---|---|
| Бриф | Клиент (по вопросам студии) | «Чего я хочу и зачем»: бизнес-цели, аудитория, примеры, бюджет |
| КП | Студия | «Что предлагаем и почём»: состав работ, цена, сроки, условия |
| ТЗ | Студия вместе с клиентом | «Что именно будет сделано»: страницы, функции, контент, критерии приёмки |
Нормальная последовательность: бриф → КП → договор → детальное ТЗ как приложение к договору. Если студия просит вас самостоятельно принести готовое ТЗ — это перекладывание профессиональной работы на заказчика. Как ещё распознать слабого подрядчика — в статье «7 проверок перед оплатой».
Как составить ТЗ на сайт: 7 обязательных блоков
Каким бы ни был формат документа, эти семь блоков обязаны в нём быть:
| Блок | Что фиксируем | Пример формулировки |
|---|---|---|
| 1. Цели | Бизнес-задача сайта, измеримые KPI | «Сайт собирает заявки на замер: цель — 30 заявок/мес при текущем трафике» |
| 2. Аудитория | Сегменты, сценарии, устройства | «ЛПР — снабженцы строительных компаний, 70% заходят с телефона» |
| 3. Структура | Карта страниц, навигация | «11 страниц: главная, 5 услуг, кейсы, о компании, блог, контакты, политика» |
| 4. Функционал | Формы, фильтры, интеграции, админка | «Форма заявки с файлом до 20 МБ, уведомления в Telegram, выгрузка в CRM» |
| 5. Контент | Кто готовит тексты, фото, видео и к какому сроку | «Тексты — студия, фото производства — клиент до 10-го дня проекта» |
| 6. SEO-требования | Семантика, мета-теги, скорость, разметка | «ЧПУ-адреса, уникальные title/description, Schema.org, LCP ≤ 2 сек» |
| 7. Критерии приёмки | Как проверяем, что готово | «Формы доставляют заявки, сайт корректен в Chrome/Safari, мобильная версия без горизонтального скролла» |
Цели и KPI: блок, который пропускают чаще всего
Девять из десяти чужих ТЗ, которые мы видим, начинаются со структуры страниц — и ни слова о том, зачем сайт бизнесу. А ведь от цели зависит всё: корпоративный сайт «для доверия снабженцев» и корпоративный сайт «для найма персонала» — два разных проекта с разной структурой. Цель формулируется в цифрах: заявки, звонки, продажи — то, что можно посчитать через аналитику рекламных каналов после запуска.
Структура и функционал: где рождается смета
Каждая страница и каждая функция — это часы работы. «Каталог» — одна строка в ТЗ, но каталог на 30 позиций без фильтров и каталог на 3 000 позиций с синхронизацией из 1С отличаются по цене в несколько раз — мы подробно разбирали это в статье о стоимости интернет-магазина. Поэтому функционал описывается сценариями: «пользователь выбирает услугу → заполняет форму с вложением → менеджер получает уведомление». Интеграции (CRM, оплата, телефония) перечисляются поимённо — «интеграция с CRM» без названия системы не считается: внедрение amoCRM и Bitrix24 — разные по трудоёмкости задачи.
Критерии приёмки: страховка от вечного проекта
Без критериев приёмки сдача превращается в переговоры «нравится — не нравится». Рабочий формат — проверяемый чек-лист: формы отправляются, страницы открываются быстрее заданного порога, вёрстка корректна на экранах от 360 px, админка позволяет менять тексты без программиста. Сюда же — порядок правок: сколько итераций входит в цену и что считается новой задачей. Как выглядит здоровый процесс целиком — в статье «Этапы создания сайта: от брифа до релиза».
Не хотите писать ТЗ самостоятельно?
Заполните квиз за 3 минуты — наш бриф заменяет первичное ТЗ. Предварительное КП пришлём за 2 рабочих часа, макет первого экрана — за 48 часов до договора и оплаты.
Пример техзадания на сайт: шаблон из 12 разделов
Каркас, который мы используем как приложение к договору на корпоративные сайты. Берите и адаптируйте под свой проект:
- О компании и проекте. Чем занимается бизнес, что продаёт, чем отличается от конкурентов. 3–5 предложений, не страница.
- Цели сайта и KPI. Главное целевое действие посетителя и измеримый показатель успеха.
- Целевая аудитория. 2–3 сегмента со сценариями: кто, с какой задачей, с какого устройства.
- Анализ конкурентов. 3–5 сайтов: что нравится, что нет, чем будем отличаться. Если ниша сложная — закажите профессиональный анализ конкурентов до старта разработки.
- Структура сайта. Полная карта страниц со вложенностью и назначением каждой.
- Описание страниц. Для ключевых страниц — блочная структура: какие секции, в каком порядке, с какими целевыми действиями.
- Функциональные требования. Формы, калькуляторы, личные кабинеты, поиск, фильтры, мультиязычность — сценариями использования.
- Интеграции. CRM, телефония, оплата, 1С, аналитика — конкретные системы и направление обмена данными.
- Контент. Матрица ответственности: какие тексты, фото и видео готовит клиент, какие — студия, и к каким датам. Если фирстиля нет — брендинг идёт отдельным этапом до дизайна.
- Технические и SEO-требования. Скорость загрузки, адаптивность, базовая SEO-подготовка: структура заголовков, мета-теги, разметка, sitemap.
- Хостинг, домен, поддержка. Где живёт сайт, кому принадлежат доступы, что входит в поддержку после релиза.
- Сроки, этапы, критерии приёмки. Календарный план с контрольными точками и проверяемый чек-лист сдачи. Ориентиры по срокам — в статье «Сколько времени занимает создание сайта».
Типовые ошибки ТЗ
- Оценочные прилагательные вместо требований. «Современный», «стильный», «продающий» — непроверяемо. Замените референсами: «как у конкурента X, но со своей палитрой».
- Списки страниц без описания содержимого. «Главная, услуги, контакты» — это не структура, а оглавление. Смета по такому списку гарантированно поплывёт.
- Забытый контент. Самая частая причина срыва сроков: дизайн готов, а текстов и фото нет. Пропишите ответственных и даты.
- «SEO потом». Структуру, ЧПУ и скорость нельзя «прикрутить» после релиза без переделки — закладывайте требования сразу, особенно если планируете уходить с конструктора на кастом.
- Нет границ объёма. Если не зафиксировано число страниц, итераций дизайна и состав работ — проект превращается в бесконечный, а отношения — в испорченные.
- ТЗ ради ТЗ. Сорок страниц, которые никто не читает, хуже четырёх страниц, по которым реально работают и принимают результат.
Отдельная история — ТЗ, скопированное из интернета под другой проект. Чужой шаблон с «личным кабинетом» и «мультиязычностью», которые вашему бизнесу не нужны, раздувает смету на сотни тысяч тенге. Каждый пункт техзадания должен отвечать на вопрос «зачем это нашим клиентам» — иначе вы платите за функции, которыми никто не воспользуется.
Чем грозит «сделайте красиво»
«Сделайте красиво, вы же профессионалы» — самая дорогая фраза в веб-разработке. Звучит как доверие, работает как мина. У «красиво» нет критерия приёмки: дизайнер делает три варианта, ни один «не то», круг повторяется. Каждая итерация — дни срока и часы бюджета. На практике проект без внятных требований дорожает на 30–50% и сдаётся на месяцы позже — или не сдаётся вовсе, пополняя коллекцию ошибок дизайна.
Лечится просто: «красиво» переводится в референсы (3–5 сайтов, которые нравятся, с комментарием почему), ограничения (фирменные цвета, логотип) и бизнес-цель (солидность для корпоративных клиентов или динамика для молодой аудитории). После этого дизайн перестаёт быть лотереей — убедитесь на наших кейсах, где у каждого проекта видна исходная задача.
Как это устроено в Hyperlab: бриф-квиз вместо первичного ТЗ
Мы не просим клиента приносить готовое техзадание. Вместо этого — структурированный квиз на 5 шагов: тип сайта, цели, бюджет, сроки, материалы. Он покрывает первичное ТЗ, и по нему мы присылаем предварительное КП за 2 рабочих часа. Дальше для лендингов, визиток и корпоративных сайтов — макет первого экрана за 48 часов до договора и оплаты: вы оцениваете не обещания, а реальную работу. Детальное ТЗ становится приложением к договору — с этапами оплаты (50/50 до миллиона, 30/40/30 выше), неустойкой 1% за день просрочки и 30 днями правок после релиза. Для крупных проектов — магазинов и порталов — добавляется дискавери-этап, где проектная документация прорабатывается глубже.
Частые вопросы
Чем ТЗ отличается от брифа?
Бриф — это вопросы студии и ответы клиента: цели, аудитория, пожелания. ТЗ — итоговый документ о том, что именно будет сделано: страницы, функции, интеграции, критерии приёмки. Бриф пишет клиент за 15 минут, ТЗ составляет студия на основе брифа и созвона.
Кто должен писать ТЗ — клиент или студия?
Студия, на основе брифа клиента. Составление ТЗ — профессиональная работа: нужно знать, какие требования влияют на смету и что забывают зафиксировать. Если подрядчик требует готовое ТЗ от вас — он экономит на аналитике за ваш счёт.
Сколько страниц должно быть в ТЗ?
Зависит от масштаба: для лендинга достаточно 2–4 страниц со структурой экранов и критериями приёмки, для корпоративного сайта — 5–10, для портала или магазина — полноценная проектная документация после дискавери. Документ, который никто не читает, бесполезен при любом объёме.
Можно ли заказать сайт без ТЗ?
Можно, но тогда роль ТЗ должен играть другой документ: детальное КП с составом работ или структурированный бриф, закреплённый в договоре. Работа вообще без зафиксированного объёма — лотерея для обеих сторон и главная причина споров на сдаче.
Что делать, если в процессе захотелось изменить ТЗ?
Это нормально и решается процедурой изменений: новая хотелка оценивается по влиянию на смету и срок, оформляется допсоглашением — и только потом уходит в работу. Мелкие правки в рамках согласованного объёма у нас покрываются итерациями в цене и 30 днями правок после релиза.