Persyaratan Pekerjaan – Apa perbedaan antara baik dan buruk?

[ad_1]

Apa itu kondisi “baik”?

Banyak klien telah meminta kami untuk memberi mereka contoh persyaratan bisnis yang “baik”. Bahkan beberapa orang paling berani telah meminta persyaratan “buruk” untuk perbandingan. Agaknya yang paling berani sejauh ini adalah mereka yang telah memberi kami contoh persyaratan mereka dan meminta untuk menilai “kualitas” persyaratan. Setelah banyak pencabutan rambut, penghancuran otak, dan abu dituangkan ke atas kepala kami, kami memutuskan untuk membahas topik ini (jangan mulai saya dengan iklan ini!). Namun, karena topiknya agak besar (artinya, terlalu besar untuk dibahas dalam satu artikel), kami memutuskan untuk memecahnya.

Persyaratan “Bagus”, meskipun kecil dan belum matang

Pertama, kita perlu menunjukkan bahwa ‘kualitas’ kebutuhan bisnis tergantung di mana mereka dikembangkan. Demi kenyamanan, kami membagi proses identifikasi kebutuhan menjadi tiga tahap utama, “capture”, “clarify” dan “confirm”.

Filosofi inti kami adalah bahwa persyaratan bisnis mungkin berada di belantara perusahaan Amerika, dan kami tidak tahu pasti. Alasan kami tidak tahu adalah karena kami tidak dapat mengetahui apakah sesuatu itu merupakan persyaratan atau tidak sampai kami mengambilnya. Apa yang kita sebagai analis bisnis (juga dikenal sebagai mereka yang bertanggung jawab untuk memenuhi persyaratan bisnis) perlu merencanakan penelitian. Kita perlu mempelajari persyaratan di habitat alami mereka untuk mencoba mempelajari sebanyak mungkin tentang mereka. Apa pun yang dapat kami pelajari tentang kebiasaan, perilaku, dan preferensi mereka akan membantu kami dalam penelitian mendatang untuk memastikan kami dapat menangkap sebanyak mungkin dari mereka tepat waktu. Ini semua tentang mendapatkan persyaratan dengan cara apa pun yang memungkinkan – dengan mewawancarai, mengamati, menganalisis, berseluncur, bertukar pikiran, mencuci otak, menendang, apa pun yang cocok untuk Anda.

Pada tahap pembentukan dalam hidupnya ini, persyaratan “baik” adalah pernyataan bahwa:

  • Itu dimulai dengan kata-kata “Saya (atau kami, atau departemen kami, atau orang-orang saya, atau peran tertentu) membutuhkan (atau tidak membutuhkan, ingin, tidak ingin, seharusnya, tidak boleh, tidak mau atau tidak)” atau menentukan beberapa dimensi komponen spesifik dari solusi masa depan;
  • Menyebutkan salah satu komponen/fitur/perilaku/ menyatakan bahwa siapa pun dalam komunitas bisnis yang memiliki kekuatan untuk membuat keputusan memutuskan bahwa itu adalah hasil dari proyek yang layak didanai;
  • Berfokus pada hasil bisnis, bukan teknologi yang digunakan; Dan
  • Hal ini dapat ditelusuri kembali ke individu yang memiliki wewenang untuk ‘memiliki’ dan ‘membiayai’ kebutuhan ini.

Beberapa contoh bagus (IONSHO – menurut pendapat kami yang tidak sederhana):

  1. Sales harus bisa mengetahui kontrak mana yang akan berakhir dalam 90 hari ke depan.
  2. Saya ingin sistem menghitung pajak penjualan secara otomatis berdasarkan undang-undang pajak penjualan yang relevan.
  3. Pengunjung situs tidak perlu mengklik lebih dari satu kali untuk mengakses halaman pesanan dari halaman lain di situs.
  4. Kita harus dapat menanggapi insiden Kode Merah di mana saja di planet ini dalam waktu 24 jam.
  5. Pajak penjualan akan diterjemahkan dengan kode pos dari alamat pengiriman.

Dalam memperjelas persyaratan

Mengklarifikasi persyaratan benar-benar tentang memastikan bahwa lebih dari satu orang (yaitu penulis) sepenuhnya memahami arti persyaratan. Bagaimanapun, persyaratan adalah sarana komunikasi, jadi kecuali pembuat dan pembaca persyaratan sepakat tentang apa artinya sebenarnya, persyaratan itu tidak dapat menyebut dirinya persyaratan eksplisit.

Sama seperti hal yang baik misalnya, mari kita ambil kondisi pertama dari himpunan di atas:

“Penjualan harus bisa mengetahui kontrak mana yang akan berakhir dalam 90 hari ke depan.”

