Business analyst

Disiplinnya

Kapabilitas inti

• 01Penggalian kebutuhan

  Menarik keluar apa yang orang butuhkan, bukan mencatat apa yang mereka katakan. Artinya mewawancara tanpa menggiring, memfasilitasi workshop di mana ahli yang pendiam ikut bicara, mengamati pekerjaan sebagaimana ia benar-benar dilakukan, dan menyadari langkah yang seseorang lewatkan karena terlalu biasa untuk disebut.

• 02Membingkai masalah

  Memisahkan permintaan dari kebutuhan yang mendasarinya, dan menyatakan masalahnya dalam bahasa hasil alih-alih mekanisme. Kebutuhan yang ditulis sebagai solusi menutup kemungkinan solusi yang lebih baik yang mungkin diusulkan tim engineering, dan itu adalah cacat paling umum dalam sebuah spesifikasi.

• 03Analisis proses

  Mendokumentasikan bagaimana pekerjaan mengalir hari ini, di mana ia tertahan, di mana ia dikerjakan ulang, dan di mana orang membangun akal-akalan informal. Pengecualiannya lebih penting daripada jalur utamanya, karena pengecualian itulah yang akan ditangani buruk oleh sistem baru bila tidak ada yang menyebutkannya.

• 04Pendefinisian kebutuhan

  Menyatakan kebutuhan sedemikian rupa sehingga dua orang yang membacanya sampai pada kesimpulan yang sama. Bisa diuji, tanpa ambiguitas, bebas dari solusi yang tersirat, dan bisa ditelusuri kembali ke hasil bisnis yang membenarkannya — dengan bagian yang memang opsional ditandai sebagai opsional.

• 05Kriteria penerimaan

  Menetapkan di awal apa yang akan membuktikan bahwa sebuah kebutuhan terpenuhi, termasuk kondisi batas dan jalur yang bukan jalur mulus. Kriteria yang ditulis setelah implementasi menggambarkan apa yang dibangun alih-alih apa yang dibutuhkan, dan itu artefak yang berbeda dan jauh kurang berguna.

• 06Aturan bisnis dan definisi data

  Menangkap logika kondisional, aturan kelayakan, perhitungan dan batasan validitas yang mengatur perilaku, bersama makna, sumber, kepemilikan dan siklus hidup data yang dioperasikannya. Decision table biasanya memperlihatkan celah yang disembunyikan oleh prosa.

• 07Analisis kesenjangan

  Membandingkan keadaan sekarang dengan keadaan yang dituju dan mengidentifikasi persis apa yang harus berubah — di dalam sistem, dan sering juga di dalam proses serta tanggung jawab di sekitarnya. Software jarang menghasilkan sebuah hasil bisnis sendirian, dan analisis yang berhenti di batas sistem cenderung melewatkan alasan hasilnya tidak tercapai.

• 08Keterlacakan

  Memelihara tautan dari sasaran bisnis ke kebutuhan ke implementasi ke pengujian, sehingga dampak sebuah perubahan bisa dinilai dan pekerjaan tanpa pembenaran di belakangnya menjadi terlihat. Inilah yang membuat pengurangan ruang lingkup menjadi keputusan yang dipertimbangkan alih-alih tebakan.

• 09Menerjemahkan antar audiens

  Menjelaskan batasan bisnis kepada engineer dengan bahasa yang menopang keputusan desain, dan menjelaskan batasan teknis kepada stakeholder dengan bahasa tentang apa artinya bagi mereka. Kedua arah dibutuhkan; analis yang fasih hanya di satu arah menghasilkan spesifikasi yang diam-diam diabaikan salah satu pihak.

Pertanyaan umum

Pertanyaan yang sering diajukan

Apa bedanya business analyst dan project manager?

Keduanya menjawab pertanyaan yang berbeda. Business analyst berurusan dengan apa yang harus dibangun dan mengapa: masalah yang mendasarinya, kebutuhannya, aturannya, datanya dan kriteria penerimaannya. Project manager berurusan dengan membuat paket pekerjaan yang disepakati itu sampai: urutan, dependency, risiko, lini masa dan pelaporan. Kedua peran ini berbicara dengan stakeholder yang sama dan mudah tertukar, tetapi tanggung jawabnya berbeda — yang satu menjawab kebenaran definisinya, yang lain menjawab kedatangannya. Ketika satu orang memegang keduanya, separuh analisisnya yang biasanya terpangkas, karena tekanan delivery lebih nyaring.

Apa bedanya business analyst dan product owner atau product manager?

