Apa yang Anda sebut pelanggan pelanggan dalam dokumen spesifikasi, kasus penggunaan, atau skenario?

9

Saya dan tim saya mengembangkan perangkat lunak yang akan digunakan pelanggan untuk berinteraksi dengan pelanggan mereka. Selain itu, kami juga memakan makanan anjing kami sendiri dan menggunakan perangkat lunak itu sendiri untuk berinteraksi dengan pelanggan kami.

Oleh karena itu, terkadang sulit untuk menjelaskan kasus penggunaan dan skenario, karena karyawan kami dapat menjadi operator, pelanggan kami dapat menjadi operator, dan pelanggan pelanggan kami dapat menjadi pengunjung.

Namun, pelanggan kami juga dapat menjadi pengunjung yang berinteraksi dengan karyawan operator kami, pelanggan pelanggan kami dapat menjadi pengunjung yang berinteraksi dengan pelanggan kami atau karyawan kami.

Berikut adalah model di mana:

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

Karena kadang-kadang pelanggan kami dapat memainkan peran yang berbeda, kadang-kadang perlu untuk merujuk pada peran tertentu, Operator atau Pengunjung, bukan Karyawan dan Pelanggan.

Ini juga suap untuk mengatakan "pelanggan" sepanjang waktu.

Saya bertanya-tanya bagaimana toko pengembangan lain menangani detail semantik ini ketika menulis kasus penggunaan dan skenario mereka.

Adakah istilah generik satu kata yang dapat diterapkan untuk produk apa pun yang melibatkan aktor tingkat ketiga?
Selain menggunakan peran khusus, Operator dan Pengunjung, kata-kata apa yang dapat digunakan untuk mengidentifikasi pelanggan dari pelanggan?

Kata itu harus cukup pendek untuk diadopsi dalam suatu organisasi. Jika lebih dari satu suku kata, bentuknya yang lebih pendek masih harus membedakannya dari aktor lain.

communication naming specifications

— jmort253
sumber

1

Itu berpikir bahwa Anda melihat hubungan yang salah. A adalah sepenuhnya operator. C adalah pengunjung. B kebetulan adalah operator dan pengunjung. Fakta bahwa B memiliki dua peran tidak mengubah fakta bahwa C adalah pengunjung. Oleh karena itu, saya tidak melihat titik memberikan C pengidentifikasi unik.

— Pemdas

@Pemdas - Masalahnya adalah sebaliknya. C benar-benar pengunjung, tetapi pengunjung tidak selalu sepenuhnya C. Juga, tidak setiap produk yang kami kembangkan memiliki operator dan pengunjung. Itu khusus untuk salah satu dari banyak produk yang melibatkan pelanggan dan aktor "pelanggan pelanggan" yang panjang. Pertanyaan saya menyangkut bagaimana saya bisa menggeneralisasi C sebagai "pelanggan pelanggan" tanpa harus dipersingkat menjadi "pelanggan" dan menciptakan kebingungan.

— jmort253

2

Bukankah pelanggan dari pelanggan akan dinyatakan "Pelanggan ** C"? :-)

— GrandmasterB

@GrandmasterB - Kemudian para pemangku kepentingan saya mungkin bingung dan berpikir saya mengacu pada B atau C padahal sebenarnya saya hanya bermaksud salah satu dari mereka.

— jmort253

Kami menggunakan "ClientsCustomer" untuk menunjukkan pelanggan Pelanggan ....

4

untuk menjelaskan kasus penggunaan dan skenario

Itulah kuncinya: gunakan terminologi domain, yaitu nama-nama peran. Siapa yang bisa memainkan peran itu tidak penting. Pastikan perannya didefinisikan dengan baik (untuk setiap skenario).

Sangat mungkin bagi saya untuk mengunjungi situs web saya sendiri dan membeli produk saya sendiri. Itu konyol, tapi itu mungkin [tetapi saya sudah melakukannya untuk menguji perangkat lunak e-commerce!]. Fakta bahwa saya adalah penyedia, tuan rumah, penulis, webmaster, copywriter, programmer, klien, pelanggan, pembeli, tamu, pemilik, dan karyawan semuanya pada saat yang sama tidak mengubah terminologi use-case: "pelanggan membeli produk dari pemilik melalui formulir web "

— Steven A. Lowe
sumber

@ Seven - Jika saya bertanya kepada Anda "Apa yang dilihat pelanggan saat pesan diterima?" , siapa yang saya maksud ketika saya mengatakan "pelanggan" ? Saya maksudkan saya pelanggan, penjualan e-commerce rep menerima pertanyaan, atau aku mengacu padanya pelanggan, orang terjebak dalam proses checkout menerima petunjuk tentang cara untuk benar memasukkan nomor kartu kredit sehingga ia dapat membeli van barunya? Terima kasih!