Masuk akal bagi saya, setelah semua, saya menulisnya. Apa artinya itu bagi para pengembang (apakah mereka duduk di negara dunia ketiga atau kubus di sebelah saya, apakah mereka berbicara bahasa Inggris sebagai bahasa ibu mereka atau tidak, dan apakah mereka berbagi latar belakang budaya dengan saya atau tidak)? Jenis pertanyaan apa yang dapat diajukan pengembang ini?

Latihan kejelasan

Sebagai latihan dalam kemampuan analitis Anda, pada titik ini Anda mungkin ingin menyisihkan dua menit untuk melihat berapa banyak pertanyaan yang dapat Anda pikirkan yang ingin Anda jawab untuk memastikan Anda memahami maksud saya dan bukan hanya interpretasi Anda atas kata-kata saya. Apakah Anda menuliskannya atau tidak, hitunglah. Dalam hal ini, kuantitas menjadi penting.

Nah, inilah daftar dua menit saya:

  1. Siapa atau apa itu “penjualan”? Apa yang bisa mereka lakukan? Apa yang akan mereka lakukan dengan semua yang saya berikan kepada mereka?
  2. Apa artinya “melihat”? Apakah mereka membutuhkan kontrak aktual atau hanya daftar?
  3. Apa itu kontrak?
  4. Apa yang membuat kontrak “kedaluwarsa” dan mengapa mereka peduli?
  5. 90 hari ke depan? mulai dari kapan? Apakah tampilan ini berubah hari demi hari, mingguan, bulanan, setiap jam atau bagaimana?
  6. Kalau dipikir-pikir, apa yang dimaksud dengan satu hari dalam konteks ini, 24 jam (setiap hari di satu tempat) atau hari dunia (dan apakah itu 47 jam atau bagaimana cara kerjanya)?

Nah, ini adalah 6 pertanyaan pertama (atau berapa banyak yang ingin Anda hitung) yang membuat saya lemah, tetapi ingat, sayalah penulisnya! Anda mungkin dapat melakukan pekerjaan yang jauh lebih baik karena Anda melihat dunia dari sudut pandang Anda. Semua ini menunjukkan bahwa meskipun persyaratan itu jelas bagi saya ketika saya menulisnya, mungkin mengandung beberapa subjektivitas yang harus diselesaikan agar tidak membawa kita untuk mengembangkan solusi yang salah.

Kapan kamu berhenti?

Mari kita pikirkan apa yang baru saja kita lakukan. Kami mengambil satu kalimat dan membuat serangkaian pertanyaan yang akan mengarah pada siapa yang tahu berapa banyak kalimat tambahan, yang masing-masing akan terdiri dari istilah yang perlu diklarifikasi. Bagi saya, ini adalah contoh klasik dari analisis kelumpuhan. Bagaimana akhirnya, dan kapan kita akhirnya cukup tahu untuk berhenti ragu-ragu dan mulai mengembangkan solusi?

Pertanyaan bagus! Bahkan, sangat mungkin pertanyaan itu diajukan kepada para analis bisnis di mana-mana. Jawaban yang lebih mahal adalah, tentu saja, untuk membangun solusi dan kemudian melihat apakah Anda telah memahami persyaratan dengan benar (yang dapat berdampak negatif pada peluang Anda untuk mendapatkan pekerjaan dalam analisis bisnis).

Jawaban terbaik yang diberikan industri kita sejauh ini adalah kutipan Tiongkok kuno, “Sebuah gambar bernilai seribu kata.” Dengan kata lain, gambar diagram atau buat prototipe dari apa yang menurut Anda berhasil dan uji pemahaman Anda tentangnya. Jika Anda dan rekan Anda (ahli materi pelajaran, alias UKM di satu sisi dan pengembang di sisi lain) berpengalaman dalam teknik pemodelan, latihan yang baik adalah meminta masing-masing pihak menggambar diagram cepat (model proses, model data, diagram jalur renang, apa pun) Apa artinya persyaratan yang mereka pahami dan kemudian bandingkan modelnya. Namun, formulir bukan satu-satunya metode yang tersedia untuk Anda.

Mengapa kita tidak menjelaskan?

Anda bertanya “Mengapa begitu banyak dari kita melewatkan proses klarifikasi”? (Setidaknya, saya pikir itulah yang saya dengar Anda katakan di kepala saya.) Sebagai permulaan, tidak banyak orang yang suka bertanya karena takut terlihat tidak mengerti. (Ini baris saya – pertanyaan tidak menunjukkan ketidaktahuan, mereka menunjukkan minat!). Kedua, mengetahui apa yang harus ditanyakan adalah kerja keras. (Tentu saja, tidak sesulit menjadi bos, tapi tetap saja.) Meskipun pertanyaannya menunjukkan minat, setidaknya beberapa pertanyaan tampak bodoh, jadi bagaimana Anda bisa yakin pertanyaan Anda bukan tipe bodoh? Nah, berapa banyak dari Anda yang memilih penggunaan tanda kurung yang tidak logis dalam paragraf ini untuk “menjelaskan” apa yang dimaksud? Apakah Anda jelas atau bingung? Ah, teka-teki yang kita ciptakan melalui keinginan akan kejelasan.

