Come si chiama il cliente di un cliente in un documento di specifica, caso d'uso o scenario?

10

Io e il mio team sviluppiamo software che i nostri clienti useranno per interagire con i loro clienti. Inoltre, mangiamo anche il nostro cibo per cani e utilizziamo noi stessi il software per interagire con i nostri clienti.

Pertanto, a volte può essere difficile spiegare casi d'uso e scenari, poiché i nostri dipendenti possono essere operatori, i nostri clienti possono essere operatori e i clienti dei nostri clienti possono essere visitatori.

Tuttavia, i nostri clienti possono anche essere visitatori che interagiscono con i dipendenti dei nostri operatori, i clienti dei nostri clienti possono essere visitatori che interagiscono con i nostri clienti o i nostri dipendenti.

Ecco un modello in cui:

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

Poiché a volte i nostri clienti possono svolgere ruoli diversi, a volte è necessario fare riferimento al ruolo specifico, Operatore o Visitatore, anziché Dipendente e Cliente.

È anche un passaparola dire sempre "cliente del cliente".

Mi chiedevo come altri negozi di sviluppo gestiscono questi dettagli semantici quando scrivono i loro casi d'uso e scenari.

Esistono termini generici di una sola parola che possono essere applicati a qualsiasi prodotto che coinvolga un attore di terzo livello?
Oltre a utilizzare i ruoli specifici, Operatore e Visitatore, quali parole potrebbero essere utilizzate per identificare un cliente di un cliente?

La parola dovrebbe essere abbastanza breve da essere adottata all'interno di un'organizzazione. Se più lungo di una coppia di sillabe, la sua forma abbreviata deve comunque differenziarla dagli altri attori.

communication naming specifications

— jmort253
fonte

1

Pensa che tu stia guardando la relazione sbagliata. A è strettamente un operatore. C è rigorosamente un visitatore. B sembra essere sia un operatore che un visitatore. Il fatto che B abbia due ruoli non cambia il fatto che C sia strettamente un visitatore. Pertanto, non vedo il punto di dare a C un identificatore univoco.

— Pemdas,

@Pemdas - Il problema è il contrario. C è strettamente un visitatore, ma un visitatore non è sempre rigorosamente C. Inoltre, non tutti i prodotti che sviluppiamo hanno un operatore e un visitatore. Questi sono specifici di uno dei tanti prodotti che coinvolgono i clienti e il lungo attore "cliente di un cliente". La mia domanda riguarda come posso generalizzare C come "cliente di un cliente" senza correre il rischio di accorciarlo a solo "cliente" e creare confusione.

— jmort253,

2

Un cliente di un cliente non verrebbe dichiarato "Cliente ** C"? :-)

— GrandmasterB

@GrandmasterB - Quindi i miei stakeholder potrebbero confondersi e pensare che mi riferisco a B o C quando in realtà intendo solo uno di loro.

— jmort253,

Usiamo "ClientsCustomer" per indicare il cliente del cliente ....

5

per spiegare casi d'uso e scenari

Questa è la chiave: usa la terminologia del dominio, cioè i nomi dei ruoli. Chi può interpretare i ruoli non è importante. Assicurarsi che i ruoli siano ben definiti (per ogni scenario).

