Разберусь, как составить ТЗ на сайт, если совсем не разбираешься в разработке - по опыту вижу такие документы регулярно: клиент присылает три сообщения в мессенджере с описанием «сайт как у конкурента, но лучше», а потом удивляется, почему смета выросла вдвое после старта. Нормальное техническое задание не требует знания кода или дизайна - оно требует конкретики: что должен делать сайт, для кого он и что считается результатом. Дальше - структура, которую я прошу заполнить перед стартом почти любого проекта, от лендинга на Tilda до кастомного веб-сервиса.
Зачем нужно ТЗ на сайт и что будет, если его не писать
Без документа проект держится на устных договорённостях, а они трактуются по-разному. Заказчик помнит, что просил «форму с оплатой», разработчик помнит только «форму». В итоге на этапе тестирования выясняется, что оплату через Т‑Банк никто не подключал, а клиент считал это само собой разумеющимся условием.
На практике был случай: лендинг с бюджетом 80 000 ₽ на старте вырос до 150 000 ₽ - не потому что я закладывал скрытые расходы, а потому что после сдачи проекта появились новые требования: калькулятор стоимости, интеграция с СДЭК, форма обратного звонка с уведомлением в Telegram. Каждое из этих требований - отдельная задача с отдельной оценкой, а без ТЗ границы проекта размыты, и любая правка выглядит как «маленькая доработка», хотя по факту это новый функционал.
Зафиксированный документ решает две вещи сразу: разработчик может дать точную оценку по срокам и бюджету, а заказчик получает критерий приёмки - список, по которому можно проверить, сделано ли то, за что платили.
Из чего состоит техническое задание на сайт: базовая структура
ТЗ на сайт не обязано быть похожим на документ из ГОСТа с нумерованными пунктами и терминологией. Мне как разработчику достаточно текста или таблицы, где закрыты следующие блоки:
- Цель сайта - продать, собрать заявки, показать портфолио, автоматизировать заказы
- Целевая аудитория - кто заходит на сайт и с каким запросом
- Структура страниц - сколько разделов, что на каждом из них
- Функционал - форма заявки, оплата, доставка, личный кабинет, интеграции
- Референсы - 2-3 сайта, которые нравятся по стилю или логике
- Тексты и материалы - кто готовит контент, фото, тексты для страниц
- Сроки и бюджет - реалистичные рамки, а не «как можно быстрее и дешевле»
Этого достаточно для оценки проекта и для старта. Технические детали - какой стек, какая архитектура базы данных - разработчик добавляет сам на этапе проработки, заказчику их прописывать не нужно.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Как описать функционал сайта без технических терминов
Главная ошибка - пытаться писать ТЗ языком разработчика, подсмотренным в чужих документах. Получается набор слов без смысла: «нужна REST API интеграция с CRM через webhook». Разработчик такое прочитает, но пользы в этой формулировке ноль, потому что не ясно, что именно должно происходить для клиента и менеджера.
Работает обратный подход - описывать сценарий, а не технологию:
Вместо «интеграция с СДЭК через API» пишу: на странице оформления заказа покупатель вводит адрес, и сайт сам показывает стоимость и сроки доставки СДЭК до этого адреса, без звонка менеджеру.
Вместо «webhook для статусов заказа» пишу: когда клиент оплатил заказ через Т‑Банк, статус в WooCommerce должен смениться на «Оплачено» автоматически, без ручного подтверждения.
Вместо «Telegram-бот на aiogram с FSM» пишу: бот в Telegram принимает заявку в несколько шагов (имя, телефон, услуга) и присылает готовую заявку менеджеру в отдельный чат.
Вместо «настроить сценарий в n8n» пишу: заявка с формы на сайте должна автоматически создавать сделку в CRM и присылать уведомление менеджеру в Telegram, без ручного переноса данных.
Такие формулировки понятны и заказчику, и разработчику - по ним легко оценить объём работы и легко проверить результат после сдачи. Кстати, часть типовых сценариев для Tilda я уже реализовывал раньше и выкладываю в разделе готовых скриптов для Tilda - если нужный функционал там уже есть, в ТЗ можно просто сослаться на такой скрипт вместо долгого описания логики.
Что обязательно прописать в ТЗ в зависимости от типа сайта
Набор обязательных пунктов отличается в зависимости от того, что за проект. Ниже - таблица с минимумом для каждого типа и ориентиром по цене на моих условиях.
| Тип сайта | Что обязательно указать в ТЗ | Цена от |
|---|---|---|
| Лендинг на Tilda | Структура блоков, форма заявки, куда уходят заявки (CRM, Telegram, почта) | от 30 000 ₽ |
| Интернет-магазин | Каталог, корзина, способы оплаты и доставки, интеграция со складом | от 80 000 ₽ |
| Сайт на WordPress | Разделы, админка для контента, кто и как будет редактировать сайт после сдачи | от 60 000 ₽ |
| Веб-сервис или SaaS | Роли пользователей, сценарии авторизации, интеграции с внешними сервисами | от 300 000 ₽ |
| Telegram-бот | Сценарий диалога, куда передаются заявки, нужна ли база данных | от 30 000 ₽ |
Для сравнения: студии на рынке часто просят за подготовку самого ТЗ отдельную оплату в диапазоне 15 000-50 000 ₽, а иногда закладывают её в итоговую смету без объяснений. Я оцениваю проект по брифу заказчика бесплатно, а если требуется углублённая проработка перед стартом - это можно обсудить как отдельную консультацию по разработке сайта.
Пошаговый шаблон: как собрать документ за один вечер
Реальный порядок действий, который сокращает подготовку ТЗ до пары часов:
- Опиши в одном абзаце, зачем нужен сайт и что должно произойти после того, как человек на него зашёл
- Выпиши список страниц - просто перечень: главная, каталог, карточка товара, контакты
- Под каждой страницей укажи, что на ней должно быть - не дизайн, а смысл: «форма заявки с именем и телефоном», «список услуг с ценами»
- Отдельным списком собери все интеграции - оплата, доставка, CRM, уведомления в мессенджер
- Приложи 2-3 ссылки на сайты, которые нравятся, с пометкой, что именно нравится - структура, стиль, скорость загрузки
- Укажи срок, к которому сайт нужен, и бюджет, в который хочется уложиться
Этого достаточно, чтобы разработчик дал точную оценку. Технические подробности - какая CMS, какой хостинг, какая архитектура базы - обычно дорабатываются уже совместно на созвоне, когда исполнитель задаёт уточняющие вопросы по каждому пункту.
Частые ошибки при составлении ТЗ на сайт
Самая частая ошибка - писать ТЗ через референсы без объяснений: «сделайте как у X». Referencing без комментария заставляет разработчика гадать, что именно понравилось - структура каталога, анимации, цветовая схема или скорость загрузки. Итог - переделки, которые можно было избежать одной строчкой пояснения.
Вторая ошибка - не указывать, кто готовит контент. Тексты, фотографии товаров, описания услуг нередко становятся узким местом проекта: дизайн и вёрстка готовы, а сайт стоит без текстов неделями, потому что их писали «по ходу дела».
Третья - закладывать в ТЗ технологии вместо результата. Формулировка «сделайте на React» ничего не говорит о задаче, а вот «нужна CRM с фильтрами по статусам заказов, которую будут одновременно смотреть 5 менеджеров» - уже понятная задача, под которую разработчик сам подберёт стек.
Четвёртая - не фиксировать критерии приёмки. Если в ТЗ не написано «форма отправляет заявку на почту и в Telegram», проверить готовность сайта можно только на глаз, а «на глаз» у заказчика и разработчика бывает разное.
Разобраться перед стартом
Консультация
от 3 000 ₽
Подробнее →Частые вопросы
Нужно ли писать ТЗ, если сайт делают на Tilda?
Да, хотя бы в сокращённом виде. Для простого лендинга достаточно списка блоков и того, куда должны уходить заявки с формы - в CRM, на почту или в Telegram. Для доработок вроде кастомного скрипта интеграции с эквайрингом или СДЭК нужен уже более подробный сценарий, иначе оценка будет приблизительной.
Кто должен писать ТЗ - заказчик или разработчик?
Первую версию логичнее готовить заказчику, потому что только он знает бизнес-задачу и как должен вести себя сайт с точки зрения клиента. Разработчик дорабатывает документ техническими деталями и уточняющими вопросами. Полностью перекладывать составление ТЗ на исполнителя можно, но это обычно отдельная оплачиваемая работа, а не часть базовой цены на разработку.
Сколько времени уходит на подготовку ТЗ?
Для лендинга или простого сайта - 1-2 часа по шаблону из этой статьи. Для интернет-магазина или веб-сервиса с интеграциями - от одного дня до недели, потому что нужно проработать сценарии для разных ролей пользователей и связать их с внешними системами вроде CRM или платёжных шлюзов.
Что делать, если в процессе работы требования изменились?
Это нормально - заранее всё предусмотреть не получается. Правильный подход - фиксировать изменения отдельным пунктом в переписке или документе с датой, чтобы было понятно, какая часть работы выходит за рамки исходной оценки. Так пересчёт бюджета и сроков не становится сюрпризом ни для заказчика, ни для разработчика.