Как составить техническое задание на сайт?

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

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

Что такое техническое задание и зачем оно нужно

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

Документ нужен заказчику, дизайнеру, разработчикам, редакторам, SEO-специалистам и другим участникам проекта. Каждая команда использует свою часть требований, но все участники должны одинаково понимать границы работ.

Качественное ТЗ помогает:

• согласовать цели и приоритеты до начала проектирования;
• точнее оценить объём, сроки и состав работ;
• снизить риск противоречивых ожиданий;
• отделить обязательные функции от пожеланий;
• спланировать подготовку текстов, фотографий и других материалов;
• проверить готовый сайт по заранее определённым критериям;
• управлять изменениями, которые появляются после согласования проекта.

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

Шаг 1. Соберите исходные данные и обозначьте границы проекта

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

В начальном разделе ТЗ укажите:

• информацию о компании, продуктах и географии работы;
• тип проекта: лендинг, корпоративный сайт, каталог, интернет-магазин, сервис или другой формат;
• причину разработки или переработки сайта;
• текущий адрес сайта, если проект предполагает редизайн или перенос;
• основные проблемы действующего решения;
• участников согласования и ответственного со стороны заказчика;
• предполагаемые этапы запуска;
• известные ограничения по технологиям, инфраструктуре и внутренним процессам;
• работы, которые точно не входят в проект.

Отдельно соберите доступные материалы: фирменный стиль, брендбук, исследования аудитории, аналитику текущего сайта, товарные базы, регламенты обработки заявок, требования IT- и юридических подразделений. В ТЗ стоит перечислить материалы и отметить, кто и когда их предоставляет.

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

Шаг 2. Опишите цели, аудиторию и пользовательские сценарии

Фраза «нужен современный и удобный сайт» не задаёт проверяемого результата. Цель должна объяснять, какое действие пользователя или какой бизнес-процесс должен поддерживать сайт.

Примеры целей: представить линейку услуг, получать квалифицированные обращения, дать партнёрам доступ к документации, автоматизировать оформление заказов, сократить нагрузку на менеджеров за счёт личного кабинета. Это примеры формулировок, а не универсальный набор: приоритеты определяются задачами конкретного бизнеса.

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

Для каждого сегмента аудитории укажите:

• кто этот пользователь и какую задачу решает;
• что влияет на выбор продукта или компании;
• какая информация нужна до обращения или покупки;
• какие сомнения и ограничения могут возникнуть;
• какое целевое действие должен поддержать сайт;
• с какого устройства и в каком контексте пользователь может заходить на сайт.

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

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

Шаг 3. Составьте структуру сайта и требования к контенту

Структура показывает состав разделов и связи между ними. Начните с перечня сущностей: услуги, товары, категории, проекты, специалисты, офисы, документы, статьи. Затем определите, какие страницы нужны каждой сущности и как пользователь будет между ними перемещаться.

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

Для каждого уникального шаблона страницы желательно зафиксировать:

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

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

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

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

Шаг 4. Зафиксируйте функциональность и интеграции

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

Удобная формула требования: роль — действие — результат — условия. Например: «Посетитель заполняет форму обращения, обязательные поля проверяются до отправки, заявка передаётся в CRM, а на экране появляется подтверждение». Затем отдельно описываются недоступность CRM, повторная отправка, допустимые форматы файлов и уведомления ответственным сотрудникам.

В зависимости от проекта функциональный раздел может включать:

• формы, калькуляторы и квизы;
• поиск, фильтры, сортировку и сравнение;
• корзину, оформление и оплату заказа;
• регистрацию, авторизацию и восстановление доступа;
• личный кабинет и роли пользователей;
• мультиязычность и региональные версии;
• импорт и экспорт данных;
• уведомления по электронной почте или другим согласованным каналам;
• управление страницами, меню, справочниками и SEO-параметрами.

Интеграцию нельзя описывать только названием системы. Укажите направление и состав обмена, инициатора передачи, частоту обновления, способ идентификации записей, действия при ошибке и ответственных за доступы. Для платёжных, учётных и CRM-систем также важно определить тестовую среду и порядок проверки.

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

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

Шаг 5. Определите требования к дизайну и технологиям

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

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

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

Технический раздел может содержать:

• требования к CMS или критерии её выбора;
• ограничения хостинга и серверной инфраструктуры;
• поддерживаемые среды и принципы адаптивной вёрстки;
• требования к системе управления контентом и ролям редакторов;
• подключение аналитики и настройку событий;
• правила обработки персональных и иных защищаемых данных;
• резервное копирование, мониторинг и журналирование;
• порядок развёртывания тестовой и рабочей версии;
• требования к передаче исходных файлов, доступов и документации.

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

Шаг 6. Согласуйте этапы, ответственность и приёмку

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

Для каждого этапа определите:

• результат и формат его передачи;
• ответственного исполнителя и согласующего;
• необходимые материалы со стороны заказчика;
• порядок сбора и обработки комментариев;
• условия перехода к следующему этапу;
• зависимости от внешних систем и команд.

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

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

Отдельно опишите управление изменениями. Новое требование после утверждения ТЗ может влиять на архитектуру, дизайн, сроки и объём работ. Разумный порядок выглядит так: инициатор описывает изменение, команда оценивает последствия, стороны согласуют новый объём, после чего требование добавляется в актуальную версию документа.

Как проверить ТЗ и избежать частых ошибок

Перед передачей документа команде проведите сквозную проверку: от бизнес-цели до конкретной функции и критерия приёмки. Если требование не связано с задачей пользователя или бизнеса, уточните его ценность. Если важная цель не поддержана ни одной страницей или функцией, документ неполон.

Финальный чек-лист технического задания:

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

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

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

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

Частые вопросы

Кто должен составлять техническое задание на веб-сайт?

ТЗ лучше готовить совместно. Заказчик предоставляет бизнес-контекст, ограничения и правила процессов, а подрядчик переводит исходные данные в требования к структуре, интерфейсу и технологиям. Один участник редко обладает всей необходимой информацией.

Чем техническое задание отличается от брифа?

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

Нужно ли составлять ТЗ до выбора подрядчика?

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

Можно ли начать разработку без полного ТЗ?

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

Как понять, что ТЗ достаточно подробное?

Документ достаточно подробный, если команда может оценить объём работ, спроектировать решение и проверить результат без критических догадок. Неизвестные параметры должны быть обозначены как вопросы, допущения или отдельные задачи аналитики.

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