Техническое задание связывает задачу бизнеса с конкретным поведением сайта и способом проверки результата. Оно помогает договориться не только о страницах, но и о данных, действиях редактора, ошибках, интеграциях и границах первого выпуска.
Не обязательно знать все решения заранее. Неизвестный параметр можно записать как открытый вопрос с ответственным и сроком уточнения. Важно не превращать предположение в незаметное обещание.
Чем ТЗ отличается от брифа
Бриф собирает исходный контекст: о компании, аудитории, задаче, известных системах и ограничениях. ТЗ уточняет, что именно создаётся и как стороны проверят работу. Один документ может развиваться в другой, но заполненная анкета сама по себе не определяет всю функциональность.
«Нужен каталог с удобной формой» — исходная задача. «Посетитель выбирает товар, отправляет контакт и комментарий, а менеджер получает запрос с кодом товара; при ошибке введённый текст сохраняется» — уже описание сценария. Для ТЗ остаётся согласовать поля, ограничения, состояния и критерии приёмки.
Если контекст ещё не собран, начните с конструктора брифа. После заполнения проверьте ответы и отдельно проработайте требования. Этот материал посвящён техническому описанию; условия договора и юридическое оформление обсуждаются отдельно.
Структура рабочего документа
- Контекст и результат. Для кого сайт, какую задачу решает, что обязательно к первому запуску.
- Ограничения и зависимости. Существующий сайт, доступы, системы, материалы и необходимые согласования.
- Аудитории и сценарии. Кто действует, с чего начинает и чем заканчивается операция.
- Структура страниц. Типы шаблонов, навигация и состав первого наполнения.
- Контентная модель. Какие сущности и поля хранятся, как связаны, кто обновляет.
- Функции и интеграции. Поведение, состояния, обмен данными, ошибки и повторы.
- Редакторские операции. Черновики, предпросмотр, публикация и права в согласованном объёме.
- Проверка и передача. Среда, устройства, сценарии приёмки, материалы и доступы.
- Открытые вопросы и изменения. Версия документа, решения, влияние нового требования.
У каждого требования полезно иметь короткий идентификатор. Он связывает описание, макет, замечание и проверку. Нумерация не заменяет содержание, но позволяет обсуждать одну и ту же функцию без неоднозначных ссылок на «ту форму».
Учебный проект: каталог поставщика без онлайн-оплаты
Все данные ниже вымышлены и служат примером требований. Это не реализованный проект CoreWeb и не универсальный объём любой разработки.
Поставщик показывает оборудование и принимает запросы на подбор. Покупатель просматривает категорию и карточку, затем отправляет обращение. Редактор обновляет товары и услуги. Менеджер получает контекст обращения в согласованной системе.
Первый выпуск: категории, карточки оборудования, страницы услуг, сведения о компании, контакты и форма запроса. Корзина, онлайн-оплата, личный кабинет и отображение складских остатков в этот учебный выпуск не входят. Если они потребуются, это изменение состава, а не следствие слова «каталог».
Зависимости: заказчик предоставляет утверждённые названия, характеристики, изображения и документы; способ доставки запроса уточняется до оценки интеграции. Объём первоначального наполнения перечисляется отдельным списком. Реальные пароли в ТЗ не записываются.
Данные и страницы описывайте раздельно
Перед описанием полей проверьте структуру корпоративного сайта: какие задачи закрывает каждая страница и как посетитель переходит между разделами.
Карточка — представление материала на странице. Запись товара — данные, которые могут использоваться в карточке, списке, поиске и обращении. Полезно определить модель до наполнения, чтобы один и тот же код товара не вводился независимо в нескольких местах.
| Сущность примера | Основные поля | Связь и проверка |
|---|---|---|
| Категория | Название, адрес, описание | Список содержит опубликованные товары этой категории |
| Товар | Уникальный код, название, описание, изображение, характеристики | При обращении передаётся код выбранного товара |
| Документ | Название, файл, версия | Скачивается документ, связанный с нужным товаром |
| Услуга | Название, содержание, изображение, состояние публикации | Черновик не показывается в публичном списке |
| Обращение | Идентификатор, контакт, комментарий, код товара | Можно проверить получение и отличить повтор того же запроса |
Для реального проекта дополните модель обязательностью полей, допустимыми значениями и правилами отсутствующего материала. Например, пустое изображение может заменяться предусмотренным состоянием, а товар без обязательного кода нельзя публиковать. Это разные решения, которые должны быть согласованы.
Заполненный фрагмент ТЗ формы запроса
F-01. Начало сценария. Посетитель открывает форму из карточки. Название товара видно в форме; в отправляемых данных используется его код. При открытии общей формы товар может быть не выбран, если такой сценарий включён в проект.
F-02. Поля и проверка. В учебном примере email обязателен, комментарий необязателен и ограничен 2 000 символами. Эти значения иллюстративны, не нормативны. Ошибка показывается возле соответствующего поля понятным текстом; введённое не исчезает. Сервер проверяет данные независимо от браузера. Если для процесса нужны согласия или дополнительные поля, их содержание согласуется отдельно.
F-03. Состояние отправки. Пока запрос обрабатывается, повторное нажатие не создаёт ещё одну отправку. Посетитель видит, что действие выполняется. В интерфейсе предусмотрено понятное сообщение при невозможности завершить запрос.
F-04. Получатель и успешный результат. До реализации записываем конкретную систему и рабочий процесс получателя. Успех означает подтверждённый приём запроса согласованным серверным процессом. Сообщение в браузере не заменяет проверку того, что менеджер сможет найти обращение.
F-05. Неизвестный результат и повтор. Если ответ потерян, повтор того же обращения использует прежний идентификатор. Получатель должен отличить его от нового запроса. Если внешняя система этого не умеет, заранее согласуем другой механизм и его ограничения. Нельзя обещать отсутствие дублей, не проверив полный путь.
F-06. Ошибка. При отказе сервиса посетителю не показывают успех. Контакт и комментарий остаются доступными для повторной попытки. Сообщение не раскрывает внутренние адреса, ключи и технические подробности.
F-07. Защита и диагностика. Согласуем ограничения длины и частоты отправки, защиту от автоматического мусора и поведение при превышении ограничений. Контакт и текст обращения не передаются в события веб-аналитики. В диагностике достаточно идентификатора и категории ошибки; секреты и содержимое запроса туда не добавляются.
F-08. Приёмка. В тестовом окружении проходят корректный запрос, неверный email, слишком длинный комментарий, двойное нажатие, отказ получателя и потерю ответа с повтором. Проверяются сообщения на странице и записи у получателя. Синтетические данные не создают реальные клиентские обращения.
Этот фрагмент задаёт сценарии, но не выбирает CRM и не описывает её неизвестный API. Если система ещё не определена, интеграция остаётся зависимостью с отдельным уточнением.
Редакторский сценарий тоже входит в ТЗ
Проверить возможности предлагаемого решения помогут задания для выбора CMS. После демонстрации перенесите подтверждённый состав в требования, не оставляя его только в устном обсуждении.
CMS-01. Создать услугу. Редактор заполняет согласованные поля и сохраняет черновик. Материал появляется в редакторском списке с понятным статусом, но отсутствует в публичной навигации и поисковой карте сайта.
CMS-02. Предпросмотр. Редактор открывает черновик в предусмотренной среде просмотра. Уточняем, кому доступен просмотр и как он защищён. Публичный адрес черновика не должен случайно становиться опубликованной страницей.
CMS-03. Публикация. Уполномоченный редактор публикует услугу. Проверяем содержание страницы, ссылку из списка и связанные материалы. Если публикация требует согласования, перечисляем участников и состояния процесса.
CMS-04. Изменение. Редактор обновляет текст или изображение и проверяет опубликованный результат. История версий, откат и автоматическое согласование не считаются включёнными, если они отдельно не описаны.
Для приёмки заказчик выполняет эти операции в согласованной роли. Возможности администратора не доказывают, что те же действия доступны обычному редактору.
Заменяйте оценочные слова проверяемым поведением
| Неопределённая фраза | Что нужно согласовать вместо неё |
|---|---|
| Удобная форма | Поля, состояния, ошибки, повтор, получатель и сценарии F-01–F-08 |
| Современная CMS | Перечень действий, роли и демонстрация CMS-01–CMS-04 |
| Быстрый сайт | Страницы, устройства, соединение, метод измерения и согласованные критерии |
| Адаптивный интерфейс | Диапазоны экранов, нужные устройства и состояния с реальным по длине содержанием |
| Готов к запуску | Завершённые проверки, материалы, доступы, план выпуска и открытые вопросы |
Требование не становится проверяемым только от добавления числа. Например, метрика скорости без устройства, страницы и условий не даёт воспроизводимого результата. Условия и целевые значения выбираются для проекта; универсальную гарантию не следует подставлять вместо обсуждения.
Фиксируйте изменения и неизвестное
Храните актуальную версию документа и список согласованных решений. Для изменения укажите автора запроса, затронутые требования, ожидаемый результат и влияние на объём, сроки и оценку. В работу оно переходит после согласования этого влияния.
Учебный пример: «Добавить остатки в карточку товара». Это затрагивает источник данных, частоту обновления, поведение при недоступности системы и смысл показанного числа. Нельзя считать такую задачу простой заменой текста до выяснения зависимостей.
Карточка открытого вопроса может содержать: «Q-01: получатель заявок не определён; ответственен заказчик; нужен выбор до оценки F-04/F-05; без решения демонстрируем форму с тестовым получателем и не считаем интеграцию готовой». Для рабочего проекта дополните конкретной согласованной датой, а не оставляйте слово «потом».
Как проверить ТЗ до начала разработки
Чтобы потренироваться на собственном проекте, выполните упражнение по критериям приёмки: пять карточек с условиями, действиями, ожидаемым результатом и доказательствами.
Попросите другого участника прочитать один сценарий и объяснить, как он его примет. Если для этого приходится угадывать поля, ошибки, права или получателя, верните эти вопросы в документ. Отдельно проверьте, что состав первого выпуска совпадает в ТЗ, смете и плане работ.
ТЗ может уточняться по мере проектирования. Его задача — сохранять понятные границы и проверяемые решения, а не изображать определённость там, где исследование ещё не проведено.
В CoreWeb можно обсудить состав разработки сайта. Для подготовки используйте бриф, статью о составе сметы и определение технического задания.
При описании интерфейса разграничьте адаптивность и дизайн-систему: первая касается поведения на разных экранах, вторая — согласованного набора решений и правил их применения. Состав и проверки каждого результата задаются отдельно.