Как составить техническое задание на сайт, если вы не технарь

Цена и выбор подрядчика 18 сентября 2026 8 мин чтения Студия Своя орбита

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

Коротко

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

Зачем ТЗ нужно вам, а не только подрядчику

Принято считать, что техническое задание — бюрократия, которую требует исполнитель, чтобы прикрыться. На практике документ защищает обе стороны, но заказчика сильнее.

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

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

И третье: документ переживает людей. Менеджер у подрядчика меняется, ваш маркетолог увольняется, а ТЗ остаётся и продолжает работать.

Чем бриф отличается от технического задания

Их путают, хотя они отвечают на разные вопросы и появляются в разное время.

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

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

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

Блок 1: бизнес-задача и целевое действие

Начинается ТЗ не со страниц, а с одного абзаца: зачем этот сайт компании.

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

Дальше — целевое действие. Что человек должен сделать на сайте: позвонить, оставить заявку, скачать прайс, рассчитать стоимость, написать в мессенджер. Одно основное и одно запасное, не пять.

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

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

Блок 2: кто клиент и какие у него возражения

Второй блок — та самая фактура, которую невозможно придумать за вас.

Опишите два-три типа клиентов человеческим языком: кто принимает решение, как он ищет подрядчика, что спрашивает по телефону первым делом, чего боится. Не «мужчины и женщины 25–55 лет» — это не описание, а статистика.

Самое ценное здесь — возражения. Их не нужно выдумывать: они звучат у ваших менеджеров каждый день. Дорого. Долго. А вдруг бросите на середине. А почему предоплата. А работаете ли вы с нашим регионом. Выпишите десять реальных фраз клиентов и передайте подрядчику дословно.

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

Заодно назовите двух-трёх конкурентов, с которыми вас сравнивают, и скажите, чем вы от них отличаетесь на самом деле.

Блок 3: структура страниц и что на каждой

Здесь ТЗ превращается из рассказа в перечень. Нужен список страниц и краткое описание содержания каждой.

Минимальный формат строки: адрес и название страницы, её задача, обязательные блоки, что на ней должен сделать человек. Например: «Страница услуги — объяснить состав работ и цену, обязательно таблица цен, сроки, фотографии объектов, форма расчёта; действие — заявка на замер».

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

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

Блок 4: функции — формы, калькуляторы, интеграции, CRM

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

Стандартный набор, который стоит проговорить:

формы: какие поля, куда приходит заявка, приходит ли дубль на почту, что видит человек после отправки;
калькулятор: по какой формуле считает, кто её даёт, что происходит с результатом;
каталог: сколько позиций, какие фильтры, откуда берутся цены и остатки;
интеграции: CRM, 1С, телефония, мессенджеры, оплата, службы доставки;
личный кабинет, если он нужен, — и честный ответ на вопрос, точно ли нужен.

Для интеграций укажите, у кого доступы и кто отвечает за сторону сервиса. Половина задержек на этом этапе выглядит как «ждём, когда нам дадут доступ к 1С».

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

Блок 5: требования к контенту и кто его готовит

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

Что перечислить:

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

Отдельно оговорите объёмы. Макет, нарисованный под заголовок в шесть слов, ломается от заголовка в двадцать, и переделывать его будут за ваш счёт или за ваше время.

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

Блок 6: приёмка — как понять, что работа сделана

Главный блок документа и самый короткий. Без него всё предыдущее не работает.

Приёмка — это список признаков, по которым этап считается принятым. Не «дизайн нравится», а проверяемые пункты:

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

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

По каким этапам удобно расставлять точки приёмки, видно на странице процесса разработки.

Формулировки, из-за которых начинаются споры

Четыре фразы, которые выглядят безобидно и стоят дороже всех остальных.

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

Проверка документа перед подписанием простая: пройдите по каждому пункту и спросите себя, можно ли по нему однозначно сказать «сделано» или «не сделано». Если ответ зависит от настроения — пункт нужно переписать.

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

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

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

Можно ли обойтись без ТЗ?

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

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

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

Насколько подробно описывать дизайн?

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

Что делать, если в процессе задача изменилась?

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

Читайте дальше

Структура, дизайн и конверсия