Apakah itu tanggung jawab pengembang perangkat lunak untuk memahami apa yang dimaksud pelanggan dengan permintaannya?

Agak pertanyaan ya / tidak dan mengapa?

Apakah itu tanggung jawab pengembang perangkat lunak untuk memahami apa yang dimaksud pelanggan dengan permintaannya atau apakah itu tanggung jawab pelanggan untuk menjelaskan dengan baik permintaannya kepada pengembang?

Situasi di tempat kerja saat ini "pelanggan sudah menjelaskan kepada kami, apa yang dia inginkan. Ini adalah tanggung jawab Anda untuk memahami permintaan, bukan untuk bertanya lebih banyak".

Walaupun bahasa Inggris bukan suite saya yang kuat, semua permintaan ditulis dalam bahasa Inggris yang tidak jelas dengan kata-kata yang salah tempat dan kalimat yang sulit dipahami, beberapa permintaan menganggap pemahaman sistem sebelumnya pada bagian saya.

Saya adalah pengembang ke-3 atau ke-4 dari sistem (pengembang terakhir berhenti dari pekerjaan) dan itu mungkin menjadi alasan pelanggan mengharapkan pengertian dari pihak pengembang.

Sistemnya sendiri cukup berantakan baik di tingkat UI dan kode sumber. Ini terlihat seperti pengkodean monyet untuk saya - kode dan harap Anda mendapatkan permintaan dengan benar, sementara tidak benar-benar memahami permintaan.

Saya sebenarnya berpikir untuk berhenti dari pekerjaan, tetapi belum, mengingat saya tidak yakin tentang siapa yang benar dan siapa yang salah.

Jika tugas Anda untuk memahami, itu adalah tugas Anda untuk mengajukan pertanyaan sampai Anda melakukannya

Orang yang Anda tanyakan mungkin seseorang yang bukan pelanggan (saya sering berbicara dengan perantara, yang berhubungan dengan pelanggan), jadi orang yang melarang Anda berbicara dengan pelanggan harus menjawab sendiri pertanyaan atau merujuk Anda ke seseorang yang bisa.

Tetapi, pada akhirnya harus ada BEBERAPA jenis komunikasi. Jika mereka menyangkalnya (dan memberikan beberapa dokumen yang tidak Anda pahami secara efektif menyangkal komunikasi), Anda harus melakukan seperti yang dilakukan pendahulu Anda: lari, cepat.

Ketika klien dan atasan Anda meninggalkan jejak kertas yang berantakan, satu-satunya hal yang dapat Anda lakukan adalah mengumpulkan sebanyak yang Anda bisa dari apa yang Anda miliki dan mulai menulis skenario dalam bahasa Inggris sederhana dalam upaya untuk menyusun pengetahuan apa yang ada tentang bagaimana sistem seharusnya berperilaku.

Skenario yang Diberikan / Kapan / Kemudian memungkinkan Anda untuk menjelaskan secara terperinci apa yang perlu terjadi dan karena semuanya ditulis dalam bahasa Inggris yang sederhana dan terstruktur, Anda dapat menggunakannya untuk berkomunikasi dengan atasan dan klien Anda: "Dengar, Saya sudah sampai pada titik ini dan saya tidak tahu apa yang seharusnya dilakukan sistem di sini ".

Jika Anda hanya dijauhi ketika Anda meminta klarifikasi tambahan, meskipun Anda telah menginvestasikan upaya untuk mendokumentasikan semua yang Anda lakukan dan tidak mengerti, maka pengembang sebelumnya gagal bukan karena mereka tidak tahu bagaimana mengkomunikasikan spesifikasi, tetapi karena tidak mungkin melakukannya.

Menurut saya baik (pelanggan dan pengembang) harus mendapatkan pemahaman yang sama tentang masalah dan solusinya.

Jika Anda tidak mengerti permintaan Anda, Anda tidak dapat membuat solusi.

Jadi, Anda harus membaca spesifikasi. Jika spek tidak cukup jelas (atau tidak ada spek tertulis) harus ada seseorang yang bisa memberikan jawaban.

