Если гуглите «тз на разработку сайта пример», значит уже наступили на грабли: либо новый разработчик просит документ, которого нет, либо предыдущий проект встал, потому что «в переписке же всё обсуждали». За практику веб-разработки я видел десятки сайтов, где техническое задание умещалось в пять сообщений в мессенджере, а потом стороны две недели спорили, входит ли личный кабинет в согласованную стоимость. Ниже - рабочая структура ТЗ, которую использую сам при оценке проектов на WordPress, Tilda и в кастомной разработке, с разделами, которые обязательны, и теми, без которых документ проще, но риски выше.
Зачем нужно техническое задание перед разработкой сайта
ТЗ - это не бюрократия для галочки, а инструмент, который переводит ожидания заказчика в конкретные пункты, проверяемые после сдачи. Без него оценка стоимости условна: назвать точную цифру за «сайт как у конкурента» невозможно, потому что неизвестно, нужен ли каталог на 500 товаров или на 20, будет ли личный кабинет с историей заказов или обычная форма обратной связи.
На практике самые дорогие правки случаются не на этапе дизайна, а после вёрстки и интеграций. Если в ТЗ не было сказано про фильтры в каталоге, а заказчик вспомнил о них после того, как вёрстка карточки товара уже готова, доработка обходится дороже, чем если бы фильтры заложили в структуру сразу - меняется не один блок, а логика нескольких страниц. ТЗ не гарантирует, что правок не будет вообще, но фиксирует, что входит в согласованную стоимость, а что - отдельная задача со своей оценкой.
Ещё один момент, который часто упускают: ТЗ защищает не только заказчика от размытых обещаний, но и разработчика от бесконечных «а давайте ещё вот так». Когда пункт не прописан, следующая правка воспринимается как часть исходной договорённости, хотя по факту это новая задача.
Из каких разделов состоит ТЗ на разработку сайта: пример структуры
Рабочий пример структуры из 8 разделов, который я использую при подготовке коммерческого предложения:
- Цели проекта и целевая аудитория - зачем сайт нужен бизнесу и кто на него придёт.
- Карта сайта - список страниц и разделов с иерархией.
- Функциональные требования - что сайт должен уметь: форма заявки, каталог, личный кабинет, поиск.
- Технические требования - платформа (Tilda, WordPress, кастомная разработка), требования к хостингу, скорость загрузки.
- Дизайн и контент - есть ли готовый макет, кто пишет тексты и готовит фото.
- Интеграции - CRM, платёжные системы, службы доставки, мессенджеры.
- Сроки и этапы - что сдаётся на каждом этапе и когда.
- Критерии приёмки и бюджет - как проверяется, что задача выполнена, и что входит в стоимость.
Для лендинга или сайта-визитки часть пунктов можно объединить в один абзац. Для интернет-магазина или сервиса с личным кабинетом каждый раздел стоит расписывать отдельно - там больше сценариев, которые нужно свести в одном документе, а не держать в переписке.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Функциональные требования и пользовательские сценарии в ТЗ
Самая частая ошибка в этом разделе - формулировки вида «сделать удобный каталог». Разработчику нужны сценарии: что видит пользователь на каждом шаге и что происходит при ошибке. Например: «пользователь добавляет товар в корзину, вводит промокод, система проверяет лимит использований и применяет скидку» - такая формулировка сразу задаёт логику для программиста и не оставляет пространства для трактовок. То же касается форм: если в ТЗ не указано, что происходит при отправке пустого обязательного поля, разработчик реализует поведение по умолчанию, а заказчик потом удивляется, почему форма ведёт себя не так, как он представлял.
Отдельно стоит прописывать интеграции, потому что именно они чаще всего выпадают из ТЗ, а потом всплывают уже на этапе разработки:
- приём оплаты - через Т‑Банк или WooCommerce, в зависимости от платформы и модели оплаты (разовая или подписка);
- расчёт доставки - через СДЭК или другую службу, с учётом зон и тарифов;
- уведомления - в Telegram через бота на aiogram, если нужна кастомная логика обработки сообщений, или через штатные вебхуки платформы, если хватает простого оповещения;
- передача заявок в CRM - напрямую по API или через сценарий в n8n, если данные нужно предварительно обработать или отправить сразу в несколько систем.
Если в проекте заложен полноценный интернет-магазин под ключ, на этапе ТЗ обычно прошу заказчика сразу определиться со способом оплаты и логикой доставки - от этого зависит, сколько времени займёт интеграция и не понадобится ли дополнительный виджет в карточке товара.
Технические требования, дизайн и контент в ТЗ
Технические требования - это не только «сайт должен быстро грузиться», а конкретные условия работы. Для сайта на Tilda или WordPress обычный обработчик формы, вебхука или расчёта в календаре бронирования спокойно работает на PHP и MySQL - это тот же хостинг, который заказчик уже оплатил вместе с сайтом, отдельный сервер под такую задачу не нужен. Если в проекте есть парсинг данных, бот с фоновой логикой на aiogram или сценарии в n8n, тогда действительно нужен отдельный сервер, который придётся обслуживать и оплачивать отдельно от хостинга сайта - это стоит сразу закладывать в ТЗ отдельным пунктом, чтобы бюджет не оказался сюрпризом на середине проекта.
В разделе дизайна фиксирую: есть ли готовый макет (в Figma или в виде референсов), кто утверждает вёрстку и сколько итераций правок входит в согласованную стоимость. В разделе контента - кто пишет тексты, кто готовит фотографии товаров и в каком формате материалы передаются верстальщику. Часть проектов замирает именно на этом шаге: дизайн готов, разработка ждёт, а тексты для карточек товаров так и не пришли.
Чем отличается ТЗ для лендинга, магазина и корпоративного сайта
Основные разделы структуры одинаковые, но глубина проработки функциональных требований разная:
| Раздел ТЗ | Лендинг | Интернет-магазин | Корпоративный сайт |
|---|---|---|---|
| Функциональные требования | форма заявки, часто одна страница | каталог, корзина, оплата, личный кабинет | новости, каталог услуг, формы для разных отделов |
| Интеграции | CRM или уведомление в Telegram | эквайринг, служба доставки, CRM, склад | CRM, иногда форма для вакансий и HR-отдела |
| Объём контента | 1-2 экрана текста, минимум фото | карточки на каждый товар, фото и описания | десятки страниц, регулярные новости |
Сроки, бюджет и критерии приёмки в ТЗ на сайт
Сроки в ТЗ должны быть привязаны к этапам, а не только к финальной дате. Обычно фиксирую: дедлайн на утверждение дизайна, дедлайн на передачу контента от заказчика, дедлайн на тестирование перед запуском. Если заказчик срывает срок передачи текстов, это сдвигает финальную дату, и в ТЗ стоит сразу прописать, что перенос входного материала переносит и запуск - иначе разработчик остаётся крайним за чужую задержку.
Бюджет фиксируется под конкретный набор функций из раздела функциональных требований, а не под общее «сделать сайт». По моим текущим расценкам ориентир такой: лендинг на Next.js - от 80 000 ₽, сайт на Tilda - от 30 000 ₽, сайт на WordPress - от 60 000 ₽, интернет-магазин под ключ - от 80 000 ₽. Если в процессе разработки в ТЗ добавляется пункт, которого не было в согласованной версии, это отдельная смета, а не бесплатное дополнение к текущей.
Критерии приёмки - последний и часто пропускаемый раздел. Формулировка вида «сайт работает корректно» ничего не проверяет: неясно, кто и как это проверяет. Рабочий вариант звучит иначе: «форма отправляет заявку на указанный email и в CRM, письмо приходит в течение минуты, обязательные поля не дают отправить пустую форму». По такому пункту заказчик и разработчик проверяют одно и то же, а не спорят на словах после сдачи.
Частые ошибки при составлении ТЗ на сайт
За годы работы с чужими ТЗ вижу одни и те же проблемы:
- нет целевой аудитории и целей - структуру сайта тогда собирают вслепую, ориентируясь на вкус, а не на сценарии посетителей;
- функции описаны через референсы без деталей - «сделать как у Х» не объясняет, какая логика нужна за конкретной кнопкой;
- интеграции не упомянуты вообще - оплата, доставка и CRM всплывают уже в процессе разработки и требуют пересчёта сроков;
- нет критериев приёмки - без них любой спорный момент решается на словах, а не по документу;
- ТЗ пишется один раз и не обновляется - если требования поменялись, а документ остался старым, разработчик и заказчик в какой-то момент начинают говорить о разных версиях сайта.
Если формулировать ТЗ самостоятельно сложно, часть этой работы можно передать на этапе обсуждения проекта - структурировать требования удобнее уже на консультации, до того как считать смету.
Частые вопросы
Сколько страниц должно быть в ТЗ на разработку сайта?
Зависит от проекта. Для лендинга структура ТЗ обычно укладывается в одну-две страницы текста: цели, карта сайта, форма заявки, дизайн и сроки. Для интернет-магазина или сервиса с личным кабинетом документ разрастается до 8-15 страниц, потому что там больше сценариев и интеграций, которые нужно описать отдельно, а не свести в один общий пункт.
Кто должен писать ТЗ - заказчик или разработчик?
На практике документ получается точнее, когда его собирают вместе: заказчик формулирует цели и бизнес-логику, разработчик переводит их в технические формулировки и указывает на нестыковки. Если заказчик приносит готовое ТЗ, я всё равно прохожу по нему на этапе консультации и уточняю функциональные требования там, где формулировки допускают разное толкование.
Нужно ли ТЗ, если сайт делают на Tilda?
Нужно, хотя часть штатных возможностей платформы снимает часть вопросов из документа. У Tilda есть встроенный обмен с 1С через CommerceML, переключатель языков в блоках меню, интеграция с Робокассой в настройках платёжных систем и расчёт доставки по зонам через калькулятор СДЭК - это не нужно описывать как отдельную разработку. Но в ТЗ всё равно стоит зафиксировать, какие блоки используются, какие кастомные доработки нужны сверх штатного функционала и кто готовит контент для страниц.
Что делать, если требования изменились в процессе разработки?
Изменение фиксируется как дополнение к текущему ТЗ, а не устно в переписке. Новый пункт оценивается отдельно, с показом, как он сдвигает сроки - если правка меняет структуру каталога или логику оплаты, это может затронуть уже сделанную работу. Так заказчик видит стоимость изменения до того, как оно внесено, а не после сдачи проекта.