Pikiran itu dan tenggat waktu yang menjengkelkan itu membayangi Anda di jalan merah muda, “Yah, ahli materi pelajaran itu pasti bermaksud, karena itulah satu-satunya hal yang masuk akal bagi saya”; Dan proyek lain yang menjanjikan berubah menjadi kerusuhan. Ada cara yang lebih baik, itu harus.

Dilema dekomposisi

Pernyataan persyaratan yang membusuk mungkin memiliki banyak definisi berbeda karena ada huruf dalam nama teknologi, tetapi pendekatan kami untuk ini adalah yang paling sederhana (sungguh, percayalah). Yang perlu Anda pikirkan hanyalah dua hal.

Orang dan sistem sama-sama melakukan sesuatu. Dalam bahasa kami, kami menyebut hal-hal ini sebagai fungsi, aktivitas, atau proses. Saat melakukan sesuatu, baik orang maupun sistem menggunakan sumber daya (seperti data) dan membuat sumber daya baru (termasuk data baru). Tujuan utama TI adalah membantu kami melakukan berbagai hal dengan lebih murah, lebih baik, lebih cepat, dan mengingat apa yang kami lakukan dengan melacak data yang relevan. Yah, karena persyaratan seharusnya menentukan TI masa depan, mungkin kita harus fokus pada apa yang akan dilakukan sistem dan apa yang harus diketahui oleh seorang pemula untuk melihat ke mana arahnya.

Komponen Fungsional dan Informasional

Dalam bentuknya yang sederhana, analisis pernyataan kebutuhan terdiri dari mengajukan tiga pertanyaan, dimulai dengan “Apa yang dinyatakan atau disiratkan oleh sistem (atau orang) yang perlu dilakukan oleh sistem (atau orang)?” Karena melakukan sesuatu memerlukan beberapa tindakan, kami mencari jawaban dalam bentuk kata kerja dan objek (misalnya “perhitungan pajak penjualan”, “cek setoran”). Karena kata kerja merujuk pada tindakan, objek biasanya adalah data (atau sesuatu yang kita perlukan untuk mendapatkan data).

Setelah kita memiliki daftar semua hal yang sistem atau pengguna perlu lakukan, pertanyaan kedua untuk setiap item dalam daftar adalah, “Data apa yang harus diketahui sistem untuk melakukan ini?” Karena data adalah suatu hal yang penting, kita sekarang mencari kata benda atau frase nominal (misalnya “pajak penjualan”, “jumlah jatuh tempo”, bank penerbit”).

Pertanyaan ketiga adalah “Dari mana data ini berasal?” Dan jawabannya di sini bisa saja fungsi lain atau di suatu tempat di luar sistem (misalnya bank, klien, IRS – maaf untuk yang terakhir, tapi itu adalah sumber yang valid ditambah rasa sakit di pembedahan)

Dan begitulah

Nah, Anda mulai dengan kalimat sederhana yang mendefinisikan fitur, status, atau perilaku masa depan komponen sistem bisnis, dan sekarang Anda memiliki beberapa daftar panjang hal-hal yang harus dilakukan sistem dan hal-hal yang harus diketahui. Satu-satunya pertanyaan penting yang tersisa adalah apakah Anda cukup tahu tentang setiap item dalam daftar untuk berkomunikasi dengan pengembang atau kompiler untuk mencari solusi. Mungkin juga ide yang bagus jika Anda juga tahu cara melihat apakah hal-hal ini ada dan berfungsi seperti yang Anda inginkan setelah solusi diberikan.

Apakah semuanya jelas sekarang?

Konfirmasi sebelum coding

Menegaskan persyaratan bisnis benar-benar tentang memastikan bahwa bisnis dan komunitas teknis memahami hal yang sama di bawah persyaratan. Ini juga tentang memastikan bahwa keduanya menyetujui prioritas relatif dalam persyaratan yang ditetapkan sehingga persyaratan paling penting dari komunitas bisnis ditangani terlebih dahulu. Memprioritaskan bukanlah sesuatu yang dapat dilakukan kecuali itu penting, jadi kami tidak akan menyelidiki seluk-beluk langkah penting ini di sini saat ini. Cukuplah untuk mengatakan bahwa kecuali persyaratan bisnis Anda dikonfirmasi dan diprioritaskan, mereka tidak siap untuk prime time yang, dalam filosofi kami, berarti “siap untuk mengelola”. Pada akhirnya, pengelolaan, pemeliharaan, dan kelayakan persyaratan bisnis Anda adalah apa yang membuat perbedaan antara persyaratan bisnis “baik” dan “buruk”.

Klaim terbaik mungkin menang.

Related Articles

Leave a Reply

Your email address will not be published. Required fields are marked *

Back to top button
Close
Close