Техническое задание на сайт: как составить, чтобы смета сошлась

Почему расплывчатое ТЗ съедает бюджет и сроки

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

Фраза «нужен сайт компании, страниц десять, с формой заявки» выглядит понятной. На самом деле в ней спрятано несколько развилок, и каждая стоит денег:

• Форма заявки — это письмо на почту или заявка падает в CRM, создаёт сделку и шлёт клиенту автоответ?
• Десять страниц — это десять уникальных экранов с отдельной вёрсткой или один шаблон, который наполняют текстом десять раз?
• Контент — вы отдаёте готовые тексты и фотографии или их тоже кто-то должен написать и снять?
• Языки — один или три, и кто отвечает за перевод?

Между «дешёвым» и «дорогим» прочтением этого абзаца разница кратная — и оба прочтения честные: просто в тексте не было ответа.

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

ТЗ, бриф и scope of work: чем отличаются и кто их пишет

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

Техническое задание — описание того, что будет сделано: список страниц, структура каждой, функции, сценарии, интеграции, требования к админке, критерии приёмки. Его пишут после того, как задача понята, и оно становится приложением к договору. Scope of work — граница работ: что входит, а что нет. Строчка «наполнение карточек товара выполняется силами заказчика» стоит дороже, чем страница красивых формулировок.

Кто должен писать ТЗ

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

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

Начало ТЗ: бизнес-цель, аудитория, конкуренты

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

Бизнес-цель

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

Аудитория

Аудиторию описывают поведением, а не демографией. «Мужчины 25–45» не даёт разработчику ничего. А вот это даёт:

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

Конкуренты

Дайте три-пять ссылок и к каждой одно предложение: что здесь сделано хорошо и что плохо. Не «нравится дизайн», а «у них цена видна сразу, без запроса — хочу так же». Такая привычка экономит недели переписки, потому что переводит вкус в требования. И напишите честно, чем вы отличаетесь от этих конкурентов: если отличий нет — это не проблема сайта, и никакая вёрстка её не решит.

Список страниц и структура: главный раздел ТЗ

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

Как описывать структуру страницы

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

1. Первый экран: заголовок, короткое описание, кнопка запроса расчёта.
2. Что входит в услугу — маркированный список, 5–8 пунктов.
3. Как проходит работа — этапы, от 3 до 6 шагов.
4. Цены: таблица тарифов либо строка «от», решаем на дискавери.
5. Примеры работ — три карточки, подтягиваются автоматически из портфолио по тегу услуги.
6. Частые вопросы — редактируются из админки. Форма запроса.

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

Навигация и связи

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

Как описывать функциональность без двусмысленностей

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

Рабочая альтернатива — сценарии: кто, что делает и что получает. Сравните. Плохо: «Личный кабинет с историей заказов». Хорошо:

• Клиент входит по email и паролю, есть восстановление пароля по ссылке из письма.
• Клиент видит список заказов: номер, дата, сумма, статус, кнопка «повторить».
• Статусов пять: новый, в работе, отгружен, доставлен, отменён. Меняет их менеджер вручную в админке.
• По кнопке «повторить» товары кладутся в корзину; чего нет в наличии, то пропускается с сообщением.
• Клиент скачивает счёт в PDF, но не может изменить название юрлица — это делает только менеджер.

Второй вариант оценивается в часах без единого звонка; первый — только гаданием, мимо.

Описывайте краевые случаи

Дорого стоит не основной сценарий, а всё вокруг него — тут прячется половина бюджета:

• Что происходит, когда данных нет: пустая корзина, поиск без результатов, категория без товаров.
• Что происходит при ошибке: платёж не прошёл, файл слишком большой, email уже зарегистрирован.
• Что видит пользователь при обрыве связи посреди оплаты и кто что может делать — у редактора и администратора разные права.

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

Контент, интеграции и языки: кто, что и когда даёт

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

Контент

В ТЗ должно быть прямо написано, кто отвечает за каждый тип контента и к какому сроку он появляется:

• Тексты страниц. Пишет заказчик, копирайтер студии, или пишете вы, а редактируем мы? Три разных цены.
• Фотографии. Ваш архив, съёмка или сток? Если съёмка — кто организует и оплачивает.
• Каталог. Кто заполняет карточки, откуда описания, в каком формате приходит выгрузка.
• Юридические документы. Политика, оферта, реквизиты — зона заказчика, но напомнить должна студия.

И отдельная строка: что делаем, если контента к сроку нет. Нормальная практика — запускаемся с заглушками по согласованному списку страниц, а не держим готовый сайт в столе месяцами, споря, кто виноват.

Интеграции

Каждая интеграция описывается по одной схеме: какая система, что и куда передаём, в какой момент, что делать при ошибке. «Интеграция с CRM» бессмысленна: под неё подпадает и два часа работы, и две недели. Переберите минимум: CRM, платёжный шлюз, доставка, складская программа, рассылка, мессенджеры, касса, аналитика. По каждому пункту нужен ответ: есть ли API, есть ли документация, у кого доступы. Если доступов нет — это риск, и он должен быть виден в ТЗ, а не всплыть за неделю до запуска.

