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

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

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

Что нужно определить до составления ТЗ

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

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

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

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

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

Как составить техническое задание по шагам

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

1. Опишите проект и его назначение. Укажите, для какой компании или продукта создается сайт, какую проблему он должен решить и какое место занимает среди других каналов продаж и коммуникации.
2. Зафиксируйте аудитории и сценарии. Для каждой основной группы пользователей опишите цель посещения, последовательность действий и ожидаемый результат.
3. Составьте структуру. Перечислите разделы, типы страниц и связи между ними. Отдельно отметьте повторяющиеся шаблоны, например карточку услуги, товара или статьи.
4. Опишите функции. Для каждой функции укажите условия запуска, вводимые данные, логику обработки, возможные ошибки и итоговое действие системы.
5. Определите требования к контенту. Зафиксируйте состав материалов, форматы, ответственных за подготовку и правила переноса информации со старого ресурса.
6. Перечислите интеграции. Укажите системы, которыми уже пользуется компания, направление обмена данными и ответственных за предоставление доступов.
7. Сформулируйте нефункциональные требования. Опишите поддерживаемые устройства, требования к производительности, безопасности, резервному копированию и управлению доступом.
8. Добавьте критерии приемки. Для каждого существенного требования должно быть понятно, каким действием или проверкой подтверждается его выполнение.

Как описать структуру и пользовательские сценарии

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

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

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

Как формулировать функциональные требования

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

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

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

Что указать о дизайне и адаптивности

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

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

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

Контент, CMS и управление сайтом

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

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

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

Как описать интеграции

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

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

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

Нефункциональные требования, которые часто забывают

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

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

Точные показатели должны быть обоснованы бизнес-задачей и способом проверки. Требование без методики измерения создает разные трактовки при приемке.

Как составить критерии приемки

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

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

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

Типичные ошибки при подготовке документа

• Копирование чужого ТЗ. Готовый шаблон помогает вспомнить разделы, но чужая бизнес-логика создает ненужные функции и не закрывает требования конкретного проекта.
• Описание решения без задачи. Требование использовать определенную технологию может быть оправдано инфраструктурой, но без объяснения причины ограничивает выбор архитектуры.
• Субъективные формулировки. Слова «красиво», «удобно» и «интуитивно» нужно раскрывать через сценарии, ограничения и проверяемое поведение.
• Отсутствие границ проекта. В документе полезно перечислить не только включенные работы, но и задачи, которые выполняет заказчик или которые не входят в текущий этап.
• Игнорирование ошибок. Сценарии часто описывают только успешный результат, хотя сбои оплаты, интеграции или проверки данных также требуют предусмотренного поведения.
• Несогласованные приложения. ТЗ, прототип и макеты не должны противоречить друг другу. При расхождениях следует определить приоритет документов.
• Нет ответственных за контент и доступы. Даже завершенная разработка не может быть полноценно проверена без материалов, учетных записей и тестовых данных.

Как проверить ТЗ перед передачей подрядчику

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

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

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