ТЗ на сайт: 10 разделов из ГОСТа и что из них нужно вам

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

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

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

01Что показал разбор восьми статей из топа

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

Объём: медиана около 15–16 тысяч знаков, средняя примерно на тысячу больше. Считал только текст статьи, без меню, комментариев и блоков «читайте также»; при таком счёте расхождение в пару тысяч знаков неизбежно, поэтому и округляю. Разброс при этом большой: самая длинная статья в несколько раз длиннее самой короткой, а средняя и медиана почти совпали, потому что длинные уравновешены короткими.

Картина в сумме такая. Шаблоны есть, объяснений, зачем в них каждый пункт, почти нет. А самого дорогого для того, кто платит, — как пользоваться этим документом в день сдачи — нет вообще.

02Откуда взять перечень разделов, если не из чужой статьи

Такой перечень существует и лежит открыто: ГОСТ 34.602-2020 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы», введён в действие 1 января 2022 года.

Две честные оговорки, без которых ссылаться на него нечестно.

Стандарт написан не про сайты. Он «распространяется на автоматизированные системы (АС), предназначенные для автоматизации различных видов деятельности (управление, проектирование, исследования и т. п.)». Сайт с личным кабинетом, оплатой и заявками подходит под это описание ближе, чем визитка на пять экранов.

Сам по себе он вас ни к чему не обязывает. ГОСТ 34.602-2020 — межгосударственный стандарт, введённый в действие в России, а стандарты по общему правилу применяются добровольно: документы национальной системы стандартизации «применяются на добровольной основе» (162-ФЗ «О стандартизации в Российской Федерации», ст. 26, п. 1), и для межгосударственных обязательность тоже не возникает сама собой. Обязывает не ГОСТ, а ссылка на него в вашем договоре: после неё требования стандарта становятся условиями договора, а качество работы, по ст. 721 ГК, должно соответствовать именно условиям договора.

Ценность стандарта в другом: это готовый перечень разделов, написанный не веб-студией и ничего вам не продающий. Похожие перечни есть и в других стандартах на разработку, но этот ближе всего к сайту как к системе с ролями, интеграциями и приёмкой. Пункт 4.1 называет десять обязательных разделов: общие сведения; цели и назначение создания системы; характеристика объектов автоматизации; требования к системе; состав и содержание работ по созданию; порядок разработки; порядок контроля и приёмки; требования к работам по подготовке объекта к вводу в действие; требования к документированию; источники разработки.

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

03Десять разделов на языке сайта

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

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

04Раздел, которого нет ни у кого: порядок контроля и приёмки

Стандарт выносит приёмку в отдельный обязательный раздел. Из 8 статей топа его не даёт ни одна. Между тем именно этот раздел превращает ТЗ из описания намерений в инструмент.

Кодекс на стороне того, кто проверяет заранее. «Заказчик обязан в сроки и в порядке, которые предусмотрены договором подряда, с участием подрядчика осмотреть и принять выполненную работу (ее результат), а при обнаружении отступлений от договора, ухудшающих результат работы, или иных недостатков в работе немедленно заявить об этом подрядчику» (ст. 720, п. 1). Дальше жёстче: «Заказчик, обнаруживший недостатки в работе при ее приемке, вправе ссылаться на них в случаях, если в акте либо в ином документе, удостоверяющем приемку, были оговорены эти недостатки либо возможность последующего предъявления требования об их устранении» (п. 2). И совсем прямо: «Если иное не предусмотрено договором подряда, заказчик, принявший работу без проверки, лишается права ссылаться на недостатки работы, которые могли быть установлены при обычном способе ее приемки (явные недостатки)» (п. 3).

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

Второе следствие: недостатки фиксируются в акте, а не в переписке. Практическая часть — какие пункты проверяют в готовом сайте за час до подписания акта — вынесена в отдельный чек-лист, потому что список получается длинный.

05Кто пишет задание и почему проверять его всё равно вам

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

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

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

«Сайт адаптивен» → «страницы открываются без горизонтальной прокрутки на экране шириной 360 точек; формы отправляются с мобильного». Здесь появился способ проверки и число.

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

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

06Что не записано в задании, будет стоить отдельно

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

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

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

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

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

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

Разберём именно
ваш сайт бесплатно

Посмотрю страницу и рекламу, найду,
где теряются заявки, и пришлю план,
что поменять.

Что входит в разбор

• 1
  Где теряются заявкипуть от объявления до формы
• 2
  Что поправить на сайтепервый экран, оффер, формы
• 3
  Что поменять в рекламезапросы, объявления, бюджет

Михаил Лапошинразберу ваш проект лично

Ваше имяТелефонСайт

TelegramWhatsAppЗвонок

Согласен на обработку данных и политику конфиденциальностиПолучить бесплатный разбор

✓ Заявка принята — отвечу в течение часа

07Домен, доступы и права на код — тоже пункт задания

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

Права на код закон по умолчанию отдаёт вам: «Исключительное право на программу для ЭВМ, базу данных или иное произведение, созданные по договору, предметом которого было создание такого произведения (по заказу), принадлежит заказчику, если договором между подрядчиком (исполнителем) и заказчиком не предусмотрено иное» (ст. 1296, п. 1). Смотреть надо на хвост этой фразы — не написано ли в договоре то самое «иное». Домен и рекламные аккаунты живут по своим правилам, и умолчаний в вашу пользу там нет: разбор того, как в договоре закрепить права на код, домен и аккаунты сайта, стоит прочитать до подписания.

08Почему скачанный образец не спасает

Файл-заготовку дают 4 статьи из 8. Как оглавление это полезно, как документ — нет, и причин две.

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

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

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

Объём документа зависит от проекта. На средний корпоративный сайт задание занимает 10–20 страниц, на лендинг — одну-две, и отказываться от него на одностраничнике не стоит: экранов мало, а вопросов «чей текст», «куда уходит заявка», «на кого домен» ровно столько же. Если задание пишется дольше, чем делается сам сайт, значит, оно избыточно: документ должен снимать риск, а не заменять работу.

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

Михаил ЛапошинМаркетолог, руководитель Laposhin Agency

«Делаем сайты и запускаем Яндекс Директ так, чтобы
сайт приносил заявки, а не просто был»

Есть вопрос по статье?Задать вопрос в Telegram