Bekerja dengan klien yang tidak tahu apa yang mereka inginkan


19

Baru-baru ini saya memulai pekerjaan yang membuat saya bekerja pada sistem yang ada. Itu membutuhkan tweak dan pembaruan serta kode baru. Saya telah melakukan beberapa proyek pemeliharaan / penambahan fitur sekarang, dan beberapa di antaranya akhirnya sangat berbeda dari apa yang sebenarnya diminta. Jadi, saya harus memprogram item itu beberapa kali untuk mendapatkannya ke tempat yang diinginkan pemohon.

Sekarang, saya tidak keberatan memprogram ulang fitur jika itu yang perlu dilakukan. Namun, saya ingin mengurangi waktu penyelesaian proyek saya. Hambatan tampaknya dalam persepsi pemohon tentang apa yang perlu dilakukan. Apakah Anda punya ide tentang apa yang bisa saya lakukan untuk mencari tahu apa yang dibutuhkan pemohon lebih cepat?


1
Ini harus menjadi lebih baik daripada yang sebaliknya, klien yang tahu apa yang mereka inginkan tetapi tidak apa yang mereka butuhkan.
Craig

2
Apakah klien pernah tahu apa yang mereka inginkan?
Dominique McDonnell

6
"Klien tidak tahu apa yang dia inginkan sampai Anda memberikan apa yang dia minta"
Benjol

Beberapa waktu yang lalu, saya mulai berfantasi tentang mempekerjakan analis persyaratan dari kejahatan terorganisir. "Apakah kamu akan memberi tahu saya apa yang terjadi ketika klien tidak ada dalam database, atau apakah saya harus bersikap kasar?"
David Thornley

Silakan ikuti proposal ini untuk pertanyaan seperti itu: Aspek organisasi
Maniero

Jawaban:


20

Beberapa poin saran:

  • Dengarkan masalah, Bukan Solusi . Banyak klien ingin memberi tahu Anda cara mengatasi masalah mereka. Jangan dengarkan mereka. Anda adalah programmer, dan itu adalah tugas Anda untuk menemukan solusi untuk masalah. Alih-alih dengarkan masalah apa yang dialami klien, dan cari cara terbaik untuk menyelesaikannya. seperti yang dikatakan orang lain, klien tidak benar-benar tahu apa yang mereka inginkan, kadang-kadang Anda harus menunjukkannya kepada mereka terlebih dahulu.

  • Ajukan Pertanyaan . Ketika Anda selesai mengajukan pertanyaan, tanyakan lagi. Klien jarang memberi rincian, karena mereka tidak benar-benar memikirkannya. Satu-satunya cara Anda akan mendapatkan informasi yang Anda butuhkan adalah mencabutnya dari mereka.

  • Dapatkan Hal-hal dalam Menulis Tergantung pada situasi dengan klien, ini bisa menjadi sangat penting nanti ketika mereka mulai mengeluh tentang apa yang Anda kirim "bukan apa yang mereka minta". dan jika tidak ada yang lain, menuliskan spesifikasi terperinci dapat membantu Anda memastikan Anda memiliki semua informasi yang Anda butuhkan, dan membantu menjernihkan ambiguitas antara Anda dan klien.

  • Komunikasi adalah kuncinya . jangan hanya berbicara dengan klien, dapatkan info, pisahkan beberapa kode dan tidak berbicara dengan mereka sampai selesai. Selalu tetap berhubungan dengan klien. Ajukan pertanyaan selama proses berlangsung. tunjukkan pada mereka kemajuan yang telah Anda buat dan dapatkan umpan balik. Ini akan membuat hidup semua orang lebih mudah dalam jangka panjang.


2
Daftar yang sangat baik, terutama poin 1. Banyak pelanggan akan bertanya 'dapatkah Anda menambahkan tombol di sini yang memberikan X' ... tetapi jika Anda menanyakan lebih lanjut tentang mengapa mereka menginginkan tombol tersebut, Anda mengetahuinya karena mereka berusaha menyelesaikan beberapa masalah yang mereka miliki dengan fitur yang sama sekali berbeda.
GrandmasterB

2
Sedikit tambahan ke poin pertama di sana - jika mereka membutuhkan fitur untuk memfasilitasi beberapa tugas, tanyakan apakah Anda dapat melihat bagaimana mereka melakukan tugas sekarang. Ini dapat membuatnya lebih mudah untuk melihat apa masalah sebenarnya dan apa jebakan potensial.
glenatron