Saya bekerja dalam tim yang memiliki satu orang yang dapat menjawab pertanyaan bisnis. Pemilik bisnis ini adalah anggota dari perusahaan pengembangan tempat saya bekerja yang mengetahui bisnis pelanggan atau anggota tim pelanggan.

Tampaknya dalam sitasi spesifik Anda, manajer proyek khawatir bahwa pelanggan akan kesal jika mereka ditanyai pertanyaan yang sama beberapa kali (diperlukan karena pergantian pengembang), dan bahwa ini akan berdampak buruk pada dirinya dan perusahaannya.

Tentu saja, jika Anda tidak mengajukan pertanyaan-pertanyaan itu, Anda akan membutuhkan waktu lebih lama untuk menyelesaikan / memodifikasi sistem dan hasilnya mungkin bukan yang diinginkan pelanggan, yang akan menyebabkan lebih banyak penundaan dan JUGA merefleksikan manajer proyek dan manajernya dengan buruk. perusahaan, setidaknya di mata pelanggan.

Ada beberapa alasan mengapa manajer proyek mungkin memilih untuk tidak membiarkan Anda mengajukan pertanyaan:

1. Dia tidak benar-benar memahami konsekuensi negatif atau membantahnya.
2. Dia menyadari alternatifnya tetapi tahu pelanggan lebih mungkin menerima penundaan dan kualitas buruk daripada pertanyaan yang mengganggu.
3. Dia bermain permainan politik: mungkin dia tahu dia akan segera meninggalkan proyek dan ingin menyembunyikan masalah sampai saat itu, atau dia berencana menyalahkan Anda untuk masalah yang disebabkan oleh kurangnya komunikasi.

Alasan IMO 2 tidak mungkin. Untuk menghilangkan alasan 1, coba jelaskan alternatifnya dan minta dia untuk membuat pilihan eksplisit di antara mereka - sarankan untuk menjelaskan masalahnya kepada pelanggan untuk mengurangi gangguan. Untuk menghilangkan alasan 3, lakukan ini secara tertulis sehingga Anda dapat membuktikan bahwa Anda mengetahui potensi probleam sejak dini dan mencoba memperbaikinya. Tapi jujur ​​saja, jika Anda mencurigai ini perlu, Anda mungkin harus keluar sana secepat mungkin.

Saya pikir itu selalu menjadi tanggung jawab penyedia layanan untuk memastikan bahwa mereka telah memahami niat klien.

Sebagai ahli di bidang kami, bukan hanya tugas kami untuk menyelesaikan briefing tetapi juga untuk membantu membimbing pelanggan kami melalui proses menggunakan layanan kami, dan ini melibatkan mendidik mereka tentang kemungkinan yang kami tawarkan, dan apa yang kami lakukan sekarang.

Saya percaya pendekatan yang berfokus pada pelanggan benar-benar cara untuk melakukan sesuatu, ini adalah model bisnis yang telah dicoba dan diuji.

Pelanggan dan pengembang perlu bekerja sama untuk memperbaiki pemahaman mereka tentang sistem.

Perusahaan perangkat lunak perlu mencapai kesepakatan dengan klien mengenai apa yang diperlukan dari masing-masing pihak, yaitu aspek mendasar dari suatu kontrak. Jika tidak ada "pertemuan pikiran" maka, dalam arti yang sangat nyata, tidak ada kontrak.

Menganggap bahwa Anda adalah seorang programmer yang kompeten, jika spesifikasinya tidak jelas maka cukup dikatakan "Ini adalah tanggung jawab Anda untuk memahami permintaan, bukan mengajukan lebih banyak pertanyaan" agak konyol.

Ini didasarkan pada beberapa informasi baru di komentar pada pertanyaan awal.

Pernyataan itu

pelanggan sudah menjelaskan kepada kami, apa yang dia inginkan. Adalah tanggung jawab Anda untuk memahami permintaan, bukan untuk bertanya lebih lanjut

berasal dari pemimpin proyek; alasan yang dinyatakan adalah

