Другие статьи
Автор статьи: Александр Ломша, COO компании «Лайкит»
Техническое задание — документ, который превращает «хотим красивый сайт» в список проверяемых требований. Без него проект живёт в переписке: одна сторона помнит одно, другая — другое, а сроки сдвигаются на согласованиях. Разбираем, из каких разделов состоит рабочее ТЗ, что в нём забывают и какие формулировки гарантируют переделки.
Зачем нужно ТЗ, если есть договор
Договор фиксирует отношения сторон: объём работ, сроки, оплату, ответственность. ТЗ отвечает на другой вопрос — что именно должно получиться. Это архитектура проекта: цели, структура, функции, требования к дизайну, контенту, SEO и интеграциям. Без него подрядчик делает свою интерпретацию задачи, и она почти всегда расходится с ожиданиями заказчика.
Польза не только в защите от споров. Хорошее ТЗ позволяет оценить бюджет и сроки до старта, а не в середине проекта. По нему видно, какие работы входят в стоимость, а какие станут дополнительными. И по нему же в конце можно принять результат: не «нравится — не нравится», а соответствует требованиям или нет.
Отдельный эффект — скорость. Когда требования описаны, дизайнер не гадает, разработчик не переспрашивает, а правки обсуждаются по существу. В проектах, где ТЗ нет, значительная часть времени уходит на выяснение того, что и так должно было быть понятно.
Кто пишет ТЗ и когда его составлять
ТЗ создаётся на стыке бизнеса и технологий, поэтому пишут его вдвоём. Заказчик формулирует бизнес-цели: зачем нужен сайт, какие показатели важны, кто клиент, что должно измениться после запуска. Исполнитель переводит это в конкретные требования: архитектуру, функциональность, пользовательские сценарии, технические ограничения.
Момент тоже важен. ТЗ составляют до оценки бюджета и до дизайна, а не после первой версии макета. Если документ пишется «по факту», он превращается в описание уже принятых решений и не защищает ни от чего. Нормальная последовательность: цели → требования → оценка → прототип → дизайн → разработка.
На практике часть работы берёт на себя студия: проводит интервью, задаёт неудобные вопросы, предлагает структуру. Заказчику не нужно писать документ самому — но нужно быть готовым отвечать про процессы, ограничения и приоритеты. Если ответы даёт только «человек, который знает сайт», а владелец бизнеса в процессе не участвует, ТЗ получится технически верным и бесполезным для дела.
Каркас документа: десять разделов
Единого стандарта ТЗ нет, но рабочая структура повторяется из проекта в проект. Вот минимальный набор разделов.
- Цели и метрики. Зачем сайт и по каким показателям вы поймёте, что он работает: заявки, звонки, продажи, загрузки. Формулировка «повысить узнаваемость» не проверяется, «получать 30 заявок в месяц с органики» — проверяется.
- Аудитория и сценарии. Кто пользователь, какая у него задача, что он должен сделать на сайте. Для B2B и B2C сценарии разные, и это влияет на всё остальное.
- Структура сайта. Карта разделов и страниц, навигация, логика переходов. Здесь же — какие страницы создаются с нуля, а какие переносятся.
- Функциональные требования. Формы, каталог, фильтры, поиск, корзина, личный кабинет, оплата. Каждая функция описывается через действие пользователя и ожидаемый результат.
- Контент. Кто готовит тексты и фото, в каком объёме, кто отвечает за перенос и редактуру.
- Дизайн и UX. Принципы, ориентиры, референсы, требования к адаптивности и компонентам. Не «как у конкурента», а что именно нравится и почему.
- SEO и аналитика. Структура URL, заголовки, метатеги, микроразметка, требования к скорости, цели в системах аналитики.
- Интеграции. CRM, 1С, склад, оплата, доставка, почта, телефония. С описанием направления обмена и того, что считается работающей интеграцией.
- Технические требования. Платформа, хостинг, поддерживаемые браузеры, требования к доступам и безопасности.
- Этапы, сроки и приёмка. Контрольные точки, состав работ по этапам, критерии готовности и порядок передачи проекта.
Разделы можно объединять — важно, чтобы ни один вопрос не остался без ответа. Если по какому-то пункту ясности нет, это фиксируется как открытый вопрос с ответственным и датой, а не пропускается.
Пример: ТЗ на корпоративный сайт
Покажем, как это выглядит на практике. Компания производит оборудование и продаёт его через дилеров; нужен корпоративный сайт с каталогом и передачей заявок в CRM.
Цели и метрики
Основная цель — заявки на подбор оборудования от дилеров и конечных клиентов. Второстепенная — снизить нагрузку на менеджеров: часть типовых вопросов закрывает каталог и раздел с документацией. Метрики: количество заявок в месяц, доля заявок из органики, глубина просмотра каталога.
Структура и сценарии
Главная, каталог с фильтрами по типу и мощности, карточка товара с характеристиками и документами, раздел «О компании» с сертификатами, «Дилерам» с условиями, блог, контакты. Основной сценарий: из поиска попасть в карточку модели, сравнить характеристики, оставить заявку на расчёт. Второй сценарий: дилер ищет условия сотрудничества и скачивает прайс.
Функционал и интеграции
Фильтры каталога, сравнение моделей, формы заявки и запроса прайса, поиск по сайту, скачивание PDF. Интеграция с CRM: заявка с сайта создаёт сделку с источником и прикреплённым файлом, ответственный назначается по региону. Дополнительно — выгрузка каталога из учётной системы, чтобы цены и наличие не дублировались вручную.
Требования к приёмке
Сайт считается готовым, когда все сценарии проходят на тестовой копии, заявки доходят до CRM, каталог выгружается без ошибок, настроены цели и переданы доступы. Отдельный пункт — обучение сотрудников и инструкция по работе с заявками.
Ориентир по бюджету и срокам для такого проекта: корпоративный сайт — от 6 000 BYN, 30–60 дней; на 1С-Битрикс — от 6 000 BYN, 30–90 дней. Подробнее об этапах и стоимости — в разборе создание корпоративных сайтов под ключ.
Что чаще всего забывают в ТЗ
Ошибки в ТЗ редко связаны с функционалом. Чаще забывают то, что не видно на макетах, но определяет жизнь сайта после запуска.
- Доступы и владение. На чьих аккаунтах хостинг, домен, админка, аналитика, сертификаты. Если всё оформлено на подрядчика, смена исполнителя превращается в отдельный проект.
- Миграция и URL. Что делать со старыми адресами, кто настраивает редиректы, сохраняется ли структура URL. Без этого новый сайт теряет накопленный поисковый трафик.
- Поддержка после запуска. Кто обновляет платформу, делает бэкапы, реагирует на падения, в какие сроки. Это отдельный раздел, а не «договоримся потом».
- Контент и права. Откуда берутся фото и тексты, есть ли права на изображения, кто отвечает за актуальность цен.
- Аналитика. Какие события считаются целевыми и кто проверяет, что они фиксируются корректно.
Четыре ошибки, из-за которых ТЗ не работает
1. Размытые требования без критериев
«Сделайте красиво и современно» — это не требование, потому что его нельзя проверить. Каждый участник понимает «современно» по-своему, и итог сравнивается не с документом, а с чьим-то вкусом. Заменяйте оценки на критерии: какие блоки обязательны, какие референсы приняты, что должно быть на экране при определённом действии.
2. ТЗ описывает внешний вид вместо задач
Иногда документ превращается в покадровое описание картинки: где какая кнопка и какого цвета. Это работа для дизайнера, а не для ТЗ. Задача ТЗ — сказать, что пользователь должен понять и сделать, а визуальное решение появляется позже и обсуждается отдельно.
3. SEO и аналитика дописываются в конце
Если требования к структуре URL, заголовкам и скорости появляются за неделю до сдачи, их реализация превращается в переделку. Проверьте, что в ТЗ есть раздел про SEO и что он не сводится к «прописать метатеги»: важны структура, вложенность, шаблоны страниц и технические ограничения.
4. Нет критериев приёмки
Без них проект сдаётся по ощущению, а правки идут бесконечно. Критерии формулируются заранее и проверяются на тестовой копии: сценарии, интеграции, скорость, отображение на мобильных, доступы. Это защищает обе стороны — и заказчика от недоделок, и исполнителя от расползающегося объёма.
Частые вопросы
Можно ли обойтись без ТЗ, если сайт небольшой?
Для лендинга из пяти экранов полноценный документ действительно избыточен — достаточно брифа на две-три страницы. Но и в нём должны быть цель, аудитория, структура, требования к форме и критерии готовности. Чем меньше проект, тем дешевле ошибка, но и тем быстрее она обнаруживается — уже после запуска, когда переделывать дороже.
Сколько времени занимает составление ТЗ?
Зависит от масштаба и готовности заказчика отвечать на вопросы. Для лендинга хватает одного-двух интервью, для корпоративного сайта с каталогом и интеграциями — нескольких встреч и проработки сценариев. Основное время уходит не на написание, а на согласование: чем больше участников, тем дольше.
Кто должен писать ТЗ — заказчик или студия?
Работает вариант, когда студию подключают к написанию: она знает, какие вопросы задать и какие ограничения учесть. Заказчик в этом случае отвечает за бизнес-часть и принимает решения. Если ТЗ пишет только заказчик без опыта, в документе часто не хватает технических требований; если только исполнитель — целей бизнеса.
Что делать, если ТЗ уже есть, но проект идёт не по плану?
Вернуться к документу и проверить, совпадает ли он с реальностью. Часто выясняется, что часть требований не была согласована, а часть появилась в процессе. Помогает короткая ревизия: что уже сделано, что изменилось, какие пункты нужно переписать и как это влияет на сроки и бюджет. Иногда дешевле обновить ТЗ, чем достраивать проект на противоречиях.
Что делать дальше
Начните с двух страниц: цели и метрики, затем структура. Если по ним есть согласие, остальные разделы пишутся быстрее и почти не переделываются. Покажите черновик будущим пользователям — менеджерам, которые будут работать с заявками: они найдут пропущенные сценарии раньше, чем разработчик.
Если нужен сайт, который сразу проектируется под рост, посмотрите, как мы делаем корпоративные сайты и сайты на 1С-Битрикс: ТЗ в этих проектах — обязательный этап, а не формальность. Перед стартом полезно также прочитать FAQ по разработке сайтов. Ответим на вопросы по вашему проекту в Telegram или на info@likeit.pro.
Кейс по теме: кейс «NutrClinic»
Назад к списку