Saya telah menghabiskan 3 bulan terakhir dalam fase pengumpulan-persyaratan yang melelahkan dan melelahkan dari sebuah proyek besar dan telah belajar, di atas segalanya, bahwa tidak ada solusi satu ukuran untuk semua . Tidak ada proses, tidak ada rahasia, yang akan berhasil dalam setiap kasus. Analisis persyaratan adalah keterampilan yang asli, dan tepat ketika Anda berpikir Anda akhirnya berhasil menyelesaikannya, Anda akan terpapar pada sekelompok orang yang benar-benar berbeda dan harus membuang semua yang Anda ketahui keluar jendela.
Pemangku kepentingan yang berbeda berpikir pada tingkat abstraksi yang berbeda.
Mudah untuk mengatakan "berbicara di tingkat bisnis, bukan teknis", tetapi itu tidak selalu mudah dilakukan . Sistem yang Anda desain adalah gajah dan pemangku kepentingan Anda adalah orang buta yang memeriksanya . Beberapa orang begitu terbenam dalam proses dan rutinitas yang mereka bahkan tidak menyadari bahwa ada adalah sebuah bisnis. Orang lain mungkin bekerja pada tingkat abstraksi yang Anda inginkan tetapi cenderung membuat klaim berlebihan atau bahkan salah, atau terlibat dalam angan-angan.
Sayangnya, Anda hanya perlu mengenal semua individu sebagai individu dan memahami bagaimana mereka berpikir, belajar bagaimana menafsirkan hal-hal yang mereka katakan, dan bahkan memutuskan apa yang harus diabaikan.
Membagi dan menaklukkan
Jika Anda tidak ingin sesuatu dilakukan, kirimkan ke komite.
Jangan bertemu dengan komite. Buat rapat itu sekecil mungkin. YMMV, tetapi dalam pengalaman saya, ukuran ideal adalah 3-4 orang (termasuk diri Anda sendiri) untuk sesi terbuka dan 2-3 orang untuk sesi tertutup (yaitu ketika Anda membutuhkan pertanyaan spesifik dijawab).
Saya mencoba bertemu dengan orang-orang yang memiliki fungsi serupa dalam bisnis. Benar-benar sangat sedikit yang bisa diraih dan sangat banyak ruginya karena melemparkan orang-orang pemasaran di ruangan dengan penghitung kacang. Carilah orang-orang yang ahli dalam satu subjek dan minta mereka untuk membicarakannya.
Pertemuan tanpa persiapan adalah pertemuan tanpa tujuan.
Beberapa jawaban / komentar lain merujuk pada teknik manusia jerami, yang merupakan teknik yang sangat baik untuk orang-orang yang menyusahkan yang sepertinya tidak bisa Anda dapatkan jawabannya. Tapi jangan mengandalkan jerami-orang terlalu banyak, atau orang-orang lain akan mulai merasa seperti Anda railroading mereka. Anda harus dengan lembut mendorong orang ke arah yang benar dan membiarkan mereka datang dengan spesifik sendiri, sehingga mereka merasa seperti mereka memiliki mereka (dan dalam arti, mereka memang memilikinya).
Yang perlu Anda miliki adalah semacam model mental tentang bagaimana Anda berpikir bisnis berjalan, dan bagaimana sistem seharusnya bekerja. Anda harus menjadi pakar domain , bahkan jika Anda bukan pakar di perusahaan tertentu yang dimaksud. Lakukan riset sebanyak mungkin pada bisnis Anda, pesaing mereka, sistem yang ada di pasar, dan hal lain yang bahkan mungkin terkait jarak jauh.
Sekali pada titik itu, saya merasa paling efektif untuk bekerja dengan konstruksi tingkat tinggi, seperti Use Cases, yang cenderung menyenangkan semua orang, tetapi masih penting untuk mengajukan pertanyaan spesifik. Jika Anda memulai dengan "Bagaimana Anda menagih pelanggan Anda?" , Anda berada dalam pertemuan yang sangat panjang. Ajukan pertanyaan yang menyiratkan suatu proses alih-alih menyiarkan proses di awal: Apa saja item baris? Bagaimana mereka dihitung? Seberapa sering mereka berubah? Berapa banyak jenis penjualan atau kontrak yang ada? Di mana mereka dicetak? Anda mendapatkan idenya.
Jika Anda melewatkan satu langkah, biasanya seseorang akan memberi tahu Anda. Jika tidak ada yang mengeluh, beri tepukan pada diri sendiri, karena Anda baru saja secara implisit mengkonfirmasi prosesnya.
Tunda diskusi di luar topik .
Sebagai analis persyaratan, Anda juga berperan sebagai fasilitator, dan kecuali Anda benar-benar menikmati menghabiskan seluruh waktu Anda dalam rapat, Anda perlu menemukan cara untuk menjaga segala sesuatunya tetap pada jalurnya. Ironisnya, masalah ini menjadi yang paling merusak ketika Anda akhirnya tidak membuat orang berbicara. Jika Anda tidak hati-hati, itu dapat menggagalkan kereta yang Anda habiskan begitu banyak waktu untuk meletakkan rel.
Namun - dan saya mempelajari ini dengan cara yang sulit sejak lama - Anda tidak bisa hanya memberi tahu orang-orang bahwa suatu masalah tidak relevan . Ini jelas relevan bagi mereka , jika tidak mereka tidak akan membicarakannya. Tugas Anda adalah membuat orang mengatakan "ya" sebanyak mungkin dan memasang penghalang seperti itu hanya membuat Anda jatuh ke wilayah "tidak".
Ini adalah keseimbangan halus yang dapat dipertahankan banyak orang dengan "item tindakan" - pada dasarnya antrian diskusi yang telah Anda janjikan untuk kembali ke suatu waktu , biasanya ditandai dengan nama-nama pemangku kepentingan yang menganggapnya sangat penting. Ini bukan hanya demi diplomasi - ini juga merupakan alat yang berharga untuk membantu Anda mengingat apa yang terjadi selama pertemuan, dan siapa yang harus diajak bicara jika nanti Anda perlu klarifikasi.
Analis yang berbeda menangani ini dengan cara yang berbeda; beberapa seperti papan tulis atau flip-chart log yang sangat umum, yang lain diam-diam menyadapnya ke laptop mereka dan dengan lembut memisahkan ke dalam topik lain. Apa pun yang Anda merasa nyaman.
Anda butuh agenda
Ini mungkin benar untuk hampir semua jenis rapat tetapi dua kali lipat berlaku untuk pertemuan persyaratan. Ketika diskusi berlanjut, pikiran orang-orang mulai mengembara dan mereka mulai bertanya-tanya kapan Anda akan mendapatkan hal-hal yang benar-benar mereka pedulikan. Memiliki agenda menyediakan beberapa struktur dan juga membantu Anda untuk menentukan, sebagaimana disebutkan di atas, ketika Anda perlu menunda diskusi yang keluar dari topik.
Jangan berjalan di sana tanpa gagasan yang jelas tentang apa yang ingin Anda liput dan kapan . Tanpa itu, Anda tidak memiliki cara untuk mengevaluasi kemajuan Anda sendiri, dan pengguna akan membenci Anda karena selalu berjalan lama (dengan asumsi mereka tidak membenci Anda karena alasan lain).
Mock It
Jika Anda menggunakan PowerPoint atau Visio sebagai alat mock-up, Anda akan menderita masalah itu tampak terlalu halus . Ini hampir merupakan lembah antarmuka pengguna yang luar biasa ; orang akan merasa nyaman dengan gambar serbet (atau gambar buatan komputer yang terlihat seperti gambar serbet, menggunakan alat seperti Balsamiq atau Sketchflow ), karena mereka tahu itu bukan hal yang nyata - alasan yang sama orang dapat menonton karakter kartun. Tetapi semakin mulai terlihat seperti UI yang nyata, semakin banyak orang akan ingin mengambil dan mengaisnya, dan semakin banyak waktu yang mereka habiskan untuk berdebat tentang detail yang pada akhirnya tidak signifikan.
Jadi pasti lakukan mock up untuk menguji pemahaman Anda tentang persyaratan ( setelah tahap analisis awal) - mereka adalah cara yang bagus untuk mendapatkan umpan balik yang sangat cepat dan terperinci - tetapi tetap gunakan lo-fi dan jangan buru-buru mengejek sampai Anda cukup yakin bahwa Anda melihat langsung dengan pengguna Anda.
Perlu diingat bahwa mock up tidak bisa dikirim , itu adalah alat untuk membantu dalam memahami. Sama seperti Anda tidak akan berharap menjadi tawanan tiruan Anda ketika melakukan desain UI, Anda tidak dapat mengasumsikan bahwa desain itu OK hanya karena mereka memberi Anda acungan jempol mock-up. Saya telah melihat ejekan digunakan sebagai tongkat penyangga, atau lebih buruk, alasan untuk mem-bypass persyaratan sepenuhnya; pastikan kamu tidak melakukan itu. Kembali dan ubah tiruan itu menjadi seperangkat persyaratan nyata.
Sabar.
Ini sulit bagi banyak programmer untuk percaya, tetapi untuk sebagian besar proyek non-sepele, Anda tidak bisa hanya duduk satu kali dan menuntaskan spesifikasi fungsional lengkap. Saya tidak hanya berbicara tentang kesabaran selama satu pertemuan; analisis persyaratan adalah berulang dengan cara yang sama dengan kode. Grup A mengatakan sesuatu dan kemudian Grup B mengatakan sesuatu yang benar-benar bertentangan dengan apa yang Anda dengar dari Grup A. Kemudian Grup A menjelaskan ketidakkonsistenan dan ternyata menjadi sesuatu yang lupa disebutkan oleh Grup C. Ulangi 500 kali dan Anda memiliki sesuatu yang secara kasar menyerupai kebenaran .
Kecuali jika Anda mengembangkan beberapa aplikasi CRUD kecil (dalam hal ini mengapa repot-repot dengan persyaratan?) Maka jangan berharap untuk mendapatkan semua yang Anda butuhkan dalam satu pertemuan, atau dua, atau lima. Anda akan banyak mendengarkan, dan banyak berbicara, dan banyak mengulangi diri sendiri. Yang bukan hal yang mengerikan, ingatlah; ini adalah kesempatan untuk membangun hubungan dengan orang-orang yang mau tidak mau akan menandatangani pengiriman Anda.
Jangan takut untuk mengubah teknik atau improvisasi Anda.
Aspek yang berbeda dari suatu proyek sebenarnya membutuhkan teknik analisis yang berbeda. Dalam beberapa kasus, UML klasik (Use Case / Activity diagram) berfungsi dengan baik. Dalam kasus lain, Anda mungkin memulai dengan KSI bisnis, atau bertukar pikiran dengan peta pikiran, atau terjun langsung ke maket meskipun saya sudah memperingatkan sebelumnya.
Intinya adalah bahwa Anda perlu memahami domain sendiri, dan melakukan pekerjaan rumah Anda sebelum Anda menghabiskan waktu orang lain. Jika Anda tahu bahwa departemen atau komponen tertentu hanya memiliki satu use case, tetapi ini adalah insanely rumit, maka lewati analisis use case dan mulailah berbicara tentang alur kerja atau aliran data. Jika Anda tidak akan menggunakan alat yang sama untuk setiap bagian dari implementasi aplikasi, lalu mengapa Anda menggunakan alat yang sama untuk setiap bagian dari persyaratan?
Jaga telinga Anda ke tanah.
Dari semua petunjuk dan tips yang saya baca untuk analisis persyaratan, ini mungkin salah satu yang paling sering diabaikan. Jujur saya pikir saya telah belajar lebih banyak tentang menguping dan kadang-kadang membuat percakapan yang lebih dingin dari pada pertemuan yang dijadwalkan.
Jika Anda terbiasa bekerja dalam isolasi, coba cari tempat di mana aksinya sehingga Anda dapat mendengar obrolan. Jika Anda tidak bisa, maka lakukan putaran, ke dapur atau kamar mandi atau di mana saja. Anda akan menemukan segala macam hal menarik tentang bagaimana bisnis benar-benar beroperasi dari mendengarkan apa yang dibanggakan atau dikeluhkan orang-orang saat kopi dan merokok.
Akhirnya, baca yang tersirat .
Salah satu kesalahan terbesar saya di masa lalu adalah begitu fokus pada hasil akhirnya sehingga saya tidak meluangkan waktu untuk benar - benar mendengar apa yang orang katakan . Kadang-kadang - sering kali - mungkin terdengar seperti orang-orang mengoceh tentang apa-apa atau mengomel tentang beberapa prosedur yang terdengar sama sekali tidak berguna bagi Anda, tetapi jika Anda benar-benar berkonsentrasi pada apa yang mereka katakan, Anda akan menyadari bahwa memang ada persyaratan terkubur di sana - atau beberapa.
Sekonyong-konyong dan hambar kedengarannya, Five Whys adalah teknik yang sangat berguna di sini. Kapan pun Anda mendapat reaksi "itu bodoh" (bukan itu Anda akan mengatakannya dengan keras), hentikan diri Anda, dan ubah menjadi pertanyaan: Mengapa? Mengapa informasi ini diketik ulang empat kali, lalu dicetak, difotokopi, dipindai, dicetak lagi, ditempelkan ke papan partikel, ditembak dengan kamera digital dan akhirnya dikirim melalui email ke manajer penjualan? Ada adalah alasan , dan mereka mungkin tidak tahu apa itu, tapi itu tugas Anda untuk mencari tahu. Semoga beruntung dengan itu. ;)