Kesalahan Umum dalam Komunikasi Klien: Bagaimana Agar Klien Anda Tidak Frustasi

Ketika seseorang meminta sebuah proyek, kita harus berasumsi bahwa itu sangat penting dan bahwa mereka sangat peduli dengan produk yang akan Anda kerjakan. Jadi, aman untuk berasumsi bahwa klien terikat untuk membangun banyak harapan di sekitar produk akhir, dan karena itu mungkin menjadi emosional ketika datang ke pengiriman.

Selama proyek berlangsung, klien mungkin menjadi sangat senang dengan fitur yang diberikan dan menyukai Anda, dan pada hari berikutnya dia dapat menemukan sesuatu yang tidak berfungsi dan kasih sayang itu akan hilang. Lebih sering daripada tidak, itu hanya masalah komunikasi klien yang salah.

Meskipun tidak ada resep untuk sukses dalam hal pengembangan perangkat lunak jarak jauh, saya yakin ada beberapa hal yang harus dihindari untuk menjaga hubungan yang sehat dan produktif dengan klien yang menaruh begitu banyak kepercayaan di tangan Anda.

Jangan Gagal Komunikasi Dasar dengan Klien

Bayangkan komunikasi dengan klien seperti halnya komunikasi sehari-hari dengan rekan kerja, teman, atau orang lain yang akan Anda beri kesopanan.

Jika seorang teman lama berkunjung ke rumah dan Anda setuju untuk menikmati kelezatan lokal “di tempat lama Anda” pada siang hari, beberapa minggu kemudian, apakah Anda akan muncul di sana? Apakah Anda akan tetap berhubungan untuk sementara waktu, menelepon untuk mengonfirmasi beberapa hari sebelumnya? Atau mungkin Anda akan menganggap mereka terlalu sibuk dan tidak ingin mengganggu mereka tanpa alasan yang jelas? Apakah Anda berharap mereka memberi tahu Anda saat mereka tiba?

Anda tidak akan terus mengobrol setiap hari kecuali jika Anda memiliki banyak hal untuk dibicarakan, tetapi Anda akan mempertahankan beberapa bentuk komunikasi, demi kesopanan dan kepraktisan: Anda tidak ingin orang lain berpikir bahwa Anda telah melupakannya , tetapi Anda pasti tidak ingin mengemudi di tengah kota tanpa alasan yang jelas.

Pada titik tertentu, Anda mungkin mengalami situasi serupa dalam komunikasi profesional Anda juga, bahkan dengan mitra dan rekan kerja lama. Beberapa proyek dijalankan dengan komunikasi yang minim, seperti mengucapkan “biasa, siang, sampai jumpa” untuk mengkonfirmasi makan siang ringan. Bahkan jika sesuatu muncul, pihak lain pasti akan memberi tahu Anda, dan Anda akan setuju untuk menjadwal ulang.

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

Jika Anda mulai mengerjakan sebuah proyek, terutama saat Anda berurusan dengan klien baru, jika mereka tidak pernah mendengar kabar dari Anda, mereka akan mulai berpikir dua kali tentang pekerjaan dan komitmen Anda. Bahkan jika Anda muncul dengan produk yang sempurna setelah beberapa minggu, klien mungkin sudah memiliki persepsi yang kurang ideal tentang Anda.

Meskipun kadang-kadang pasti akan terasa canggung, tidak ada salahnya untuk berbicara dengan klien bahkan jika Anda tidak memiliki sesuatu yang tidak biasa untuk dilaporkan! Apakah Anda memiliki keraguan tentang satu poin kecil dari cerita pengguna? Jika menurut Anda itu penting, beri tahu mereka. Anda sedikit terlambat dan tidak yakin apakah Anda akan dapat memenuhi perkiraan tanggal yang Anda setujui? Hubungi klien secepatnya! Lebih baik mereka segera mendengarnya.

Anda tidak ragu dan proyeknya tepat waktu, tetapi klien tidak banyak bicara? Mengapa tidak mengirim email yang menjelaskan kemajuan Anda setiap beberapa hari? Itu tidak akan membahayakan karena email tidak akan mengganggu siapa pun, ditambah Anda akan mendokumentasikan kemajuan Anda dan menjaga komunikasi rutin dengan klien.

Komunikasi Klien yang Cacat Menumbuhkan Harapan yang Tidak Realistis

Jadi, pada awalnya, saya menyebutkan bahwa klien pasti memiliki banyak harapan tentang proyek, bukan? Benar. Periode.

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