Языки

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

Дизайн-референсы и ловушка «хочу как у X»

Референсы нужны: без них дизайнер вынужден угадывать вкус, а угадать вкус по переписке невозможно. Но подавать их надо правильно.

Ловушка «хочу как у X» выглядит безобидно, а стоит дорого. Проблема даже не в том, что копия чужого сайта не работает для вашего бизнеса — другой продукт, другая аудитория, другой средний чек. Проблема в том, что сайт вы видите снаружи, а стоимость сидит внутри: за гладкой анимацией конкурента могут быть три месяца работы, за живым каталогом — интеграция со складом, за «просто красивыми фотографиями» — студийная съёмка, которой у вас нет.

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

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

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

Что ещё стоит зафиксировать

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

Технические ограничения, SEO и работа с админкой

Раздел, который заказчики пропускают со словами «вам виднее». Студии действительно виднее насчёт решений, но исходные ограничения знаете только вы.

Технические ограничения

• Хостинг и домен. Где живёт сейчас, у кого доступы, есть ли требования к размещению данных.
• Существующая система. Если сайт уже есть — что переносим, что выбрасываем, что остаётся параллельно.
• Внутренние правила. Служба безопасности, требования к паролям, ограничения на внешние сервисы.
• Права на код и персональные данные. Кому принадлежит результат, что собираете и как удаляете по запросу.

SEO

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

• Управляемые title, description и заголовки на каждом типе страниц — из админки, без программиста.
• Человекочитаемые адреса и понятная схема URL, настройка редиректов при переезде.
• Разметка данных, карта сайта, канонические адреса, а при нескольких языках — языковые атрибуты.
• Требования к скорости: не «быстро», а конкретные метрики и на каком устройстве меряем.

Админка и редактирование

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

Критерии приёмки, сроки и бюджетная рамка

Эти три вещи заканчивают ТЗ и превращают его из описания мечты в рабочий документ.

Критерии приёмки

Критерий приёмки — это проверяемое утверждение. Не «сайт работает корректно», а список того, что будет проверено:

• Все страницы из списка открываются, ссылки не ведут в ошибку.
• Форма заявки отправляется, письмо приходит на адрес, заявка появляется в CRM.
• Сайт корректно отображается в актуальных браузерах и на телефоне.
• Метрики скорости на главной и на карточке товара укладываются в согласованный порог.
• Оплата тестовой картой проходит, заказ создаётся, письмо клиенту уходит.

Такой список защищает обе стороны: заказчик знает, что смотреть, а студия знает, где финиш, и не оказывается в приёмке, которая длится вечно, потому что заказчику «что-то не то».

Сроки

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

Бюджетная рамка

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

Что не надо писать в ТЗ

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

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

Готовые технические решения, если вы не технический специалист. Строчка «сделать на такой-то технологии» без объяснения почему связывает руки и удорожает проект. Правильнее описать ограничение: «наш админ обслуживает только такой стек» или «должно жить на нашем сервере». Причину студия учтёт, а способ подберёт сама.

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

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

И то, чего почти всегда не хватает

Обратная сторона: есть вещи, которые пропускают в девяти ТЗ из десяти и которые не выглядят важными, пока не выстрелят.

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

Как ТЗ превращается в смету и что делать с правками

Смета — это не число из опыта, а арифметика по документу.

Механика оценки

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

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

Правки после подписания

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

1. Изменение формулируется письменно — в виде пункта, а не голосом на созвоне.
2. Студия оценивает: сколько часов, что сдвинется по срокам, что зацепит.
3. Заказчик решает: делаем сейчас, вторым этапом или отказываемся, и решение фиксируется приложением к ТЗ.

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

Чек-лист: ТЗ готово, если в нём есть

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

1. Бизнес-цель в терминах бизнеса, а не сайта.
2. Аудитория через поведение: кто решает, откуда приходит, что проверяет, с какого устройства.
3. Конкуренты: 3–5 ссылок с комментарием, что взять и чего избегать.
4. Список страниц с разделением на уникальные и типовые шаблоны.
5. Структура каждой уникальной страницы: блоки сверху вниз и назначение каждого.
6. Функции сценариями: кто, что делает, что получает. Плюс краевые случаи и ошибки.
7. Приоритеты: обязательно к запуску / желательно / второй этап.
8. Контент: кто пишет тексты, кто даёт фото, к какому сроку, что при задержке.
9. Интеграции поимённо: что, куда, когда, что при ошибке, у кого доступы.
10. Языки: сколько на запуск, кто переводит, что при отсутствии перевода.
11. Дизайн: референсы с комментариями, брендбук, кто утверждает, сколько итераций.
12. Технические ограничения: хостинг, доступы, права на код, персональные данные.
13. SEO: управляемые метатеги, схема адресов, редиректы при переезде, порог по скорости.
14. Админка: что меняете сами и как часто, роли, черновики, откат, обучение.
15. Критерии приёмки: проверяемый список, а не «работает корректно».
16. Сроки этапами с зависимостями и бюджетная рамка диапазоном.
17. После запуска: поддержка, бэкапы, передача доступов, граница гарантии.

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

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

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