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