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

Спасибо! вот кстати я уже когда писала, тоже сформулировала так же :) сила юзер стори

тут юзер стори что-то типа "оформляя заказ, я хочу подтверждать его кодом из СМС, чтобы кто-то левый не мог получить мои личные данные"

Очень рекомендую "Грехи пользовательских историй" от Стаса Рождественского с прошлого AD-12.
https://analystdays.ru/ru/slides-85514-53330.htm и https://youtu.be/S4yUgnmRa0Q
Всего 15 минут, но прекрасно отрезвляет сознание, и шпаргалкой советы себе можно куски презентации выписать, особенно те места, где часто "спотыкаешься".

Шутка дня:
Когда заказчик создаёт задачу в JIRA на аналитика/программиста

Благодарю

А это очень даже не шутка

У меня сегодня было прекрасное. Отправляю в проектный офис подтверждение прохождения контрольной точки по проекту. В ответ "Какого хера пишите в почту. Вы обязаны соблюдать правила и вот вам инструкция". Открываю PDF, а так обрезанный скрин страницы SharePoint с выделенной строкой "Документы". И схема процесса на второй страницы: Подготовить артефакт-загрузить артефакт-profit.

Я видал некоторое дерьмо, но это перебор. Меня остановила сумма, которую вычтут из моей ЗП за разбитый ап стену ноут. Жаль что мы на удалёнке, и нельзя об голову автора разбить.

Из Иннотеха небось)

вряд ли ))) по пропро именно банковские больше упарываются )))

Безопасность. Что бы что, что бы другой не проверл операцию от его имени.

Upd. А вам уже ответили, как говориться все вторично)

Придумали инструмент, а потом сидим мучаемся с грехами. Я не к статье/подкасту, я вообще.

Никогда не любил Юзер Стори как единственный инструмент. Так еще и с обязательным атомарным value. Вообще синергия, эмерджментность value обсуждается?

Все топят что Analyst и вообще все в ИТ почему то должны(не должны, но не суть это сегодня) начать мыслить как предпрениматель, вот можно начать с азов, пусть мыслят с синергией.

Ведь что это, это конфигурация ресурсов с получением продукта/услуги с другими характеристиками и стоимостью. Чем не конфигурация требований с synergy value, как у предпренимателя, value в совокупности в продукте возникает, а не атомарно.

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

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

И вот от них мы часто получаем задачи. Аналитиков обязали искать ценность дабы проекты от таких заказчиков не стреляли в никуда.

И тут не надо быть предпринимателем. Просто базовое понимание "зачем это надо и что это принесет. На пальцах желательно".

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

Вот для более мощных маневров есть всякие архитекторы предприятия, сильные предприниматели и так далее.

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

Я бы сказал, что аналитиков засосало в эту роль как самых близких (крайних).

Согласен, первый вопрос "зачем". Но в случае атомарного требования холдера, "зачем" из примера выше придумывает аналитик. Да еще и в Юзер Стори должен вписать. За счет юз стори пытается повесить это на роль клиента (я как клиент не хочу что бы, и value в том числе).

Я как клиент плевал на это value и требование. Безопасность и отсутсвие операций с моим аккаунтом головная боль инвестора (и закон это даже подтвердит).

Постановка задачи должна звучать по другому. Тогда может и СМС можно заменить. Пользоваться смс сейчас будет клиент, но защита от утечки аккаунта и верификация легетимности операции с аккаунтом это все не на стороне клиента. Юз кейс хотя бы, должен быть про бэк с ограничениями от законодательства или внутренних регламентов. Тогда и value в деньгах будет убытком, в ux будет убытком, но в сокращении возможных потерь будет в плюс.

Или для простоты Юзер стори, но без вот этого вот "валуе". А зачем, прописываем отдельно в ограничениях, и ссылаемся.

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

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

US описывает ценность, которую продукт несёт клиенту. Формулирует его исключительно PO который отвечает за эту самую ценность. Т.е. формат US имеет большую ограниченность по применению.