ТЗ на сайт — это не 40-страничный документ по ГОСТ, а 3–6 страниц, на которых зафиксированы договорённости: цели сайта и метрики успеха, структура, функции, интеграции, SEO-требования и критерии приёмки. Пишется оно сторонами вместе — подрядчик задаёт вопросы, заказчик отвечает про свой бизнес. По опыту наших 100+ проектов рабочее ТЗ экономит 20–30% бюджета: ровно столько съедают переделки по мотиву «я думал, это входит».
Что такое ТЗ на сайт
Техническое задание — документ, в котором записано, какой именно сайт делает подрядчик: из каких страниц он состоит, какие функции работают, по каким критериям результат считается готовым и что происходит при спорной ситуации. Это не описание технологий и не инструкция программисту — это фиксация границ проекта, за которые отвечает каждая сторона.
Мы прочитали сотни ТЗ: своих, чужих и написанных заказчиками самостоятельно. Видели документ на 60 страниц, собранный по образцам из интернета, — его не открывали ни разу после подписания, а спор по проекту всё равно случился, потому что в главе про «требования к эргономике» не было ни слова о том, кто пишет тексты. И видели одностраничный бриф, после которого лендинг для производителя вентиляции собрался с первого захода: там было главное — чего ждём, из чего состоит и по чему принимаем. Объём не спасает, спасает точность в спорных местах.
Рынок 2026 года диктует и третий вывод: сайт теперь почти никогда не делают «один раз и навсегда». Первая версия живёт 6–12 месяцев, собирает статистику, потом дорастает новыми разделами. Поэтому ТЗ фиксирует не идеальный сайт на пять лет вперёд, а первую работающую версию и правила её расширения. Такая рамка снимает главный страх заказчика — «а вдруг я забыл что-то важное и теперь навсегда так».
Зачем ТЗ заказчику, а не подрядчику
Существует миф, что ТЗ нужно студии — чтобы спрятаться за формулировками и брать деньги за каждое лишнее движение. В реальности всё наоборот: у подрядчика и так есть смета и договор, а вот у заказчика без ТЗ нет ничего, чем можно апеллировать.
Первая функция — фиксация цены и сроков. Смета без ТЗ похожа на счёт из ресторана без меню: «корпоративный сайт, 500 тысяч» — это 8 страниц или 30? Наполнение входит? А интеграция с CRM? В Москве корпоративный сайт в среднем сегменте стоит около 500 тысяч рублей, лендинг — около 250, магазин — от 800; в Липецке то же самое — примерно вдвое дешевле (мы разбирали цены разработки в Москве и стоимость сайтов в Липецке отдельно). Но вилка внутри одного сегмента — в два-три раза, и зависит она именно от состава работ. ТЗ превращает «сайт за 500 тысяч» в список из двадцати конкретных позиций.
Вторая функция — критерий приёмки. Самый частый спор на сдаче проектов звучит так: заказчик говорит «сайт сырой», подрядчик — «всё по смете». Без письменных критериев обе стороны правы по-своему. Классический случай из нашей практики: в задании значилось «раздел блог». Заказчик — производитель оборудования для пищевых производств — имел в виду редакцию с рубриками, редакторами и планом из 20 публикаций. Подрядчик сдал пустой модуль со статьями-заглушками. Обе стороны работали честно, но переделка стоила около 60 тысяч рублей и двух недель — и легла на заказчика, потому что в ТЗ было написано одно слово «блог».
Третья функция — защита от «а мы так не договаривались». Типовой пример: интеграция с 1С. Заказчик уверен, что «сайт с товарами» автоматически значит обмен остатками с учётной системой. Подрядчик точно так же уверен в обратном — в смете такой работы нет. Кто прав? Если в ТЗ есть строка «обмен с 1С: остатки и цены, один раз в час» — вопрос закрыт за минуту. Если нет — это переговоры, часы разработки по 2 500–4 000 рублей за штуку и минус неделя к сроку. Заметьте: почти все такие споры не про деньги, а про ожидания. ТЗ — единственное место, где ожидания фиксируются до того, как стали претензией.
Кто пишет ТЗ и что заказчик приносит с собой
Честный ответ: в восьми проектах из десяти ТЗ пишет подрядчик — но не сам по себе, а из ответов заказчика. Нормальный процесс выглядит как цепочка «бриф → разговор → ТЗ → согласование». Сначала анкета на 20–40 вопросов: чем продаёте, кому, за сколько, кто конкуренты, что делать сайту. Потом созвон на час-полтора, где вопросы уточняются. Потом документ, который заказчик правит и согласовывает. Если студия прислала «готовое ТЗ» без единого вопроса о вашем бизнесе — перед вами шаблон, и отличаться от других проектов будет только логотип на обложке.
Но есть вещи, которые подрядчик не знает и не узнает без вас. Заказчик приносит сам:
- Цели и цифры — сколько заявок или звонков ждёте, какой чек, какой срок окупаемости. Формулировка «хотим больше продаж» не работает, «30 заявок в месяц на монтаж в Москве и области» — работает.
- Примеры сайтов — 3–5 ссылок с пометками «нравится вот это» и «так не делайте». Не для копирования, а для калибровки вкуса.
- Контент — описания услуг, прайс, фото продукта и производства, сертификаты. Это самый частый пробел: все ждут, что «тексты напишут дизайнеры».
- Бренд-материалы — логотип, фирменные цвета и шрифты, брендбук, если он есть. Если его нет — так и скажите, свобода тоже позиция, но её надо зафиксировать.
- Доступы и реалии бизнеса — где домен, какая учётная система, какая CRM, кто будет отвечать на заявки. Скрытый доступ на этапе запуска — классическая причина сдвига сроков.
- Список возражений клиентов — то, что люди говорят на отказе: «дорого», «далеко», «нет сертификатов». Эти фразы потом становятся блоками на сайте.
На этом этапе заказчик экономит бюджет подрядчику — и свой. Чем полнее ответы, тем меньше часов уходит на «выяснение» в процессе. О том, как вообще выбрать команду, которая задаст правильные вопросы, у нас есть отдельный разбор — как выбрать веб-студию в Москве.
Шаблон ТЗ: 11 разделов с примерами строк
Ниже — рабочая структура, по которой мы собираем задания на сайты — от лендингов до магазинов. Можно взять её как каркас и заполнять по своим реалиям. На каждый раздел — что в нём писать и пример строки из настоящего ТЗ.
1. Цели и метрики сайта
Единственный раздел, который заказчик не может делегировать: что считаем успехом. Заявки, звонки, скачивания прайса, записи на замер — с числами и сроком. Метрика указывается та, которую можно увидеть своими глазами в аналитике, а не «повышение узнаваемости».
Пример: «Цель сайта — 30 заявок в месяц на монтаж вентиляции в Москве и области через 6 месяцев после запуска. Считаем по цели "Отправка формы" в Яндекс.Метрике, контроль — ежемесячно».
2. Аудитория и сценарии
Кто приходит на сайт и что должен сделать. Достаточно 2–4 сценариев с портретами: не «мужчины 25–55», а «снабженец, который ищет сертификат соответствия и прайс, зашёл с телефона из цеха». Сценарий сразу подсказывает структуру: если человеку нужен документ — ссылка на него не дальше второго клика с главной.
Пример: «Сценарий А: закупщик промышленного предприятия ищет сертификаты и условия поставки — раздел "Документы" доступен из главного меню, прайс скачивается без формы заявки. Сценарий Б: владелец кафе сравнивает поставщиков — главная показывает 3 кейса и калькулятор».
3. Тип сайта и структура
Тип — лендинг, корпоративный сайт, магазин — и карта страниц с приоритетами. Какой тип под какую задачу, мы разбирали в статье о типах сайтов; правила построения самой структуры — в материале о проектировании структуры сайта. В ТЗ карта выглядит таблицей:
| Страница | Приоритет | Зачем нужна |
|---|---|---|
| Главная | P0 | Оффер, распределение потока по услугам |
| Услуга «Монтаж вентиляции» | P0 | Денежная страница под рекламу |
| Кейсы | P1 | Доказательства для длинного цикла сделки |
| Контакты | P0 | Звонок и маршрут до офиса |
| Блог | P2 | SEO-хвосты, запуск второй очередью |
Приоритеты честно показывают, без чего сайт не запускать, а что можно доделать потом. Это и есть та самая «первая версия» — рамка, которая защищает бюджет от попытки сделать всё сразу.
4. Функциональные требования
Уровень «что должно работать», а не «как это реализовано». Технологии — забота подрядчика; заказчик описывает поведение. Удобный формат — тройка «функция / как работает / что не входит»:
| Функция | Как должно работать | Что НЕ входит |
|---|---|---|
| Форма заявки | Имя и телефон, маска +7, отправка в CRM и на почту, защита от спама | Квиз на 10 вопросов |
| Личный кабинет | Регистрация по e-mail, история заказов, повтор заказа в один клик | Мобильное приложение |
| Оплата | Платёжный шлюз, карты МИР и Visa, онлайн-чек по 54-ФЗ | Рассрочка и оплата частями |
| Фильтр каталога | По цене и 4 параметрам, работает вместе с поиском | Подбор по фото |
Колонка «что не входит» — не перестраховка, а миротворец: она заранее отсекает споры на сдаче. Отдельно перечислите требования к CMS — кто и какими правками будет пользоваться сайтом после запуска; как её выбрать, разбирали в статье о выборе CMS.
5. Интеграции
Какие системы соединяются с сайтом и зачем каждая нужна: CRM, 1С, аналитика, платёжные шлюзы, телефония. Формулировка «подключите CRM» — заготовка конфликта; у интеграций есть десятки настроек — что падает, кому, в каком поле. Подробно механику разбирали в статье об интеграции сайта с CRM и аналитикой.
Пример: «Заявки со всех форм создают сделку в amoCRM: контакт + сделка на этапе "Новое", ответственный — менеджер по входящим. Дубли отслеживаются по телефону».
6. Контент
Самый забываемый раздел — и главный тормоз запусков. Фиксируется построчно: кто пишет тексты каждого раздела, откуда фото, кто наполняет каталог, в каком формате и к какому сроку. Проект может быть свёрстан идеально и стоять месяц — потому что «тексты сейчас подготовим».
Пример: «Тексты 8 страниц услуг пишет подрядчик на основе брифа, согласование — 2 круга правок. Фото производства и сертификаты передаёт заказчик до 15 сентября. Карточки каталога (200 позиций) заказчик загружает сам в CSV по шаблону подрядчика».
7. SEO-требования
База, которая должна стоять с запуска, а не «потом оптимизируем»: HTTPS, ЧПУ-адреса, скорость загрузки, микроразметка, sitemap, настроенная Метрика с целями. Переписывать это после запуска дороже, чем заложить сразу, — а отдельные доработки вроде микроразметки и вовсе требуют доступа к шаблонам страниц.
Пример: «SSL-сертификат, адреса вида /uslugi/montazh-ventilyacii/, LCP до 2,5 с на мобильных, микроразметка Organization и BreadcrumbList, sitemap.xml и robots.txt, Яндекс.Метрика с целями на все формы — всё в составе запуска».
8. Дизайн-рамки
Либо есть брендбук — тогда указываются его границы, либо свободы больше — тогда прикладываются референсы с пометками. Минимальный набор: 3–5 сайтов «нравится», 2–3 «не нравится» и объяснение почему. Про то, когда брендбук стоит заказывать отдельно, писали в материале о разработке брендбука.
Пример: «Фирменные цвета и шрифт — из брендбука заказчика. По духу — референс N: воздух, крупные фотографии, минимум текста на первом экране. Главная = оффер, 3 кейса, форма заявки».
9. Адаптив и браузеры
Диапазон экранов и список браузеров, в которых сайт обязан работать корректно. Формулировка «адаптивный сайт» без цифр — источник истории «сайт адаптивный, но на iPhone SE поехал футер».
Пример: «Корректное отображение на 360–1920 px; проверка на iPhone SE, iPhone 15, среднем Android, iPad. Браузеры: Chrome, Safari, Firefox, Edge, Samsung Internet — последние две версии».
10. Критерии приёмки и гарантия
Что считается «сделано» и сколько времени подрядчик чинит баги бесплатно. Это раздел, к которому возвращаются в самый напряжённый день проекта — день приёмки, поэтому его пишут короткими проверяемыми фразами.
Пример: «Сайт считается принятым после прохождения чек-листа приёмки (приложение № 2) и передачи всех доступов. Гарантия на исправление ошибок — 60 календарных дней с даты подписания акта. Доработки вне ТЗ — по отдельной смете».
11. Права и передача
Исходники, доступы и домен оформляются на заказчика — это фиксируется письменно, до старта работ. Ситуация «сайт сделали, а он на аккаунте фрилансера» встречается до сих пор и решается мучительно. Подробно о том, что вы должны получить на выходе, мы рассказывали в материале о том, как сэкономить на разработке — там есть раздел про права.
Пример: «После оплаты передаются: доступы к домену, хостингу, CMS, Метрике и Вебмастеру — на учётные записи заказчика; исходный код и макеты — ссылкой на репозиторий и облако. Исключительные права на сайт переходят заказчику с момента полной оплаты».
Как согласовать ТЗ, чтобы оно не зависло
Написать ТЗ — половина дела; вторая половина — провести его через согласование. Самая частая ловушка здесь — коллективное согласование: документ уходит на пять руководителей, каждый дописывает «по чуть-чуть», и через три недели вместо рамки первой версии получается список желаний на 30 страниц. Работает наоборот: со стороны заказчика у документа один ответственный, остальные дают замечания через него.
Несколько правил, которые экономят недели:
- Согласование — 2–3 рабочих дня. Дольше — значит, у документа нет владельца внутри компании.
- Правки режимом комментариев, а не правленным файлом — чтобы подрядчик видел, что изменилось, и мог аргументировать.
- Финал фиксируется версией. ТЗ v1.0 подписано — изменения только дополнением с оценкой срока и стоимости. Это касается обеих сторон: и заказчика с новыми идеями, и подрядчика с «упростим пока так».
- Спорные пункты помечаются прямо в документе словом «обсудить» — чтобы на созвоне не проскочили мимо.
Парадокс в том, что дисциплина согласования говорит о проекте больше, чем сам текст: команды, которые прошли этот этап за неделю, почти никогда не срывали сроки дальше по цепочке.
Плохое ТЗ vs хорошее: одни и те же требования двумя языками
Разница между слабым и рабочим ТЗ видна не в объёме, а в проверяемости формулировок. Слева — фразы, которые мы получаем в первых письмах; справа — то, во что они превращаются после брифа:
| Плохо | Хорошо |
|---|---|
| «Сделайте красиво» | «Дизайн в духе референса N; главная = оффер + 3 кейса + форма» |
| «Сайт должен продавать» | «Цель: 30 заявок в месяц, считаем по целям в Метрике» |
| «Нужен блог» | «Раздел новостей: рубрики, 20 карточек; наполнение — заказчик» |
| «Подключите CRM» | «Заявки создают сделку в amoCRM, ответственный — менеджер» |
| «Сайт должен быть быстрым» | «PageSpeed Insights мобильная версия — 80 и выше, LCP до 2,5 с» |
| «Адаптивный дизайн» | «Корректно на 360–1920 px: iPhone SE, iPhone 15, Android, iPad» |
| «Сделайте SEO» | «SSL, ЧПУ, микроразметка, sitemap, скорость — в составе запуска» |
| «Наполните сайт» | «Тексты 8 услуг — подрядчик; 200 карточек каталога — заказчик в CSV» |
| «Как у конкурента, только лучше» | «У конкурента берём структуру каталога, дизайн и тексты — свои» |
Обратите внимание на закономерность: в левом столбце слова оценивают, в правом — измеряют. «Красиво», «быстро», «удобно» не проверяются; количество страниц, миллисекунды и цели в Метрике — проверяются. Перевод оценочных слов в измеримые — и есть основная работа над ТЗ.
Чек-лист приёмки сайта по ТЗ
Финальная проверка перед оплатой последнего этапа. Проходит за час-полтора, и проходить её лучше вместе с подрядчиком — по экрану:
- Структура на месте. Все страницы из карты существуют, каждая открывается с главной не дальше чем за три клика, в меню нет заглушек «раздел готовится».
- Формы и действия работают. Отправили тестовые заявки с каждой формы — данные дошли до почты и CRM, уведомление пришло, на телефоне отображается маска номера.
- Интеграции живые, а не «настроены». Сделка реально создалась в CRM с правильным ответственным; тестовая оплата прошла и чек пришёл; обмен с 1С отдал актуальные остатки.
- Аналитика считает. Цели в Метрике срабатывают на отправку форм и звонок, визит виден в отчётах, доступ к счётчику — на аккаунте заказчика.
- Адаптив на реальных устройствах. Проверили на своём телефоне, телефоне коллеги и планшете — не в окне браузера, а в руках: ничего не уезжает, кнопки нажимаются пальцем.
- Скорость и SEO-база. PageSpeed на мобильной версии в зелёной зоне, сайт открывается по HTTPS, в поиске находятся главная и пара услуг, в Вебмастере нет критичных ошибок.
- Контент ваш. Тексты вычитаны и не содержат «текст-заполнителя», фото — ваши, а не с фотостоков, цены и телефоны актуальны, в футере — правильные реквизиты.
- Передача зафиксирована. Получены доступы к домену, хостингу, CMS, аналитике и рассылкам — на учётные записи компании; исходники и макеты выгружены; пароли от общих аккаунтов сменены.
Если все восемь пунктов закрыты — подписывайте акт. Если нет — фиксируйте замечания списком со ссылкой на пункты ТЗ: это дисциплинирует разговор и переводит его из «не нравится» в «пункт 4.2 не выполнен».
Если ТЗ нет: как выглядят типовые конфликты
Спор без письменных договорённостей почти всегда разворачивается по одному из трёх сценариев.
Первый — переделка за счёт заказчика. Подрядчик честно сделал то, что написано в смете строкой «дизайн внутренних страниц». То, что заказчик ждал другой компоновки, нигде не зафиксировано — значит, новая компоновка это новая работа. Второй — «это не входило». Чаще всего достаётся интеграциям с 1С, загрузке каталога и написанию текстов: в разговоре казалось очевидным, в смете этого нет. Третий — молчаливое недовольство: сайт приняли, но заказчик разочарован, подрядчик не понимает в чём, и вместо развития проекта обе стороны занимаются разбором полётов.
Ни один из этих сценариев не про плохих людей — все они про пустоту там, где должна была быть строчка в ТЗ. Поэтому правило простое: не успеваете написать полный документ — напишите хотя бы цели, состав первой версии и критерии приёмки. Одна страница лучше нуля.
ТЗ — это не бюрократия, а самый дешёвый способ поговорить о будущем сайте на языке, который не придётся оспаривать. Возьмите одиннадцать разделов из этой статьи, заполните своими словами, а спорные места оставьте для разговора с подрядчиком — их и надо обсуждать в первую очередь.
Если черновик уже есть или вы только собираете требования — принесите его к нам. Мы делаем сайты в Липецке и Москве для клиентов по всей России и СНГ и начинаем каждый проект с вопросов, из которых рождается ТЗ. Посмотрим, что не учтено, и честно скажем, где бюджет можно сократить, а где экономия обернётся переделкой — вот разработка сайтов в Москве, здесь — та же работа для Липецка.
Комментарии · 0