Berikut paralel cepat: Anda membeli tablet secara online dan dijanjikan pengiriman 10 hari. Pada hari ke-8, toko memberi tahu Anda bahwa ada masalah dan penundaan pengiriman selama seminggu. Untuk mengimbangi ketidaknyamanan Anda, pengecer berjanji memberi Anda kredit toko $75.

Anda mungkin tidak benar- benar membutuhkan tablet itu untuk beberapa hari ke depan, jadi menurut Anda itu adalah tawaran yang bagus! Sekarang Anda dapat menikmati tablet, plus menggunakan kredit toko untuk membelikan anak Anda sesuatu yang bagus. Tapi toko menelepon keesokan harinya, mengatakan semuanya beres dalam semalam.

Anda akan mendapatkan tablet pada hari berikutnya. Tidak ada tambahan, tidak ada kredit toko. Sekarang Anda yang frustrasi!

"Apa? Baru kemarin Anda memberi tahu saya bahwa saya akan mendapatkan kesepakatan yang lebih baik! Itu tidak adil! Aku sudah memberitahu anak-anak…”

Mundur beberapa hari dan yang Anda harapkan hanyalah tablet. Seandainya tidak ada yang menjanjikan Anda kesepakatan yang lebih baik, Anda akan senang dengan mainan Anda ketika tiba keesokan harinya. Tapi sekarang, Anda merasa kehilangan tanpa alasan yang jelas, selain keputusan toko untuk memberi tahu Anda.

Bagaimana pengembang, terutama pekerja lepas, menghindari situasi serupa dalam komunikasi mereka dengan klien?

Dengan tidak menjadi gila dan mengatakan semua yang terlintas di pikiran Anda sejak awal. Saran tidak dilarang; sebenarnya, mereka sangat menyambut jika Anda berpikir bahwa fitur yang diminta tertentu bukanlah pilihan yang sangat baik untuk memecahkan masalah yang dihadapi. Tapi kuncinya adalah: Pikirkan dulu.

• Dengarkan klien.

• Analisis masalah mereka.

• Analisis solusi yang diusulkan.

• Pastikan sesuai anggaran/jadwal.

• Terakhir, lanjutkan dan sampaikan saran Anda.

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

Jangan Asumsikan Anda Tahu Apa yang Dibutuhkan Klien

Mengutip Mary Schmich, Hadirin sekalian dari kelas '17: Dengarkan klien. Jika saya bisa menawarkan Anda hanya satu tip untuk masa depan, mendengarkan klien adalah itu.

Jika Anda dipanggil untuk sebuah proyek, itu karena seseorang membutuhkan sesuatu. Dan siapa yang lebih tahu tentang kebutuhan itu selain klien Anda? Ini mungkin tampak jelas, tetapi terkadang, di dunia nyata, orang melupakannya.

Biarkan saya memberi Anda sebuah contoh. Seorang pengecer meminta "sistem perangkat lunak" untuk bisnisnya. Segera setelah Anda melihatnya, Anda melompat ke kesimpulan bahwa apa yang mereka inginkan adalah sesuatu untuk mendaftarkan semua produk yang tersedia, mencatat setiap pembelian yang dilakukan, membuat tanda terima untuk pelanggan, dan melaporkan apa yang terjual secara berkala dan item mana yang kehabisan. persediaan.

Jadi, pada pertemuan pertama Anda, Anda ingin menunjukkan bahwa Anda efisien dan mempresentasikan kepada mereka apa yang telah Anda siapkan, fitur yang diusulkan, desain dasar yang sesuai dengan identitas visual toko dan semuanya. Tetapi kemudian klien yang bingung mengatakan bahwa, sebenarnya, yang mereka butuhkan adalah algoritme untuk menghitung cara menampilkan produk dengan lebih baik di rak, yang bertujuan untuk meningkatkan pendapatan untuk merek dan produk tertentu!

Kesalahan di sini sama sekali tidak mengidentifikasi masalah apa yang seharusnya Anda selesaikan. Tentu saja, dalam kasus ini, karena ini masih sangat awal dalam proyek, akan ada banyak waktu untuk memperbaikinya, tetapi terkadang, kesalahan semacam ini terjadi lebih jauh. Meskipun tidak sedrastis contoh sebelumnya, hal itu tetap dapat membahayakan proyek dan/atau hubungan Anda dengan klien.

