Як ви називаєте клієнта клієнта у специфікаційному документі, регістрі використання чи сценарії?


10

Я та моя команда розробляємо програмне забезпечення, яке наші клієнти використовуватимуть для взаємодії зі своїми клієнтами. Крім того, ми також їмо власні корми та використовуємо програмне забезпечення для взаємодії з нашими клієнтами.

Тому іноді може бути важко пояснити випадки використання та сценарії використання, оскільки наші працівники можуть бути операторами, наші клієнти можуть бути операторами, а клієнти наших клієнтів можуть бути відвідувачами.

Однак нашими замовниками також можуть бути відвідувачі, що взаємодіють із нашими операторами, замовниками наших клієнтів можуть бути відвідувачі, що взаємодіють із нашим замовником чи нашим співробітником.

Ось модель, де:

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

Оскільки іноді наші клієнти можуть грати різні ролі, іноді потрібно звернутися до конкретної ролі, Оператора чи Відвідувача, а не працівника та Замовника.

Це також приємно весь час говорити "замовник клієнта".

Мені було цікаво, як інші майстерні розвитку обробляють ці смислові деталі, коли пишуть випадки їх використання та сценарії.

  • Чи є однословні, загальні терміни, які можуть застосовуватися до будь-якого продукту, що включає актора третього рівня?
  • Окрім використання конкретних ролей, Оператора та Відвідувача, які слова можна використати для ідентифікації клієнта клієнта?

Це слово повинно бути досить коротким, щоб бути прийнятим в організації. Якщо довше пари складів, скорочена форма повинна все-таки відрізняти її від інших суб'єктів.


1
Це здається, що ви неправильно дивитесь на відносини. A - це суворо оператор. С - строго відвідувач. B, буває, є і оператором, і відвідувачем. Те, що B має дві ролі, не змінює того факту, що C - строго відвідувач. Тому я не бачу сенсу надавати С унікальний ідентифікатор.
Pemdas

@Pemdas - проблема навпаки. C - це суто відвідувач, але відвідувач не завжди є строго C. Також не кожен продукт, який ми розробляємо, має оператора та відвідувача. Вони характерні для одного з багатьох продуктів, що стосуються клієнтів та тривалого актора "клієнт замовника". Моє запитання стосується того, як я можу узагальнити C як "клієнта замовника", не загрожуючи скороченням його до просто "замовника" та створення плутанини.
jmort253

2
Чи не вдалося б клієнтові замовника оголосити "Клієнт ** С"? :-)
GrandmasterB

@GrandmasterB - Тоді мої зацікавлені сторони можуть заплутатися і подумають, що я маю на увазі B або C, якщо я маю на увазі лише один з них.
jmort253

Ми використовуємо "ClientsCustomer", щоб вказати на клієнта Замовника ....

Відповіді:


5
пояснити випадки використання та сценарії використання

Ось і головне: використовуйте термінологію домену, тобто назви ролей. Хто може грати ролі, не важливо. Переконайтесь, що ролі чітко визначені (для кожного сценарію).

Мені цілком можливо відвідати власний веб-сайт та придбати власну продукцію. Це нерозумно, але це можливо [але я це зробив для тестування програмного забезпечення для електронної комерції!]. Той факт, що я є провайдером, хостом, автором, веб-майстром, копірайтером, програмістом, клієнтом, клієнтом, відвідувачем, покупцем, гостем, власником та службовцем, все одно не змінює термінологію випадку використання: "замовник купує товар у власника через веб-форму "


@Steven - Якби я запитав у вас "Що бачить клієнт, коли отримує повідомлення?" , до кого я маю на увазі, коли кажу "клієнт" ? Я маю на увазі свого клієнта, представника з продажу електронної комерції, який отримує запитання, або я маю на увазі її клієнта, хлопець, який застряг у процесі оформлення каси, отримуючи інструкції, як правильно ввести номер кредитної картки, щоб він міг придбати свої нові мікроавтобуси? Дякую!
jmort253