@ Glenatron: Itu ide yang sangat bagus, esp. karena tidak mungkin bagi saya untuk mempelajari seluruh sistem.
Michael K

@ Gsto: Pada # 2, apakah Anda berbicara tentang programmer menulis permintaan dengan input klien, atau klien menulisnya? Salah satu masalah yang saya miliki adalah bahwa permintaan tertulis klien tidak akurat.
Michael K

Saya sering kali membuat pelanggan atau penanya benar-benar membuktikan bahwa fitur atau perubahan adalah kebutuhan dan akan memperbaiki keadaan. Anda mungkin tidak memiliki kemewahan ini, tetapi jika Anda bisa meminta klien atau pemohon untuk menunjukkan kepada Anda bahwa mereka memahami sepenuhnya mengapa mereka menginginkan perubahan dan bagaimana itu akan menguntungkan orang lain, Anda mungkin dapat menawarkan alternatif untuk memenuhi kebutuhan mereka alih-alih mereka ingin.
Josaph

5

Cukup banyak buku bantuan diri apa pun yang Anda terima tentang komunikasi yang akan memberi Anda beberapa variasi dari ini:

  • Berusahalah terlebih dahulu untuk mengerti, lalu untuk dipahami

Itu berasal dari buku 7 kebiasaan, tetapi mereka semua adalah beberapa variasi dari metode " mendengarkan aktif ". Tujuannya bukan hanya untuk memahami, tetapi untuk berkomunikasi kembali dengan mereka yang Anda pahami.

Setelah saya pikir saya memiliki ide bagus tentang apa yang mereka butuhkan (menjauh dari apa yang mereka inginkan terutama jika mereka mulai menggambarkan detail implementasi - itu pekerjaan Anda, bukan milik mereka), saya memberi mereka contoh cerita dari berbagai orang yang menggunakan sistem, dan melihat apakah yang bercanda dengan mereka.

Lalu saya menerapkannya, sepenuhnya berharap bahwa begitu mereka melihat fitur, mereka akan benar-benar menyadari bahwa itu bukan yang mereka inginkan. Usahakan semuanya fleksibel. Satu-satunya yang konstan adalah perubahan. Saya biasanya mendapatkan sebagian besar tepi kasar berhasil setelah pembaruan cepat kedua setelah yang pertama, tapi saya selalu menemukan saya mendekati beberapa ideal yang asimtotik yang tidak pernah bisa saya jangkau. Akhirnya, Anda harus membiarkan hal-hal yang tidak penting pergi dan beralih ke target nilai yang lebih tinggi.


4

Aku merasakan sakitmu ....

Berita buruknya adalah: tergantung pada klien seperti apa yang Anda hadapi, ini mungkin bisnis seperti biasa.

Masalah umum yang umum pada dasarnya adalah bahwa klien tidak tahu apa yang mereka inginkan . Mereka biasanya tahu apa yang ingin mereka capai, dalam hal tujuan bisnis, tetapi mereka sering tidak tahu bagaimana seharusnya terlihat dalam hal solusi perangkat lunak. Jadi, dalam banyak kasus, Anda akan menemukan diri Anda dalam siklus berulang ini di mana proyek memantul bolak-balik selama lima kali selama estimasi awal, karena klien terus berubah pikiran dan ingin solusi tweak dan tweak ulang. Dan ya, itu tidak biasa untuk hasil akhir yang berubah menjadi sesuatu yang sama sekali berbeda dengan apa yang tampak seperti tujuan awal.

Saya punya contoh epik tentang hal ini terjadi beberapa tahun yang lalu - sebuah proyek yang awalnya membutuhkan 10 minggu untuk kode berubah menjadi 15 bulan re-iterasi grind. Dalam hal itu, itu terutama karena manajer dan departemen yang berbeda di perusahaan klien menginginkan hal-hal yang berbeda, sehingga mereka terus mengirim pekerjaan kembali, untuk di-tweak dan di-tweak (perangkat lunak kami berbasis langganan dan ini adalah klien utama, jadi ini tidak ada masalah keuangan di belakang kami - hanya gangguan teknis besar benar-benar).

Jadi pada dasarnya saran saya adalah ini:

Jika ini adalah cara industri khusus Anda dan klien-klien ini (itu JIKA besar), maka biasakan saja. Anggap saja sebagai pekerjaan yang gesit, berorientasi pada pemeliharaan (beginilah penampilan saya saat ini, kurang lebih). :)