Saran saya adalah sebagai berikut: Bicaralah dengan pengguna masa depan Anda, banyak jika memungkinkan, dan konsultasikan dengan berbagai pemangku kepentingan dalam proyek. Mereka adalah orang-orang dengan gambaran yang baik tentang situasi 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 apa yang diinginkan klien, tujuan saya adalah hampir dapat melakukan pekerjaan mereka sendiri. Jika Anda mendekati titik ini, maka Anda telah benar-benar mengetahui apa kebutuhan mereka.

Tidak Memahami Apa yang Diminta Klien

Tidak jarang menerima semacam dokumentasi tentang masalah yang dihadapi. Terkadang itu hanya deskripsi tingkat tinggi, sedangkan di lain waktu itu adalah dokumen terperinci dengan kasus penggunaan dan aturan bisnis. Bagaimanapun, tidak peduli seberapa jelas catatannya, satu hal yang tidak dapat Anda lakukan, anggap saja semua yang tertulis di sana adalah kebenaran mutlak.

Apa???

Tepat. Pertama, sesuatu dapat berarti satu hal bagi seseorang, dalam konteks tertentu, dan hal yang sama sekali berbeda bagi orang yang tidak termasuk dalam realitas itu. Dan jika ada sesuatu yang Anda dan klien tidak memiliki kesamaan, itu adalah konteksnya!

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

Jadi, setelah membaca semua yang dikirimkan kepada Anda, bagaimana Anda bisa yakin bahwa apa yang Anda baca benar-benar maksudnya? Nah, Anda akan mencerna semuanya, membuat beberapa catatan, menganalisis semuanya dan… mengadakan rapat . (Anda lihat? Ini semua tentang komunikasi!) Pada pertemuan itu, Anda akan membicarakan masalah, dan menjelaskan apa yang Anda pahami dengan kata-kata Anda sendiri. Pada tahap ini, Anda mungkin akan dapat mengidentifikasi kesalahpahaman.

“Oh, tapi dalam kasusku, aku tidak mendapatkan dokumen apapun. Saya hanya duduk dengan klien dan mereka menjelaskan semuanya kepada saya sementara saya membuat beberapa catatan”.

Yah, masih tidak ada jaminan bahwa Anda mengerti apa yang mereka maksud dan saran saya tetap berlaku: Luangkan waktu dengan catatan Anda, pikirkan seluruh masalah, atur semuanya, sebaiknya dalam semacam timeline acara, dan kemudian telepon/bertemu lagi dengan klien untuk mempresentasikan apa yang Anda pahami. Ini mungkin terdengar berulang bagi Anda, tetapi terkadang bahkan klien tidak memiliki visi penuh tentang semua proses yang terlibat untuk menyelesaikan tugas tertentu dan kemudian akan melihat betapa rumitnya perangkat lunak itu.

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

Mengapa Anda Tidak Harus Memberikan Semua yang Diminta Klien tanpa Berpikir

Oke, sekarang setelah Anda tahu bahwa Anda harus mendengarkan klien dan mengonfirmasi apa yang Anda pahami, Anda dapat melanjutkan dan melakukan semua yang mereka minta, bukan?

Salah!

Sekarang saatnya Anda akhirnya dapat menggunakan semua pengalaman yang Anda miliki dan bertanya pada diri sendiri: Apakah yang diminta klien Anda akan menyelesaikan masalah mereka? Apakah yang mereka tanyakan kepada Anda benar-benar yang mereka butuhkan?

Anda akan terkejut melihat berapa kali jawabannya adalah "tidak."

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

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

Prototipe—Jangan Menulis Dokumentasi yang Luas

Saya sudah mengatakan bahwa Anda dan klien Anda umumnya tidak memiliki perspektif yang sama, bukan? Oleh karena itu, sama seperti hal itu memengaruhi pemahaman Anda tentang dokumentasi mereka, hal itu akan memengaruhi pemahaman mereka tentang apa yang Anda sampaikan secara tertulis. Ini masalah konteks juga.

Jadi, saya setuju bahwa entah bagaimana (pada tingkat yang lebih tinggi atau lebih rendah), kita harus mendokumentasikan apa yang akan kita kembangkan. Tetapi menyerahkan beberapa halaman teks tanpa elemen visual apa pun tidak akan banyak membantu Anda. Klien akan bosan membacanya, akan berhenti memperhatikan, dan mungkin tidak akan dapat memahami apa yang Anda maksud dengan aturan bisnis yang rumit itu—atau mereka akan menafsirkan sesuatu yang sama sekali berbeda dari apa yang Anda bayangkan.

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

