Техническое задание на разработку сайта: что включить

Что такое техническое задание на сайт

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

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

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

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

Максим Пистун, веб-разработчик и веб-дизайнер

Кто должен составлять ТЗ

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

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

В своей работе я чаще использую второй и третий варианты. Если у клиента нет времени или опыта, я самостоятельно собираю первоначальную структуру под его задачу. Затем мы проходим по документу, исправляем спорные моменты и только после согласования переходим к следующим этапам.

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

Что подготовить заказчику до начала работы

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

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

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

Какие разделы включить в техническое задание

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

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

Насколько подробным должно быть ТЗ

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

В моей практике составление ТЗ для крупного проекта может занимать 2–3 дня. После этого документ обсуждается с заказчиком, и согласование иногда продолжается до недели. Продолжительность зависит не только от количества страниц, но и от скорости обратной связи, числа интеграций и объёма ещё не принятых решений.

Как описывать функциональность без двусмысленности

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

Мини-пример описания формы

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

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

Как ТЗ связано с дизайном и прототипом

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

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

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

Почему время на ТЗ ускоряет разработку

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

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

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

Частые ошибки при подготовке ТЗ

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

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

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

Нужно ли техническое задание для лендинга?

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

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

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

Можно ли составить ТЗ, если ещё нет текстов и фотографий?

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

Чем ТЗ отличается от брифа и прототипа?

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

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

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

Входит ли подготовка ТЗ в стоимость сайта?

Это зависит от масштаба. В практике Максима компактное ТЗ для небольшого лендинга обычно не оплачивается отдельно. Для крупного проекта подробная проработка может стать самостоятельным платным этапом.