Яка мета пункту "так, що" у визначенні розповіді користувачів?

Історію користувача можна визначити у реченні, як:

As a <type of user> I want <some goal> so that <some reason>

Просто Google для "формули розповіді користувачів" та перші посилання, які пропонують цю формулу.

Моє запитання: яка мета цього пункту? Це там для менеджерів? Чи є так, щоб керівники проектів та зацікавлені сторони могли краще зрозуміти пріоритет пункту? Чому саме там?

Примітка. Я працював з as a <type of user> I want <some goal>формулою, і вона працює добре. Я не помітив жодної проблеми в своїй роботі, застосувавши цей формат, який є більш коротким.

Мета - уникнути непотрібної роботи, змусивши користувача / замовника надати міцну, відчутну вигоду для бізнесу як причину існування цієї функції.

Це не є нечуваним, що функції додаються лише тому, що хтось подумав, що вони звучать круто, або тому, що це є інше програмне забезпечення, тож і у нас це має бути. Найчастіше вони є, принаймні, зовсім непотрібними, якщо не активно шкідливими.

Однак зазвичай помітити ці функції легко, тому що люди, які пропонують їх, як правило, матимуть труднощів із переконливою діловою причиною для них.

Існує техніка під назвою Popping The Why Stack , де ви берете частину "так, що", і запитуєте "Чому?", Потім ви приймаєте цю відповідь і запитуєте "Чому?" знову ж таки, рекурсивно. Якщо після (скажімо) трьох-п’яти "Чому", ви не прийшли або "тому, що це заробить нам гроші", або "тому що це заощадить нам гроші" (бажано з точним описом, як саме це це станеться), тоді цю функцію не варто застосовувати.

Деякі люди вважають, що це настільки важливо, що вони насправді ставлять його першим у шаблоні розповіді:

Щоб [...]

Як [...]

Я хочу [...]

Ось чудовий приклад з розмови деяких людей із «Мислячих робіт»: один із їхніх клієнтів хотів, щоб друковані звіти були відформатовані дуже своєрідно. Коли консультант запитав "Чому", вони сказали, що таким чином їх було легше набрати ще раз. Отже, замість того, щоб застосувати функцію форматування звіту, вони просто перенесли звіти по мережі. Без пункту "так, що", вони все одно роздруковуватимуть ці папери в одному відділі, надсилатимуть їх до іншого відділу та набиратимуть їх назад.

"Так, що" - це причина для досягнення мети.

Наприклад, метою може бути відображення показників продажів за минулий місяць. Ви можете з цим працювати, але вам потрібно знати, чому ви хочете їх відобразити, щоб ви могли отримати більш глибокі вимоги. Що вони хочуть зробити з показниками продажів або перспективою? Знання цієї інформації дасть вам більше розуміння програми та більше шансів розробити користувальницький інтерфейс, який дозволяє клієнту робити те, що він хоче.

Ще одне використання причини - розставити пріоритети історії. Якщо у вас є дві історії:

Я хочу показати показники продажів минулого місяця.
Я хочу відобразити список перспектив.

але у вас є лише ресурси, щоб зробити один - який ви робите? Без причини ви просто здогадуєтесь і не можете вчасно доставити потрібну. Хоча це і менш важливо, оскільки замовник повинен говорити вам, що робити спочатку, але іноді це не так.

На додаток до сказаного, надання причини вимогам дозволяє судити про обґрунтованість вимоги. Користувач може захотіти речі з неправильної причини. Наявність "так, що" роз'яснює причину, отже, дозволяє аналітику підтвердити, що цей запит найкраще задовольняється таким чином.

Приклад:

AI хочу мати можливість вибрати працівників зі списку всіх співробітників компанії

BI хочуть, щоб можна було вибрати працівників зі списку всіх співробітників компанії, щоб я міг видалити тих, що вийшли з компанії 5 років тому.

(B) не має сенсу навіть у середній організації, але ви можете підтвердити вимогу користувача та запропонувати інший спосіб, щоб клієнт виконав цю вимогу.