Kesalahan Umum dalam Komunikasi Klien

Selamat pagi sobat blogger kali ini saya akan share Kesalahan Umum dalam Komunikasi Klien: Bagaimana Tidak Frustrasi Klien Anda.

Ketika seseorang meminta sebuah proyek, kita harus berasumsi bahwa ini sangat penting dan mereka sangat peduli dengan produk yang akan Anda kerjakan. Jadi, aman untuk mengasumsikan bahwa klien terikat untuk membangun banyak harapan seputar produk akhir, dan karena itu mungkin menjadi emosional dalam hal pengiriman.

Sepanjang jalannya proyek, seorang klien mungkin merasa sangat gembira dengan fitur yang disampaikan dan mencintaimu, dan keesokan harinya dia dapat menemukan sesuatu tidak berhasil dan kasih sayang itu akan hilang. Lebih sering daripada tidak, itu hanya masalah komunikasi klien yang tidak beres.

Meskipun tidak ada resep keberhasilan saat menyangkut pengembangan perangkat lunak jarak jauh, saya yakin ada beberapa hal yang harus dihindari untuk menjaga hubungan yang sehat dan produktif dengan klien yang menaruh kepercayaan pada tangan Anda.

Jangan Gagal Komunikasi Dasar dengan Klien
Bayangkan komunikasi dengan klien seperti yang Anda lakukan setiap hari berkomunikasi dengan rekan kerja, teman, atau orang lain yang akan Anda hormati.

Jika seorang teman lama berkunjung ke rumah dan Anda setuju untuk menikmati kelezatan lokal "di tempat lama Anda" pada siang hari, beberapa minggu kemudian, maukah Anda muncul di sana? Maukah Anda tetap berhubungan sementara ini, menelepon untuk mengkonfirmasi beberapa hari sebelumnya? Atau mungkin Anda menganggap mereka terlalu sibuk dan tidak ingin mengganggu mereka tanpa alasan yang bagus? Apakah Anda mengharapkan mereka memberi tahu Anda kapan mereka tiba?

Anda tidak mungkin terus mengobrol setiap hari kecuali jika Anda memiliki banyak hal untuk dibicarakan, namun Anda akan mempertahankan beberapa bentuk komunikasi, sebagai masalah sopan santun dan kepraktisan: Anda tidak ingin orang lain berpikir bahwa Anda melupakannya. , tapi Anda pasti tidak ingin mengemudi setengah jalan melintasi kota tanpa alasan yang bagus.

Pada titik tertentu, Anda mungkin juga mengalami situasi serupa dalam komunikasi profesional Anda, bahkan dengan rekan kerja dan rekan kerja lama. Beberapa proyek dieksekusi dengan komunikasi minimal, seperti mengatakan "biasa, siang hari, sampai jumpa di sana" untuk mengkonfirmasi makan siang ringan. Bahkan jika ada sesuatu yang muncul, pihak lain pasti akan memberi tahu Anda, dan Anda akan setuju untuk menjadwal ulang.

Namun, hal-hal yang tidak sesederhana atau linier dalam dunia pengembangan perangkat lunak.

Jika Anda mulai mengerjakan sebuah proyek, terutama saat Anda menghadapi klien baru, jika mereka tidak pernah mendengar kabar dari Anda, mereka akan mulai memikirkan kedua gagasan tentang pekerjaan dan komitmen Anda. Bahkan jika Anda muncul dengan produk tanpa cela setelah beberapa minggu, klien mungkin sudah memiliki persepsi yang kurang ideal tentang Anda.

Meskipun terkadang hal itu pasti terasa canggung, tidak ada salahnya berbicara dengan klien meski Anda tidak mempunyai sesuatu yang biasa untuk dilaporkan! Apakah Anda memiliki keraguan tentang satu hal kecil dari sebuah cerita pengguna? Jika Anda pikir itu penting, beri tahu mereka. Anda agak terlambat dan tidak yakin apakah Anda bisa memenuhi perkiraan tanggal yang Anda setujui? Hubungi klien secepatnya! Lebih baik mereka mendengarnya segera.