@ jmort253, простий: ніколи не використовуйте слово клієнт. Покупець і торговець.
Пітер Тейлор

@ Петер - Припустимо, я хочу узагальнити ці рівні та застосувати їх до інших продуктів. Можливо, у мене є працівник адміністратора, клієнт адміністратора та кінцевий користувач як A, B, C. Чи існує загальна умова для "замовника клієнта", яка не повинна бути специфічною лише для мого продукту, але може також застосовуватись до продуктів, які ви будуєте, де ви пропонуєте продукцію своїм клієнтам, щоб допомогти їм у замовленні. Я вважаю, що ця проблема повинна бути досить поширеною у бізнесі та на ринках бізнесу.
jmort253

@ jmort253: відпустити термін "клієнт" ; це не має внутрішнього значення у вашому випадку використання. У наведених вище прикладах використовуйте "клієнт" (той, хто користується вашими послугами), "одержувач" (той, хто отримує запитання) або "покупець" (той, хто щось купує)
Стівен А. Лоу

1
@ jmort253, проект, над яким я працюю на даний момент, має клієнтів клієнтів мого клієнта. Жаргоном проекту є те, що замовників мого клієнта називають "абонентами", а їх замовників називають "споживачами". Використовуючи метафору ринку Amazon, вони замість цього можуть бути власниками торговців та покупцями.
Пітер Тейлор

8

Щоб зрозуміти, зателефонуйте своєму клієнту як клієнтам , а потім клієнтам як клієнтам . Це зробить зрозумілішим чи не так?

Рекомендую вам перейменувати умови та трохи налаштувати пакет програмного забезпечення для кожного свого клієнта залежно від його переваг. Деякі клієнти можуть захотіти зателефонувати своїм клієнтам або користувачам.

Також стосунки трохи смішні. Як ваш працівник може взаємодіяти з клієнтами клієнта?


Чудове запитання. Ми розробляємо Програмне забезпечення для чатів для наших клієнтів, щоб використовувати для взаємодії зі своїми клієнтами / потенційними клієнтами, але ми також приймаємо ті самі чати від імені тих самих ... ну ... клієнтів. Бачите плутанину? Мені подобається ваша пропозиція і раніше я намагався просунути цю угоду про іменування. Я буду розглядати спробу ще раз.
jmort253

Якщо клієнтами вашого клієнта є ваші потенційні клієнти, чи не слід їх називати вже потенційними клієнтами чи клієнтами?
mauris

/ Між клієнтами та потенційними клієнтами мали означати І / АБО. "Ми розробляємо програмне забезпечення для наших клієнтів, щоб використовувати для взаємодії зі своїми клієнтами І / АБО їх потенційними клієнтами." Замовники або потенційні клієнти нашого замовника не обов'язково є нашими клієнтами або потенційними замовниками. Нічого собі, я думаю, я не усвідомлював, наскільки насправді це заплутано. Просто ввести його, щоб уточнити, відчувається складно. Люди, з якими взаємодіють наші оператори, можуть бути клієнтами, потенційними клієнтами, АБО не клієнтами чи не потенційними клієнтами, якщо вони є клієнтами нашого замовника
jmort253

намагаючись
звести

3

Тож питання стає простішим, коли думка про Ролі як про відносну сутність а виконує роль стосовно сутності b. Ваш Клієнт вважає себе Користувачем, а їх Клієнт - Клієнтами для них. Єдина людина, яка піклується про Вашого Клієнта як Клієнта - це Ви. Ви маєте дві ролі в системі як адміністратор і як користувач.

Я побачив пояснення того, що у вас є працівники, які взаємодіють із кінцевими клієнтами через ваше чатове програмне забезпечення (назвемо цю роль агентом). Для уточнення, чи Агент представляє себе працівником Вашого Користувача?

Я б заперечував, що роль як і раніше Агент, Користувач, Замовник. Звернення до Вашого Користувача як до клієнта просто плутає речі. (Як ти бачиш).

