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