Skip to main content

Membedah Keperluan Pengguna

·675 words·4 mins
aplikasi keperluan pengguna
rsmn
Author
rsmn
Software Engineer in Bangi

Sepanjang proses mencungkil keperluan pengguna (eliciting user requirements) untuk menghasilkan aplikasi tersuai, bacaan saya adalah kebanyakan pengguna tahu secara kasar apa mereka mahu. Masalah yang dihadapi biasanya mudah untuk diceritakan. Tapi tidak ramai yang tahu secara terperinci bentuk solusi yang diinginkan.

Ada pembuat aplikasi yang mengenakan caj untuk proses konsultasi bagi menghasilkan dokumen keperluan pengguna, terutamanya bagi projek yang ultra besar dan ultra rumit. Ada juga yang memberikan secara percuma (atau mungkin diserap dalam kos akhir).

the devil is in the detail.

Benarlah kata pujangga, “syaitannya adalah pada butiran terperinci”.


Saya nak bawa satu senario yang mungkin anda sendiri pernah hadapi.

Klien anda, pemilik francais kedai gunting rambut ternama datang berjumpa dengan anda.

Klien: “Bro, saya nak sistem yang pelanggan boleh guna untuk buat temujanji sesi gunting rambut.”

Langkah seterusnya, kita buat anggaran harga/quotation. Kita buat juga prototaip asas untuk tunjuk pada klien.

Halaman untuk buat temujanji kita akan buat borang. Ada ruangan untuk isi nama, tarikh, dan masa. Kemudian ada butang Hantar.

 -----------------------
|				 	    |
| Nama      __________  |
|				 	    |
| Tarikh    __________  |
| Masa      __________  |
|				 	    |
|			[ Hantar ]  |
 -----------------------

Anggaran masa: 2 minggu.
Anggaran harga: RM3,000.

Seterusnya kita demo prototaip kepada klien beserta anggaran masa/harga.

Klien: “Ok. Boleh tak dalam borang ni tambahkan ruangan untuk simpan maklumat jenis perkhidmatan yang nak diambil, samada gunting rambut sahaja, cukur, atau basuh rambut sekali?”

Kita salin maklumbalas klien dan kembali semula ke papan lukis, tambah dropdown/pilihan untuk memilih servis.

 -----------------------
|				 	    |
| Nama      __________  |
|				 	    |
| Tarikh    __________  |
| Masa      __________  |
|				 	    |
| Servis    [------v-]  |
|				 	    |
|			[ Hantar ]  |
 -----------------------

Anggaran masa: 3 minggu.
Anggaran harga: RM4,000.

Tunjuk pada klien.

Klien: “Terbaik.”

Klien ni biasanya pemilik perniagaan. Kadangkala ada yang tidak bergelumang dengan operasi.

Bila bawa prototaip pada staf yang terlibat dengan operasi,

Klien (staf operasi): “Encik pembangun, boleh tak dekat dropdown Servis ni, kalau kita nak pilih Servis yang masih belum ada, kita boleh tambah terus kat situ? Tak payah nak kena pegi laman tetapan (settings) untuk tambah Servis baharu.”

Kita salin maklumbalas klien dan kembali semula ke papan lukis, tambah pautan untuk terus boleh tambah servis baharu di dalam prototaip.

 -----------------------
|				 	    |
| Nama      __________  |
|				 	    |
| Tarikh    __________  |
| Masa      __________  |
|				 	    |
| Servis    [------v-]  |
|			Servis A	|
|			Servis B	|
|			Servis C	|
|			[Tambah +]	|
|				 	    |
|			[ Hantar ]  |
 -----------------------

Anggaran masa: 5 minggu.
Anggaran harga: RM6,000.


Adakah anda pernah mengalami situasi sebegini?

Cuba kita bedah situasi ini bersama dan kenal pasti jika ada jalan pintas agar tak perlu ada mundar-mandir yang sebenarnya boleh dielakkan.

Biasanya dalam sebuah syarikat pembangun aplikasi, paling asas kena ada dua pasukan. Pasukan produk (Product team) dan pasukan teknikal (Engineering team).

Salah satu peranan yang perlu diisi dalam pasukan produk adalah Penganalisis Perniagaan (Business Analyst/BA). Secara asas, BA berperanan untuk menganalisa keperluan pengguna dan menterjemahkannya kepada senarai tugasan yang akan diserahkan kepada pengaturcara.

BA yang berpengalaman akan mampu mengekstrak sebanyak mungkin maklumat pada pertemuan pertama.

Antara perkara yang boleh diminta dari klien adalah cara kerja atau solusi yang sedang digunakan samada menggunakan Microsoft Excel atau mana-mana perisian lain. Dari situ kita boleh lihat struktur data dan boleh terus tangkap semua maklumat yang diperlukan.

BA akan bawa input yang diterima ke dalam perbincangan bersama pasukan produk. Dalam pasukan produk ada peranan-peranan lain seperti Perekabentuk UI/UX dan Pengurus Produk/Projek. Perekabentuk UI/UX yang berpengalaman akan mampu empati dengan pengguna dan seterusnya menghasilkan aliran UX yang lancar (ie fitur terus tambah Servis baharu di laman yang sama).

Semakin “simple” UX aplikasi yang dihasilkan, boleh jadi semakin kompleks enjin yang diperlukan untuk menghasilkannya (ie cuba mempertahankan kenaikan anggaran harga dari 4k ke 6k).

Bila berurusan dengan manusia memang begitulah adat resamnya. Sifatnya dinamik dan sentiasa berubah. Yang penting perlu ada empati yang tinggi dan dalam masa yang sama pastikan semuanya direkodkan agar boleh mengelakkan perayapan skop ( scope creep).

  • Nota: Technerve sedang mencari Business Analyst dan UI/UX Designer

FB Technerve