Biarkan pengguna mendapatkan persyaratan bersama atau membimbing mereka?

Saya yakin semua orang pernah mengalami hal seperti ini. Anda pergi ke pertemuan dengan klien yang memiliki proyek. Mereka tidak memiliki / sedikit persyaratan dalam pikiran dan pemahaman yang samar tentang apa yang mereka inginkan / butuhkan. Pada titik ini, tampaknya ada dua opsi:

1) Beri tahu para pengguna, "Oke, jadi saya tidak bisa membuatkan sesuatu untuk Anda jika Anda bahkan belum bisa menggambarkannya. Mengapa kita tidak kembali bersama dalam beberapa minggu ketika Anda tahu apa yang Anda inginkan".

2) Bertemu dengan pengguna beberapa kali dan membantu mereka mengetahui apa yang mereka inginkan dengan membimbing mereka melalui metode Sokrates yang baik. "Apakah Anda perlu melacak X?", "Bagaimana dengan Y?", "Apakah Anda memerlukan fungsionalitas Z?"

Dengan opsi pertama, Anda tidak terjebak melakukan pekerjaan orang lain, atau mendapatkan kekuatan psikis, namun, pengguna mungkin tidak akan pernah memberi Anda spesifikasi yang koheren, atau mereka mungkin butuh waktu lama karena tenggat waktu terus mendekat. Dengan opsi kedua, Anda membuang banyak waktu menjadi analis bisnis, dan harus menjejalkan banyak pengetahuan bisnis ke dalam kepala Anda bahwa Anda mungkin tidak akan pernah menggunakannya lagi, tetapi Anda akan lebih mungkin untuk keluar dengan spesifikasi yang masuk akal.

Bagi saya, ini adalah salah satu aspek pembangunan yang paling menantang, dan saya merasa saya tidak sendirian dalam sentimen ini. Dalam pengalaman Anda, mana dari opsi ini yang cenderung bekerja lebih baik?

Saya harus mengakui bahwa terkadang saya memilih opsi 3)

3) Dengarkan ide-ide klien yang samar-samar, pucatlah ide menghabiskan minggu membantu mereka mencari tahu apa yang mereka inginkan ... jadi cari tahu apa yang mereka butuhkan, bangun itu, dan refactor sesuai kebutuhan.

Ini bekerja, terutama untuk pekerjaan kecil, karena membantu menghindari situasi di mana klien memiliki ide cemerlang di kepala mereka, yang tidak praktis di dunia nyata.

Itu terjadi pada saya sepanjang waktu; "tentu saja kita bisa melakukan ..." adalah ungkapan yang sangat menakutkan. Terutama karena hal-hal yang disebutkan hampir selalu lonceng, peluit dan kelas fitur "nice to have". Mereka tidak cukup memahami hal itu dalam pernyataan "jelas pelacak kutu, dan kemudian ..." sebagian besar pekerjaan potensial terletak pada empat kata pertama.

Jadi, kadang-kadang itu baik untuk mengambil visi klien , menerapkan dosis yang wajar dari akal sehat-programmer, dan membangun sesuatu yang sesuai dengan kebutuhan mereka.

Dalam hal pertanyaan awal; Saya menemukan itu sangat tergantung pada konteksnya. Jika terjebak dengan klien (yaitu melalui kontrak kerja saya terikat, atau tidak ada pekerjaan alternatif) maka # 2 adalah pendekatan yang paling sehat. Kalau tidak, ada kemungkinan besar bahwa dalam seminggu Anda akan disajikan dengan spesifikasi yang indah dan terperinci ... yang sama sekali tidak berguna bagi Anda sebagai seorang programmer.

