Вернуться к блогу
Фраза «нужен каталог с фильтрами и формой заявки» понятна на уровне идеи, но для разработки ее недостаточно. Неясно, какие категории появятся в каталоге, как формируются фильтры, что происходит после отправки формы и откуда сайт получает данные. Разработчик все равно вернется с вопросами, а оценка сроков и стоимости будет строиться на предположениях.
Техническое задание снимает эту неопределенность. В статье под ТЗ мы понимаем согласованный комплект требований к сайту. В зависимости от масштаба проекта это может быть один документ или несколько связанных материалов: спецификация функций, модель данных, описание интеграций, макеты и программа приемочных испытаний.
Ниже разберем, чем ТЗ отличается от брифа, какие разделы действительно нужны и как превратить общий запрос в проверяемое требование. В конце приведен каркас, который можно адаптировать под конкретный проект.
Техническое задание описывает, что должна делать система, для каких ролей, при каких условиях и как проверить результат. Оно связывает интерфейс, данные, интеграции, разработку и тестирование.
ТЗ не обязано состоять из сотни страниц. Глубина зависит от проекта: для промосайта достаточно компактного документа, а сервису с личным кабинетом, несколькими ролями и обменом данными потребуются отдельные спецификации. Важен не объем, а отсутствие критичных решений, оставленных «на потом».
Бриф собирает исходную информацию: чем занимается компания, зачем ей новый сайт, какие материалы уже есть и какие ограничения известны. Предпроектное обследование помогает разобраться в процессах, пользователях, системах и проблемах текущего решения.
Если исходные требования еще не сформулированы, работу стоит начать с брифа для клиента: он помогает собрать бизнес-контекст, цели проекта и основные ограничения.
ТЗ появляется на следующем уровне. В нем гипотезы превращаются в согласованные требования: роли получают права, страницы – состав и поведение, интеграции – формат обмена, а функции – условия приемки.
Бизнес-контекст можно кратко оставить во введении, но описание целевой аудитории, ее мотивации и сомнений не заменяет требований. Для разработки важнее ролевые модели: что видит и может сделать неавторизованный посетитель, клиент, контент-менеджер или администратор.
Если в целях используются цифры, рядом нужны исходное значение и способ измерения. Формулировка «сократить ручную работу менеджеров на 30%» полезна только тогда, когда известно текущее время операции и определено, как измерять результат после запуска.
Рабочее ТЗ объединяет требования к пользователям, интерфейсу, данным, обмену с системами и проверке результата.
Состав документа меняется от проекта к проекту, но рабочий каркас обычно охватывает несколько групп требований.
В начале фиксируют назначение системы, краткий контекст, ограничения и границы работ. Здесь важно отделить то, что входит в разработку, от того, что остается на стороне заказчика или другой команды. Термины, сокращения и специфические названия выносят в небольшой глоссарий.
Для каждой роли указывают доступные разделы и действия. Например, неавторизованный пользователь просматривает каталог, но для сохранения товара в избранное должен авторизоваться. Контент-менеджер редактирует карточки, но не управляет правами других сотрудников. Администратор меняет статусы заявок и видит журнал операций.
Название роли само по себе ничего не объясняет. Требование должно связывать роль с разрешенным действием и ограничениями.
В ТЗ фиксируют согласованные разделы, типы страниц и состав блоков. Для страницы описывают шапку, подвал, навигацию, контентные блоки, кнопки, поля и состояния интерфейса. Для каждого динамического элемента важно указать источник данных и правила отображения.
Документ не должен содержать «предполагаемую карту сайта» с неразрешенными гипотезами. Если структура еще обсуждается, ее сначала уточняют в рамках системного анализа или проектирования, а затем фиксируют как требование.
Функциональное требование описывает действие и реакцию системы, а не просто называет модуль. «Личный кабинет», «корзина» и «избранное» – существительные. Из них непонятно, зачем нужен модуль и как он работает.
Чем подробнее описаны функции, роли и интеграции, тем точнее подрядчик сможет рассчитать стоимость создания сайта и отделить обязательный функционал от следующих этапов развития.
Требования можно оформлять как user story, use case или описание возможностей и функций системы. Например: «Система должна позволять [роли] выполнять [действие]» или «Система должна [выполнять действие] при [условии]».
Формат не принципиален, если команда видит:
Для ключевых сущностей описывают состав и связи: пользователь, товар, категория, заявка, заказ и другие объекты конкретной системы. Для полей указывают тип, обязательность, ограничения, допустимые значения и источник.
Этот раздел помогает избежать ситуации, когда интерфейс уже нарисован, но неизвестно, где хранить значение, кто его изменяет и как оно связано с остальными данными.
Фраза «подключить CRM» не определяет задачу. Для каждого обмена нужно зафиксировать назначение, инициатора, направление, периодичность и способ передачи: REST API, SOAP, вебхук или файл.
Если используется API, документ раскрывает методы, endpoints, авторизацию, формат данных, параметры запросов, структуру ответов и ошибки. Для файлового обмена указывают формат, состав и правила формирования файла, канал передачи и обработку некорректных данных. Также нужны повторные попытки, логирование и ответственные за доступы.
Чтобы глубже разобраться в обмене данными между системами, прочитайте, что такое веб-сервисы и как они работают.
SEO-требования задают до разработки шаблонов страниц. В ТЗ фиксируют правила URL, формирование title и description, canonical, индексацию служебных страниц, редиректы, sitemap.xml, robots.txt и микроразметку.
При переносе отдельно сопоставляют старые и новые адреса. Ошибки на этом этапе могут привести к выпадению страниц из поиска и потере органического трафика, а для бизнеса – к снижению заявок и выручки.
Кто готовит тексты и заполняет карточки, можно указать в ролевой модели или организационных договоренностях. Это не заменяет технические SEO-требования.
Для каждого события указывают название, условие и момент срабатывания, систему аналитики и передаваемые параметры. Например, событие отправки формы должно срабатывать после подтвержденной успешной передачи, а не при нажатии кнопки. Иначе отчет будет учитывать заявки, которые система не получила.
Эта группа определяет не отдельные функции, а свойства решения: поддерживаемые браузеры и устройства, адаптивность, производительность, безопасность, доступность, нагрузку и хранение данных. Здесь же фиксируют требования к журналированию, мониторингу и резервному копированию.
Общая идея становится рабочим требованием, когда команда фиксирует состав каталога и поведение его ключевых элементов.
Рассмотрим связанный сценарий: пользователь открывает каталог оборудования, применяет фильтры, переходит в карточку и отправляет заявку.
Слабая формулировка: «Нужен каталог с категориями, фильтрами и формой заявки».
Она задает направление, но не позволяет начать реализацию без уточнений. В ТЗ нужно определить параметры каждого элемента.
Категории. Укажите количество уровней вложенности, порядок сортировки, способ управления и источник данных.
Фильтры. Зафиксируйте перечень параметров и то, как они формируются: статически в административной панели или динамически по характеристикам товаров. Опишите множественный выбор, сочетание условий, сброс значений, сохранение параметров в URL и состояние без результатов.
Карточка товара. Перечислите обязательные блоки, правила отображения цены и наличия, доступные действия и различия для ролей.
Форма заявки. Для каждого варианта формы укажите место вызова, поля, обязательность, формат, валидацию, согласия, успешное состояние и тексты ошибок. Отдельно зафиксируйте, какие данные и UTM-метки передаются в CRM и что видит пользователь при сбое интеграции.
Это еще не готовое ТЗ для конкретного каталога, а перечень решений, которые необходимо принять. В рабочем документе каждое требование получает идентификатор и связывается с проверкой.
Тестирование проверяет качество решения и помогает найти дефекты. Критерий приемки отвечает на более узкий вопрос: выполнено ли конкретное требование.
Критерии приемки становятся основой проверок, а подробнее о том, как они используются в работе команды, мы рассказали в статье про QA в заказной разработке.
Не стоит смешивать критерии с процессом приемки и составом поставки. Это три отдельных блока:
Критерии приемки – измеримые условия готовности каждого требования.
Процесс приемки – окружение, тестовые данные, участники, сроки проверки, классификация дефектов и порядок повторной проверки.
Состав поставки – исходный код, доступы, инструкции, конфигурации и другие согласованные материалы.
Для сложного проекта проверки можно вынести в программу и методику испытаний. Тогда заказчик и команда проходят одинаковые сценарии с зафиксированными шагами и ожидаемыми результатами. Связка «цель → требование → тест» помогает проверить полноту документа.
Единого порядка нет. Иногда сначала фиксируют требования, а затем создают макеты. В других проектах интерфейсы и техническое задание прорабатывают параллельно или детализируют ТЗ по уже согласованному дизайну.
Главное – до начала разработки согласовать роли, ключевые сценарии, ограничения, источники данных и поведение системы. Иначе макеты будут выглядеть законченными, но разработчикам придется самостоятельно додумывать правила.
Каркас связывает границы проекта, функции, данные, интеграции, качество, аналитику и проверку результата.
Ниже приведен базовый каркас, который адаптируют под конкретный проект. Ненужные пункты можно убрать, а объемные части вынести в приложения или отдельные документы.
Объем ТЗ определяется не количеством разделов в оглавлении, а глубиной описания требований. Для простого сайта модель данных, роли и критерии приемки можно раскрыть внутри основных разделов. В сложной системе они становятся самостоятельными спецификациями.
1.1. Назначение документа.
1.2. Термины и сокращения.
1.3. Общее описание системы.
1.4. Ограничения и допущения.
2.1. Что входит и не входит в разработку.
2.2. Зависимости от внешних команд и систем.
2.3. Роли пользователей.
2.4. Доступные разделы, действия и ограничения.
3.1. Роли пользователей
3.2. Структура сайта и типы страниц
3.3. Состав и поведение интерфейсных блоков
3.4. Пользовательские и системные сценарии
3.5. Доступные разделы, действия и ограничения
3.6. Поля, валидация и ошибки
3.7. Источники и правила изменения данных
3.8. Критерии приемки требований
4.1. Основные сущности и их атрибуты.
4.2. Связи между сущностями.
4.3. Источники и правила изменения данных.
4.4. Статусы и жизненный цикл данных.
5.1. Назначение и участники обмена.
5.2. Протокол, авторизация и формат данных.
5.3. Методы, запросы, ответы и ошибки.
5.4. Периодичность, повторные попытки и логирование.
6.1. Браузеры, устройства и адаптивность.
6.2. Производительность и нагрузка.
6.3. Безопасность и доступность.
6.4. Мониторинг и резервное копирование.
7.1. URL, метатеги и индексация.
7.2. Редиректы и перенос страниц.
7.3. События, условия срабатывания и параметры.
8.1. Объем тестирования.
8.2. Процесс и критерии приемки.
8.3. Состав поставки.
8.4. Связь требований с проверками.
В Amiga подготовка начинается с системного анализа: мы уточняем границы решения, роли, процессы, данные и зависимости. Затем переводим результаты в требования, которые можно оценить, реализовать и проверить.
Мы не используем каркас как формальность. Для простого сайта документ остается компактным, а для системы с личным кабинетом и интеграциями отдельные части становятся самостоятельными спецификациями. Такой подход помогает не перегружать проект описаниями, но не оставлять разработку на догадках.
Это согласованный комплект требований к структуре, функциям, данным, интеграциям и качеству сайта. Он помогает разработчикам оценить работу, а заказчику – проверить результат.
Бриф собирает исходный бизнес-контекст и пожелания. ТЗ фиксирует согласованное поведение системы, ограничения и проверяемые условия готовности.
Заказчик предоставляет контекст и ограничения, а системный аналитик вместе с командой переводит их в требования. Состав участников зависит от сложности проекта.
Не всегда. Требования могут предшествовать дизайну, уточняться параллельно с прототипами или детализироваться по согласованным макетам. До разработки важно согласовать поведение системы.
Настолько, чтобы разработчик и тестировщик одинаково понимали роль, условия, действия, данные, ошибки и ожидаемый результат. Критичные сценарии требуют большей детализации.
Да, как основу структуры. Его нужно адаптировать под роли, функции, данные и интеграции конкретного проекта, а ненужные разделы убрать.
ТЗ на разработку сайта – не перечень пожеланий и не описание бизнеса. Это согласованный набор требований, который отвечает на вопросы: кто пользуется системой, что она делает, откуда получает данные, как ведет себя в разных состояниях и по каким условиям принимается результат.
Каркас помогает сохранить структуру, но качество документа определяет детализация критичных сценариев. Если после чтения требования разработчику все еще нужно самостоятельно выбирать поведение системы, решение пока не зафиксировано.
