Что важно понять по теме «Как составить техническое задание на сайт»
Техническое задание на сайт — это не юридический документ и не таблица с сотней пунктов. Это инструмент взаимопонимания между вами и подрядчиком. Задача ТЗ проста: чтобы вы получили именно то, что ожидаете, а исполнитель чётко понимал, что ему делать.
Главная ошибка — относиться к ТЗ как к формальности. Многие владельцы бизнеса подписывают шаблонный бриф из десяти вопросов, а потом удивляются, почему сайт не продаёт, не удобен или вообще не похож на то, что они представляли. Проблема не в подрядчике. Проблема в том, что ожидания не были озвучены.
ТЗ должно описывать результат, а не процесс. Вам не нужно прописывать, на какой CMS делать сайт или какие библиотеки использовать — это решение исполнителя. Вам нужно описать, что сайт должен делать для вашего бизнеса, какие страницы на нём есть, как люди будут на нём двигаться и что в итоге считается готовым проектом.
Ещё один важный момент: ТЗ пишется не в одиночку. Хороший подрядчик всегда поможет его дополнить, задаст наводящие вопросы, укажет на то, что вы забыли. Если вам дают подписать бриф и молча уходят делать сайт — это тревожный сигнал.
Практические особенности и варианты применения
Реальное рабочее ТЗ на сайт состоит из нескольких смысловых блоков. Не обязательно оформлять их как строгий документ — иногда достаточно структурированного письма или заполненного брифа с дополнениями.
О компании и продукте. Кратко: кто вы, что продаёте, кому, на каком рынке, чем отличаетесь от конкурентов. Подрядчик не погружается в ваш бизнес — он должен понять контекст, чтобы сайт говорил с клиентами на вашем языке.
Задачи сайта. Конкретно: что сайт должен делать. Не «привлекать клиентов», а «получать 15–20 заявок в месяц на ремонт квартир в Москве» или «давать людям возможность записаться на приём онлайн». Чем точнее задача, тем понятнее критерий успеха.
Целевая аудитория. Кто заходит на сайт: возраст, профессия, что человек ищет, какие у него сомнения, что его останавливает от заказа. Это напрямую влияет на тексты, структуру и акценты на страницах.
Структура сайта. Список страниц: главная, услуги (какие именно), о компании, контакты, блог, личный кабинет — всё, что нужно. Для интернет-магазина — категории товаров, карточка товара, корзина, оформление заказа. Чем детальнее список, тем меньше потом сюрпризов.
Функционал. Что сайт должен уметь: формы обратной связи, онлайн-запись, калькулятор стоимости, фильтры товаров, интеграция с CRM, онлайн-оплата. Если чего-то не указать — этого не сделают.
Контент. Кто пишет тексты, кто делает фотографии, есть ли у вас логотип и фирменный стиль. Если контента нет — это отдельная задача и бюджет.
Дизайн и референсы. Покажите три-пять сайтов, которые вам нравятся, и объясните, что именно: цвет, расположение элементов, простота, стиль фотографий. И так же — покажите, что не нравится.
Технические требования. На каком хостинге работать, есть ли уже домен, нужна ли интеграция с 1С или конкретной CRM, должны ли быть мобильная версия или адаптивная вёрстка.
Критерии приёмки. По каким признакам вы считаете сайт готовым. Это важно: без этого пункта подрядчик решит сам, когда работа окончена.
По формату ТЗ бывает разным. Для простого сайта-визитки на десять страниц достаточно заполненного брифа и списка страниц. Для интернет-магазина или сложного сервиса нужен документ на несколько страниц с описанием пользовательских сценариев. Для корпоративного портала — ещё детальнее. Масштаб ТЗ должен соответствовать масштабу проекта.
Ошибки, ограничения и что учитывать на практике
Самая частая ошибка — ТЗ в стиле «сделайте как у конкурента, только лучше». Это не работает. Во-первых, вы не знаете, что происходит внутри чужого сайта: как он ведёт клиентов, какие у него настройки, что работает, а что нет. Во-вторых, копирование структуры без понимания логики приводит к сайту, который выглядит нормально, но не решает ваших задач.
Вторая ошибка — перегруз ТЗ техническими деталями, которые вы не понимаете. Иногда владельцы бизнеса копируют требования из интернета: конкретные движки, протоколы, настройки серверов. Если вы не разбираетесь в этом, не пишите. Подрядчик сам выберет подходящее решение. Ваша задача — описать бизнес-результат, а не техническую реализацию.
Третья ошибка — ТЗ без привязки к бюджету. Можно описать сайт уровня Amazon, но если бюджет — сто тысяч рублей, это бессмысленно. ТЗ и бюджет должны соответствовать друг другу. Нормальная практика: сначала обсуждаете масштаб и бюджет, потом детализируете ТЗ под эти рамки.
Четвёртая ошибка — отсутствие критериев приёмки. Без этого пункт работы считаются законченными, когда подрядчик так решит. Пропишите конкретно: сайт загружается за три секунды, корректно отображается на мобильных устройствах, все формы отправляют данные в вашу почту и CRM, тексты размещены, картинки оптимизированы. Это ваш чеклист при приёмке.
Из ограничений: идеального ТЗ не бывает. В процессе работы всегда что-то уточняется, меняется, дорабатывается. Это нормально. ТЗ — это стартовая точка, а не жёсткая клетка. Важно, чтобы изменения обсуждались и фиксировались, а не накапливались молча.
Ещё один практический момент: ТЗ становится частью договора. Обычно это приложение к договору подряда. Поэтому формулировки должны быть понятными и однозначными. Не «красивый дизайн», а «дизайн в светлых тонах с использованием фирменного синего цвета, примеры в приложении». Не «быстрый сайт», а «время загрузки главной страницы не более трёх секунд при стандартном соединении».
Если вы не уверены, что сможете составить ТЗ самостоятельно — это нормально. Хороший подрядчик на этапе общения сам задаст нужные вопросы и поможет сформулировать документ. Но инициатива должна исходить от вас: вы знаете свой бизнес лучше, чем кто-либо. Подрядчик может структурировать, но наполнить ТЗ смыслом можете только вы.
