Dalam artikel tersebut, Hal tersulit tentang Teknik adalah Persyaratan, penulis Jay menjelaskan mengapa persyaratan menangkap itu sulit. Yang terpenting adalah tantangan komunikasi antara tim teknis dan bisnis. Desainer dan insinyur menginginkan persyaratan yang jelas sehingga mereka dapat menyingsingkan lengan baju mereka untuk menerapkan aliran yang diinginkan dan membangun solusi yang dioptimalkan untuk melakukan yang terbaik untuk kasus penggunaan yang disebutkan. Namun, pengguna bisnis tidak dapat atau tidak punya waktu untuk menuliskan kasus penggunaan. Mereka tidak dapat melakukannya karena kasus penggunaan baru atau kesenjangan dalam persyaratan hanya terungkap ketika mereka melihat solusi yang berfungsi. 

Michael Lewis menangkap ini dengan luar biasa di Episode Enam Tingkat Turun (Podcast Melawan Aturan). Dia berbagi bagaimana mendapatkan ahli yang mengetahui aturan bisnis adalah kunci untuk membantu Athena Health menjadi perusahaan perangkat lunak Miliar dolar. Para ahli biasanya adalah pengguna sebenarnya (6 tingkat di bawah hierarki) dan bukan yang ada di ruang rapat. Jika Anda hanya memiliki waktu 5 menit, saya sarankan untuk mendengarkan dari 30 hingga 35 menit episode tersebut.

Berikut adalah kesimpulan utamanya:

1) Memiliki persyaratan dalam bentuk tertulis

• Bicaralah dengan pengguna yang sebenarnya. Dokumen persyaratan mereka. Apa yang mereka inginkan dari perangkat lunak? Tindakan apa yang ingin mereka lakukan? Informasi apa yang mereka butuhkan?
• Dalam pengalaman kami sendiri, kami telah menemukan bahwa sesi curah pendapat yang baik dapat menghasilkan banyak skenario yang dapat ditangkap dalam persyaratan.
• Mengharuskan pemangku kepentingan utama untuk menandatangani persyaratan. Meskipun ini mungkin menambah penundaan, ini juga akan memaksa pengguna untuk memikirkannya matang-matang.

2) Analisis persyaratan, Identifikasi kesenjangan, dan Perbarui

• Pakar implementasi dan pengembang harus menyadari bahwa persyaratan akan memiliki celah, dan pandai mengidentifikasi celah tersebut dan mengklarifikasinya sebelum solusi diimplementasikan.

3) Desain-dalam beberapa fleksibilitas

• Desainer dan Pengembang harus mengizinkan templat, aturan, peringatan, laporan, dan alur yang dapat dikonfigurasi.

4) Dapatkan umpan balik awal dengan menunjukkan prototipe

• Umpan balik awal akan menghemat waktu karena bantuan akan membutuhkan lebih sedikit usaha dibandingkan dengan mendapatkan umpan balik setelah diimplementasikan sepenuhnya.

Webinar & Video

Akademi & Basis Pengetahuan Vtiger

Buzz CRM

(Berita CRM dan Tren Teknologi)

Fitur Favorit Saya

Dapatkan konten CRM eksklusif!