¿Cómo se llama al cliente de un cliente en un documento de especificación, caso de uso o escenario?

9

Mi equipo y yo desarrollamos software que nuestros clientes usarán para interactuar con sus clientes. Además, también comemos nuestro propio alimento para perros y usamos el software nosotros mismos para interactuar con nuestros clientes.

Por lo tanto, a veces puede ser difícil explicar los casos y escenarios de uso, ya que nuestros empleados pueden ser operadores, nuestros clientes pueden ser operadores y los clientes de nuestros clientes pueden ser visitantes.

Sin embargo, nuestros clientes también pueden ser visitantes que interactúan con nuestros empleados operadores, los clientes de nuestros clientes pueden ser visitantes que interactúan con nuestro cliente o nuestro empleado.

Aquí hay un modelo donde:

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

Debido a que a veces nuestros clientes pueden desempeñar diferentes roles, a veces es necesario referirse al rol específico, Operador o Visitante, en lugar de Empleado y Cliente.

También es un bocado decir "cliente del cliente" todo el tiempo.

Me preguntaba cómo otras tiendas de desarrollo manejan estos detalles semánticos cuando escriben sus casos de uso y escenarios.

¿Hay algún término genérico de una palabra que pueda aplicarse a cualquier producto que involucre a un actor de tercer nivel?
Además de usar los roles específicos, Operador y Visitante, ¿qué palabras podrían usarse para identificar a un cliente de un cliente?

La palabra debería ser lo suficientemente corta como para ser adoptada dentro de una organización. Si es más larga que un par de sílabas, su forma abreviada aún debe diferenciarla de los otros actores.

communication naming specifications

— jmort253
fuente

1

Piensa que estás mirando mal la relación. A es estrictamente un operador. C es estrictamente un visitante. B resulta ser tanto un operador como un visitante. El hecho de que B tenga dos roles no cambia el hecho de que C es estrictamente un visitante. Por lo tanto, no veo el punto de darle a C un identificador único.

— Pemdas

@Pemdas: el problema es al revés. C es estrictamente un visitante, pero un visitante no siempre es estrictamente C. Además, no todos los productos que desarrollamos tienen un operador y un visitante. Esos son específicos de uno de los muchos productos que involucran a los clientes y al prolongado actor "cliente de un cliente". Mi pregunta implica cómo puedo generalizar a C como "cliente de un cliente" sin estar en peligro de acortarlo a solo "cliente" y crear confusión.

— jmort253

2

¿No se declararía el cliente de un cliente "Cliente ** C"? :-)

— GrandmasterB

@GrandmasterB: entonces mis partes interesadas pueden confundirse y pensar que me estoy refiriendo a B o C cuando en realidad solo me refiero a uno de ellos.

— jmort253

Utilizamos "ClientsCustomer" para señalar al cliente del Cliente ...

4

para explicar casos de uso y escenarios

Esa es la clave: usar la terminología del dominio, es decir, los nombres de los roles. Quién puede desempeñar los roles no es importante. Asegúrese de que los roles estén bien definidos (para cada escenario).

Es totalmente posible para mí visitar mi propio sitio web y comprar mis propios productos. Es una tontería, pero es posible [¡pero lo he hecho para probar el software de comercio electrónico!]. El hecho de que yo sea el proveedor, anfitrión, autor, webmaster, redactor, programador, cliente, cliente, visitante, comprador, invitado, propietario y empleado al mismo tiempo no altera la terminología del caso de uso: "cliente compra el producto del propietario a través del formulario web "

— Steven A. Lowe
fuente

@ Steven - Si tuviera que preguntarle "¿Qué ve el cliente cuando recibe un mensaje?" ¿A quién me refiero cuando digo "cliente" ? ¿Me estoy refiriendo a mi cliente, el representante de ventas de comercio electrónico está recibiendo una pregunta, o me estoy refiriendo a su cliente, el sujeto atrapado en el proceso de pago recibiendo instrucciones sobre cómo ingresar correctamente un número de tarjeta de crédito para que pueda comprar sus nuevas furgonetas? ¡Gracias!

