ТЗ на разработку сайта: что включить, чтобы получить то, что нужно

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

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

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

Раздел 1. Бизнес-контекст

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

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

Раздел 2. Структура сайта

Список страниц и разделов. Достаточно дерева: Главная, О компании, Услуги (список), Кейсы, Блог, Контакты. Для каталога — принцип организации: категории, фильтры, что в карточке товара.

Раздел 3. Функциональность

Всё, что сайт должен уметь, списком: формы и их поля, калькуляторы, личный кабинет, поиск, корзина и способы оплаты, мультиязычность. Формулируйте через сценарии пользователя: «клиент выбирает товар, оплачивает картой, получает письмо с подтверждением». Сценарии проверяемы — по ним потом принимается работа.

Раздел 4. Интеграции

С чем сайт должен обмениваться данными: 1С (что именно: товары, цены, остатки, заказы), CRM (какие поля попадают в сделку), телефония, доставки, платёжные системы, рассылки. Для каждой интеграции — направление обмена и частота. Это самый недооценённый раздел: «забытая» интеграция после старта работ — главный источник допсоглашений и сдвига сроков.

Раздел 5. Дизайн и контент

Референсы: три-пять сайтов, которые нравятся, с пояснением, что именно (стиль, структура, подача). Наличие брендбука и фирменного стиля. Кто готовит тексты и фото — вы или исполнитель, и что переносится со старого сайта.

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

Раздел 6. Технические требования

Платформа, если у вас есть требования (корпоративный стандарт, реестр российского ПО, существующая 1С). Требования к скорости, нагрузке, безопасности, если они есть. Хостинг: ваш или подбирает исполнитель. Если требований нет, так и напишите — исполнитель предложит и обоснует. Сориентироваться в вопросе платформы поможет наш разбор «Конструктор или CMS».

Раздел 7. SEO и переезд

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

Раздел 8. Порядок приёмки

Как сдаётся работа: по этапам с промежуточными согласованиями (правильно) или всё разом в конце (рискованно). Что считается выполнением: сценарии из раздела 3 работают, сайт открывается на мобильных, скорость в зелёной зоне, формы приходят в CRM. Гарантийный срок и его условия. Кому принадлежат исходники, макеты и доступы (ответ: вам, и это должно быть написано).

Три ошибки, которые убивают ТЗ

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

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

ТЗ как договор о намерениях. Формулировки «современный дизайн», «удобная навигация», «быстрая загрузка» непроверяемы, а значит, бесполезны при приёмке. Каждую хотелку переводите в проверяемый вид: не «быстрая загрузка», а «основные страницы в зелёной зоне PageSpeed».

Куда это ТЗ нести

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

Мы в Design Lab считаем нормой, когда клиент приходит с одностраничным брифом, а уходит с проработанным ТЗ, — это часть проекта, а не предварительное условие. Так что не откладывайте разговор со студиями до «допишу ТЗ»: тезисов по восьми разделам выше уже достаточно для предметного диалога.