Что должно быть в ТЗ на сайт, чтобы не переделывать

Хорошее техническое задание не описывает, как сайт выглядит. Оно описывает, что должно быть правдой после сдачи работы — так, чтобы это можно было проверить.

Разница существенная. «Современный, удобный, продающий» проверить нельзя, и спорить об этом можно бесконечно. «На странице услуги ровно один заголовок первого уровня» проверяется за секунду, и спорить тут не о чем.

Ниже — одиннадцать пунктов, которые чаще всего оказываются за пределами задания и всплывают потом, когда переделка стоит дороже всего.

Структура и адреса

1. Список страниц с адресами

Не «раздел услуг», а перечень: какие страницы будут, по каким адресам, какая из какой доступна. Это решается до вёрстки, потому что переделка структуры после запуска стоит дороже всего остального вместе взятого.

Отдельно опишите, что происходит, когда страница меняет адрес: должен оставаться переход со старого на новый. Без этого каждая перестановка разделов теряет накопленные позиции и внешние ссылки.

2. Языковые версии

Если языков больше одного, задайте правило: как выглядит адрес каждой версии, что происходит при переключении языка на внутренней странице, и что показывать, если страница переведена не на все языки.

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

3. Хлебные крошки и вложенность

Опишите, какая страница чья. Это нужно не только для навигации: из этой же структуры собирается разметка, которую читает поисковик. Если вложенность живёт только в голове дизайнера, она не появится ни там, ни там.

И заложите механизм, а не список: завтра внутри услуги появится подуслуга, и цепочка должна выстроиться сама, без правки кода.

Содержимое и кто его правит

4. Что редактируется без разработчика

Перечислите поимённо: заголовки, тексты, цены, блоки, вопросы и ответы, ссылки, SEO-поля. Всё, что не попало в этот список, будет меняться через задачу разработчику — и меняться поэтому не будет.

Проверка простая: после сдачи попробуйте сами изменить одно предложение на трёх языках. Если получилось — пункт выполнен.

5. Как устроены повторяющиеся блоки

Списки, карточки, вопросы и ответы должны заполняться полями, а не разметкой в текстовом окне. Разница проявляется на третий месяц, когда контент ведёт не тот, кто делал сайт: одна лишняя кавычка — и блок исчезает со страницы.

6. Кто отвечает за тексты

Пункт не технический, но срывает сроки чаще остальных. Договоритесь заранее, кто пишет тексты, к какому сроку и что происходит, если их нет: сайт сдаётся с заглушками или работа встаёт.

Формулировка «тексты предоставляет заказчик» без даты — это отложенный конфликт. Добавьте дату и договоритесь, что делать при её срыве.

7. Пустые состояния

Что показывать, когда в разделе ещё ничего нет, когда результат поиска пуст, когда у статьи нет тегов. Это всегда забывают, и это всегда обнаруживается на боевом сайте. Опишите заранее — стоит одну строчку в задании.

Техническая часть

8. Что считается сделанным

Пропишите, как выглядит готовность: собранный сайт на рабочем адресе, наполненный настоящим содержимым, проверенный по списку из последнего раздела. Не «свёрстаны макеты», а «страницы работают».

Отдельно договоритесь о доступах. Домен, хостинг, панель, аналитика, репозиторий кода — всё должно быть оформлено на вас, а не на подрядчика. Переоформление потом возможно, но зависит от доброй воли, а она иногда заканчивается вместе с проектом.

9. SEO-поля и их нормы

Заголовок страницы, описание, адрес, служебные метки — для каждой страницы. Плюс нормы: заголовок до шестидесяти знаков, описание от семидесяти до ста пятидесяти пяти. Хорошо, если панель показывает счётчик и предупреждает о превышении: контролировать это глазами не получается.

Сюда же — карта сайта и служебный файл для поисковых роботов. Кажется мелочью до того дня, когда выясняется, что половина страниц в поиск не попала.

10. Поведение на телефоне

Не «адаптивность», а конкретика: минимальный размер зоны нажатия, что происходит с длинными заголовками, как ведут себя ряды кнопок, когда не помещаются — переносятся или прокручиваются вбок. И обязательно: горизонтальной прокрутки у страницы быть не должно ни на одной ширине.

11. Доступность и темы

Если планируется тёмная тема или увеличение шрифта, это закладывается сразу. Прикрутить потом — значит переписать цвета во всех блоках. Минимум, который стоит требовать в любом случае: контраст текста к фону не ниже четырёх с половиной к одному и возможность увеличить шрифт без разъезжающейся вёрстки.

Как принимать работу

Последнее, и оно важнее половины предыдущего: в задании должен быть список проверок, а не описание желаемого.

Формулируйте так, чтобы ответ был «да» или «нет». Не «страница должна хорошо выглядеть на мобильном», а «на ширине 375 пикселей нет горизонтальной прокрутки». Не «нужна микроразметка», а «валидатор проходит без ошибок на всех типах страниц». Не «сайт должен быть быстрым», а конкретные значения и способ их измерить.

Такое задание дольше писать и гораздо быстрее принимать. И оно защищает обе стороны: подрядчик понимает, что от него требуется, а заказчик не расширяет требования по ходу работы.

Если из всех одиннадцати пунктов вы возьмёте только один — возьмите этот.

И последнее замечание про объём. Задание на сайт услуг редко бывает длиннее десяти страниц, и это нормально: его ценность не в подробности, а в проверяемости. Документ, где половина требований начинается со слова «удобный», не защитит ни одну из сторон, какой бы толстый он ни был.