Как составить техническое задание на сайт: рабочий шаблон и чек-лист

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

Ниже — структура, по которой можно составить рабочее ТЗ даже без опыта в разработке.

1. Контекст проекта

Прежде чем говорить о структуре страниц, стоит зафиксировать:

• Чем занимается бизнес и какую задачу должен решить сайт — заявки, продажи, имидж, поддержка клиентов.

• Кто целевая аудитория и на каких языках она говорит.

• География: один город, вся страна, несколько стран.

• Как будет измеряться успех — количество заявок, время на сайте, конверсия из определённого канала.

• Ограничения: сроки, бюджет, уже существующий бренд-бук, действующая инфраструктура (хостинг, CRM, почта).

2. Карта сайта и структура URL

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

3. Пользовательские сценарии

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

4. Контент и зоны ответственности

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

5. Интеграции

Для каждой интеграции (CRM, платёжная система, Telegram-бот, аналитика) стоит указать: кто владелец доступа, где документация, какие данные передаются и в какую сторону, как обрабатываются ошибки, есть ли тестовая среда для проверки перед запуском.

6. SEO, скорость и доступность

Уникальные заголовки и описания для каждой страницы, целевые показатели скорости загрузки (Core Web Vitals), базовые требования к доступности — навигация с клавиатуры, контрастность текста, alt-теги у изображений, структурированные данные.

7. Критерии приёмки

Самый недооценённый раздел. «Сайт должен быть быстрым» — не критерий, а пожелание. «Главная страница загружается быстрее 3 секунд на 4G» — уже можно проверить и принять или отклонить. Чем конкретнее сформулированы требования, тем меньше поводов для споров на этапе сдачи проекта. Отдельно стоит прописать порядок внесения изменений в ТЗ после старта работ — это нормальная практика, если она заранее согласована.

Мини-шаблон для старта

• Цель сайта и как измеряем результат.

• Аудитория и языки.

• Список страниц и структура разделов.

• Ключевые пользовательские сценарии.

• Интеграции и кто за них отвечает.

• Требования к SEO и скорости.

• Критерии приёмки по каждому пункту.

Мы в Code Nova Evolution обычно помогаем собрать такое ТЗ на этапе анализа перед стартом проекта — это ускоряет разработку и снимает большую часть недопониманий на старте.