Как сформулировать вопрос «Почему я должен этому верить?» в Требованиях к продукту

Пользователь читает ответ ИИ, делает паузу и задает вопрос, который либо сохраняет развертывание, либо завершает его:

«Почему я должен этому верить?»

Если ваш продукт не может ответить на этот вопрос четко и последовательно, у вас нет «ИИ». У вас очень уверенный в себе текстовый генератор. А уверенность – это не то же самое, что правильность.

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

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

1) Что означает «Provenance UX» (простыми терминами BA)

Provenance UX — это пользовательский опыт объяснение ответаа не просто представить это. Это часть продукта, которая превращает «вот мой вывод» в «вот почему этот вывод заслуживает доверия».

На практике он отвечает на несколько повторяющихся вопросов, которые задают пользователи (вслух или про себя):

• Откуда это взялось? (источники)

• Насколько это актуально? (свежесть)

• Насколько мы уверены? (уверенность/неуверенность)

• Что, если источники не согласятся? (конфликты)

• Почему оно отличается от вчерашнего? («что изменилось»)

• Можем ли мы доказать это позже? (аудит/экспорт)

Если ваша функция делает заявления, которые влияют на решения (деньги, соответствие требованиям, безопасность, одобрения), происхождение не является обязательным. Это стоимость приема.

2) Распространенный режим отказа: ответы без квитанций.

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

Вот обычный список грехов (вы их видели):

• Источники показаны, но не привязаны к конкретным утверждениям (поэтому они бесполезны).

• Продукт ссылается на что-то устаревшее (и не признает этого).

• Два источника не согласны, и ИИ выбирает победителя без объяснения причин.

• Ответ меняется между запусками, и пользователь не получает ответа «почему».

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

3) Артефакт: шаблон требований к происхождению (ваш новый лучший друг)

Если вы хотите, чтобы происхождение было доставлено, вам нужен артефакт, который требует точности, потому что «Мы должны показать источники» не является требованием. Шаблон требований к происхождению — это одностраничный бланк, который вы можете заполнить для каждой функции (или для каждого типа ответа) до того, как будут написаны статьи.

Шаблон требований к происхождению (копировать/вставить)

Держите его крепко. Цель – ясность, а не бюрократия.

А) Типы утверждений (что мы утверждаем?)

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

Б) Разрешенные источники

Определите, на что может ссылаться продукт: системы учета, утвержденные внутренние документы, файлы, предоставленные пользователями, утвержденные внешние источники (если таковые имеются). Также определите исключенные источники (да, явно).

В) Правила цитирования (когда показывать источники)

Указать когда нужны исходники и как они появляются:

• встроенные цитаты для каждого утверждения, ящик «Источники», сноски или и то, и другое.
• «Всегда показывать» и «Показывать по требованию» по типу заявки

D) Требования к свежести («SLA о свежести»)

Определите максимальный возраст по типу утверждения и что произойдет, если источник устарел (предупреждение, отказ или продолжение заявления об отказе от ответственности).

E) Уверенность/неуверенность в поведении

Определите, что означает «Высокий/Средний/Низкий» (или его эквивалент), и когда система должна сказать «Я не знаю» или задать уточняющий вопрос.

Е) Разрешение конфликтов

Определите, что считается конфликтом и что должна делать система: покажите и то, и другое, объясните причину конфликта и/или попросите пользователя сделать выбор.

Г) «Что изменилось?»

Определите, что вызывает объяснение изменения (новый источник, обновление, изменение модели/версии) и что видит пользователь.

H) Аудит экспортных требований

Определите формат экспорта, включаемые поля, тех, кто может экспортировать, и правила хранения/доступа.

Я) Валидация

Перечислите несколько тестовых примеров, которые необходимо пройти (устаревший источник, отсутствующий источник, конфликт, низкая достоверность, полнота экспорта).

Этот шаблон позволяет предотвратить «дрейф происхождения» во время спринтов.

4) Когда показывать источники (а когда нет)

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

Показывать источники по умолчанию, когда ответ влияет на принятие решениятакой как:

• руководство по политике/соответствию

• деньги/тарифы/цены/право на участие

• любая «рекомендация», подразумевающая риск

• резюме документов или записей

Сделайте источники необязательными («Показать источники»), если ответ незначителен.например базовые шаги навигации или простые воспроизводимые расчеты.

Язык требований, который можно украсть

• REQ-PROV-001: Для ответов, содержащих фактические утверждения или политические рекомендации, система должен предоставлять цитаты с детализацией по каждому утверждению (каждое утверждение соответствует ≥1 источнику).

• REQ-PROV-002: Система должен предоставить представление «Источники», включающее имя/заголовок источника, систему/издателя и метку времени.

Ключевая фраза там за претензию. Общий список источников без сопоставления не является источником происхождения; это вибрации.

5) Разрешение конфликтов: что делать, если источники не согласны

Конфликты — это не ошибка. Они нормальные. Ошибка в том, что они делают вид, что их не существует.

Практическая продуктовая политика обычно представляет собой некоторую версию:

1. Власть побеждает (система учета / владелец полиса превосходит комментарии)
2. Если власть равна, недавние победы (в пределах свежести SLA)
3. Если давность равна, специфичность побеждает (ближайшее соответствие контексту пользователя)

Но не применяйте это молча. Сделайте это видимым.