È del tutto possibile per me visitare il mio sito Web e acquistare i miei prodotti. È sciocco, ma è possibile [ma l'ho fatto per testare il software di e-commerce!]. Il fatto che io sia il fornitore, l'host, l'autore, il webmaster, il copywriter, il programmatore, il cliente, il cliente, il visitatore, l'acquirente, l'ospite, il proprietario e il dipendente allo stesso tempo non modifica la terminologia del caso d'uso: "cliente acquista il prodotto dal proprietario tramite il modulo web "

— Steven A. Lowe
fonte

@Steven - Se dovessi chiederti "Cosa vede il cliente quando riceve un messaggio?" , a chi mi riferisco quando dico "cliente" ? Mi riferisco al mio cliente, al rappresentante di vendita e-commerce che riceve una domanda o mi riferisco al suo cliente, il ragazzo bloccato nel processo di pagamento che riceve le istruzioni su come inserire correttamente un numero di carta di credito in modo da poter acquistare i suoi nuovi furgoni? Grazie!

— jmort253,

@ jmort253, semplice: non usare mai la parola cliente. Acquirente e commerciante.

— Peter Taylor,

@Peter - Supponiamo che io voglia generalizzare questi livelli e applicarli ad altri prodotti. Forse ho un dipendente amministratore, un client amministratore e un utente finale come A, B e C. Esiste una convenzione comune per il "cliente di un cliente" che non deve essere specifica solo per il mio prodotto ma potrebbe anche applica ai prodotti che stai costruendo dove offri prodotti ai tuoi clienti per aiutarli con i loro clienti. Sento che questo problema dovrebbe essere abbastanza comune nei mercati business to business.

— jmort253,

@ jmort253: lascia andare il termine "cliente" ; non ha alcun significato intrinseco nel tuo caso d'uso. Nei tuoi esempi precedenti, usa "client" (uno che utilizza i tuoi servizi), "destinatario" (uno che riceve una domanda) o "acquirente" (uno che acquista qualcosa)

— Steven A. Lowe,

1

@ jmort253, il progetto a cui sto lavorando in questo momento ha clienti di clienti del mio cliente. Il gergo del progetto è che i clienti del mio cliente sono chiamati "abbonati" e i loro clienti sono chiamati "consumatori". Utilizzando la metafora del marketplace di Amazon, potrebbero invece essere titolari di bancarelle e acquirenti.

— Peter Taylor,

8

Per chiarire, chiama il tuo cliente come cliente , quindi i clienti del cliente come clienti . Ciò renderà più chiaro non è vero?

Ti consiglio di rinominare i termini e personalizzare (un po ') il pacchetto software per ciascuno dei tuoi clienti a seconda delle loro preferenze. Alcuni clienti potrebbero voler chiamare i propri clienti clienti o utenti.

Anche la relazione è un po 'divertente. Come può il tuo dipendente interagire con i clienti del cliente?

— Mauris
fonte

Ottima domanda Sviluppiamo software di chat che i nostri clienti possono utilizzare per interagire con i loro clienti / potenziali clienti, ma prendiamo anche le stesse chat per conto degli stessi ... beh ... clienti. Vedi la confusione? Mi piace il tuo suggerimento e ho provato a spingere prima quella convenzione di denominazione. Prenderò in considerazione di provarlo di nuovo.

— jmort253,

Se i clienti del tuo cliente sono i tuoi potenziali clienti, non dovrebbero già essere nominati come potenziali clienti o clienti?

— mauris,

Il / tra clienti e potenziali clienti doveva rappresentare un AND / OR. "Sviluppiamo software che i nostri clienti possono utilizzare per interagire con i loro clienti E / O i loro potenziali clienti." I clienti o potenziali clienti dei nostri clienti non sono necessariamente nostri clienti o potenziali clienti. Wow, immagino di non aver capito quanto sia davvero confuso. Scrivere semplicemente per chiarire è complicato. Le persone con cui i nostri operatori interagiscono potrebbero essere clienti, potenziali clienti, o non clienti o non potenziali clienti, se sono clienti dei nostri clienti

— jmort253

cercando di

— capirlo

3

Quindi la domanda diventa più semplice quando si pensa ai ruoli come entità relativa a svolge un ruolo in relazione all'entità b. Il tuo cliente si considera un utente e i suoi clienti sono clienti per loro. L'unica persona che si prende cura del tuo cliente come cliente sei tu. Hai due ruoli nel sistema come Amministratore e come Utente.

Ho visto la spiegazione che hai dipendenti che interagiscono con i clienti finali attraverso il tuo software di chat (chiamiamo questo ruolo agente). Per chiarimenti, l'Agente si rappresenta come dipendente del tuo Utente?

Direi che il ruolo è ancora agente, utente, cliente. Fare riferimento al proprio Utente come cliente confonde semplicemente le cose. (Come potete vedere).

Ho avuto di peggio ... Ho dovuto lavorare su tre livelli di riferimento indiretto. C'era un'entità aziendale che in alcuni casi erano utenti diretti della nostra applicazione. Avevano account con cui vendevano vari pacchetti dalle nostre offerte e monitoravano i clienti per tali account.

— Michael Brown
fonte

Penso che sia questo il problema. I miei ingegneri e io dobbiamo considerare due ruoli diversi quando discutiamo del progetto. Stiamo discutendo dal ruolo di noi o dal loro ruolo . Anche se, il nostro ruolo è anche l'utente mentre mangiamo il nostro cibo per cani. Sto iniziando a pensare che sto pensando troppo a questo!

— jmort253,

2

Forse un po 'tangente ma ...

Adoro il design dell'interazione da solo, e lì non usi mai "ruoli" o "utenti" astratti, ma qualcosa chiamato "personaggi". Fondamentalmente crei un personaggio con un nome, una descrizione e una fotografia e poi lo usi nel tuo processo di progettazione

"Bob è un dirigente di banca nei suoi anni centrali, ha una certa esperienza al computer ma non gli è particolarmente affezionato."

Quindi nel tuo progetto puoi usare i loro veri nomi "No, Bob non lo vorrebbe", "Se Bob lo fa, Alice deve essere avvisata in qualche modo". Le persone sono particolarmente utili quando si eseguono scenari.

Consiglio vivamente I detenuti gestiscono l'asilo e il volto

— Homde
fonte

Grazie per la risposta! Questo è un ottimo suggerimento. Dovrò pensare se potrebbe applicarsi o meno a tutti i nostri prodotti. Le persone del mio cliente e del cliente cliente dovrebbero essere in grado di essere attori in tutti i nostri sistemi per farlo funzionare. In altre parole, Bob dovrebbe essere un cliente del nostro strumento di creazione dei widget e anche un cliente del nostro prodotto foo e del nostro prodotto da bar, se questo ha senso.

— jmort253,

@jmort, probabilmente non è così che dovresti usare quelli di persona. A meno che Bob non sia davvero la stessa persona che acquisterebbe sia lo strumento di creazione dei widget sia foo and bar, questi dovrebbero essere definiti come personaggi separati ... questo è il punto, costruisci persone diverse per scenari / applicazioni / sistemi specifici e personalizzi la soluzione per loro. I nomi delle persone non sono solo sinonimi di "l'utente"

— Homde

Prediligo questo approccio, abbiamo avuto delle difficoltà a spiegare cosa facciamo agli investitori e ai nostri clienti immediati. Abbiamo inventato Jamie e Dave come fondatori di una società fittizia e utilizziamo Jamie e Dave nelle nostre storie, sceneggiature video, casi d'uso ecc. Molto più facile per gli utenti finali dei clienti del cliente, ecc.

— Dickey Singh,

2

Mi è stato chiesto di pubblicare questo commento come risposta, quindi:

Il progetto a cui sto lavorando al momento ha clienti di clienti del mio cliente. Il gergo del progetto è che i clienti del mio cliente sono chiamati "abbonati" e i loro clienti sono chiamati "consumatori". Utilizzando la metafora del marketplace di Amazon, potrebbero invece essere titolari di bancarelle e acquirenti.

— Peter Taylor
fonte

0

Operatore e Visitatore sembrano abbastanza ben definiti. Non sono sicuro che ci sia differenza quando un operatore diventa Visitatore o un Visitatore diventa Visitatore. A quel punto, tutti sono Visitatori.

— Jeffo
fonte

0

A seconda di ciò che il software è destinato a utilizzare personaggi fittizi ben noti, ad esempio Silente, fa sempre perdere conoscenza a Harry (insegnandogli cose che non sapeva prima e / o rispondendo alle sue domande). Usa personaggi che si adattano alla cultura dei tuoi sviluppatori. Quindi puoi fare riferimento a loro nei casi d'uso come tali: quando A è seduto sulla sedia di Silente o quando B interpreta Harry.

Se pensi che questo renderebbe le tue specifiche informali e prive di professionalità, dovresti leggere questo articolo di Joel e guardare le sue Specifiche funzionali di esempio .

— Penang
fonte

Per un po ', stavo usando atleti e stelle del cinema nelle mie specifiche per cercare di renderli più facili da leggere. Avevo Brett Favre, Sachin Tendulkar e Aishwarya Rai, solo per citarne alcuni.

— jmort253,