Anda tidak memiliki keraguan dan proyek ini sesuai jadwal, tapi kliennya tidak banyak bicara? Mengapa tidak hanya mengirim email yang menjelaskan kemajuan Anda setiap beberapa hari? Ini tidak akan membahayakan karena email tidak akan menjadi gangguan bagi siapapun, ditambah lagi Anda akan mendokumentasikan kemajuan Anda dan menjaga komunikasi reguler dengan klien.

Komunikasi Klien yang Cacat Memupuk Harapan yang Tidak Realistis
Jadi, pada awalnya, saya menyebutkan bahwa klien pasti punya banyak harapan mengenai proyek tersebut, bukan? Kanan. Periode.

Klien sudah berharap banyak dari produk. Jika tidak berjalan seperti yang mereka bayangkan, klien pasti akan merasa frustrasi. Jadi, mengapa ada yang menjanjikan lebih dari yang bisa mereka berikan, sehingga menciptakan harapan yang lebih tidak realistis?

Berikut adalah paralel yang cepat: Anda membeli tablet secara online dan dijanjikan pengiriman 10 hari. Pada hari ke 8, toko tersebut memberitahu Anda bahwa ada masalah dan penundaan pengiriman seminggu. Untuk mengimbangi ketidaknyamanan Anda, janji pengecer memberi Anda kredit senilai $ 75.

Anda mungkin tidak terlalu membutuhkan tablet itu untuk beberapa hari ke depan, jadi Anda pikir ini bagus! Kini Anda bisa menikmati tablet ini, plus menggunakan kredit toko untuk membeli sesuatu yang bagus untuk anak-anak Anda. Tapi tokonya menelepon keesokan harinya, mengatakan semuanya beres semalam.

Anda akan mendapatkan tablet keesokan harinya. Tidak ada tambahan, tidak ada kredit toko. Sekarang kau yang frustrasi!

"Apa? Baru kemarin kau bilang aku akan mendapatkan kesepakatan yang lebih baik! Itu tidak adil! Saya sudah mengatakan kepada anak-anak ... "

Rewind beberapa hari dan yang Anda harapkan hanyalah tablet. Seandainya tidak ada yang menjanjikan kesepakatan yang lebih baik, Anda pasti senang dengan mainan Anda saat tiba keesokan harinya. Tapi sekarang, Anda merasa kehilangan karena alasan yang tidak masuk akal, selain keputusan toko untuk memberi tahu Anda.

Dengan tidak menjadi gila dan mengatakan segala sesuatu yang terlintas dalam pikiran Anda di tempat pertama. Saran tidak dilarang; Sebenarnya, mereka sangat menyambut jika Anda berpikir bahwa fitur permintaan tertentu bukanlah pilihan yang sangat bagus untuk memecahkan masalah yang dihadapi. Tapi kuncinya adalah: Pikirkan dulu.
  • Dengarkan kliennya.
  • Menganalisis masalah mereka.
  • Analisis solusi yang diusulkan.
  • Pastikan itu sesuai anggaran / jadwal.
  • Akhirnya, teruskan dan sampaikan saran Anda.

Inilah sebabnya mengapa keterampilan komunikasi klien bisa menjadi rumit, karena gagal pada satu dari empat langkah pertama berarti Anda bisa menghabiskan waktu Anda dan lebih buruk lagi, waktu klien Anda.

Jangan Asumsikan Anda Tahu Apa Kebutuhan Klien

Jika Anda dipanggil untuk sebuah proyek, itu karena seseorang membutuhkan sesuatu. Dan siapa yang tahu lebih baik tentang kebutuhan itu daripada klien Anda? Ini mungkin tampak jelas, tapi kadang-kadang, di dunia nyata, orang melupakannya.

Izinkan saya memberi contoh. Seorang pengecer meminta "sistem perangkat lunak" untuk bisnisnya. Begitu Anda melihatnya, Anda langsung menyimpulkan bahwa yang mereka inginkan adalah sesuatu untuk mendaftarkan semua produk yang ada, mencatat setiap pembelian yang dilakukan, menghasilkan tanda terima bagi pelanggan, dan melaporkan apa yang telah dijual secara berkala dan item mana yang kehabisan. persediaan.

