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

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

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

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

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

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

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

Опишите пользователя, действие и нужный результат

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

В Service Manual GOV.UK пользовательский сценарий связывает человека, действие и цель. Критерии приёмки описывают результаты, по которым проверяют выполнение задачи. Это полезный метод постановки требований; британское руководство не устанавливает обязательную форму ТЗ для вашего коммерческого проекта.

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

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

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

Укажите данные, правила и неудобные случаи

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

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

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

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

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

Как сделать требования к интерфейсу и скорости проверяемыми

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

У WCAG 2.2 SC 1.4.10 Reflow есть конкретный ориентир: обычное вертикально читаемое содержимое должно перестраиваться на ширине, эквивалентной 320 CSS-пикселям, без потери информации или функции. Для частей, которым необходимо двумерное представление, предусмотрены исключения. Это отдельное требование, а не полный набор проверки доступности.

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

«Быстрый сайт» также требует контекста. Что измеряют, на какой странице, в каких условиях и чем подтверждают результат? web.dev разделяет лабораторные и полевые данные: первые получают в заданной среде, вторые — у реальных посетителей. Один лабораторный отчёт не подтверждает опыт всей аудитории.

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

Заполненный пример требования: фильтр учебного каталога

Ниже — вымышленная карточка R-01 для каталога аренды оборудования. Модели, параметры и ожидаемые результаты придуманы для объяснения. Это не реализованная функция сайта и не сведения об ассортименте клиента.

Контрольный набор состоит из demo-A с высотой 8 м, demo-B с высотой 12 м и demo-C с неизвестным параметром. При вводе 10 м подтверждённо подходит только demo-B. Это математическое правило учебного примера, а не подтверждение доступности оборудования в аренде.

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

Что подготовить заказчику и кто отвечает за вопросы

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

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

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

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

Как фиксировать версию и новые требования

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

Представим, что после R-01 заказчик добавил выбор даты аренды и обещание «доступно сейчас». Это уже не только новый элемент фильтра. Потребуются источник состояния, правила актуальности и поведение при недоступности данных. Изменение стоит обсудить как расширение сценария с отдельными зависимостями.

Если же фильтр на согласованном наборе показывает demo-A при вводе 10 м, это расхождение с правилом R-01. Его описывают как замечание к реализации: версия, шаги, ожидание и фактический результат. Новая идея и ошибка утверждённой функции не должны сливаться в один список «правок».

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

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

Проверка задания перед передачей подрядчику

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

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

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