Comment appelez-vous le client d'un client dans un document de spécification, un cas d'utilisation ou un scénario?

9

Mon équipe et moi développons un logiciel que nos clients utiliseront pour interagir avec leurs clients. De plus, nous mangeons également nos propres aliments pour chiens et utilisons nous-mêmes le logiciel pour interagir avec nos clients.

Par conséquent, il peut parfois être difficile d'expliquer des cas d'utilisation et des scénarios, car nos employés peuvent être des opérateurs, nos clients peuvent être des opérateurs et les clients de nos clients peuvent être des visiteurs.

Cependant, nos clients peuvent également être des visiteurs en interaction avec nos employés opérateurs, les clients de nos clients peuvent être des visiteurs en interaction avec notre client ou notre employé.

Voici un modèle où:

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

Parce que parfois nos clients peuvent jouer des rôles différents, il est parfois nécessaire de se référer au rôle spécifique, opérateur ou visiteur, au lieu d'employé et de client.

C'est aussi une bouchée de dire "client du client" tout le temps.

Je me demandais comment d'autres boutiques de développement géraient ces détails sémantiques lors de l'écriture de leurs cas d'utilisation et scénarios.

Existe-t-il des termes génériques d'un seul mot qui peuvent s'appliquer à tout produit impliquant un acteur de troisième niveau?
Outre l'utilisation des rôles spécifiques, Opérateur et Visiteur, quels mots pourraient être utilisés pour identifier un client d'un client?

Le mot devra être suffisamment court pour être adopté au sein d'une organisation. Si elle est plus longue que quelques syllabes, sa forme raccourcie doit tout de même la différencier des autres acteurs.

communication naming specifications

— jmort253
source

1

Il pense que vous regardez mal la relation. A est strictement un opérateur. C est strictement un visiteur. B se trouve être à la fois un opérateur et un visiteur. Le fait que B ait deux rôles ne change pas le fait que C est strictement un visiteur. Par conséquent, je ne vois pas l'intérêt de donner à C un identifiant unique.

— Pemdas

@Pemdas - Le problème est l'inverse. C est strictement un visiteur, mais un visiteur n'est pas toujours strictement C. De plus, tous les produits que nous développons n'ont pas d'opérateur et de visiteur. Celles-ci sont spécifiques à l'un des nombreux produits qui impliquent les clients et le long acteur «client d'un client». Ma question porte sur la manière de généraliser C en tant que «client d'un client» sans risquer de le raccourcir en «client» et de créer de la confusion.

— jmort253

2

Un client d'un client ne serait-il pas déclaré "Client ** C"? :-)

— GrandmasterB

@GrandmasterB - Alors mes parties prenantes pourraient être confuses et penser que je fais référence à B ou C alors qu'en fait je ne parle que de l'une d'entre elles.

— jmort253

Nous utilisons "ClientsCustomer" pour signaler le client du client ....

4

pour expliquer les cas d'utilisation et les scénarios

C'est la clé: utilisez la terminologie du domaine, c'est-à-dire les noms des rôles. Qui peut jouer les rôles n'est pas important. Assurez-vous que les rôles sont bien définis (pour chaque scénario).

Il est tout à fait possible pour moi de visiter mon propre site Web et d'acheter mes propres produits. C'est idiot, mais c'est possible [mais je l'ai fait pour tester le logiciel de commerce électronique!]. Ce fait que je suis le fournisseur, hôte, auteur, webmaster, concepteur - rédacteur, programmeur, client, client, visiteur, acheteur, invité, propriétaire et employé en même temps ne modifie pas la terminologie de l'utilisation cas: « client achète le produit du propriétaire via le formulaire Web "

— Steven A. Lowe
source

@Steven - Si je vous demandais "Que voit le client quand un message est reçu?" , Qui suis - je parle quand je dis « client » ? Est-ce que je fais référence à mon client, le représentant des ventes de commerce électronique recevant une question, ou est-ce que je fais référence à son client, le gars coincé dans le processus de paiement reçoit des instructions sur la façon d'entrer correctement un numéro de carte de crédit afin qu'il puisse acheter ses nouvelles camionnettes? Merci!