— jmort253

@ jmort253, sederhana: tidak pernah menggunakan kata pelanggan. Pembeli dan pedagang.

— Peter Taylor

@ Peter - Misalkan saya ingin menggeneralisasi level-level ini dan menerapkannya pada produk lain. Mungkin saya memiliki Karyawan Admin, Klien Admin, dan pengguna akhir sebagai A, B, dan C. Apakah ada konvensi umum untuk "pelanggan pelanggan" yang tidak harus spesifik untuk hanya produk saya tetapi juga bisa berlaku untuk produk yang Anda bangun di mana Anda menawarkan produk kepada pelanggan Anda untuk membantu mereka dengan pelanggan mereka. Saya merasa masalah ini seharusnya cukup umum dalam bisnis ke pasar bisnis.

— jmort253

@ jmort253: lepaskan istilah "pelanggan" ; itu tidak memiliki makna intrinsik dalam kasus penggunaan Anda. Dalam contoh Anda di atas, gunakan "klien" (orang yang menggunakan layanan Anda), "penerima" (orang yang menerima pertanyaan), atau "pembeli" (orang yang membeli sesuatu)

— Steven A. Lowe

1

@ jmort253, proyek yang sedang saya kerjakan saat ini memiliki pelanggan pelanggan dari klien saya. Jargon proyek ini adalah bahwa pelanggan klien saya disebut "pelanggan" dan pelanggan mereka disebut "konsumen". Dengan menggunakan metafora pasar Amazon, mereka malah bisa menjadi penjaja dan pembeli.

— Peter Taylor

7

Untuk membuatnya jelas, panggil pelanggan Anda sebagai klien , lalu pelanggan pelanggan Anda sebagai pelanggan . Itu akan membuatnya lebih jelas bukan?

Saya sarankan Anda untuk mengubah nama persyaratan dan menyesuaikan paket perangkat lunak Anda (sedikit) untuk setiap pelanggan Anda tergantung pada preferensi mereka. Beberapa pelanggan mungkin ingin memanggil pelanggan atau pengguna mereka.

Relasinya juga agak lucu. Bagaimana karyawan Anda dapat berinteraksi dengan pelanggan pelanggan?

— mauris
sumber

Pertanyaan yang bagus Kami mengembangkan Perangkat Lunak Obrolan bagi pelanggan kami untuk digunakan untuk berinteraksi dengan pelanggan / pelanggan potensial mereka, tetapi kami juga mengambil obrolan yang sama atas nama pelanggan yang ... baik ... baik itu. Lihat kebingungannya? Saya suka saran Anda dan telah mencoba untuk mendorong konvensi penamaan itu sebelumnya. Saya akan mempertimbangkan mencobanya lagi.

— jmort253

Jika pelanggan Anda adalah pelanggan potensial Anda, bukankah seharusnya mereka sudah disebut sebagai pelanggan potensial atau pelanggan?

— mauris

/ Antara pelanggan dan pelanggan potensial dimaksudkan untuk mewakili suatu DAN / ATAU. "Kami mengembangkan perangkat lunak untuk digunakan pelanggan untuk berinteraksi dengan pelanggan mereka DAN / ATAU pelanggan potensial mereka." Pelanggan atau pelanggan potensial dari pelanggan kami belum tentu pelanggan kami atau pelanggan potensial. Wow, kurasa aku tidak menyadari betapa membingungkannya ini. Mengetiknya saja untuk menjelaskan terasa rumit. Orang-orang yang berinteraksi dengan operator kami dapat berupa pelanggan, pelanggan potensial, ATAU bukan pelanggan atau bukan pelanggan potensial, jika mereka adalah pelanggan kami

— jmort253

mencoba memahami ini dengan ekspresi logika = \

— mauris

3

Jadi pertanyaannya menjadi lebih sederhana ketika menganggap Peran sebagai entitas relatif a melakukan peran dalam kaitannya dengan entitas b. Pelanggan Anda menganggap diri mereka sebagai Pengguna dan Pelanggan mereka adalah Pelanggan untuk mereka. Satu-satunya orang yang peduli tentang Pelanggan Anda sebagai Pelanggan adalah Anda. Anda memiliki dua peran dalam sistem sebagai Administrator dan sebagai Pengguna.

Saya melihat penjelasan bahwa Anda memiliki Karyawan yang berinteraksi dengan Pelanggan Akhir melalui perangkat lunak obrolan Anda (sebut agen Agen ini). Untuk klarifikasi, apakah Agen mewakili dirinya sebagai karyawan Pengguna Anda?

Saya berpendapat bahwa perannya masih Agen, Pengguna, Pelanggan. Merujuk Pengguna Anda sebagai pelanggan hanya membingungkan hal-hal. (Seperti yang Anda lihat).

