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

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

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

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

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

Многие думают, что ТЗ - формальность для разработчика. На самом деле наоборот. Подрядчик и без подробного документа что-нибудь соберёт. Вопрос в том, совпадёт ли это «что-нибудь» с тем, что было у вас в голове. ТЗ нужно прежде всего тому, кто платит: оно фиксирует обещание. Когда на сдаче вы говорите «а где раздел с отзывами», ответ ищется не в споре, а в подписанном файле.

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

Что происходит, когда сайт делают без ТЗ#

Чтобы не быть голословным, три сценария, которые мы видим регулярно, когда проект стартовал на словах.

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

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

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

Во всех трёх случаях проблема не в людях, а в отсутствии общего документа. Час на составление ТЗ экономит недели на правках и нервов на конфликте.

Из чего состоит рабочее техническое задание#

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

Контекст: кто вы и какую задачу решаете#

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

Цель сайта и как поймём, что сработало#

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

Структура: страницы и что на каждой#

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

Функции: что сайт должен уметь#

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

Дизайн: референсы, а не «сделайте красиво»#

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

Контент: кто готовит тексты и фото#

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

Технические требования и интеграции#

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

Что НЕ входит в проект#

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

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

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

Мини-образец: плохой пункт против хорошего#

Разница между бесполезным и рабочим ТЗ - в конкретности. Один и тот же пункт можно написать так, что он ничего не гарантирует, или так, что по нему можно принять работу.

Правый столбец длиннее, и это нормально. Каждый такой пункт - то, что на сдаче можно открыть и сверить: сделано или нет. Левый столбец на сдаче превращается в «по-моему, недостаточно удобно» против «по-моему, достаточно», и спор уходит в характер, а не в факты.

Сколько детализировать: ТЗ - не роман на восемьдесят страниц#

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

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

ТЗ под разные типы сайтов#

Каркас один, но акценты смещаются в зависимости от того, что вы делаете. Где-то главный риск - дизайн, где-то - интеграции, где-то - контент.

Если пока не определились с типом - это нормально, и разговор о ТЗ как раз помогает определиться. Какой сайт вам подходит под задачу и сколько он стоит, мы разбирали в отдельной статье сколько стоит сайт в 2026. А что вообще происходит после того, как ТЗ подписано, - в материале про этапы разработки сайта.

Кто пишет ТЗ на практике#

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

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

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

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

Поможем собрать ТЗ под вашу задачу#

Если нужен сайт, но непонятно, с чего начать описывать задачу, - это и есть работа брифа. Напишите нам, задаём правильные вопросы и собираем из ваших ответов нормальное ТЗ, по которому потом считаем фикс-цену и фикс-срок. Бесплатно, без обязательств. Хотите быстрый старт - посмотрите экспресс-сайт за 3 дня или полноценную разработку сайтов под ключ, а прикинуть бюджет можно в калькуляторе на странице цен. Готовые проекты - в разделе «Работы».