Как составить ТЗ на сайт, чтобы проект не расползся

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

Зачем вообще писать ТЗ, если «и так всё понятно»

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

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

Минимальный каркас, который я прошу заполнить

• Цель. Одна главная: заявка, звонок, запись, оплата. Не пять равнозначных.
• Страницы. Список URL или названий: главная, услуги, цены, контакты, кейсы.
• Контент. Кто даёт тексты, фото, логотип, реквизиты и к какой дате.
• Интеграции. Форма в Telegram, CRM, оплата, Метрика - по пунктам.
• Правки. Сколько раундов входит и что считается новой задачей.
• Приёмка. Чеклист: формы, HTTPS, мобильная версия, мета-теги.

Где ТЗ должно быть жёстким, а где - гибким

Жёстко фиксирую деньги, сроки, состав страниц, интеграции и правила сдачи. Мягче - формулировки блоков, порядок секций, оттенок кнопки. Так проект остаётся живым, но не превращается в бесконечный чат «а давайте ещё».

Пример блока «приёмка», который экономит нервы

Готово, если:
- все страницы из списка открываются по HTTPS
- форма отправляет заявку в Telegram и показывает успех
- сайт читаем на iPhone 13 и Android среднего класса
- title и description заполнены на каждой странице
- доступы к домену, хостингу и репозиторию переданы заказчику

Такой список можно проверить за полчаса. Без него финальная оплата превращается в «ну вроде красиво».

Типичные места, где проект расползается

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

ТЗ не убивает идеи. Оно не даёт каждой идее стать обязательной работой без отдельной оценки.

Как связать ТЗ с деньгами

Если в документе есть список страниц и функций, их можно оценить. Отдельно - сколько стоит сайт в вашем случае. Без списка остаётся только вилка «от и до», которая никому не помогает.

Я обычно прошу прислать черновик ТЗ или хотя бы ответы на шесть пунктов каркаса выше. По ним видно, где проект может вырасти: личный кабинет, фильтры, мультиязык, сложная CRM. Лучше назвать это до предоплаты - в статье что спросить у разработчика до предоплаты есть список вопросов, который дополняет ТЗ.

Мини-шаблон, который можно скопировать

Цель: заявки в Telegram с главной и страницы услуг
Страницы: /, /services, /prices, /contacts
Контент: тексты от заказчика до 15.06, фото 10 шт, логотип SVG
Интеграции: форма -> Telegram + цель Метрики lead_form
Правки: 2 раунда по согласованному макету
Приёмка: см. чеклист выше
Доступы: домен и хостинг оформлены на ИП Иванов

Такой документ на полстраницы уже сильнее, чем PDF на сорок листов с общими словами вроде «digital» и «лидерство на рынке». Его можно приложить к договору, отправить второму подрядчику для сравнения смет и использовать как чеклист при сдаче. Если вы покупаете сайт впервые, полезно также прочитать как правильно купить сайт для бизнеса - там про порядок шагов до подписания.

Как я провожу первый созвон по ТЗ

Обычно за сорок минут проходим по цели, страницам, контенту и интеграциям. Я задаю неудобные вопросы: «Нужен ли каталог в первой версии?», «Кто будет менять цены?», «Куда падает заявка ночью?». Ответы сразу попадают в документ. После созвона заказчик получает черновик на одну-две страницы, а не презентацию на тридцать слайдов.

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

Контент - часть срока, не приложение

Если тексты и фото обещаны «к концу разработки», проект почти всегда встанет. Я закладываю дедлайны: логотип до старта вёрстки, тексты главной до сборки hero, фото кейсов до блока портфолио. Без дат срок разработки становится резиновым - и это не лень исполнителя, а объективная пауза.

Шаблон вопросов по контенту: кто пишет, кто согласует, в каком формате (Google Doc, Word, Notion), сколько раундов правок текста входит. Юридические блоки, реквизиты, политика конфиденциальности - отдельная строка, их часто забывают до запуска.

Интеграции: одна строка - одна оценка

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

