Bekerja dengan klien yang tidak tahu apa yang mereka inginkan

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?

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.

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.

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.

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.

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.

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.