Подготовить пользовательские истории и проверяемые критерии приёмки
Автор: AILesson9 мин на настройкуПроверено на:ChatGPTПроверено: 2026-08-28
Быстрый ответ
Преобразуйте подтверждённые потребности пользователей и бизнеса в ограниченные по объёму истории и наблюдаемое поведение, не выдумывая продуктовых решений. Укажите: Потребность и подтверждения, Утверждённые продуктовые решения, Поставка и проверка. Ожидаемый результат: Набор историй с подтверждениями, границами, сценариями, критериями приёмки, нефункциональными потребностями, зависимостями и открытыми решениями.
1
Добавьте контекст
ваш текст остаётся в этом браузере. AILesson Prompts не отправляет его ни в модель, ни на сервер.
2
Ваш промпт
Незаполненные поля остаются видимыми как заполнители, поэтому вы всё равно можете скопировать и отредактировать промпт
Подготовьте пользовательские истории и проверяемые критерии приёмки на основе подтверждённых потребностей и утверждённых продуктовых решений.
Ситуации пользователей, роли, цели, поведение, подтверждения, бизнес-причина, ограничения исследования и отрицательные случаи:
[evidence]
Выбранный объём, процесс, состояния, правила, разрешения, данные, интеграции, платформы, нефункциональные потребности и исключения:
[product]
Выпуск, команды, зависимости, аналитика, доступность, конфиденциальность, безопасность, среды, готовность и открытые решения:
[delivery]
Разделяйте подтверждённую данными потребность, продуктовую гипотезу, утверждённое решение, допущение реализации и нерешённый выбор. Делите истории по исполнителям и независимым результатам, а не по техническим слоям или чрезмерно крупным эпикам. Используйте предложение пользовательской истории только как краткое описание; добавьте контекст, указатель подтверждения, включённое и исключённое из объёма, предварительные условия, триггер, основной, альтернативный и ошибочный пути, разрешения, обработку данных, бизнес-правила и зависимости. Записывайте критерии приёмки как наблюдаемые сценарии Given/When/Then или их эквивалент, охватывая обычный путь, границы, отсутствующие или недопустимые данные, отказ в разрешении, одновременное или повторное действие, восстановление, доступность, конфиденциальность и безопасность, аналитику и совместимость только там, где это утверждено. Не выдумывайте текст интерфейса, состояние, порог, интеграцию, роль, хранение данных, цель производительности, уведомление, поведение при ошибке или метрику. Отмечайте нерешённые вопросы как блокирующие затронутые критерии. Не включайте идеи решений, если решение не утверждено. В конце покажите трассировку от подтверждения к истории и критерию и аудит проверяемости, объёма, конфликтов и готовности.
Конфиденциально по умолчаниюПромпт собирается локально в вашем браузере. Не вводите конфиденциальную информацию в сервисы ИИ, если ваша организация этого не разрешает.
От исходных данных к результату
Разобранный пример
Посмотрите, как конкретный контекст превращает этот рецепт в полезный результат
Реальный ввод
Потребность и подтверждения
Данные исследований, UX-сессии P01/P03: когда у передачи в состоянии Ready не видна ответственность за приёмку, владельцы искали нужного человека или пропускали ожидаемое упоминание. Отрицательные случаи P02/P04 показывают, что некоторое ожидание намеренно или связано с известным согласованием. Утверждённая бизнес-причина: сократить устранимую неопределённость, не увеличивая нагрузку уведомлений. Данные не устанавливают распространённость или спрос на электронную почту.
Утверждённые продуктовые решения
Утверждённое исследовательское решение для прототипа: показывать необязательное поле принимающего в передаче; только инициатор или координатор рабочего пространства может его задавать и изменять; владелец и принимающий могут его видеть. Существующие состояния Draft, Active, Ready, Accepted сохраняются. Если принимающий не задан, показывать неназначенное состояние утверждённым дизайн-токеном; точный текст интерфейса не определён. Без электронной почты и push-уведомлений. Принимающий должен быть активным участником рабочего пространства. Журнал аудита записывает исполнителя, прежнего и нового принимающего и время. Поддерживается только веб-приложение. Изменение хранения не утверждено.
Поставка и проверка
Выпуск прототипа для тестирования удобства, не для производства. Design отвечает за текст; Engineering проверяет членство и событие аудита; Accessibility требует работы с клавиатуры, программной метки и обозначения состояния не только цветом. Проверка конфиденциальности использования существующих идентификаторов участников завершена. Имена событий аналитики и порог производительности не определены. Готовность: рассмотренный дизайн, работающий прототип, модульные тесты, проверка доступности, сценарий исследования. Не указывать производственный SLA.
Пример вывода
История 1 — назначить ответственность за приёмку
Как инициатор или координатор рабочего пространства, я хочу назначить активного участника принимающим передачу, чтобы вовлечённые люди видели, кто уполномочен её принять. Подтверждение: P01/P03; область — гипотеза прототипа, а не подтверждённый спрос.
Критерии приёмки
• Given передача в веб-приложении и уполномоченный инициатор или координатор, When он выбирает активного участника рабочего пространства и подтверждает, Then этот участник сохраняется как принимающий и виден инициатору, владельцу и принимающему. Точный интерфейс подтверждения не определён и должен быть предоставлен утверждённым дизайном.
• Given пользователь, который не является инициатором или координатором, When он просматривает передачу, Then он видит принимающего, но не может его изменить. Утверждённое поведение при отказе отсутствует и блокирует точный критерий.
• Given неактивная учётная запись или неучастник, When она указана принимающим, Then система её не сохраняет. Точный текст ошибки ожидается от Design; не выдумывать его.
• Given существующий принимающий, When уполномоченный исполнитель изменяет или очищает его, Then данные аудита записывают исполнителя, старое и новое значения и время. Хранение следует действующей политике; новый срок не указан.
История 2 — понять неназначенную передачу
Как владелец или инициатор, я хочу видеть, что принимающий не назначен, чтобы решить, следует ли его определить или намеренно продолжить без него. Такая формулировка сохраняет отрицательные случаи P02/P04 и не подразумевает, что любое ожидание является ошибкой.
Критерии: при отсутствии принимающего появляется утверждённый визуальный токен неназначенного состояния; состояние остаётся Ready, новое состояние не создаётся. Индикатор имеет программную метку и различим не только по цвету. Пользователь клавиатуры может перейти к полю и выполнить все разрешённые действия в логичном порядке. Точный видимый и доступный текст ожидается от Design и блокирует окончательные утверждения о тексте.
Вне объёма: электронная почта и push-уведомления, производственный выпуск, новый срок хранения, заявления о распространённости или результате, автоматическое назначение, производственный SLA. Критерий аналитики заблокирован до утверждения имён и цели событий. Трассировка связывает P01/P03 с историями видимости, а P02/P04 требуют необязательного назначения и отсутствия автоматического оповещения.
Почему это работает
1
Трассируемость не позволяет краткому предложению истории скрыть неподтверждённое поведение продукта.
2
Граничные и ошибочные сценарии делают критерии приёмки полезными не только для демонстрации обычного пути.
Проверьте результат
Соответствует ли каждая история подтверждению потребности и утверждённому продуктовому решению?
Наблюдаемы и однозначны ли критерии и не содержат ли они вымышленных элементов интерфейса или порогов?
Охвачены ли уместные границы, разрешения, ошибки, восстановление, доступность, конфиденциальность и открытые решения?
Используйте уверенно
Часто задаваемые вопросы
Практические ответы о том, когда использовать этот рецепт, что нужно предоставить и где по-прежнему важна проверка человеком
Что подготовить перед использованием рецепта «Подготовить пользовательские истории и проверяемые критерии приёмки»?
Для рецепта «Подготовить пользовательские истории и проверяемые критерии приёмки» подготовьте потребность и подтверждения, утверждённые продуктовые решения, а также сведения о поставке и проверке. Заменяйте заполнители только проверяемыми сведениями. Если какая-либо деталь неизвестна, явно сохраните эту неопределённость и не просите модель её додумывать.
В каких случаях результат рецепта «Подготовить пользовательские истории и проверяемые критерии приёмки» ещё не готов к использованию?
Результат не готов, если на основе предоставленных данных он ещё не обеспечивает заявленный итог — набор историй с подтверждениями, границами, сценариями, критериями приёмки, нефункциональными потребностями, зависимостями и открытыми решениями — либо опирается на неразрешённые предположения, недостающие согласования или вымышленные детали. Используйте проверки как условия допуска: исправьте исходные данные или назначьте конкретного уполномоченного проверяющего вместо того, чтобы шлифовать результат без достаточных оснований.
Для каких инструментов ИИ есть зафиксированные тесты рецепта «Подготовить пользовательские истории и проверяемые критерии приёмки»?
По состоянию на 28 августа 2026 года в опубликованной записи о тестировании рецепта «Подготовить пользовательские истории и проверяемые критерии приёмки» указан ChatGPT. Это подтверждает лишь наличие зафиксированных запусков, но не гарантирует совместимость или одинаковые результаты в последующих версиях продукта. При использовании другого инструмента или версии сохраните все ограничения в явном виде и повторите проверки результата перед применением.
Преобразуйте исследовательские вопросы в реалистичные ненаводящие задания со свидетельствами успеха, наблюдениями, подсказками и ограничениями прототипа
Преобразуйте наблюдения сеансов в проблемы удобства использования с подсчётом доказательств, не обвиняя участников и не преувеличивая распространённость
Перейдите от понимания ИИ к выполнению задач. Практикуйтесь в составлении запросов, проверке и улучшении результатов с помощью интерактивных уроков для работы и повседневной жизни.
ChatGPT