Как выглядит хороший конфликтный UX

Если два источника расходятся во мнениях, в продукте должно быть написано что-то вроде:

• «Два источника расходятся во мнениях. Я использую Источник А потому что это система записи, и она была обновлена совсем недавно. Вот что Источник Б говорит».

Язык требований, который можно украсть

• REQ-PROV-101: Если два источника конфликтуют по одному и тому же требованию, система должен показать (a) выбранное значение, (b) конкурирующие значения и (c) причину выбора на основе настроенного разрешения конфликтов.

Это одно из тех мест, где единственное «обязательное» требование предотвращает год недоверия заинтересованных сторон.

6) Соглашения об уровне обслуживания по свежести: самый простой рычаг доверия, который вы можете указать.

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

Не выбирайте один номер свежести. Выберите небольшой стол. Например:

• Интерпретация политики: ≤ 30 дней (или указать дату вступления в силу)

• Тарифы/цены: ≤ 24 часов

• Наличие/инвентарь: ≤ 15 минут

• Общая информация о продукте: ≤ 180 дней

• Файлы, загруженные пользователем: «свежесть равна времени загрузки» (явное)

Затем укажите, что происходит, когда свежесть не удается. Вам понадобятся всего три варианта:

• Предупредить + продолжить (средний риск)

• Продолжайте молча (используйте экономно)

Язык требований, который можно украсть

• REQ-PROV-201: Система должен отображать индикатор актуальности для источников, чувствительных ко времени (например, «Обновлено 3 часа назад»).

• REQ-PROV-202: Если срок требуемого источника превышает соглашение об уровне обслуживания, указанное в соглашении об уровне обслуживания, система должен [refuse/warn] и укажите следующий шаг (обновление, альтернативный источник, эскалация).

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

7) Триада доверия, которая обеспечивает устойчивость провенанса: уверенность + «что изменилось» + аудит.

Когда у вас есть источники, конфликтные правила и новизна, команды часто останавливаются. Не. Разговор о доверии не закончится, пока вы не рассмотрите еще три варианта поведения, которые потребуют пользователи (и аудиторы) в момент внедрения вашей функции.

А) Уверенность/неуверенность (определите, как выглядит «я не уверен»)

Выберите схему доверия, которую может защитить ваш продукт:

• Высокий/Средний/Низкийили
• Проверено/Непровереноили
• Уверенность, основанная на правилах (Высокий уровень только в случае исходного + свежего + отсутствия конфликтов)

Затем нарисуйте четкую линию, когда система должна сказать: “Я не знаю” (или необходимо задать уточняющий вопрос). Общие триггеры:

• отсутствуют источники для требуемого типа утверждения
• неразрешенный конфликт (тай-брейк не применяется)
• Невыполнение SLA по актуальности для претензий с высоким уровнем риска

REQ-PROV-401: Если доверие ниже порога для утверждений о формировании решений, система должен задайте уточняющий вопрос или укажите на неопределенность и предложите безопасный следующий шаг.

Б) «Что изменилось?» (потому что пользователи замечают)

Если завтра ИИ даст другой ответ, пользователи будут считать, что он все выдумывает, если вы не объясните почему. Минимально жизнеспособный вопрос «Что изменилось?» является:

• триггер (новый источник/обновление/обновление политики/изменение версии)
• затронутая претензия(и)
• краткое объяснение со ссылкой на доказательства

REQ-PROV-402: Когда для одного и того же контекста запроса выдается существенно отличающийся ответ, система должен укажите вопрос «Что изменилось?» краткое изложение, включая причину и затронутые претензии.

C) Аудит экспорта (чтобы вы могли доказать это позже)

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

• кто может экспортировать (на основе ролей)
• формат (CSV/JSON/PDF)
• минимум полей (ответ, цитаты, временные метки, достоверность, идентификаторы версий)

REQ-PROV-403: Авторизованные пользователи должен иметь возможность экспортировать запись аудита, включая ответ, источники с метками времени, достоверностью и применимыми идентификаторами версий.

Доводим дело до конца: истории + критерии приемки

Наконец, преобразуйте правила происхождения в истории, которые можно будет создавать и тестировать:

• «Как пользователь, я могу развернуть заявку, чтобы увидеть ее источник(и), временную метку и достоверность».
• «Как рецензент я могу экспортировать аудиторскую запись ответа с цитатами и временными метками».

А затем заблокируйте его с помощью AC:

• Данный претензия, срочная
  Когда цитируемый источник старше SLA
  Затем система должна предупредить/отказаться от использования настроенной копии
  И предложить следующий шаг (обновить/заменить/эскалировать)

Это происхождение как поведение продукта, а не вежливое предложение.

Закрытие: шаблон, который вы фактически будете использовать повторно.

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

Скачать: Шаблон требований к происхождению (источники, актуальность, достоверность, «что изменилось», конфликты, экспорт аудита)

---

Автор: Морган Мастерс, бизнес-аналитик, Modern Analyst Media LLC

Морган Мастерс Бизнес-аналитик и штатный писатель в ModernAnalyst.comведущее сообщество и ресурсный портал для бизнес-аналитиков. Ресурсы бизнес-анализа, такие как статьи, блоги, шаблоны, форумы, книги, а также процветающий сообщество бизнес-аналитиков можно найти по адресу http://www.ModernAnalyst.com