Jaki jest cel klauzuli „tak, że” w definicji historii użytkownika?

Historię użytkownika można zdefiniować w zdaniu takim jak:

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

Tylko Google dla „formuły historii użytkownika” i pierwszych linków wszystkie proponują tę formułę.

Moje pytanie brzmi: jaki jest cel takiej klauzuli? Czy to jest dla menedżerów? Czy istnieje, aby kierownicy projektów i interesariusze mogli lepiej zrozumieć priorytet przedmiotu? Dlaczego tam jest

Uwaga: Pracowałem z as a <type of user> I want <some goal>formułą i działa ona dobrze. Nie zauważyłem żadnego problemu w mojej pracy, implementując ten krótszy format.

Celem jest uniknięcie niepotrzebnej pracy poprzez zmuszenie użytkownika / klienta do zapewnienia solidnej, wymiernej korzyści biznesowej jako powodu istnienia tej funkcji.

Nie jest niczym niezwykłym, że te funkcje są dodawane tylko dlatego, że ktoś uważał, że brzmiały fajnie, lub dlatego, że ma to inne oprogramowanie, więc nasze też muszą je mieć. Najczęściej są one co najmniej całkowicie niepotrzebne, jeśli nie są aktywnie szkodliwe.

Zazwyczaj jednak łatwo jest dostrzec te funkcje, ponieważ osoby, które je proponują, będą miały trudności z dostarczeniem przekonujących powodów biznesowych.

Istnieje technika o nazwie Popping The Why Stack , w której bierzesz część „tak, że” i pytasz „dlaczego?”, A następnie bierzesz tę odpowiedź i pytasz „dlaczego?”. znowu rekurencyjnie. Jeżeli po (powiedzmy) 04:57 „Dlaczego” s, nie dotarły albo „bo to zrobi nam pieniądze” lub „bo będzie to nam zaoszczędzić pieniądze” (najlepiej z dokładnym opisem dokładnie jak to ma się wydarzyć), wtedy funkcja nie jest warta wdrożenia.

Niektórzy uważają, że jest to tak ważne, że faktycznie umieścili to na pierwszym miejscu w szablonie historii:

W celu [...]

Jak [...]

Chcę [...]

Jest świetny przykład z przemówienia niektórych osób z Thoughtworks: jeden z ich klientów chciał wydrukować raporty sformatowane w bardzo szczególny sposób. Kiedy konsultant zapytał „Dlaczego”, powiedzieli, że w ten sposób łatwiej było pisać z powrotem. Zamiast więc wdrożyć funkcję formatowania raportów, po prostu przesłali raporty przez sieć. Bez klauzuli „tak, że” nadal drukowaliby te dokumenty w jednym dziale, wysyłali je do drugiego i wpisywali z powrotem.

„Tak, że” stanowi przyczynę celu.

Na przykład celem może być wyświetlenie wyników sprzedaży z ostatniego miesiąca. Możesz z tym pracować, ale jednym z powodów, dla których musisz wiedzieć, dlaczego chcesz je wyświetlić, aby uzyskać głębsze wymagania. Co chcą zrobić z danymi dotyczącymi sprzedaży lub perspektywami? Znajomość tych informacji zapewni lepszy wgląd w aplikację i większe szanse na zaprojektowanie interfejsu użytkownika, który umożliwi klientowi robienie tego, co chce.

Innym zastosowaniem tego powodu jest nadanie priorytetu historiom. Jeśli masz dwie historie:

Chcę wyświetlić dane dotyczące sprzedaży w ubiegłym miesiącu.
Chcę wyświetlić listę potencjalnych klientów.

ale masz tylko zasoby, by to zrobić - który z nich? Bez powodu po prostu zgadujesz i możesz nie dostarczyć tego na czas. Jest to mniej ważne, ponieważ klient powinien najpierw powiedzieć ci, co zrobić, ale czasami tak nie jest.

Oprócz tego, co zostało powiedziane, podanie uzasadnienia wymagań pozwala ocenić ważność wymagań. Użytkownik może chcieć rzeczy z niewłaściwego powodu. Wyjaśnienie przyczyny „tak, że” pozwala analitykowi potwierdzić, że żądanie jest najlepiej spełnione w ten sposób.

Przykład:

AI chce mieć możliwość wyboru pracowników z listy wszystkich pracowników firmy

BI chce mieć możliwość wyboru pracowników z listy wszystkich pracowników firmy, abym mógł usunąć tych, którzy opuścili firmę 5 lat temu.

(B) nie ma sensu nawet w średniej organizacji, ale możesz zweryfikować wymaganie użytkownika i zaproponować klientowi inny sposób spełnienia tego wymagania.