Jadi, pada pertemuan pertama Anda, Anda ingin menunjukkan bahwa Anda efisien dan menyajikan apa yang telah Anda siapkan, fitur yang diusulkan, desain dasar untuk mendapatkan identitas visual toko dan semua. Tapi kemudian klien yang bingung mengatakan bahwa, sebenarnya, yang mereka butuhkan adalah sebuah algoritma untuk menghitung bagaimana menampilkan produk dengan lebih baik di rak, yang bertujuan untuk meningkatkan pendapatan bagi merek dan produk tertentu!

Kesalahan di sini sama sekali tidak mengidentifikasi masalah apa yang harus Anda selesaikan. Tentu saja, dalam kasus ini, karena proyek ini sangat awal, akan banyak waktu untuk memperbaikinya, tapi terkadang, kesalahan semacam ini terjadi lebih jauh lagi. Bahkan tidak bisa begitu drastis seperti contoh sebelumnya, masih bisa membahayakan proyek dan / atau hubungan Anda dengan klien.

Saran saya adalah sebagai berikut: Bicaralah dengan pengguna masa depan Anda, jika mungkin, dan berkonsultasilah dengan berbagai pemangku kepentingan dalam proyek ini. Mereka adalah orang-orang dengan gambaran situasi yang baik dan mereka tahu apa yang mereka butuhkan. Cobalah untuk mencari tahu apa yang mereka lakukan saat ini, setiap langkahnya, dan jelaskan bagaimana perangkat lunak akan berguna. Saya suka mengatakan bahwa, ketika saya mencoba memahami keinginan klien, tujuan saya adalah hampir dapat melakukan pekerjaan mereka sendiri. Jika Anda mendekati titik ini, maka Anda benar-benar telah mengetahui apa kebutuhan mereka.

Tidak Memahami Apa yang Klien Minta
Ini tidak biasa untuk menerima beberapa jenis dokumentasi tentang masalah yang dihadapi. Terkadang hanya deskripsi tingkat tinggi, padahal lain kali ini adalah dokumen terperinci dengan use-cases dan aturan bisnis. Bagaimanapun, tidak masalah seberapa jelas catatannya, satu hal yang tidak dapat Anda lakukan, hanya menganggap semua yang tertulis ada kebenaran mutlak.
Apa???
Persis. Pertama, sesuatu bisa berarti satu hal untuk seseorang, dalam konteks tertentu, dan hal yang sama sekali berbeda bagi orang-orang yang bukan milik kenyataan itu. Dan jika ada sesuatu yang Anda dan klien tidak memiliki kesamaan, itu konteksnya!

Kedua, tidak semua orang adalah seorang penulis yang sangat terampil; mereka mencoba untuk mengatakan A tapi akhirnya menggambarkan B.

Jadi, setelah membaca semua yang telah Anda kirim, bagaimana Anda akan yakin bahwa apa yang Anda baca benar-benar sesuai dengan keinginan mereka? Nah, Anda akan mencerna semuanya, membuat beberapa catatan, menganalisis semuanya dan ... memanggil rapat. (Anda lihat? Ini tentang komunikasi!) Pada pertemuan tersebut, Anda akan membicarakan masalah ini, dan menjelaskan apa yang Anda pahami dengan kata-kata Anda sendiri. Pada tahap ini, Anda mungkin bisa mengidentifikasi kesalahpahaman.

"Oh, tapi dalam kasus saya, saya tidak mendapatkan dokumen apapun. Saya hanya duduk dengan klien dan mereka menjelaskan semuanya kepada saya sementara saya mencatatnya ".

Nah, masih belum ada jaminan bahwa Anda mengerti maksud mereka dan saran saya masih ada: Luangkan waktu dengan catatan Anda, pikirkan keseluruhan masalah, atur semuanya, sebaiknya dalam semacam jadwal acara, dan kemudian hubungi / bertemu lagi dengan klien untuk mempresentasikan apa yang Anda pahami. Mungkin kedengarannya berulang bagi Anda, tapi terkadang klien tidak memiliki visi penuh tentang semua proses yang terlibat untuk menyelesaikan tugas tertentu dan kemudian akan melihat betapa kompleksnya perangkat lunak itu.

Pada akhirnya, Anda pasti yakin tidak ada ambiguitas atau kesalahpahaman.