— jmort253

@ jmort253, simple: nunca use la palabra cliente. Comprador y comerciante.

— Peter Taylor

@Peter: supongamos que quiero generalizar estos niveles y aplicarlos a otros productos. Tal vez tengo un empleado administrativo, un cliente administrador y un usuario final como A, B y C. ¿Existe una convención común para el "cliente de un cliente" que no tiene que ser específica solo para mi producto sino que también podría aplique a los productos que está creando donde ofrece productos a sus clientes para ayudarlos con sus clientes. Siento que este problema debería ser bastante común en los mercados de empresa a empresa.

— jmort253

@ jmort253: deje ir el término "cliente" ; no tiene un significado intrínseco en su caso de uso. En sus ejemplos anteriores, use "cliente" (uno que usa sus servicios), "destinatario" (uno que recibe una pregunta) o "comprador" (uno que compra algo)

— Steven A. Lowe

1

@ jmort253, el proyecto en el que estoy trabajando en este momento tiene clientes de clientes de mi cliente. La jerga del proyecto es que los clientes de mi cliente se llaman "suscriptores" y sus clientes se llaman "consumidores". Utilizando la metáfora del mercado de Amazon, podrían ser vendedores y compradores.

— Peter Taylor

7

Para que quede claro, llame a su cliente como clientes , luego los clientes de su cliente como clientes . Eso lo hará más claro, ¿no?

Le recomiendo cambiar el nombre de los términos y personalizar su paquete de software (un poco) para cada uno de sus clientes, según sus preferencias. Algunos clientes pueden querer llamar a sus clientes clientes o usuarios.

También la relación es un poco divertida. ¿Cómo puede interactuar su empleado con los clientes del cliente?

— mauris
fuente

Gran pregunta Desarrollamos software de chat para que nuestros clientes lo utilicen para interactuar con sus clientes / clientes potenciales, pero también tomamos esos mismos chats en nombre de esos mismos ... bueno ... clientes. ¿Ves la confusión? Me gusta su sugerencia y he tratado de impulsar esa convención de nombres antes. Consideraré intentarlo de nuevo.

— jmort253

Si los clientes de su cliente son sus clientes potenciales, ¿no deberían ser nombrados como clientes potenciales o clientes ya?

— mauris

El / entre clientes y clientes potenciales estaba destinado a representar un AND / OR. "Desarrollamos software para que nuestros clientes lo utilicen para interactuar con sus clientes Y / O sus clientes potenciales". Los clientes o clientes potenciales de nuestro cliente no son necesariamente nuestros clientes o clientes potenciales. Wow, supongo que no me di cuenta de lo confuso que es esto realmente. Simplemente escribirlo para aclarar se siente complicado. La gente nuestros operadores interactuar con los clientes, podrían ser clientes potenciales, o no clientes o no clientes potenciales, si son clientes de nuestro cliente

— jmort253

tratando de entender esto en la expresión lógica = \

— mauris

3

Entonces, la pregunta se vuelve más simple cuando se piensa en Roles como una entidad relativa a que desempeña un rol en relación con la entidad b. Su Cliente se considera un Usuario y sus Clientes son Clientes para ellos. La única persona que se preocupa por su Cliente como Cliente es usted. Tiene dos roles en el sistema como administrador y como usuario.

Vi la explicación de que tiene empleados que interactúan con los clientes finales a través de su software de chat (llamemos a este rol Agente). Para aclarar, ¿se representa el Agente como un empleado de su Usuario?

Yo diría que el rol sigue siendo Agente, Usuario, Cliente. Referirse a su Usuario como cliente simplemente confunde las cosas. (Como puedes ver).

Lo he tenido peor ... Tuve que trabajar en tres niveles de indirección. Había una entidad de la Compañía que en algunos casos eran Usuarios directos de nuestra aplicación. Tenían cuentas a las que vendieron varios paquetes de nuestras ofertas y rastrearon a los clientes para esas cuentas.