У мене було гірше ... Мені довелося працювати на трьох рівнях непрямості. Була компанія, яка в деяких випадках була безпосереднім Користувачем нашої програми. У них були облікові записи, на які вони продавали різні пакети з наших пропозицій, і вони відстежували Клієнтів цих облікових записів.


Я думаю, що це проблема. Ми з моїми інженерами повинні розглядати дві різні ролі, коли обговорюємо проект. Чи обговорюємо ми з ролі нас чи ролі їх . Хоча, наша роль також є Користувачем, оскільки ми їмо власні собачі продукти. Я починаю думати, що перемагаю це!
jmort253

2

Можливо, трохи дотичної, але ...

Я сам захоплююся дизайном взаємодії, і там ти ніколи не використовуєш абстрактних "ролей" або "користувачів", а щось, що називається "персонами". В основному ви складаєте персонажа з іменем, описом та фотографією, а потім використовуєте це в процесі дизайну

"Боб - менеджер банку в середні роки, він має певний досвід роботи з комп'ютером, але особливо не любить їх".

Тоді у своєму проекті ви можете використовувати їх справжні імена "Ні, Боб не хотів би цього", "Якщо Боб це робить, то Алісі потрібно якось повідомити". Персони особливо корисні, коли ви робите сценарії.

Я настійно рекомендую Ув'язненим керувати притулком та про особу


Дякую за Вашу відповідь! Це чудова пропозиція. Мені доведеться подумати про те, чи може це стосуватися всіх наших продуктів. Приклад мого замовника та замовника, люди повинні мати можливість бути акторами у всіх наших системах, щоб це працювало. Іншими словами, Боб повинен був бути замовником нашого інструменту для створення віджетів, а також бути замовником нашого продукту Foo та бару, якщо це має сенс.
jmort253

@jmort, це, мабуть, не так, як ви повинні використовувати персони. Якщо Боб насправді не є тією самою людиною, яка придбала б інструмент для створення віджетів та foo та смугу, їх слід визначити як окремі персони. У цьому суть, ви будуєте різні персони для конкретних сценаріїв / застосувань / систем та адаптуєте рішення для них. Імена персонажів не є просто синонімами "користувача"
Homde,

Я підтримую такий підхід, нам було важко пояснити, що ми робимо для інвесторів та наших безпосередніх клієнтів. Ми створили Джеймі та Дейва як засновників вигаданої компанії і використовуємо Джеймі та Дейва в наших історіях, відеоскриптах, використанні справ тощо. Набагато простіше, ніж кінцеві користувачі замовника клієнта тощо
Dickey Singh

2

Мене попросили опублікувати цей коментар як відповідь, так:

У проекті, над яким я зараз працюю, є клієнти клієнтів мого клієнта. Жаргоном проекту є те, що замовників мого клієнта називають "абонентами", а їх замовників називають "споживачами". Використовуючи метафору ринку Amazon, вони замість цього можуть бути власниками торговців та покупцями.


0

Оператор і відвідувач здаються досить чітко визначеними. Не впевнений, що є різниця, коли оператор стає відвідувачем або відвідувач стає відвідувачем. У цей момент всі відвідувачі.


0

Залежно від того, що програмне забезпечення призначене для використання добре відомих вигаданих персонажів, наприклад, Дамблдор завжди скидає знання про Гаррі (навчаючи його речам, яких він раніше не знав та / або відповідаючи на його запитання). Використовуйте символи, які відповідають культурі ваших розробників. Тоді ви можете посилатися на них у випадках використання як таких: коли А сидить у кріслі Дамблдора або коли Б грає Гаррі.

Якщо ви думаєте, що це зробить ваші технічні характеристики неформальними та не вистачає професіоналізму, вам слід прочитати цю статтю Джоеля і подивитися його зразок функціональних специфікацій.


Я деякий час використовував спортсменів та зірок кіно у своїх специфікаціях, щоб спробувати полегшити їх читання. У мене були Бретт Фавр, Сахін Тендулкар та Айшварія Рай, лише декілька.
jmort253
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.