— jmort253

@ jmort253, simple: ne jamais utiliser le client mot. Acheteur et marchand.

— Peter Taylor

@Peter - Supposons que je veuille généraliser ces niveaux et les appliquer à d'autres produits. Peut-être que j'ai un employé administrateur, un client administrateur et un utilisateur final comme A, B et C. Existe-t-il une convention commune pour le "client d'un client" qui ne doit pas nécessairement être spécifique à mon produit mais qui pourrait également appliquer aux produits que vous construisez là où vous offrez des produits à vos clients pour les aider avec leurs clients. Je me sens comme ce problème devrait être assez commun dans les affaires sur les marchés d'affaires.

— jmort253

@ jmort253: abandonner le terme "client" ; il n'a aucune signification intrinsèque dans votre cas d'utilisation. Dans vos exemples ci-dessus, utilisez «client» (celui qui utilise vos services), «destinataire» (celui qui reçoit une question) ou «acheteur» (celui qui achète quelque chose)

— Steven A. Lowe

1

@ jmort253, le projet sur lequel je travaille en ce moment a des clients de clients de mon client. Le jargon du projet est que les clients de mon client sont appelés "abonnés" et leurs clients sont appelés "consommateurs". En utilisant la métaphore du marché d'Amazon, ils pourraient plutôt être des commerçants et des commerçants.

— Peter Taylor

7

Pour être clair, appelez votre client en tant que clients , puis les clients de vos clients en tant que clients . Ce sera plus clair, non?

Je vous recommande de renommer les termes et de personnaliser (un peu) votre progiciel pour chacun de vos clients en fonction de leurs préférences. Certains clients peuvent souhaiter appeler leurs clients clients ou utilisateurs.

De plus, la relation est un peu drôle. Comment votre employé peut-il interagir avec les clients des clients?

— mauris
source

Grande question. Nous développons un logiciel de chat que nos clients peuvent utiliser pour interagir avec leurs clients / clients potentiels, mais nous prenons également ces mêmes chats au nom de ces mêmes ... eh bien ... clients. Vous voyez la confusion? J'aime votre suggestion et j'ai essayé de pousser cette convention de dénomination auparavant. J'envisagerai de réessayer.

— jmort253

Si les clients de vos clients sont vos clients potentiels, ne devraient-ils pas déjà être désignés comme clients potentiels ou clients?

— mauris

Le / entre les clients et les clients potentiels devait représenter un ET / OU. "Nous développons des logiciels que nos clients peuvent utiliser pour interagir avec leurs clients ET / OU leurs clients potentiels." Les clients ou clients potentiels de nos clients ne sont pas nécessairement nos clients ou clients potentiels. Wow, je suppose que je ne savais pas à quel point c'était vraiment déroutant. Il suffit de taper pour clarifier semble compliqué. Les personnes avec

— lesquelles

essayant de faire descendre ceci sur l'expression logique = \

— mauris

3

La question devient donc plus simple lorsque l'on considère les rôles comme étant l'entité relative a joue un rôle par rapport à l'entité b. Votre client se considère comme un utilisateur et ses clients sont des clients pour lui. La seule personne qui se soucie de votre client en tant que client est vous. Vous avez deux rôles dans le système en tant qu'administrateur et en tant qu'utilisateur.

J'ai vu l'explication selon laquelle vous avez des employés qui interagissent avec les clients finaux via votre logiciel de chat (appelons ce rôle Agent). Pour plus de précision, l'agent se représente-t-il en tant qu'employé de votre utilisateur?

Je dirais que le rôle est toujours Agent, Utilisateur, Client. Faire référence à votre utilisateur en tant que client ne fait que confondre les choses. (Comme vous pouvez le voir).

Je l'ai eu pire ... J'ai dû travailler sur trois niveaux d'indirection. Il y avait une entité de la société qui, dans certains cas, était des utilisateurs directs de notre application. Ils avaient des comptes auxquels ils vendaient divers packages de nos offres et ils suivaient les clients pour ces comptes.