Mengapa Anda Tidak Memberikan Segalanya yang Klien Minta Tanpa Berpikir
Baiklah, sekarang Anda tahu bahwa Anda harus mendengarkan klien dan mengkonfirmasi apa yang Anda pahami, Anda bisa terus maju dan melakukan semua yang mereka minta, bukan?
Salah!
Sekarang adalah saatnya Anda akhirnya dapat menggunakan semua pengalaman yang Anda miliki dan bertanya pada diri sendiri: Apakah klien meminta Anda untuk memecahkan masalah mereka? Apa yang mereka tanyakan benar-benar apa yang mereka butuhkan?

Anda akan terkejut melihat berapa kali jawabannya "tidak".

Sebelum hanya memberikan apa yang diminta klien, kita perlu menganalisis masalahnya dan, jika Anda tidak setuju dengan apa yang diusulkan oleh atasan, maka tugas dan tanggung jawab profesional Anda untuk menjelaskan hal ini. Tentu saja, Anda harus menjelaskan mengapa menurut Anda proposisi mereka tidak baik dan pendekatan alternatif Anda akan dilakukan untuk mengatasi kekurangan ini. Sekali lagi, komunikasi adalah kuncinya.

Jika Anda dan kliennya masuk akal, Anda akan melanjutkan solusi Anda atau sesi brainstorming untuk menghasilkan yang lebih baik (jika ide Anda tidak diterima oleh klien karena alasan tertentu).

Prototipe-Jangan Menulis Dokumentasi Ekstensif
Saya sudah mengatakan bahwa Anda dan klien Anda umumnya tidak memiliki perspektif yang sama, bukan? Oleh karena itu, sama seperti hal itu mempengaruhi pemahaman Anda terhadap dokumentasi mereka, ini akan mempengaruhi pemahaman mereka tentang apa yang Anda sampaikan secara tertulis. Ini juga masalah konteks.

Jadi, saya setuju bahwa bagaimanapun (pada tingkat yang lebih tinggi atau lebih rendah), kita harus mendokumentasikan apa yang akan kita kembangkan. Tapi menyerahkan beberapa halaman teks tanpa elemen visual pun tidak akan banyak berguna bagimu. Klien akan bosan membacanya, akan berhenti memperhatikan, dan mungkin tidak akan bisa mengerti apa yang Anda maksud dengan peraturan bisnis yang kompleks-atau mereka akan menafsirkan sesuatu yang sama sekali berbeda dari apa yang Anda bayangkan.

Ingatlah bahwa kesalahpahaman ini bisa lebih buruk lagi jika klien tidak memiliki latar belakang teknis.

Semua faktor ini dapat mengakibatkan hasil bermasalah yang sama: Klien akan mengeluh saat Anda mengirimkan produk karena kemungkinan hal itu tidak akan menjadi apa yang ada dalam pikiran mereka.

Inilah yang saya sarankan: Selalu prototipe, biarpun hanya sketsa untuk menggambar rencana Anda. Dan apa pun definisi yang harus Anda buat, mulailah dari sana. Buat referensi dan usahakan tetap sederhana.

Stop Menyia nyiakan waktu Meyakinkan Klien Anda Benar
Saya hampir dapat memastikan bahwa setiap pengembang telah melalui situasi berikut: Pada awal proyek, klien mengatakan "Saya memerlukan warna latar belakang perangkat lunak untuk menjadi kuning. Ini sudah disepakati oleh dewan direksi. "Kemudian, saat perangkat lunak dikirimkan, mereka berkata" Oh, tapi warna latar belakangnya tidak bisa berwarna kuning. Sudah kukatakan itu harus hijau! "Nah, bagaimana seharusnya kamu mengatasi ini?

Tentu saja, tidak akan ada gunanya, hanya dengan bersikeras Anda benar dan mereka salah. Jika ada, itu hanya akan memberi Anda dan klien mengalami kesulitan.