— Michael Brown
fuente

Creo que ese es el problema. Mis ingenieros y yo tenemos que considerar dos roles diferentes al discutir el proyecto. ¿Estamos discutiendo desde el papel de nosotros o el papel de ellos ? Aunque, nuestro papel también es Usuario, ya que comemos nuestro propio alimento para perros. ¡Estoy empezando a pensar que estoy pensando demasiado en esto!

— jmort253

2

Tal vez un poco tangente pero ...

A mí también me gusta el diseño de interacción, y allí nunca usas "roles" o "usuarios" abstractos, sino algo que se llama "personas". Básicamente, inventas un personaje con un nombre, descripción y fotografía y luego lo usas en tu proceso de diseño

"Bob es gerente de banco en sus años intermedios, tiene algo de experiencia en informática pero no le gusta especialmente".

Luego, en su proyecto, puede usar sus nombres reales "No, Bob no querría eso", "Si Bob hace esto, entonces Alice debe ser notificada de alguna manera". Las personas son especialmente útiles cuando estás haciendo escenarios.

Recomiendo encarecidamente que los reclusos estén dirigiendo el asilo y sobre la cara

— Homde
fuente

¡Gracias por su respuesta! Esta es una gran sugerencia. Tendré que pensar si podría aplicarse o no a todos nuestros productos. Mi cliente y el ejemplo del cliente del cliente las personas tendrían que ser capaces de ser actores en todos nuestros sistemas para que eso funcione. En otras palabras, Bob tendría que ser cliente de nuestra herramienta de creación de widgets y también ser cliente de nuestro producto foo y producto de barra, si eso tiene sentido.

— jmort253

@jmort, probablemente no es así como debes usar los personajes. A menos que Bob realmente sea la misma persona que compraría tanto la herramienta de creación de widgets como foo y bar, deberían definirse como personajes separados ... ese es el punto de ellos, usted construye diferentes personajes para escenarios / aplicaciones / sistemas específicos y adapta la solución para ellos. Los nombres de las personas no son solo sinónimos de "el usuario"

— Homde

Estoy a favor de este enfoque, nos costó explicar lo que hacemos a los inversores y a nuestros clientes inmediatos. Hicimos Jamie y Dave como fundadores de una empresa ficticia y el uso de Jamie y Dave en nuestras historias, escribas vídeo, etc. usos casos mucho más fácil que los usuarios finales del cliente del cliente, etc.

— Dickey Singh

2

Me pidieron que publicara este comentario como respuesta, así que:

El proyecto en el que estoy trabajando actualmente tiene clientes de clientes de mi cliente. La jerga del proyecto es que los clientes de mi cliente se llaman "suscriptores" y sus clientes se llaman "consumidores". Utilizando la metáfora del mercado de Amazon, podrían ser vendedores y compradores.

— Peter Taylor
fuente

0

Operador y Visitante parecen bastante bien definidos. No estoy seguro de que haya una diferencia cuando un operador se convierte en un visitante o un visitante se convierte en un visitante. En ese punto, todos son visitantes.

— JeffO
fuente

0

Dependiendo de lo que el software está destinado a hacer, use personajes ficticios bien conocidos, por ejemplo, Dumbledore siempre está dejando caer el conocimiento sobre Harry (enseñándole cosas que no sabía antes y / o respondiendo sus preguntas). Utiliza personajes que encajen con la cultura de tus desarrolladores. Luego puede referirse a ellos en casos de uso como tales: cuando A está sentado en la silla de Dumbledore o cuando B está jugando a Harry.

Si cree que esto haría que sus especificaciones fueran informales y carecieran de profesionalismo, debería leer este artículo de Joel y mirar las especificaciones funcionales de muestra de él .

— Penang
fuente

Por un tiempo, estaba usando atletas y estrellas de cine en mis especificaciones para tratar de hacerlos más fáciles de leer. Tenía a Brett Favre, Sachin Tendulkar y Aishwarya Rai, solo por nombrar algunos.

— jmort253