Как составить ТЗ на разработку сайта

Зачем ТЗ, если «все и так поняли»

Техническое задание нужно не бюрократии. Оно нужно, чтобы через два месяца не спорить, входила ли форма на услуге, редирект со старого URL и доступ редактора в «сделать сайт». Устные «ну как у них, только наше» не являются критерием приёмки.

Плохое ТЗ бывает двух видов. Роман: миссия, ценности, «современный подход», ноль URL. Смета наоборот: список модулей без сценария, из которого потом нельзя понять, зачем модуль. Рабочее ТЗ — границы и проверка: что должно получиться, чего не будет, как понять, что этап закрыт.

Типовые провалы запуска часто растут из дырявой постановки: основные ошибки при создании сайта.

Что должно быть в документе

Цель и заявка. Зачем сайт, какая операция считается успехом, какие каналы предполагаются в первом цикле. Без этого подрядчик оптимизирует красоту главной.

Аудитория фактами. Кто приходит и с какой задачей. Примеры писем и отказов. Запрещённые обещания. География. B2B или розница — это влияет на форму, документы, тон.

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

Сценарии. Три–семь маршрутов «вошёл → сделал». Для каждого: устройство (телефон в приоритете, если так живут клиенты), что видно, что происходит с формой, какое письмо уходит, если уходит.

Контент. Кто пишет, в каком виде сдаёт, что считается готовым текстом. Заглушка «рыба» не равна принятому шаблону услуги.

Роли и доступы. Кто редактирует после запуска, кто админ, что нельзя сломать редактору. Хостинг, домен, аналитика, почта форм.

Интеграции. Перечень явно. «И всё остальное по мере необходимости» — дыра в смете.

Технический контур. ЧПУ, https, 404, редиректы со старого, карта сайта, закрытие служебного, формы, резервное копирование, базовая скорость шаблонов. Не лимиты чужих интерфейсов, которые плавают, а ваши правила.

Приёмка. Как тестируете: чек-лист сценариев, браузеры, на которых принимаете, что не является дефектом (контент, который не сдал заказчик).

Прототип экранов к этому документу прилагают, не вместо него. Зачем он отдельно — в статье зачем нужен прототип сайта.

Чего в ТЗ быть не должно

Формулировок «удобно, интуитивно, в духе бренда» без примера. Выдуманных сроков интеграций, которые ещё не обследованы. Требования «как Amazon». Копипаста чужого ТЗ с модулями, которых у вас нет. Обещаний позиций в поиске и конверсии — это не функция вёрстки.

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

Как писать критерии приёмки

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

Плохо: «SEO заложено». Хорошо: «у шаблона услуги уникальные title и h1 из полей CMS, ЧПУ без транслита-каши, служебные параметры не индексируются по правилам из раздела N».

Плохо: «форма работает». Хорошо: «отправка пишет в почту/CRM поле X, в аналитике цель на успешную отправку, повторная отправка не плодит десять писем без защиты».

Чем конкретнее критерий, тем меньше театра на сдаче.

Порядок сборки ТЗ

1. Заказчик набрасывает цели, услуги, ограничения, старые URL.
2. Вместе фиксируют сценарии и первую очередь страниц.
3. Подрядчик добавляет технический контур и риски интеграций.
4. Прототип ключевых шаблонов.
5. Согласование приёмки.
6. Смета и календарь после этого, не до.

Обратный порядок — смета «сайт под ключ» с неизвестным каталогом — почти всегда кончается дополнительными соглашениями или тихим выкидыванием контуров.

Изменения после утверждения

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

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

Примеры строк, которые нельзя принимать

«Сделать удобно». «Учесть SEO». «Интеграции по необходимости». «Дизайн на уровне лидеров рынка». «Адаптив для всех устройств» без перечня сценариев приёмки. Такие строки не проверяются, значит, не входят в работу — сколько ни подписывай.

Нормальная замена: «сценарий заявки со страницы услуги проходит на узком телефоне», «шаблон услуги отдаёт title из поля CMS», «оплата X и доставка Y в первой очереди, остальное — этап 2».

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

Короткий шаблон разделов

• Паспорт: домен, языки, владельцы.
• Цели и метрика заявки.
• Не входит в первую очередь.
• Карта URL и шаблоны.
• Сценарии приёмки.
• Контент и сроки сдачи текстов.
• Интеграции и зависимости.
• Роли CMS.
• Редиректы и индекс.
• Юридические страницы и формы.
• Хостинг, доступы, резерв.
• Критерии «готово» по этапам.

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

Признак, что ТЗ уже можно отдавать в работу

Посторонний человек из вашей компании может по документу сказать, какие страницы появятся и как проверить услугу на телефоне. Если это не так, макеты рано. Сначала допишите сценарии, не палитру.