Perbedaan yang diniatkan adalah soal wewenang. Product owner atau product manager memutuskan apa yang layak dikerjakan dan dalam urutan apa, dan menjawab nilai dari hasilnya. Business analyst menetapkan dan menspesifikasikan apa yang harus dilakukan hal yang sudah dipilih itu, dan menjawab kebenaran serta kelengkapan definisi tersebut. Dalam praktiknya batas ini belum disepakati di industri: sebagian organisasi mengharapkan product owner melakukan analisisnya sendiri, sebagian mempekerjakan analis yang praktis menentukan prioritas, dan sebutan jabatannya dipakai tidak konsisten antar perusahaan. Sebelum menambah salah satu peran ini, ada baiknya eksplisit tentang siapa yang memegang wewenang prioritisasi di struktur Anda, karena di situlah kedua peran ini benar-benar berbeda.

Apakah tim agile masih membutuhkan business analyst?

Anggapan bahwa mereka tidak membutuhkannya berangkat dari pengamatan yang wajar — praktik agile mengganti spesifikasi besar di muka dengan percakapan, dan banyak dokumentasi berhenti berguna. Yang tidak hilang adalah pekerjaan memahami domain yang rumit, menyelesaikan pandangan stakeholder yang saling bertentangan dan menyatakan perilaku cukup presisi untuk bisa diuji. Di domain yang sederhana, seorang product owner dan tim yang terlibat bisa menyerapnya. Di domain dengan batasan regulasi, aturan yang berbelit atau sistem yang perilakunya tidak sepenuhnya diketahui siapa pun, itu pekerjaan yang besar, dan membiarkannya tanpa penugasan biasanya berarti ia dikerjakan sebagian-sebagian oleh beberapa orang di tengah sprint.

Apakah business analyst sama dengan data analyst?

Tidak, meskipun sebutannya dipakai longgar dan sebagian peran memang mencakup keduanya. Data analyst menafsirkan data untuk menjawab pertanyaan tentang apa yang telah terjadi, dan sebagian besar bekerja dengan query, statistik dan pelaporan. Business analyst mendefinisikan apa yang harus dilakukan sebuah sistem, dan memakai data sebagai bukti tentang bagaimana sebuah proses sebenarnya berperilaku, bukan sebagai hasil akhir pekerjaannya. Banyak business analyst yang cakap juga menulis query, dan itu aset yang besar — tetapi kandidat yang pengalamannya sepenuhnya di pelaporan belum tentu pernah mengerjakan pendefinisian kebutuhan.

Seberapa banyak dokumentasi yang sebaiknya dihasilkan business analyst?

Cukup agar orang yang membangun dan menguji pekerjaannya sampai pada pemahaman yang sama, dan tidak lebih. Tingkat yang tepat bervariasi menurut biaya jika keliru: perhitungan yang diatur regulasi, migrasi data yang tidak bisa dibalik atau antarmuka yang diandalkan organisasi lain layak mendapat presisi yang tidak dibutuhkan penyesuaian layar internal. Dokumen yang ada untuk memenuhi sebuah proses, alih-alih untuk menopang sebuah keputusan, adalah pemborosan yang paling dikenal di disiplin ini — dan volumenya sering disalahartikan sebagai bukti bahwa analisisnya menyeluruh.

Apakah business analyst membutuhkan keterampilan teknis?

Mereka tidak perlu menulis kode production, tetapi literasi teknis secara substansial menaikkan kualitas keluarannya. Membaca skema database, menulis query untuk memeriksa sebuah asumsi, memahami apa yang bisa dan tidak bisa diekspresikan sebuah API, dan mengikuti percakapan arsitektur sama-sama memungkinkan seorang analis memverifikasi alih-alih sekadar meneruskan. Pengetahuan domain setidaknya sama pentingnya: analis yang memahami bidang bisnisnya bisa mengenali jawaban yang keliru, dan kemampuan itu tidak diberikan oleh teknik analisis generik.

Bagaimana business analyst bekerja dengan tim engineering yang sudah ada?

Dalam pengaturan penambahan kapasitas tim, seorang analis bekerja di dalam proses yang sudah berjalan di klien — backlog mereka, sesi refinement mereka, standar dokumentasi mereka dan hubungan stakeholder mereka — dengan klien yang mengarahkan pekerjaan. Kepemilikan produk, prioritas bisnis dan roadmap tetap milik klien sepanjang waktu; kapasitas analisis tambahan menopang keputusan tersebut dan tidak pernah menggantikannya. Bagian Talent.ID terbatas pada kepegawaian: memegang hubungan kerja, menjalankan payroll dan benefit karyawan, menangani administrasi talenta serta menjaga hubungan yang berkelanjutan dengan karyawan tersebut.