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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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