Кому нужен этот промт и как он работает?
Этот промт предназначен для бизнес-аналитиков, продуктовых менеджеров и разработчиков, которые хотят структурировать требования к функциям в понятном и проверяемом формате. Он помогает преобразовывать разрозненные запросы от заинтересованных лиц в качественные пользовательские истории с четко описанными критериями приемки. Благодаря этому повышается прозрачность требований, упрощается коммуникация внутри команды и снижается риск недопонимания.
Работает промт, разбирая заданный запрос или набор запросов и формируя для каждого из них пользовательскую историю по формату Майка Кона: что хочет пользователь, кто он и зачем. Далее приводятся критерии приемки в стиле Gherkin — с минимум двумя условиями GIVEN, одним WHEN и одним THEN, которые определяют чёткие сценарии и ожидаемые результаты. В итоговом ответе используется разметка Markdown для удобства чтения и интеграции в документацию.
Готовый промт
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
Перепиши поступившие запросы на функции в формате пользовательских историй, используя шаблон, который сочетает формат пользовательской истории Майка Кона с критерием приемки в стиле Gherkin. Укажи минимум два условия GIVEN, одно WHEN и одно THEN для каждого сценария. Используй разметку Markdown. Пример пользовательской истории с критериям приемки: ### Пользовательская история [Номер]: * **Краткое описание**: [заголовок истории] * **История**: **Как** [тип пользователя], **Я хочу** [действие], **Чтобы** [результат] ### Критерии приемки: * **Сценарий**: [краткое описание] * **Дано**: [первое условие] * **И Дано**: [второе условие] * **Когда**: [событие] * **Тогда**: [ожидаемый результат] Применить для следующих запросов: 1. Запрос от управляющего, ищущего решение: пользователь с аллергией на глютен хочет видеть кнопку "Пиццы без глютена" в приложении, при нажатии показывающую только доступные безглютеновые пиццы. 2. Запрос от исполнительного директора, ориентированного на результаты: пользователь должен получать подробное уведомление с временной линией каждого этапа приготовления и доставки пиццы, отображаемое при каждом открытии приложения, с числовыми данными и графиками. |
Как использовать промт и на что обратить внимание
Используйте этот промт для быстрой и структурированной трансформации требований в понятные и однозначные пользовательские истории. Это особенно полезно при работе с запросами от разных заинтересованных лиц и при планировании задач разработки.
Рекомендуется перед запуском уточнить в каждом запросе ключевые детали — это улучшит качество результата и уменьшит количество доработок. Также убедитесь, что запросы четко сформулированы и не содержат двусмысленностей.
Возможные ограничения: при слишком расплывчатых или неполных вводных данных нейросеть может сформировать неполные сценарии, где условия GIVEN или действия WHEN требуют дополнений. Рекомендуется проводить последующий просмотр и корректировку итогов.
Примеры использования промта
Пример 1. Формирование истории для функции фильтрации меню по аллергенам.
|
1 |
Запрос: пользователь с аллергией на лактозу хочет кнопку "Пиццы без лактозы" для фильтрации меню. |
Этот пример помогает быстро оформить запросы по фильтрам меню в четкие задачи для команды.
|
1 2 3 4 |
Перепиши поступившие запросы на функции в формате пользовательских историй, используя шаблон, который сочетает формат пользовательской истории Майка Кона с критерием приемки в стиле Gherkin. Укажи минимум два условия GIVEN, одно WHEN и одно THEN для каждого сценария. Используй разметку Markdown. Применить для следующих запросов: 1. Запрос: пользователь с аллергией на лактозу хочет видеть кнопку "Пиццы без лактозы" в приложении, при нажатии показывающую только доступные безлактозные пиццы. |
Пример 2. Создание пользовательской истории для функции детализированных уведомлений по статусу заказа.
|
1 |
Запрос: пользователь должен получать ежедневное уведомление с деталями заказа, включая этапы сбора, упаковки и доставки с графиками прогресса. |
Эта задача помогает систематизировать требования к уведомлениям и согласовать формат подачи данных.
|
1 2 3 4 |
Перепиши поступившие запросы на функции в формате пользовательских историй, используя шаблон, который сочетает формат пользовательской истории Майка Кона с критерием приемки в стиле Gherkin. Укажи минимум два условия GIVEN, одно WHEN и одно THEN для каждого сценария. Используй разметку Markdown. Применить для следующих запросов: 1. Запрос: пользователь должен получать ежедневное уведомление с деталями заказа, включая этапы сбора, упаковки и доставки с графиками прогресса. |
Пример результата нейросети
Ниже приведен пример того, как может выглядеть итоговое оформление пользовательских историй по исходным запросам:
✅ Пример:
### Пользовательская история 1:
* **Краткое описание**: Фильтр безглютеновых пицц
* **История**:
**Как** пользователь с аллергией на глютен,
**Я хочу** видеть кнопку «Пиццы без глютена» в приложении,
**Чтобы** при нажатии отображать только безглютеновые пиццы.### Критерии приемки:
* **Сценарий**: Фильтрация пицц без глютена
* **Дано**: Пользователь вошёл в приложение
* **И Дано**: В меню доступны пиццы с разными ингредиентами
* **Когда**: Пользователь нажимает кнопку «Пиццы без глютена»
* **Тогда**: Отображаются только пиццы без глютена### Пользовательская история 2:
* **Краткое описание**: Уведомления со статусом заказа
* **История**:
**Как** пользователь приложения,
**Я хочу** получать подробное уведомление с временной линией этапов приготовления и доставки,
**Чтобы** отслеживать прогресс в реальном времени с числовыми данными и графиками.### Критерии приемки:
* **Сценарий**: Отображение уведомления статуса заказа
* **Дано**: Заказ создан и в процессе приготовления
* **И Дано**: Пользователь открыл приложение
* **Когда**: Открывается экран уведомлений
* **Тогда**: Показано подробное уведомление с графиками и временной линией
Примечание: результат приблизительный и может варьироваться.
Итоги: зачем использовать этот промт?
Использование данного промта значительно экономит время на формализацию требований. Он превращает сложные и неструктурированные запросы в стандартизированные пользовательские истории с четкими проверяемыми критериями. Это упрощает коммуникацию в команде и снижает ошибки в реализации.
Главное преимущество: быстрое и четкое оформление требований в виде пользовательских историй с критериями приемки.
