Дизайн без цели
Референсы полезны только вместе с объяснением, какую задачу решает конкретный приём.
ТЗ на сайт
Как составить ТЗ на разработку сайта
Хорошее техническое задание фиксирует проверяемый результат и границы проекта, но не заставляет заказчика заранее проектировать чужую работу.
Короткий ответ
Для старта ТЗ на сайт достаточно описать бизнес-задачу, аудитории, ключевые действия, обязательные разделы, источники контента, интеграции, ограничения и критерии приёмки. Технологии и детальную архитектуру можно выбрать вместе с исполнителем после уточнения требований. Не подменяйте цель списком экранов и не оставляйте формулировки вроде «современно» без проверяемого примера.
Проверено редакцией LaunchStrategies: 1 сентября 2026 г.
Минимум для начала оценки
- Какую бизнес-задачу должен поддержать сайт
- Кто основные аудитории и какое действие ожидается от каждой
- Какие продукты, услуги и материалы уже существуют
- Какие функции и интеграции обязательны в первом релизе
- Кто принимает решения и готовит контент со стороны заказчика
- Как будет проверяться готовность перед публикацией
Рабочий файл
Заполните шаблон по разделам
Файл можно открыть в любом текстовом редакторе, удалить неприменимые пункты и приложить к первому обращению.
Структура технического задания
Ответьте на вопросы предметно; неизвестное отметьте как вопрос для discovery.
01
Контекст и цель
- — Что происходит сейчас и почему требуется новый сайт?
- — Какой результат должен измениться после запуска?
- — Какие ограничения по сроку, бренду и инфраструктуре известны?
02
Аудитории и сценарии
- — Кто принимает решение и кто влияет на него?
- — С каким вопросом пользователь приходит на сайт?
- — Какое целевое действие и что происходит после него?
03
Структура и контент
- — Какие направления имеют самостоятельную ценность?
- — Какие страницы и повторяемые сущности обязательны?
- — Кто предоставляет и утверждает тексты, фото и документы?
04
Функции и данные
- — Какие формы, фильтры, роли или операции нужны?
- — Какие данные вводятся, хранятся и передаются?
- — Какие ошибки и пустые состояния должен видеть пользователь?
05
Интеграции и аналитика
- — С какими CRM, оплатой, доставкой или API нужен обмен?
- — Какие события и цели должны фиксироваться?
- — Кто предоставляет доступы и тестовые данные?
06
SEO и эксплуатация
- — Какие URL и материалы нужно сохранить при миграции?
- — Кто будет обновлять сайт и какие права ему нужны?
- — Кто отвечает за домен, хостинг, резервные копии и поддержку?
Критерии приёмки
- Все обязательные URL открываются с ожидаемым статусом и canonical
- Основные сценарии пройдены на согласованных устройствах и браузерах
- Формы валидируют данные и доставляют тестовое обращение ответственному
- События аналитики фиксируются по опубликованной карте целей
- Контент, юридические сведения и контакты утверждены владельцами
- Переданы доступы, инструкция обновления и перечень известных ограничений
Частые пробелы в ТЗ
Страницы без владельца
Неопределённый источник и согласующий контента превращают структуру в блокер запуска.
Интеграция одним словом
Нужно указать системы, события, поля, направление обмена и поведение при ошибке.
SEO после разработки
URL, серверный контент, metadata и миграцию нужно учитывать в архитектуре, а не добавлять в конце.
Нет критериев готовности
Формулировка «всё работает» не заменяет список проверяемых сценариев и ожидаемых результатов.
Первый релиз без границ
Обязательные функции должны быть отделены от идей для следующих этапов.
Примеры scope
Опубликованные проекты
Проекты помогают увидеть возможный тип задачи; их состав и результат нельзя автоматически переносить в новое ТЗ.
Связанные услуги
Другие гайды
Как проверяются материалыПроверить заполненный шаблон
Пришлите черновик и доступные материалы. Уточним противоречия, отделим обязательный scope от следующих этапов и подготовим вопросы к оценке.