Aku sudah lebih buruk ... aku harus bekerja pada tiga tingkat tipuan. Ada entitas Perusahaan yang dalam beberapa kasus adalah Pengguna langsung aplikasi kami. Mereka memiliki Akun yang mereka jual berbagai paket dari penawaran kami dan mereka melacak Pelanggan untuk Akun tersebut.

— Michael Brown
sumber

Saya pikir itu masalahnya. Insinyur saya dan saya harus mempertimbangkan dua peran yang berbeda ketika membahas proyek. Apakah kita sedang mendiskusikan dari peran kita atau peran mereka . Meskipun, peran kami juga Pengguna saat kami makan makanan anjing kami sendiri. Saya mulai berpikir saya terlalu memikirkan ini!

— jmort253

2

Mungkin sedikit singgung tapi ...

Saya suka desain interaksi sendiri, dan di sana Anda tidak pernah menggunakan "peran" abstrak atau "pengguna" tetapi sesuatu yang disebut "personas". Pada dasarnya Anda membuat karakter dengan nama, deskripsi dan foto dan kemudian Anda menggunakannya dalam proses desain Anda

"Bob adalah manajer bank di tahun-tahun pertengahan, dia memiliki pengalaman komputer tetapi tidak terlalu menyukai mereka."

Kemudian dalam proyek Anda, Anda dapat menggunakan nama asli mereka "Tidak, Bob tidak akan mau itu", "Jika Bob melakukan ini maka Alice perlu diberitahu entah bagaimana". Persona sangat berguna saat Anda melakukan skenario.

Saya sangat merekomendasikan para tahanan menjalankan suaka dan Tentang wajah

— Homde
sumber

Terimakasih atas tanggapan Anda! Ini saran yang bagus. Saya harus memikirkan apakah itu bisa berlaku untuk semua produk kami. Pelanggan saya dan pelanggan pelanggan contoh orang harus bisa menjadi aktor dalam semua sistem kami untuk itu untuk bekerja. Dengan kata lain, Bob harus menjadi pelanggan alat pembuat widget kami dan juga menjadi pelanggan produk foo dan produk bar kami, jika itu masuk akal.

— jmort253

@ jmort, mungkin itu bukan cara Anda menggunakan persona. Kecuali Bob benar-benar orang yang sama yang akan membeli alat pembuat widget dan foo and bar, mereka harus didefinisikan sebagai persona yang terpisah .. itulah intinya, Anda membangun persona yang berbeda untuk skenario / aplikasi / sistem tertentu dan menyesuaikan solusi untuk mereka. Nama Persona bukan hanya sinonim untuk "pengguna"

— Homde

Saya menyukai pendekatan ini, kami kesulitan menjelaskan apa yang kami lakukan kepada investor dan pelanggan langsung kami. Kami menjadikan Jamie dan Dave sebagai pendiri perusahaan fiktif dan menggunakan Jamie dan Dave dalam kisah kami, juru video, menggunakan kasing, dll. Jauh lebih mudah bagi pelanggan akhir pelanggan pelanggan, dll.

— Dickey Singh

2

Saya diminta memposting komentar ini sebagai jawaban, jadi:

Proyek yang saya kerjakan saat ini memiliki pelanggan pelanggan klien saya. Jargon proyek ini adalah bahwa pelanggan klien saya disebut "pelanggan" dan pelanggan mereka disebut "konsumen". Dengan menggunakan metafora pasar Amazon, mereka malah bisa menjadi penjaja dan pembeli.

— Peter Taylor
sumber

0

Operator dan Pengunjung tampaknya didefinisikan dengan cukup baik. Tidak yakin ada perbedaan ketika operator menjadi Pengunjung atau Pengunjung menjadi Pengunjung. Pada saat itu, semua orang adalah Pengunjung.

— JeffO
sumber

0

Bergantung pada apa yang dimaksudkan perangkat lunak untuk menggunakan karakter fiktif terkenal misalnya Dumbledore selalu memberikan pengetahuan tentang Harry (mengajarinya hal-hal yang tidak dia ketahui sebelumnya dan / atau menjawab pertanyaannya). Gunakan karakter yang sesuai dengan budaya pengembang Anda. Maka Anda dapat merujuk mereka dalam kasus penggunaan seperti: ketika A duduk di kursi Dumbledore atau ketika B sedang bermain Harry.

Jika Anda berpikir ini akan membuat spesifikasi Anda menjadi informal dan kurang profesional, Anda harus membaca artikel ini oleh Joel dan melihat contoh Spesifikasi Fungsional miliknya .

— Penang
sumber

Untuk sementara, saya menggunakan atlet dan bintang film dalam spesifikasi saya untuk mencoba dan membuatnya lebih mudah dibaca. Aku punya Brett Favre, Sachin Tendulkar, dan Aishwarya Rai, hanya untuk beberapa nama.

— jmort253