Banyak masalah yang sama seperti yang disebutkan di atas (# 3) dan satu yang membuat Anda harus melakukan # 2 pula.

jika Anda ingin menjadi seorang programmer, maka Anda menunggu sampai orang lain mengetahui apa yang dibutuhkan klien dan kemudian mengkodekannya

jika Anda ingin menjadi pengembang , dan ini adalah klien Anda , maka Anda mengambil tangan klien Anda dan dengan lembut menuntun mereka melalui hutan kemungkinan yang menakutkan sampai bersama-sama Anda menemukan padang rumput yang dipenuhi kelinci yang bahagia di persimpangan Wants and Needs.

TAMBAHAN: proses ini disebut "analisis dan desain sistem" alias Konsultasi, dan tidak boleh dilakukan secara gratis

Pemrograman awalnya tentang memecahkan masalah pengguna. Jadi bagi saya, melakukan upaya dan rasa sakit "ekstra" untuk mendapatkan solusi yang berfungsi dan memuaskan bagi pengguna kami hampir selalu menang karena menghindari kerumitan "ekstra", dan tidak memberikan apa pun yang bermanfaat pada akhirnya.

(Tentu saja, ada pengguna nyata di luar sana yang benar-benar tidak tahu apa yang mereka inginkan, dan tidak ada upaya yang dapat membuat mereka dalam keadaan di mana mereka dapat membuat keputusan yang berarti. Tetapi saya percaya bahwa dalam sebagian besar kasus mereka memang memiliki masalah nyata, mereka rela mengeluarkan usaha dan uang untuk menyelesaikannya, dan mereka akan senang jika kita dapat membantu mereka lebih dekat dengan solusi kerja.)

Jadi intinya adalah, fokus kami harus menyelesaikan masalah pengguna. Ini kadang-kadang mungkin memerlukan mengajukan beberapa pertanyaan yang ditargetkan dan memberi mereka lebih banyak waktu untuk mencari tahu jawabannya. Terkadang diperlukan pemetaan domain bersama, dalam kerja sama yang erat. Kadang-kadang perlu menghabiskan waktu membuat sketsa / prototipe / maket sederhana, kemudian menunjukkan hasilnya dan bertanya "apakah ini terlihat seperti apa yang ada dalam pikiran Anda?" (lalu membuang prototipe ketika mereka berkata "sebenarnya, saya sedang memikirkan sesuatu yang sama sekali berbeda ..." dan mulai lagi dari ... :-)

Keahlian nyata adalah dalam memilih pendekatan yang tepat untuk waktu yang tepat.

Last but not least, dalam pengalaman saya, solusi yang baik hampir selalu membutuhkan setidaknya beberapa pengetahuan domain dari bagian pengembang. Tanpa ini, Anda tidak memiliki bahasa umum yang nyata dengan pengguna, sehingga tidak ada jaminan apa pun yang Anda berikan benar-benar bermanfaat bagi mereka. Pengguna biasanya tidak memiliki banyak petunjuk tentang teknologi, jadi tidak tahu apa yang bisa dan tidak mungkin, dan berapa biaya pendekatan / fitur yang berbeda. Karena kita tidak dapat secara wajar mengharapkan mereka untuk mempelajari teknologi hingga detail yang cukup, kita harus mengambil langkah ekstra dari ujung jembatan kita.

Ini mungkin dilihat sebagai upaya "ekstra" yang tidak membuahkan hasil - namun, saya lebih suka melihatnya sebagai investasi, karena dua alasan:

• itu membantu saya memberikan solusi yang baik, yang dalam jangka panjang meningkatkan nilai pasar saya sebagai pengembang, dan
• domain yang berbeda tidak sepenuhnya berbeda, jadi setidaknya sebagian dari pengetahuan domain itu mungkin akan dapat digunakan kembali di pertunjukan mendatang.

Sebagai pengembang perangkat lunak, bagian dari tugas Anda adalah untuk mendapatkan pemahaman yang memadai tentang domain tempat perangkat lunak tersebut akan digunakan. Dengan demikian, menjadi bagian dari fase awal proyek sangat berharga (dalam hal waktu dan pengalaman pelanggan) . Ya, ini berarti melakukan analisis domain dan persyaratan yang menyeluruh. Ini adalah waktu yang tepat untuk menggabungkan target pengguna, mewawancarai mereka atau berjalan di sekitar lokasi di mana perangkat lunak Anda akan digunakan.

Tapi, untuk mendapatkan keterampilan ini hampir merupakan bentuk seni, terutama ketika domain tidak terhubung dengan disiplin teknik. Pertanyaan Anda yang jelas mungkin tampak menakutkan bagi pelanggan, kehadiran Anda di tempat mungkin tidak diinginkan, kurangnya pemahaman Anda tentang struktur sosial audiens target Anda mungkin menghancurkan koneksi yang masih rapuh.

Gagal memahami seluk-beluk fase ini sering menyebabkan kekecewaan, baik dengan pengembang perangkat lunak, seperti halnya dengan pelanggan. Kami ingin melewati fase ini lebih cepat atau menyelesaikannya sepenuhnya. Hasilnya sering kali membawa malapetaka: setelah awal yang cepat, selama perkembangan taruhannya semakin tinggi dan semakin sulit untuk kembali ke papan gambar. Ketika sistem akhirnya selesai dan jutaan telah dihabiskan, baik pelanggan, maupun perusahaan teknik tidak mau mengakui kegagalannya, yang mengarah pada pengenalan paksa sistem yang gagal.

Alternatifnya adalah membiarkan analis bisnis melakukan pekerjaan untuk Anda. Ini mungkin masuk akal untuk beberapa produk, dan analis sering dapat menjadi perantara, tetapi hanya akan menciptakan lebih banyak saluran komunikasi (dan dengan demikian kemungkinan kesalahan yang lebih tinggi).

Dalam kasus apa pun: menulis ulang sepotong kode tidak pernah melebihi menulis ulang sepotong persyaratan.

ps mungkin Anda pikir saya menganjurkan metode air terjun. Saya bukan orang yang percaya 'desain besar di muka', tapi saya yakin upaya analisis domain harus sebanding dengan upaya implementasi. Seseorang dapat membuat banyak siklus (prototipe, kandidat rilis, dll.).

Pilihan 2 kecuali jika pengguna Anda adalah pengembang (bahkan mungkin opsi 2 diperlukan).

Banyak siklus pengembangan perangkat lunak yang paling fokus pada pengumpulan kebutuhan. Tidak hanya sebagian besar pengguna tidak tahu apa yang mereka inginkan, mereka juga tidak tahu apa yang mungkin, jadi bekerja sama dengan pengguna untuk memahami apa yang dibutuhkan pengguna adalah tugas pengembangan perangkat lunak yang penting.

Saya pikir Anda harus menggunakan kedua opsi. Biarkan mereka pergi dan memutuskan apa yang mereka inginkan. Kemudian, ketika ada ide konkret untuk digunakan sebagai titik awal, pandu mereka untuk membantu memperbaiki persyaratan menjadi sesuatu yang bermanfaat.

Anda tidak ingin melompat ke Opsi # 2 ketika mereka hampir tidak dapat mengartikulasikan apa yang mereka inginkan karena akan membuat seluruh proses lebih lambat dan lebih membuat frustrasi (kecuali mereka sudah memiliki ide yang sangat jelas tentang apa yang mereka inginkan ketika mereka mendatangi Anda, tetapi dalam pengalaman saya ini sangat jarang). Buat mereka mengumpulkan ide-ide mereka. Mintalah mereka menuliskan sesuatu di atas kertas, buat jelaskan apa yang mereka inginkan dalam hal sistem yang ada jika memungkinkan (mis. "Kami ingin situs web seperti blahblah.com tetapi dengan perbedaan ini ... kami ingin alat yang mengerjakan Tugas A seperti Produk X , tetapi UI juga harus melakukan Tugas B ... "). Maka ini saat yang tepat untuk mulai memperbaiki apa yang mereka inginkan menjadi persyaratan yang sangat spesifik yang dapat Anda gunakan untuk membangun sistem.

Secara umum, klien akan datang kepada Anda mengetahui persis apa yang mereka pikir mereka butuhkan. Sayangnya, ini adalah apa yang akan mereka katakan kepada Anda, alih-alih menggambarkan masalah yang mengarah pada solusi yang mereka pikir akan Anda berikan.

Untuk merancang sesuatu yang akan memenuhi kebutuhan mereka, Anda harus mengidentifikasi kebutuhan itu, dan untuk melakukan itu, seseorang harus menahan klien dan mengekstrak kebutuhan itu. Jika tidak ada orang lain yang bisa melakukannya, maka Anda harus melakukannya. (Jika orang lain berpikir mereka bisa, Anda mungkin harus duduk bersama mereka dan mengekstrak kebutuhan sebenarnya nanti ...)

Dengan opsi 2, selama beberapa pertemuan, Anda diharapkan dapat melatih klien untuk berbagi masalah dengan Anda alih-alih solusi. (Bahkan jika klien memiliki kemampuan teknis - misalnya, mereka tidak memiliki ketersediaan untuk melakukan pekerjaan ini dan Anda perlu melakukannya - mereka mungkin masih fokus pada implementasi yang tidak ideal untuk klien akhir.) apa pun proses pengembangan yang Anda gunakan, Anda masih harus bolak-balik beberapa kali sampai mereka dapat menjawab pertanyaan dengan cara yang akan menentukan spesifikasi untuk Anda.

Ingat, Anda ingin menangkap cacat sedini mungkin dalam siklus pengembangan. Jika Anda dapat menangkap mereka selama persyaratan daripada selama pengkodean atau pengujian, Anda akan menghemat banyak waktu.

Opsi 1 adalah cara terbaik untuk menghindari melakukan pekerjaan. Saya sudah menggunakannya ketika saya percaya pekerjaan itu tidak perlu atau saya memiliki hal-hal yang lebih penting untuk dilakukan.

Pertama, pengguna tidak tahu apa yang bisa dilakukan komputer. Sebagian besar dari kita telah menghabiskan waktu bertahun-tahun belajar untuk memahami komputer dan komputasi, dan apa yang jelas bagi kita mungkin tidak mudah dimengerti bagi seseorang yang menghabiskan tahun-tahun itu mempelajari hal-hal lain.

Kedua, pengguna tidak perlu tahu apa yang mereka butuhkan, dan biasanya tidak tahu apa yang mereka inginkan, dalam arti apa pun yang dapat ditindaklanjuti.

Sebagai analogi, ketika saya membeli rumah saya saat ini, seorang desainer interior memilih warna dinding untuk kamar-kamar di lantai utama (pertama di Inggris). Saya tidak akan pernah memilih warna-warna itu sendiri. Saya ingin rumah yang terlihat bagus, dan mendapatkannya. Jika perancang mendengarkan saya dan memberi saya apa pun yang bisa saya ungkapkan, itu tidak akan keluar juga.

Satu-satunya cara memberi pengguna sesuatu yang melakukan apa yang mereka butuhkan dengan cara yang mereka sukai adalah bekerja dengan mereka sendiri.