— Michael Brown
source

Je pense que c'est ça le problème. Mes ingénieurs et moi devons considérer deux rôles différents lors de la discussion du projet. Discutons-nous de notre rôle ou de leur rôle . Bien que notre rôle soit également Utilisateur, nous mangeons nos propres aliments pour chiens. Je commence à penser que j'y pense trop!

— jmort253

2

Peut-être un peu tangente mais ...

J'aime moi-même le design d'interaction, et là on n'utilise jamais de "rôles" ou d '"utilisateurs" abstraits mais quelque chose appelé "personas". Fondamentalement, vous créez un personnage avec un nom, une description et une photographie, puis vous l'utilisez dans votre processus de conception

"Bob est directeur de banque au milieu de son enfance, il a une certaine expérience en informatique mais ne les aime pas particulièrement."

Ensuite, dans votre projet, vous pouvez utiliser leurs vrais noms "Non, Bob ne le voudrait pas", "Si Bob le fait, Alice doit être notifiée d'une manière ou d'une autre". Les personas sont particulièrement utiles lorsque vous faites des scénarios.

Je recommande fortement Les détenus gèrent l'asile et About face

— Homde
source

Merci pour votre réponse! C'est une excellente suggestion. Je devrai me demander si cela pourrait s'appliquer à tous nos produits. Mon client et l'exemple de client du client devraient pouvoir être des acteurs dans tous nos systèmes pour que cela fonctionne. En d'autres termes, Bob devrait être un client de notre outil de création de widgets et également un client de notre produit foo et de notre produit bar, si cela est logique.

— jmort253

@jmort, ce n'est probablement pas comme ça que vous devriez utiliser les personnages. À moins que Bob ne soit vraiment la même personne qui achète à la fois l'outil de création de widgets et foo et bar, ils doivent être définis comme des personnages distincts. C'est leur but, vous créez des personnages différents pour des scénarios / applications / systèmes spécifiques et personnalisez la solution pour eux. Les noms de Persona ne sont pas seulement des synonymes de "l'utilisateur"

— Homde

Je suis favorable à cette approche, nous avons eu du mal à expliquer ce que nous faisons aux investisseurs et à nos clients immédiats. Nous avons fait jusqu'à Jamie et Dave comme fondateurs d'une société fictive et utiliser Jamie et Dave dans nos histoires, scribes vidéo, ce type de cas , etc. Beaucoup plus facile que les utilisateurs finaux de la clientèle du client etc.

— Dickey Singh

2

On m'a demandé de poster ce commentaire comme réponse, donc:

Le projet sur lequel je travaille en ce moment a des clients de clients de mon client. Le jargon du projet est que les clients de mon client sont appelés "abonnés" et leurs clients sont appelés "consommateurs". En utilisant la métaphore du marché d'Amazon, ils pourraient plutôt être des commerçants et des commerçants.

— Peter Taylor
source

0

L'opérateur et le visiteur semblent assez bien définis. Pas sûr qu'il y ait une différence quand un opérateur devient un visiteur ou un visiteur devient un visiteur. À ce stade, tout le monde est un visiteur.

— JeffO
source

0

En fonction de ce que le logiciel est censé faire, utilisez des personnages fictifs bien connus, par exemple, Dumbledore perd toujours des connaissances sur Harry (lui enseignant des choses qu'il ne savait pas auparavant et / ou répondant à ses questions). Utilisez des personnages qui correspondent à la culture de vos développeurs. Ensuite, vous pouvez vous y référer dans les cas d'utilisation en tant que tels: lorsque A est assis sur la chaise de Dumbledore ou lorsque B joue Harry.

Si vous pensez que cela rendrait vos spécifications informelles et manquent de professionnalisme, vous devriez lire cet article de Joel et consulter son exemple de spécifications fonctionnelles.

— Penang
source

Pendant un certain temps, j'utilisais des athlètes et des stars de cinéma dans mes spécifications pour essayer de les rendre plus lisibles. J'avais Brett Favre, Sachin Tendulkar et Aishwarya Rai, pour n'en nommer que quelques-uns.

— jmort253