Selalu baik untuk memiliki catatan komunikasi yang baik dengan klien, hanya untuk memastikan Anda berada di halaman yang sama dan meninggalkan jejak tertulis. Sebagian besar waktu, jika itu sesuatu yang sederhana, Anda bisa mengirim email ke klien, dengan mengatakan, "Seiring kami sepakat pada pertemuan itu, latar belakang sistem akan menjadi kuning." Dan jika, di masa depan, klien mengubah pikiran mereka, Anda dapat membantah bahwa Anda melakukannya karena pertemuan yang disebutkan di email, tapi jika modifikasi itu benar-benar perlu dilakukan, Anda dapat menjalankannya, untuk tambahan x jam (dan kadang-kadang, dolar ekstra x).

Tapi jika tidak ada yang bisa membuktikan bahwa Anda benar, mungkin Anda punya keputusan untuk membuat (dan juga pelajaran untuk dipelajari): Apakah perubahan itu besar yang memerlukan perubahan pada arsitektur saat ini atau mempengaruhi fitur lainnya? Jika tidak, mungkin lebih baik melakukannya saja, lakukanlah, dan dapatkan klien di sisi Anda (tapi dengan mata terbuka lebar sehingga tidak terjadi lagi). Jika ya, maka pembicaraan dengan klien akan menjadi solusi terbaik; Tidak ada yang berfokus pada "bagaimana Anda benar," tapi tentang "bagaimana kita bisa memperbaiki masalah saat ini."

Bagaimanapun, cara terbaik untuk mencegah modifikasi besar adalah menghadirkan fitur baru singkat dalam waktu singkat. Karena itu, jika ada yang harus diubah, mungkin tidak akan menjadi transformasi besar dari apa yang sudah ada.

Tahu kapan harus melakukan deadline
Terakhir, namun tidak kalah pentingnya, salah satu kesalahan terbesar yang dapat Anda lakukan adalah memberi tenggat waktu kepada klien Anda untuk menyelesaikan proyek Anda. Dan mereka akan memohon Anda untuk membuat kesalahan itu!

Tentu saja, sebagai klien, Anda ingin tahu kapan Anda dapat menggunakan semua fitur bagus yang telah Anda bahas selama beberapa minggu terakhir (bulan?). Tapi, karena sebuah proyek bukanlah produk yang pasti, banyak yang bisa terjadi saat pengembangan dimulai sampai perangkat lunak siap digunakan.

Pertama-tama, kita tidak bisa memprediksi yang tak terduga. Kemungkinan besar Anda harus menghadapi sesuatu yang tidak Anda duga. Ini bisa menjadi lisensi yang dijanjikan klien yang tidak dibeli tepat waktu, atau beberapa perangkat lunak internal lain yang perlu Anda gunakan namun tidak dilepaskan kapan seharusnya, atau lingkungan berbeda dari yang disepakati sebelumnya, atau klien berubah pikiran tentang beberapa (beberapa) fitur dan Anda harus mengulang beberapa hal.

Tidak ada yang benar-benar merupakan kesalahan pengembang dan dapat sangat mempengaruhi batas waktu proyek. Tetapi jika Anda bersedia untuk menyenangkan klien, berjanji akan memberikan semuanya dengan beberapa tanggal dan berakhir, untuk semua alasan yang benar, tidak melakukannya, satu hal yang dapat saya jamin adalah klien akan menjadi, setidaknya sedikit , frustrasi Jika Anda seorang freelancer, Anda harus mengatur waktu Anda secara efisien, karena artikel Blog Teknik Toptal ini menjelaskannya. Jangan lupa bahwa manajemen hubungan klien adalah pekerjaan Anda juga.

Jadi, lakukanlah diri Anda dan orang yang bergantung pada proyek ini dan setidaknya memberi mereka perkiraan berapa lama waktu yang dibutuhkan untuk mengembangkan segalanya, tapi selalu jadikan itu sangat jelas bahwa ini hanyalah perkiraan dan bukan tenggat waktu.

Juga, saya sangat menyarankan (terutama jika Anda sudah memberi perkiraan) bahwa Anda selalu memberi tahu klien saat ada sesuatu yang memakan waktu lebih lama dari perkiraan sehingga mereka dapat bertindak untuk membantu Anda!

Sekian share kali ini semoga apa yang saya share bermanfaat bagi temanteman semua, Jangan lupa untuk share dan koment dibawah jika artikel ini berguna.

Artikel from : www.toptal.com - ANDREZA CRISTINA DA SILVA