Jak nazywasz klienta klienta dokumentem specyfikacji, przypadkiem użycia lub scenariuszem?

Mój zespół i ja opracowujemy oprogramowanie, z którego nasi klienci będą korzystać w celu interakcji z klientami. Ponadto jemy również własne produkty dla psów i sami używamy oprogramowania do interakcji z naszymi klientami.

Dlatego czasami może być trudno wyjaśnić przypadki użycia i scenariusze, ponieważ nasi pracownicy mogą być operatorami, nasi klienci mogą być operatorami, a klienci naszych klientów mogą być gośćmi.

Jednak naszymi klientami mogą być także goście wchodzący w interakcje z pracownikami naszego operatora, klienci naszych klientów mogą być odwiedzający wchodzący w interakcje z naszym klientem lub naszym pracownikiem.

Oto model, w którym:

A is an employee
B is a customer
C is our customers' customer

X  interacts with  Y
Operator --> Visitor
      A  -->  B
      A  -->  C
      B  -->  C

Ponieważ czasami nasi klienci mogą odgrywać różne role, czasami konieczne jest odniesienie się do konkretnej roli, operatora lub gościa, zamiast pracownika i klienta.

Przez cały czas można także powiedzieć „klient klienta”.

Zastanawiałem się, jak inne sklepy programistyczne radzą sobie z tymi semantycznymi szczegółami, pisząc swoje przypadki użycia i scenariusze.

• Czy są jakieś ogólne, jednowyrazowe terminy, które mogą odnosić się do każdego produktu z udziałem aktora trzeciego poziomu?
• Oprócz używania określonych ról, Operatora i Odwiedzającego, jakich słów można użyć do identyfikacji klienta klienta?

Słowo musiałoby być wystarczająco krótkie, aby mogło zostać przyjęte w organizacji. Jeśli jest dłuższa niż kilka sylab, jej skrócona forma musi wciąż odróżniać ją od innych aktorów.

wyjaśnić przypadki użycia i scenariusze

To jest klucz: użyj terminologii domeny, tj. Nazw ról. Kto może odgrywać role, nie jest ważne. Upewnij się, że role są dobrze zdefiniowane (dla każdego scenariusza).

Jest całkowicie możliwe, że odwiedzam własną stronę internetową i kupuję własne produkty. To głupie, ale jest możliwe [ale zrobiłem to, aby przetestować oprogramowanie e-commerce!]. Fakt, że jestem dostawcą, gospodarzem, autorem, webmasterem, copywriterem, programistą, klientem, klientem, gościem, nabywcą, gościem, właścicielem i pracownikiem jednocześnie nie zmienia terminologii przypadku użycia: „klient kupuje produkt od właściciela za pośrednictwem formularza internetowego „

Aby to wyjaśnić, zadzwoń do klienta jako klienta , a następnie do klienta jako klienta . To sprawi, że będzie to wyraźniejsze, prawda?

Zalecam zmianę nazwy warunków i dostosowanie pakietu oprogramowania (trochę) dla każdego klienta w zależności od jego preferencji. Niektórzy klienci mogą chcieć nazywać swoich klientów klientami lub użytkownikami.

Również relacja jest trochę zabawna. Jak Twój pracownik może wchodzić w interakcje z klientami klienta?

Pytanie staje się więc prostsze, gdy pomyśli się o Rolach jako bycie względnym a, które pełni rolę w stosunku do bytu b. Twój klient uważa się za Użytkownika, a jego Klient jest dla niego Klientem. Jedyną osobą, która dba o Twojego klienta jako Klienta, jesteś Ty. W systemie masz dwie role: administratora i użytkownika.

Widziałem wyjaśnienie, że masz pracowników, którzy wchodzą w interakcje z klientami końcowymi za pośrednictwem oprogramowania do czatu (nazwijmy tę rolę agentem). Dla wyjaśnienia, czy Agent reprezentuje się jako pracownik Twojego Użytkownika?

Twierdziłbym, że rolą nadal jest Agent, Użytkownik, Klient. Określanie użytkownika jako klienta po prostu myli rzeczy. (Jak widzisz).

Miałem gorzej ... Musiałem pracować na trzech poziomach pośrednich. Istniała spółka, która w niektórych przypadkach była bezpośrednimi użytkownikami naszej aplikacji. Mieli konta, które sprzedawali różne pakiety z naszej oferty i śledzili klientów dla tych kont.

Może trochę styczna, ale ...

Sam lubię projektowanie interakcji i tam nigdy nie używasz abstrakcyjnych „ról” lub „użytkowników”, ale czegoś, co nazywa się „personami”. Zasadniczo tworzysz postać z imieniem, opisem i fotografią, a następnie używasz jej w procesie projektowania

„Bob jest menedżerem banku w swoim średnim wieku, ma pewne doświadczenie komputerowe, ale nie lubi ich szczególnie”.

Następnie w swoim projekcie możesz użyć ich prawdziwych nazw: „Nie, Bob nie chciałby tego”, „Jeśli Bob to zrobi, wtedy Alice musi zostać w jakiś sposób powiadomiona”. Personas są szczególnie przydatne, gdy wykonujesz scenariusze.

Gorąco polecam Więźniowie prowadzą azyl i O twarzy

Poproszono mnie o opublikowanie tego komentarza jako odpowiedzi, więc:

Projekt, nad którym obecnie pracuję, ma klientów klientów mojego klienta. Żargonem projektu jest to, że klienci mojego klienta nazywani są „subskrybentami”, a ich klienci nazywani są „konsumentami”. Korzystając z metafory rynkowej Amazon, mogą zamiast tego być kramarzami i kupującymi.

Operator i gość wydają się dość dobrze zdefiniowani. Nie jestem pewien, czy istnieje różnica, kiedy operator staje się gościem lub gość staje się gościem. W tym momencie każdy jest gościem.

W zależności od tego, co oprogramowanie ma robić, używaj dobrze znanych fikcyjnych postaci, np. Dumbledore zawsze przekazuje Harry'emu wiedzę (ucząc go rzeczy, których wcześniej nie wiedział i / lub odpowiadając na jego pytania). Używaj postaci pasujących do kultury twoich programistów. Następnie możesz odnieść się do nich w takich przypadkach użycia: gdy A siedzi na krześle Dumbledore'a lub gdy B gra Harry'ego.

Jeśli uważasz, że spowodowałoby to, że twoje specyfikacje stałyby się nieformalne i pozbawione profesjonalizmu, powinieneś przeczytać ten artykuł Joela i spojrzeć na jego przykładowe specyfikacje funkcjonalne.