Semua faktor ini dapat mengakibatkan hasil bermasalah yang sama: Klien akan mengeluh ketika Anda mengirimkan produk karena kemungkinan produk tersebut tidak sesuai dengan yang mereka pikirkan.

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

Berhentilah Membuang Waktu Meyakinkan Klien bahwa Anda Benar

Saya hampir yakin bahwa setiap pengembang telah melalui situasi berikut: Pada awal proyek, klien mengatakan “Saya membutuhkan warna latar belakang perangkat lunak menjadi kuning. Itu sudah disepakati oleh dewan.” Kemudian, ketika software dikirimkan mereka berkata “Oh, tapi warna backgroundnya tidak boleh kuning. Sudah kubilang itu harus hijau!” Sekarang, bagaimana Anda harus menghadapi ini?

Yang pasti, tidak ada gunanya, dalam hal apa pun, untuk bersikeras bahwa Anda benar dan mereka salah. Jika ada, itu hanya akan menyulitkan Anda dan klien.

Itu 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 cukup mengirim email ke klien, mengatakan, "Seperti yang kita sepakati pada pertemuan itu, latar belakang sistem akan menjadi kuning." Dan jika, di masa depan, klien berubah pikiran, Anda dapat berargumen bahwa Anda melakukannya karena pertemuan yang disebutkan di email, tetapi jika modifikasi itu benar-benar perlu dilakukan, Anda dapat menjalankannya, selama x jam tambahan (dan terkadang, tambahan x dolar).

Tetapi jika tidak ada sesuatu untuk membuktikan bahwa Anda benar, maka Anda mungkin harus mengambil keputusan (dan juga pelajaran untuk dipelajari): Apakah perubahan sebesar itu akan memerlukan perubahan pada arsitektur saat ini atau memengaruhi fitur lainnya? Jika tidak, mungkin yang terbaik adalah melanjutkan, melakukannya, dan membuat klien berada di sisi Anda (tetapi dengan mata terbuka lebar sehingga hal itu tidak terjadi lagi). Jika ya, maka berbicara dengan klien akan menjadi solusi terbaik; bukan yang berfokus pada "bagaimana Anda benar", tetapi pada "bagaimana kami dapat memperbaiki masalah saat ini."

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

Tahu Kapan Harus Berkomitmen pada Tenggat Waktu

Terakhir, namun tidak kalah pentingnya, salah satu kesalahan terbesar yang dapat Anda lakukan adalah memberikan tenggat waktu kepada klien Anda untuk menyelesaikan proyek. 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 diskusikan selama beberapa minggu terakhir (bulan?). Namun, karena proyek bukanlah produk yang ditentukan, banyak hal yang dapat terjadi mulai dari saat pengembangan dimulai hingga perangkat lunak siap digunakan.

Pertama-tama, seseorang tidak dapat memprediksi hal yang tidak terduga. Sangat mungkin bahwa Anda harus berurusan dengan sesuatu yang tidak Anda harapkan. Itu bisa berupa lisensi yang dijanjikan klien yang tidak dibeli tepat waktu, atau perangkat lunak internal lain yang perlu Anda gunakan tetapi tidak dirilis pada saat seharusnya, atau lingkungan yang berbeda dari yang disepakati di awal, atau klien berubah pikiran tentang (beberapa) fitur dan Anda harus mengulang beberapa hal.

Tak satu pun dari itu benar-benar kesalahan pengembang dan dapat sangat memengaruhi tenggat waktu proyek. Tetapi jika Anda, bersedia untuk menyenangkan klien, berjanji akan memberikan semuanya pada tanggal tertentu dan akhirnya, untuk semua alasan yang tepat, tidak melakukannya, satu hal yang dapat saya jamin adalah bahwa klien akan, setidaknya sedikit , frustrasi. Jika Anda seorang freelancer, Anda harus mengatur waktu Anda secara efisien, seperti yang dijelaskan oleh artikel Blog Toptal Engineering ini. Jangan lupa bahwa manajemen hubungan klien adalah pekerjaan Anda juga.

Jadi, bantulah diri Anda sendiri dan orang yang bergantung pada proyek tersebut dan setidaknya beri mereka perkiraan berapa lama waktu yang dibutuhkan untuk mengembangkan semuanya, tetapi selalu jelaskan bahwa itu hanya perkiraan dan bukan tenggat waktu.

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