verifikasi persyaratan pengguna, bagaimana?

Pertanyaan saya adalah: Bagaimana Anda bisa memverifikasi persyaratan pengguna di awal proses pembuatan perangkat lunak?

Saya menunjukkan spesifikasi, prototipe, demo ... tetapi pengguna masih lupa untuk membagikan beberapa "detail tidak penting" tentang proses atau aturan bisnis dan data. Yang muncul setelah tes akhir sebagai beberapa "pengecualian sangat kecil dan langka" - yang diubah menjadi permintaan perubahan dan mengumpulkan banyak pekerjaan.

Jadi, bagaimana Anda membuat prototipe (atau memverifikasi) persyaratan pengguna di awal proyek?

Gunakan pengembangan berulang yang memaksa Anda untuk sering memberikan umpan balik kepada pelanggan / pengguna.

Juga tingkatkan kolaborasi antara pengembang dan pengguna dengan menghapus perantara (biasanya tidak berguna) seperti manajer proyek atau bahkan analis bisnis (yang terakhir bisa sangat diperlukan dalam domain bisnis yang sangat kompleks).

Itu hanya beberapa rekomendasi. Ada banyak yang bisa dikatakan tentang masalah ini.

Saya sangat menyarankan Anda untuk melihat Scrum . Yang menyelamatkan hidupku.

Mulailah dengan tidak menyingkirkan perantara seperti analis bisnis, karena mereka sebenarnya terlatih dalam hal ini. Jika Anda tidak memiliki orang-orang seperti itu, terimalah bahwa setidaknya salah satu pengembang Anda perlu mengembangkan keterampilan ini.

Selanjutnya, seiring berjalannya waktu, terkumpul serangkaian naluri tentang hal-hal yang sering diminta orang di proyek, dan membawa mereka dalam percakapan di awal proyek. "Apakah diskon akan selalu sama untuk semua pesanan, atau apakah itu berbeda menurut pelanggan?" "Bisakah setiap pengguna melihat setiap laporan, atau sebagian hanya untuk pengawas?" "Apakah pajak penjualan selalu sama, atau apakah itu tergantung di mana pelanggan berada?" dan seterusnya.

Selain itu, cobalah untuk menulis kode Anda sehingga terisolasi dari jenis perubahan yang datang terlambat, karena beberapa masih akan datang terlambat tidak peduli apa. Jika Anda memiliki logika bisnis di penangan klik untuk tombol Anda, perubahan ini sangat merugikan. Jika Anda memiliki logika bisnis di kelas tertentu yang namanya memudahkan Anda menemukannya, dan Anda dapat memanfaatkan polimorfisme untuk, katakanlah, memiliki pesanan reguler dan mempercepat pesanan dan setiap pesanan menghitung biaya pengirimannya sendiri, maka perubahan yang mereka miliki meminta jauh lebih menyakitkan.

Anda tidak dapat mencegah perubahan yang terlambat. Hukum berubah, penggerak bisnis (pelanggan, penjualan apa yang menjanjikan, gagasan hebat yang dimiliki CEO saat membaca sesuatu di pesawat) berubah. Cegah apa yang Anda bisa dan merangkul yang lain dengan merancang kode Anda agar bisa berubah.

Anda benar-benar hanya perlu sepanjang jalan memastikan Anda memenuhi kriteria yang tercantum di sana. Misalnya jika dikatakan "fungsionalitas x harus tersedia untuk semua pengguna" maka pastikan ini benar.

Di awal proses pengembangan ini akan sulit tetapi lebih dekat dengan tenggat waktu semakin Anda harus dapat memverifikasi.

Mungkin hal-hal yang belum Anda terapkan, Anda dapat memverifikasi mereka dalam pertimbangan desain sehingga Anda tahu mereka sedang dipertimbangkan selama pengembangan awal.

Saya ingat berada dalam pertemuan bisnis dan memiliki salah satu analis bisnis yang mengatakan bahwa pasti hebat menjadi pengembang selalu memiliki spesifikasi tetap untuk bekerja.

Di dunia nyata, ada beberapa hal yang sangat membantu dalam hal ini. Yang pertama, adalah menerima bahwa detail-detail terakhir ini adalah fakta kehidupan. satu-satunya spesifikasi lengkap 100% dari produk akhir adalah kode sumber. Jika pelanggan sudah memiliki ini, maka mereka tidak perlu Anda menulisnya bukan?