Jika ini bukan cara yang seharusnya dilakukan, dan Anda disalahkan atas perputaran yang panjang, maka bicaralah dengan atasan Anda. Jelaskan kepada mereka bahwa ada masalah komunikasi dan bahwa spesifikasi yang datang kepada Anda dari klien tidak cukup jelas bagi Anda untuk mengimplementasikan solusi yang diinginkan. Anda tidak ingin menemukan diri Anda dalam situasi di mana Anda disalahkan karena tidak memberikan klien apa yang mereka inginkan, jika Anda tidak mendapatkan semua informasi yang diperlukan untuk memberi mereka apa yang mereka inginkan.


1
Ini sebenarnya cukup normal di sini, tetapi itu adalah sesuatu yang saya ingin ubah setidaknya untuk proyek saya. Saya pikir banyak dari permintaan ini dapat diputar balik dengan lebih cepat - yang sederhana dapat memakan waktu 3-4 (atau lebih) minggu tergantung.
Michael K

2

Pertama-tama, Anda harus menerima kenyataan bahwa klien tidak benar-benar tahu apa yang mereka cari sampai mereka melihatnya. Mereka mungkin memberi tahu Anda saat ini bahwa mereka memerlukan fitur X. Tunjukkan pada mereka fitur X maka mereka akan menyadari bahwa yang benar-benar mereka butuhkan adalah fitur Y atau variasi fitur X lainnya.

Cara yang baik untuk mengetahui apa yang benar-benar diinginkan pelanggan dengan lebih cepat adalah dengan merangkul dan mengikuti Agile Manifesto , yang berfokus pada komunikasi dan kolaborasi pelanggan. Bagilah siklus pengembangan ke dalam iterasi dan tunjukkan klien prototipe fitur setiap akhir iterasi. Dengan begitu, Anda akan mendapatkan umpan balik langsung dan mengubahnya, sesuai dengan umpan balik dari klien, tanpa harus menginvestasikan terlalu banyak sumber daya pada fitur tersebut. Dengan begitu, Anda dan klien akan senang dengan hasil produk.

Saya cukup yakin transisi akan sulit untuk tim Anda atau perusahaan Anda, tetapi ini adalah salah satu cara terbaik untuk mengatasi persyaratan yang berubah dengan cepat.


1
+1 untuk "Pertama-tama, Anda harus menerima kenyataan bahwa klien tidak benar-benar tahu apa yang mereka cari sampai mereka melihatnya.". Dan ini bukan hal yang buruk. Beberapa proyek terburuk yang pernah saya kerjakan adalah proyek di mana mereka habiskan untuk mencoba mencari tahu apa yang mereka inginkan sebelum mereka melibatkan pengembang. Percaya atau tidak, beberapa iterasi seringkali lebih cepat daripada desain awal yang besar.
Jon Hopkins

1

Banyak sekali, dan banyak kisah serupa dapat ditemukan di sini . Saya tidak pernah, bahkan bekerja sebagai subkontraktor untuk perusahaan pengembangan lain, menemukan klien yang tahu persis apa yang mereka inginkan.

Saya cukup senang bekerja dengan seseorang yang memiliki ide bagus tentang apa yang tidak mereka inginkan, atau ingin hindari. Saya biasanya dapat bekerja dari sana ke sesuatu yang mereka sukai.

Pengalaman saya sebagian besar dalam pengembangan aplikasi / platform. Untungnya, saya jarang harus berurusan dengan masalah estetika seperti yang dilakukan perancang web.


1

Setelah banyak penulisan ulang yang mengganggu, saya sekarang mengoperasikan apa yang saya sebut pengungkapan penuh.

Jadi setelah membahas persyaratan dan keinginan pelanggan, saya akan selalu menulis apa yang saya rasa mereka inginkan dan bagaimana saya akan melanjutkan untuk memenuhi persyaratan itu. Saya kemudian akan mengirimkan kepada mereka apa yang saya tulis dan menunggu sampai mereka menjawab dengan persetujuan sebelum mulai bekerja.

Jika ini proyek besar (lebih dari 5 hari kerja) saya akan prototipe juga. Ini memberi mereka kesempatan untuk mengubah pikiran mereka tanpa perubahan kode besar-besaran di akhir saya.

Itu tidak selalu berhasil, tetapi setidaknya saya berada dalam posisi di mana klien tahu bahwa mereka berubah pikiran dan bukan saya yang menerapkannya secara tidak benar.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.