Penyebab utama frustrasi Anda dengan situasi ini mungkin salah satu persepsi dan istilah yang menyesatkan / salah digunakan oleh pelanggan. Pelanggan biasanya tidak mendatangi Anda dengan daftar persyaratan , tetapi daftar harapan dari setiap hal yang dapat mereka pikirkan yang mungkin berguna bagi mereka. Itu tidak semua persyaratan karena pelanggan belum menghabiskan waktu untuk benar-benar berpikir jika setiap fitur benar-benar diperlukan .
Ini tidak selalu menjadi masalah
Jika pelanggan Anda memiliki uang untuk semua fitur itu dan bersedia untuk berpisah dengannya, dan Anda tidak benar-benar peduli untuk memecahkan masalah aktual dan nyata yang dimiliki pelanggan, maka ini bisa menjadi proyek yang sangat menguntungkan. Itu terjadi, sangat jarang, dan bagi sebagian besar pengembang itu adalah pekerjaan mematikan jiwa karena Anda dapat merasa di muka bahwa proyek pada akhirnya tidak akan berhasil bagi pelanggan (bahkan jika itu secara finansial berhasil bagi Anda sebagai pengembang). Ini juga berisiko tinggi karena Anda mungkin berakhir dengan proyek biaya tetap dengan banyak ketidakpastian, dan itu benar-benar masalah untuk salah menilai risiko pada proyek besar.
Bagaimana jika itu masalah?
Mari kita asumsikan Anda tidak dalam situasi langka itu. Dalam hal ini Anda akan ingin mengatasi dua kekurangan utama dari daftar keinginan seperti yang diberikan:
- Tidak mungkin pelanggan memiliki gagasan yang benar tentang biaya pengembangan daftar persyaratan yang sedemikian besar, sehingga Anda tidak mungkin mendapatkan kontrak untuk jumlah uang yang sebenarnya Anda perlukan untuk melakukannya.
- Tidak mungkin daftar keinginan ini secara akurat dan ringkas menggambarkan masalah nyata yang dimiliki dan ingin dipecahkan oleh pelanggan.
Dalam pengalaman saya, Anda perlu mengatasi 2 untuk memperbaiki 1. Mengebor ke masalah sebenarnya berarti bahwa Anda, pengembang, sekarang memiliki input yang diperlukan untuk membuat lompatan kreatif dalam memecahkan masalah dengan cara yang bahkan tidak pernah dipikirkan oleh pelanggan sendiri. Solusi ini cenderung jauh lebih murah dan lebih cepat daripada implementasi daftar keinginan lengkap.
Bagaimana Anda memperbaikinya?
Seperti yang dikatakan Matthew Flynn dalam jawabannya - mulailah dengan membuat pelanggan memprioritaskan persyaratan. Ini tidak selalu mudah, tetapi paksakan mereka untuk melakukannya. Jika perlu gunakan frasa "Jika seseorang memegang pistol di kepala Anda, satu persyaratan apa yang akan Anda simpan?". Anda akan sering menemukan selama proses ini bahwa pelanggan benar-benar tidak memiliki ide yang sangat jelas tentang apa arti persyaratan individu. Dalam hal itu lakukan apa yang disarankan Peter Rowell dan dapatkan pelanggan untuk bekerja melalui Cerita Pengguna. Anda dan pelanggan akan mulai memahami masalah dan persyaratan dengan lebih baik, dan kemudian Anda dapat kembali ke penentuan prioritas. Ulangi langkah-langkah itu sesering yang Anda butuhkan sampai Anda merasa nyaman bahwa Anda cukup tahu untuk menyelesaikan masalah pelanggan .
Bagaimana hal itu menjawab pertanyaan tentang mengembangkan solusi?
Setelah Anda memiliki daftar persyaratan yang diprioritaskan, Anda memiliki input yang Anda butuhkan untuk menyarankan proses pengembangan tambahan kepada pelanggan Anda. Anda tidak harus menyebutnya Agile, tetapi Anda dapat menyarankan untuk memecah kontrak menjadi bagian-bagian yang lebih kecil untuk setiap persyaratan (atau serangkaian persyaratan yang tidak dapat dibagi) dan mengirimkannya satu per satu dengan validasi oleh pelanggan. Atau Anda bisa habis-habisan dan menggunakan banyak sumber daya yang tersedia online dan offline untuk meyakinkan pelanggan bahwa demi kepentingan terbaik mereka untuk bekerja sama dalam salah satu gaya pengembangan Agile. Dalam kasus apa pun, Anda dapat memberikan proposal kontrak / proyek Anda dalam bentuk yang dengan jelas menyarankan blok bangunan persyaratan ini dalam urutan prioritas, masing-masing dengan biaya dan kesimpulan sendiri. Pegang wortel itu di depan pelanggan,