Hal kedua yang harus dilakukan adalah secara aktif mencoba menghilangkan detail spesifikasi yang hilang. sekarang Anda bisa mencoba membuat pelanggan untuk menandatangani 300 halaman Gunakan dokumen Kasus dan mekanisme kontrak lainnya, tetapi pada akhirnya, saya dapat mengatakan dengan kepercayaan 100%, cara terbaik adalah memberikan perangkat lunak kepada pelanggan Anda. Mintalah mereka untuk memeriksanya, menggunakannya, secara aktif mendorong mereka untuk mengubah spesifikasi sesuai dengan kebutuhan mereka (dan ketika sesuai untuk membebankan biaya untuk pekerjaan mereka). Bahkan ketika hanya beberapa fitur yang diterapkan, umpan balik pelanggan adalah kuncinya.

Yang ketiga, ketika membaca spesifikasi, pikirkan tentang apa yang menyebabkan persyaratan ini berubah dan bagaimana Anda dapat menangani variasi. sering kali tidak masuk akal untuk merekayasa secara berlebihan untuk perubahan yang mungkin tidak muncul, tetapi memiliki rencana, dan yang sama pentingnya tidak merancang dalam kesulitan ekstra akan membuat hidup Anda lebih mudah - dan poin brownies tambahan untuk menjaga ketenangan dan kepercayaan diri Anda ketika Anda mengatakan "Kita bisa mengatasinya dengan .... dan itu akan memakan waktu sekitar 4 hari untuk dilakukan." akan menginspirasi orang lain untuk memiliki kepercayaan pada Anda.

Saya pikir Anda tidak boleh melupakan pihak lain. Untuk pengguna mana pun, sulit untuk menghasilkan daftar detail lengkap dari apa yang Anda inginkan. Pikirkan diri Anda sendiri, Anda memikirkan hal-hal baru setiap saat.

Ini adalah kerja keras yang luar biasa untuk menghasilkan semua persyaratan dan detail dari sesuatu yang hanya Anda miliki dengan gagasan yang kabur. Saya tidak berpikir siapa pun bisa.

Saya punya buku di sini dari tahun 70-an yang disebut "mengapa proyek perangkat lunak gagal". Ketika saya membaca di blog dan mendapatkan majalah IT saya membaca di sampul "mengapa proyek perangkat lunak gagal". Dan ketika saya membandingkan konten buku dengan daftar saat ini .... tidak ada yang berubah. Pengembangan berulang: ya banyak variasi dan itu membantu pada tingkat tertentu. Namun setelah sekian lama isi majalah memiliki sampul yang sama. Jika Anda tidak percaya saya gali beberapa magz dari masa lalu dan lihat bagaimana Anda dapat menyalin dan menempelkan teks ke sekarang.

Masalah ini tidak dapat dipecahkan pada akhirnya. Kami telah menemukan alat baru, proses, daftar periksa, skema analisis persyaratan, kasus penggunaan (bisnis), kerangka kerja pengembangan, BPM, SOA, Anda menyebutnya dan masih ada masalah yang sama ...

Anda perlu mengoptimalkan ini di sekitar 'specifier persyaratan'. Jadi, Anda perlu memberi orang-orang itu alat yang memadai, apa pun yang memungkinkan mereka untuk meningkatkan level mereka :

Jadi mis. Untuk orang-orang ini: pola-pola tertentu di luar kotak, masukan dari proyek-proyek lain dan perusahaan yang melakukan hal yang sama menyalin persyaratan dan hasil akhir pelajaran mereka, membuat orang-orang di sana yang telah melalui kotoran dan dapat membantu orang ini untuk menentukan hal-hal yang menyebabkan masalah terbesar dan bukan "sepele" tetapi hanya dapat dipelajari setelah melakukannya (misalnya konsultan teknis senior yang melakukan hal yang sama di perusahaan lain), berikan orang-orang ini persyaratan perkakas komposer, untuk asuransi, bank, telekomunikasi dll ... : jangan menemukan proses Anda sendiri, beli proses generik di luar kotak, dll ... mereka PERLU alat seperti pengembang membutuhkan alat dan pola dan kerangka kerja.

Tidak menyelesaikannya tetapi memperbaikinya secara signifikan IMHO perbaikan harus di sekitar area itu dan tidak lebih lambat.

Sama seperti pengembang, orang-orang ini hanya berusaha melakukan yang terbaik yang mereka bisa. Tapi tidak seperti pengembang untuk bidangnya, sebagian besar barang yang kami terima begitu saja setelah 30 tahun bahkan tidak ada di bidang itu. Secara umum alat mereka adalah pandangan, keunggulan, kata dan papan. Proses mereka adalah sesi curah pendapat. Banyak perbaikan yang bisa dilakukan di bidang ini. Ofcourse masalahnya adalah kebanyakan mereka duduk "di luar" IT sehingga bahkan rencana dari CIO untuk memperbaiki situasi di bidang itu jatuh di telinga tuli ... tapi itu pertanyaan lain: bagaimana "menjual" ini.