Если интеграция не критична для первого запуска, так и пишем: «Этап 2: CRM, после запуска формы в Telegram». Это дешевле, чем тащить всё в первый релиз и не успеть к дедлайну.

И последнее: ТЗ живёт вместе с проектом. Если в середине работы появилась новая страница - это не «мелкая правка», а изменение объёма. Фиксируйте дополнение письменно, даже одной строкой в том же файле. Так обе стороны остаются в одной реальности, и проект не расползается незаметно.

Роли в проекте: кто за что отвечает

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

Ещё полезно указать, кто принимает результат. Один человек с правом «да/нет» экономит недели согласований. Комитет из пяти человек без правил - гарантия бесконечных правок.

Примеры формулировок, которые не расползаются

Вместо «удобная форма» - «форма: имя, телефон, комментарий; успех - зелёное сообщение; ошибка - текст на русском; дубль в Telegram». Вместо «адаптив» - «iPhone SE, iPhone 13, планшет 768px, десктоп 1280px; меню не перекрывает контент». Чем конкретнее, тем меньше споров «мы имели в виду другое».

Если проект с несколькими этапами, ТЗ делю на «релиз 1» и «бэклог». В первом - только то, без чего нельзя принимать заявки. Во втором - идеи с пометкой «оценить отдельно». Так «каталог потом» не превращается в «каталог обещали в первой версии».

Версионирование ТЗ: как не потерять договорённости

Я веду ТЗ в одном файле с датой в названии: tz-site-v3-2026-06.pdf или Notion с историей. Каждое изменение - новая версия или явная строка «добавлено 15.06: страница /blog». Без этого через месяц спор «мы же не согласовывали каталог» превращается в переписку на сорок экранов.

К заказчику уходит ссылка на актуальную версию, не вложение «tz_final_final2.docx». Старые версии не удаляю - они показывают, когда и почему вырос объём.

Чеклист перед подписанием сметы

• Цель одна, измеримая.
• Список страниц закрыт или помечен «этап 2».
• Дедлайны по контенту с именами ответственных.
• Интеграции с критерием «готово».
• Правки: число раундов и граница новой задачи.
• Приёмка: чеклист приложен к документу.

Если хотя бы два пункта пустые - не подписывайте смету, допишите. Час на документ дешевле недели переделок. Подробнее про структуру - в материале про ТЗ на сайт, про деньги - в сколько стоит сайт.

Когда ТЗ можно упростить

Лендинг на три блока не требует PDF на двадцать страниц. Достаточно полстраницы в переписке с шестью пунктами каркаса. Но даже для лендинга фиксирую: оффер, форма, куда падает заявка, срок, цена, что не входит.

Короткое ТЗ лучше длинного «про всё и ни о чём».

На созвоне я часто слышу «у нас всё просто». Простота - тоже объём: одна страница с формой в Telegram и Метрикой - это уже интеграции, SSL, мобильная версия. Простое не значит «без документа».

Типичный спор на финале и как его избежать

«Мы думали, SEO входит». «Мы думали, тексты пишете вы». «Мы думали, правок безлимит». Каждый пункт «мы думали» - дыра в ТЗ. Я явно пишу «не входит: копирайт, SEO-продвижение, фото, юридическая проверка» - список из пяти строк снимает половину конфликтов.

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

Слабые звенья без драмы

• Писать «современный сайт как у конкурента» без списка страниц и функций.
• Обсуждать цвета и шрифты до того, как зафиксирована цель и состав сайта.
• Не указать, кто готовит тексты и фото - и ждать, что подрядчик «сам придумает».
• Не описать критерии приёмки и потом спорить на финальной оплате.
• Добавлять в ТЗ «на всякий случай» функции, которые не нужны в первой версии.

Что сделать до пятницы

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

Если без специалиста никак

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

Соседние темы

• Техническое задание на сайт - разбор структуры ТЗ
• Сколько стоит сайт - как оценить объём
• Что спросить до предоплаты - вопросы подрядчику
• Цены - ориентиры по срокам