bahwa karena saya bukan pengembang pertama pada sistem, kita tidak boleh repot-repot dengan perwakilan klien dengan lebih banyak pertanyaan, tetapi cobalah untuk dan jika perlu, menghabiskan waktu ekstra menafsirkan pertanyaan

Jadi, apa yang secara spesifik diperintahkan kepada Anda untuk dihindari adalah mengganggu pelanggan dengan pertanyaan .

Meminta Anda untuk "menghabiskan waktu ekstra menafsirkan pertanyaan" tidak selalu tidak masuk akal. Anda harus melakukan upaya yang masuk akal, atau mungkin bahkan upaya yang sedikit tidak masuk akal, untuk mencari tahu apa persyaratan didasarkan pada apa yang sebenarnya dikatakan pelanggan. Jika tidak ada yang lain, itu adalah keterampilan yang berharga.

Jika gagal (dan sepertinya sudah, karena berbagai alasan), maka minta bantuan pimpinan proyek Anda. Cobalah untuk sespesifik mungkin dalam pertanyaan Anda, menunjukkan bahwa Anda telah menyelesaikan pekerjaan rumah Anda. Misalnya, bukan

apa yang orang-orang ini inginkan ??? "

tanyakan sesuatu seperti,

Dalam paragraf 17 dokumen persyaratan, dikatakan bahwa foobar harus membekukan frozzle; yang mana dari ketiga kerekan yang dimaksud? "

Atau, jika persyaratan ditulis dengan sangat buruk sehingga Anda tidak dapat menguraikannya, katakan padanya.

Saya akan mengatakan bahwa pada akhirnya tanggung jawab pemimpin proyek untuk memastikan bahwa persyaratan dipahami dengan benar (tentu saja demi kepentingan terbaiknya agar proyek berhasil). Tetapi sebagai anggota tim, Anda berbagi sebagian dari tanggung jawab itu. Jika Anda menunjukkan bahwa Anda telah melakukan upaya sendiri, dan pemimpin proyek menolak untuk membantu Anda, maka dia membuat itu sepenuhnya menjadi tanggung jawab Anda. Jika sampai pada titik itu, pastikan dia tahu itu.

Dalam dunia yang sempurna, harus ada daftar fitur dan spesifikasi di suatu tempat, sesuatu yang tertulis pada kontrak yang mengikat perusahaan Anda dan pelanggan Anda.

Untuk menjawab pertanyaan Anda, pengembang harus benar-benar memahami apa yang diinginkan pelanggan, dan memiliki dokumen tertulis sehingga kedua belah pihak setuju dengan visi yang sama.

Tentu saja, ini bukan dunia yang sempurna dan seringkali tidak ada spesifikasi, dan jika Anda tidak memiliki spesifikasi tertulis, ya, ini akan sulit. Adakah yang tersisa di perusahaan Anda yang bekerja sebagai delegasi hubungan dengan pelanggan, yang dapat membantu Anda memahami apa yang diinginkan pelanggan?

Jika tidak, di posisi Anda, saya akan mencoba dan mendapatkan info dari pengembang sebelumnya, dengan asumsi mereka mengerti tugasnya.

Saya pikir peran sebenarnya yang menentukan siapa yang memahami persyaratan bervariasi tergantung pada beberapa variabel ini

• Ukuran tim
• Standar perusahaan
• Cara bos terbiasa bekerja
• Keahlian yang berbeda di antara anggota tim

Jadi jika Anda hanya tim satu orang, Anda harus melakukan segala upaya untuk sampai ke bagian bawah permintaan. jika Anda baru dalam proyek yang sedang berjalan, Anda harus berusaha untuk membahas kembali permintaan dengan pelanggan.

EDIT: Yang paling penting, pelanggan mungkin tidak tahu dia membuat persyaratan yang buruk, dan proses mengumpulkan persyaratan seringkali panjang dan membosankan, tetapi ini adalah proses yang penting, dan jika itu jatuh pada Anda karena tidak ada orang lain yang melakukannya, maka Anda harus lakukan dengan mereka.