Техническое задание на разработку сайта - это документ, который убирает главную причину конфликтов между заказчиком и исполнителем: разработчик делает не то, что вы себе представляли, потому что бриф на словах каждый достраивает в голове по-своему. В проектах на Tilda, WordPress и Next.js, которые я веду, разница между чётким ТЗ и его отсутствием заметна сразу: там, где документ составлен по разделам до старта работ, проект укладывается в согласованный срок, а там, где его нет, правки и созвоны растягиваются на месяцы. Ниже структура, по которой я прошу клиентов присылать требования, и как собрать такой документ самостоятельно, без агентства и брифов на пятьдесят страниц.
Зачем самому писать техническое задание на разработку сайта
Если сайт делает агентство или фрилансер, ТЗ обычно составляет исполнитель по итогам созвона. Проблема в том, что документ отражает его понимание задачи, а не ваше: то, что для вас «форма обратной связи с проверкой телефона», для разработчика может значить просто текстовое поле без валидации. Когда требования сначала фиксирует сам заказчик, а исполнитель их дополняет техническими деталями, спорных мест становится меньше.
Второй повод - сравнение предложений. Если разослать одно и то же ТЗ трём подрядчикам, сметы получаются сопоставимыми: все считают один и тот же объём работ. Без документа один посчитает лендинг из пяти блоков, другой - из пятнадцати, и цифры в коммерческих предложениях будут отличаться в разы без всякой связи с качеством работы.
Третий повод практический: ТЗ становится приложением к договору. Если через месяц после сдачи проекта всплывает «а я думал, здесь будет калькулятор доставки», при наличии документа с зафиксированными разделами это дополнительная работа, а не недоделка по вине разработчика.
Структура ТЗ: какие 8 разделов должны быть в документе
Формат не важен, Google Docs, Notion или обычный Word подойдут одинаково. Важна структура. Вот 8 обязательных разделов, которые входят в документ:
- Цель сайта и аудитория - зачем бизнесу вообще нужен сайт и кто на него придёт: холодный трафик из рекламы, постоянные клиенты, B2B-закупщики
- Карта сайта - список страниц и то, как они связаны между собой
- Функциональные требования - что должно происходить на каждой странице: какие формы, кнопки, фильтры, личный кабинет
- Интеграции - с какими сервисами сайт обменивается данными: CRM, эквайринг, служба доставки, мессенджеры
- Дизайн и контент - кто готовит макеты, тексты, фотографии и в каком виде их передавать разработчику
- Технические требования - платформа или CMS, хостинг, домен, требования к скорости и адаптивности
- Бюджет и сроки - разбивка по этапам с датами сдачи каждого
- Критерии приёмки - как обе стороны поймут, что работа сделана и соответствует ТЗ
Каждый раздел не обязан быть длинным. Для лендинга разделы 1-8 умещаются на двух-трёх страницах текста, для интернет-магазина с каталогом и доставкой документ разрастается до 10-15 страниц просто потому, что у каждого раздела каталога и у каждого способа доставки свои условия.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Функциональные требования и пользовательские сценарии в техзадании
Самая частая ошибка в этом разделе - описывать страницы, а не сценарии. «Страница услуги с формой заявки» ничего не говорит разработчику о логике. Лучше расписывать сценарий целиком: пользователь заходит на страницу услуги, нажимает «Оставить заявку», заполняет имя и телефон, форма проверяет телефон на формат, после отправки данные уходят на почту менеджера и в Telegram, а пользователь видит сообщение об успехе вместо перезагрузки страницы.
Такой сценарий на обычном хостинге сайта закрывается PHP-обработчиком и записью в MySQL, отдельный сервер здесь не нужен, хостинг под сайт уже оплачен вместе с доменом. То же самое с личным кабинетом, промокодами, бронированием слота на консультацию: блокировка слота на время оплаты решается транзакцией и уникальным индексом в той же базе, Postgres или отдельный сервер для этого избыточны.
Другое дело, если в сценарии появляется бот в Telegram с собственной логикой, например клиент выбирает услугу кнопками, а не через сайт, или регулярная фоновая задача вроде выгрузки заказов раз в час. Такие вещи пишут на aiogram, потому что боту нужен постоянный процесс, который слушает сообщения, а не просто отвечает на HTTP-запрос. Для связки «новая заявка на сайте - уведомление в CRM и в Telegram» часто хватает n8n: сценарий собирается из готовых блоков без написания кода, но сам n8n тоже нужно где-то развернуть или оплачивать облачный тариф. В ТЗ это стоит сразу отметить отдельным пунктом, чтобы бюджет не наступил на грабли «а кто это будет поддерживать».
Интеграции, дизайн и техническая часть сайта: что фиксировать отдельно
Раздел с интеграциями - тот, где чаще всего теряют деньги и время, потому что «интеграция с CRM» звучит как одна строчка, а по факту это отдельный кусок работы. В ТЗ стоит указывать не просто название сервиса, а что именно передаётся, в какую сторону и по какому триггеру.
Для Tilda многое закрывается штатными настройками платформы, и это стоит проверить до найма разработчика: обмен товарами, ценами и остатками с 1С через CommerceML настраивается прямо в панели сайта, приём оплаты через Робокассу подключается в разделе платёжных систем, а расчёт доставки по зонам считает встроенный калькулятор СДЭК. Если бизнес использует Яндекс Доставку, токен для неё тоже вставляется в настройки без правки кода. В ТЗ по такому сайту важно прописать не «нужна доставка», а через какую именно службу и по каким зонам считается стоимость. Если же нужна нестандартная логика вроде ограничения количества использований промокода или конвертера валют в каталоге, это отдельный пункт ТЗ с описанием самой логики, а не просто название функции.
Для сайта на WordPress с магазином на WooCommerce типовая связка - эквайринг Т‑Банка через официальный плагин: здесь в ТЗ важно указать, чьи будут тестовые и боевые ключи, куда ведёт вебхук об изменении статуса заказа и что происходит с заказом при неуспешной оплате. Если интеграций набирается много: каталог, оплата, доставка, синхронизация с учётной системой, разумнее сразу закладывать в ТЗ полноценную разработку интернет-магазина под ключ, а не собирать магазин из точечных доработок поверх лендинга.
Дизайн и контент тоже стоит развести по ответственности прямо в документе: кто готовит макеты (дизайнер, конструктор с готовыми блоками, референсы сайтов конкурентов), кто пишет тексты и кто отвечает за фотографии товаров. Без этого разработчик получает пустые страницы и ждёт контент, а заказчик ждёт готовый сайт - оба правы, но проект стоит на месте.
Бюджет и сроки в техническом задании на сайт
Объём раздела с функциональными требованиями и срок на подготовку самого ТЗ сильно зависят от типа сайта:
| Тип сайта | Что обязательно детализировать в разделе «Функциональные требования» | Обычный срок на подготовку ТЗ |
|---|---|---|
| Лендинг (одна страница) | Порядок блоков, форма заявки, счётчики и виджеты аналитики | 1-2 дня |
| Корпоративный сайт (5-15 страниц) | Карта разделов, каталог услуг, интеграция с CRM, форма обратной связи | 3-5 дней |
| Интернет-магазин | Каталог с фильтрами, корзина, оплата, зоны доставки, синхронизация с учётной системой | 7-10 дней |
Сроки в таблице - это время на сбор и согласование самого документа, а не на разработку сайта. Дальше уже разработчик или агентство считает бюджет от готового ТЗ, и здесь стоит ориентироваться на реальные ценники, а не на «сайт от 10 000 ₽» из объявлений. У меня, например, сайт на Tilda начинается от 30 000 ₽, сайт на WordPress - от 60 000 ₽, лендинг на Next.js - от 80 000 ₽, а интернет-магазин под ключ - от 80 000 ₽. Чем подробнее ТЗ, тем точнее эти цифры превращаются в фиксированную смету, а не в «оценим по ходу дела».
Частые ошибки при составлении ТЗ на разработку сайта
Даже с хорошими намерениями в ТЗ закрадываются одни и те же ошибки:
- Формулировки вроде «современный дизайн» или «удобный интерфейс» без референсов - у каждого человека своё «удобно»
- Отсутствие критериев приёмки: непонятно, по какому чек-листу принимать готовый сайт
- Интеграции описаны названием сервиса без деталей: «нужна CRM» вместо конкретного триггера и набора полей
- Документ не обновляется по ходу проекта - новые договорённости живут только в переписке и забываются
- Не указано, кто и в какие сроки предоставляет тексты и фото - это тормозит проект чаще, чем сама разработка
- Мобильная версия не выделена отдельным пунктом, хотя на телефонах сайт открывают чаще, чем с компьютера
Если что-то из этого списка уже случилось на текущем проекте, проще один раз обсудить документ с разработчиком, чем переписывать договорённости в мессенджере на ходу.
Частые вопросы
Сколько страниц должно быть в техническом задании на сайт?
Дело не в количестве страниц, а в том, закрыты ли все 8 разделов. Для лендинга обычно хватает двух-трёх страниц текста, для интернет-магазина с каталогом и доставкой документ вырастает до 10-15 страниц, потому что у каждого раздела каталога и способа доставки свои условия.
Нужно ли писать ТЗ, если сайт делаю на Тильде?
Да. На конструкторе не нужно описывать код, но структуру страниц, набор блоков, тексты и интеграции вроде СДЭК, Робокассы или обмена с 1С всё равно стоит зафиксировать заранее, иначе разработчик настраивает то, что кажется логичным ему, а не то, что нужно бизнесу.
Кто должен писать техническое задание, заказчик или разработчик?
Черновик пишет заказчик - только он знает цели бизнеса и специфику аудитории. Разработчик дальше дополняет документ технической частью: как именно реализовать сценарии, какие поля нужны в базе, какие ограничения есть у выбранной платформы.
Что делать, если после согласования ТЗ появились новые требования?
Не переписывать исходный документ задним числом, а оформлять новые пункты отдельным списком с датой и статусом «дополнительная работа». Так видно, что было в изначальной смете, а что добавилось по ходу проекта и должно оплачиваться отдельно.