ТЗ на разработку сайта: что в нём должно быть, чтобы потом не переделывать

Бриф отвечает на вопрос «чего я хочу»: кто покупает, что продаём, кто конкуренты, что не устраивает в текущем сайте. Его заполняет клиент, и в нём допустимы формулировки вроде «хочу, чтобы было понятно, что мы дорогие, но за дело». Техническое задание отвечает на другой вопрос: «что именно будет сделано и как мы поймём, что это сделано». Оно пишется языком проверяемых пунктов и подписывается как приложение к договору.

Из этой разницы вытекает и авторство. Клиент не обязан знать, что такое canonical, чем 301-й редирект отличается от 302-го и как называется цель в Метрике. Поэтому мы не присылаем клиенту шаблон на двадцать страниц с просьбой заполнить: после брифа и одного созвона пишем документ сами, а клиент читает, задаёт вопросы и утверждает. Как подготовить бриф — отдельная статья; здесь речь только о ТЗ.

Первый раздел ТЗ — зачем сайт бизнесу. Здесь чаще всего и закладывается будущий спор: «современный, продающий сайт, повышающий доверие» — не цель, а набор прилагательных, под который подходит что угодно. Цель формулируется как измеримое действие посетителя: заявка через форму, звонок по клику с мобильного, запись на приём, запрос коммерческого предложения. Рядом — как это действие будет считаться: конкретные цели в Яндекс.Метрике по каждой форме и по клику на телефон.

Отдельно фиксируется, откуда сайт будет получать людей на старте. Сайт под Яндекс.Директ и сайт под органический поиск — разные требования к структуре: для рекламы достаточно двух-трёх посадочных под конкретные кампании, для поиска нужна карта страниц под запросы. Если источник трафика в ТЗ не назван, подрядчик сделает «просто сайт», и через два месяца выяснится, что продвигать на нём нечего. Сюда же — кто принимает заявки и в каком окне отвечает: от этого зависит, нужен ли онлайн-чат или достаточно формы.

Самая дорогая дыра в ТЗ — отсутствие списка страниц. Формулировка «сайт с разделами об услугах и о компании» на приёмке превращается в разговор «а где страница про монтаж?» — «а её не было в задаче». Поэтому в ТЗ входит полная таблица: адрес страницы, её название, под какой запрос она сделана, кто её читатель и какое действие он должен совершить. Для сайта услуг это обычно главная, отдельная страница под каждую услугу, страницы под ниши или типы объектов, цены, контакты, о компании и, при необходимости, статьи.

Порядок важен: сначала фиксируется структура под поисковый спрос, потом рисуются макеты, а не наоборот. Если дизайнер собрал главную с одной страницей «Услуги», а потом выяснилось, что под «ремонт кровли» и «монтаж кровли» нужны разные посадочные, переделывается и дизайн, и вёрстка. Проверка спроса делается по Wordstat до дизайна и записывается прямо в таблицу — какая фраза какой странице соответствует. Отдельным пунктом — чего на сайте не будет: например, «блог в первой версии не делаем».

Второй по частоте спор на приёмке — наполнение. Сайт свёрстан, а на страницах стоит «текст в разработке», потому что клиент думал, что тексты пишет студия, а студия ждала материалы. В ТЗ прямо записывается: кто пишет тексты для каждой группы страниц, кто согласует, в какой срок клиент передаёт прайс, описания услуг, лицензии, фото объектов и команды. Если тексты пишем мы — фиксируются источник фактов (интервью с владельцем, прайс, документы) и объём. Если фото нет — что используется вместо них и когда клиент их предоставит.

Функциональная часть описывается по действиям, а не по названиям блоков. Не «форма обратной связи», а: какие поля, что обязательно, что происходит после отправки — сообщение в Telegram-бот, письмо на почту, карточка в CRM — и в какой срок заявка должна дойти. Здесь же — какие цели Метрики срабатывают на отправку, нужен ли калькулятор, онлайн-запись, обмен с 1С. Каждая интеграция — отдельный пункт: кто даёт доступы и на чьей стороне настройка.

Технический раздел описывает не только «на чём», но и «насколько хорошо». Стек или CMS с обоснованием — почему именно он под эту задачу и кто сможет поддерживать сайт дальше. Адаптивность — не словом, а списком устройств и разрешений, на которых сайт проверяется. HTTPS с первого дня, а не «потом подключим». Скорость — измеримым порогом: например, оценка мобильной версии в PageSpeed Insights не ниже оговорённой, крупнейший элемент страницы прогружается в пределах 2,5 секунды по тому же отчёту. Если порог не записан, любая скорость будет «нормальной».

Если сайт заменяет старый, в ТЗ обязана быть таблица редиректов: каждый старый адрес — куда ведёт на новом сайте, с кодом 301. Без неё после переезда позиции и трафик уходят вместе со старыми URL. Здесь же — доступы: домен и хостинг оформляются на клиента, счётчик Метрики и Вебмастер заводятся в аккаунте клиента, все пароли передаются при сдаче. Формулировка «доступы у подрядчика» через год превращается в невозможность сменить исполнителя.

SEO-требования — гигиена, которая должна быть в любом ТЗ, даже если продвижение пока не планируется: человекопонятные адреса, уникальные title и description для каждой страницы, один H1, canonical со слешем в конце, sitemap.xml и robots.txt, микроразметка организации, хлебных крошек и FAQ, alt у изображений. Переделывать это после запуска дороже, чем заложить сразу: меняются адреса, ломаются ссылки, приходится заводить редиректы.

Критерии приёмки — раздел, из-за отсутствия которого спорят чаще всего. Каждый критерий проверяется за несколько минут: страницы из таблицы открываются по своим адресам; тестовая заявка с каждой формы дошла в Telegram или CRM; цели в Метрике сработали и видны в отчёте; редиректы со старого сайта отдают 301; оценка скорости не ниже порога из ТЗ; на всех страницах согласованный текст, а не заглушки. Всё, что нельзя проверить, — «дизайн понравился», «сайт выглядит дорого» — в критерии не попадает.

Этапы оплаты привязываются к этим же критериям, а не к календарю: часть при старте, часть после утверждения структуры и макетов, остаток после приёмки. Тогда обе стороны одинаково понимают, за что переводятся деньги. И последний раздел — что не входит: тексты, если их даёт клиент; фотосъёмка; покупка домена и хостинга; ведение рекламы после запуска; наполнение каталога сверх оговорённого числа позиций; поддержка и доработки после сдачи — они идут отдельным договором. Этот список экономит больше нервов, чем все остальные вместе.