Masalah Ayam-Telur

Apa yang Anda perjuangkan disebut masalah ayam-telur dalam fase analisis kebutuhan perangkat lunak. Klien tidak membagikan detail persyaratan karena mereka tidak tahu arsitektur detail dan arsitek tidak dapat membuat arsitektur detail karena mereka tidak tahu detail semua persyaratan.

Solusi Twin-Peak

Namun ada solusi yang terkenal untuk masalah ini. Itu adalah model puncak kembar. Dalam model ini Anda harus membuat beberapa iterasi komunikasi dengan klien mulai dari persyaratan umum hingga persyaratan spesifik serta Anda harus mengembangkan arsitektur Anda dari detail umum ke spesifik.

Keuntungan dari model Twin-Peak:

• Persyaratan memperhitungkan batasan sistem
• Pengembangan cepat alternatif desain
• Pembuatan prototipe dengan cepat
• Pengembangan arsitektur yang efisien melalui penggunaan solusi yang ada
• Beban kerja persyaratan dapat diperkirakan dari rencana arsitektur kasar pertama
• Pengurangan biaya karena persyaratan "tidak realistis" diidentifikasi sebelum solusi dikembangkan
• Pengurangan risiko dalam pembangunan

Referensi

Anda harus memberi tahu pengguna bahwa nanti 'persyaratan' diidentifikasi dalam proyek, semakin banyak biayanya. Mereka mungkin memutuskan bahwa mereka sebenarnya tidak membutuhkan perubahan. Jika mereka bersikeras perubahan, tetapi menolak biaya tambahan / waktu tunda, Anda memiliki masalah yang perlu dinegosiasikan. Itu tidak akan diselesaikan melalui teknologi atau perencanaan tetapi dengan penjualan dan manajemen hubungan klien.

Terus mendapatkan perangkat lunak yang berfungsi di depan mereka DAN mengharuskan mereka melakukan upaya untuk menggunakan / menguji / mengevaluasi adalah taruhan terbaik Anda. Mereka tidak akan sepenuhnya memahami kontrak, spesifikasi, diagram, dan cerita pengguna.

Ini adalah bagian dari Tes Joel. Ambil siapa saja yang dapat Anda temukan untuk menguji perangkat lunak sebanyak mungkin selama seluruh proses pengembangan.

Jika Anda benar-benar ingin melakukan pekerjaan dengan benar, sebelum Anda mulai mengerjakan kode atau mendesain arsitektur, duduklah bersama beberapa orang yang akan menjadi pengguna kode Anda (bukan manajemen mereka atau pemangku kepentingan tingkat lebih tinggi lainnya) dan dapatkan mereka untuk menunjukkan kepada Anda bagaimana melakukan pekerjaan mereka. Idealnya benar-benar melakukan pekerjaan selama satu atau dua hari. Itu akan memberi Anda pemahaman tentang cara sistem saat ini bekerja dan jenis orang yang melakukannya. Ini juga akan menunjukkan kepada Anda frustrasi yang mereka miliki dengan sistem saat ini dan hal-hal yang memukul produktivitas mereka. Anda juga perlu mendengar semua keluhan dan gangguan sehari-hari, yang mungkin berarti Anda harus melakukan apa yang perlu untuk memastikan umpan balik mereka berhenti pada Anda atau tim desain Anda, jika gagasan untuk menyampaikan pandangan mereka kepada anggota lain dari organisasi mereka adalah kemungkinan menghambat itu.

Untuk setiap kelompok pengguna, Anda perlu memiliki seseorang yang akan mengerjakan pengembangan bagian dari perangkat lunak yang melakukan hal yang sama. Kemudian Anda semua dapat bertemu dan mendiskusikan apa yang telah Anda pelajari dalam peran yang telah Anda bayangi untuk melihat apakah ada bidang crossover dan bagaimana Anda dapat membuat hal-hal termudah untuk semua orang yang terlibat.

Saya tidak menyarankan ini menggantikan proses pengumpulan persyaratan lainnya, tetapi ini adalah suplemen yang memungkinkan Anda memahami apa yang dibutuhkan pengguna nyata dari sistem Anda. Apa pun manajemen yang mereka pikir perlu, ada kemungkinan bahwa manajer dan analis bisnis tidak akan menjadi pengguna sistem yang sebenarnya, tetapi jika Anda dapat membuat sistem bekerja dengan baik bagi para pengguna, itu akan membuat mereka lebih produktif, membuat manajer bahagia dan membuat perusahaan Anda terlihat bagus.