Business analyst
Business analyst menetapkan apa sebenarnya yang harus dilakukan sebuah software, dan menyatakannya cukup presisi untuk dibangun dan diverifikasi. Disiplin ini berada di antara orang yang memahami bisnis dan orang yang memahami sistemnya, dan nilainya terukur dalam defect yang tidak pernah terjadi â pengerjaan ulang yang terhindarkan, salah paham yang tertangkap selagi masih murah. Panduan ini menjelaskan perannya, situasi yang menciptakan kebutuhan nyata untuknya, dan cara membedakan analisis dari dokumentasi.
Apa yang dikerjakan business analyst di sebuah proyek software?
Business analyst menyelidiki sebuah masalah bisnis dan mendefinisikan apa yang harus dilakukan sebuah sistem untuk menyelesaikannya. Di proyek software itu berarti menggali kebutuhan dari stakeholder dan pengguna, memetakan proses yang berjalan sekarang beserta titik gagalnya, mengidentifikasi jarak antara perilaku saat ini dan perilaku yang dituju, lalu menuangkan hasilnya sebagai kebutuhan, aturan bisnis, definisi data dan kriteria penerimaan yang bisa dijadikan acuan engineer untuk membangun dan tester untuk memverifikasi. Tanggung jawabnya adalah agar tim membangun hal yang benar â berbeda dari agar tim membangunnya tepat waktu.
Bagian pekerjaan yang paling berkonsekuensi adalah jarak antara apa yang diminta seorang stakeholder dan apa yang sebenarnya mereka butuhkan. Stakeholder menggambarkan solusi, karena solusi lebih mudah diutarakan daripada masalah: permintaan akan tombol export biasanya adalah permintaan untuk merekonsiliasi dua sistem, dan membangun tombolnya meninggalkan rekonsiliasinya tetap tidak terselesaikan. Business analyst yang menerima permintaan apa adanya menghasilkan spesifikasi yang akurat sekaligus tidak relevan.
Presisi adalah separuh pekerjaan berikutnya. Kebutuhan lebih sering gagal karena ambiguitas daripada karena kelalaian â kata seperti cepat, relevan, sesuai dan pengguna berarti berbeda bagi setiap orang yang membacanya, dan setiap pembacaan ditemukan secara terpisah selama pengembangan, pengujian dan setelah rilis. Membuat ambiguitas itu terlihat sebelum ia berubah menjadi kode adalah kontribusi ekonomi utama dari disiplin ini.
Sebagian besar substansinya berada pada aturan, data dan kasus tepi, bukan pada layar. Apa yang membuat sebuah akun memenuhi syarat, field mana yang wajib dalam kondisi apa, bagaimana pengembalian dana berinteraksi dengan pengiriman sebagian, apa yang terjadi di batas sebuah rentang tanggal, sistem mana yang otoritatif ketika keduanya berbeda. Organisasi biasanya menyimpan pengetahuan ini tersebar di beberapa orang yang tak satu pun memegang seluruhnya, dan sering kali belum ada yang pernah menuliskan apa yang terjadi ketika jalur normalnya tidak diikuti.
Peran ini juga memikul pola kegagalan yang paling melekat padanya. Seorang business analyst bisa menghasilkan dokumentasi dalam jumlah besar yang tidak dibaca siapa pun, memuaskan sebuah proses tanpa memberi kejelasan apa pun. Keluaran yang penting adalah pemahaman bersama yang mutakhir dan bisa diuji tentang apa yang sedang dibangun â dan bila sebuah dokumen tidak dipakai untuk mengambil keputusan, panjangnya adalah biaya, bukan bukti kerja.
Kapan tim membutuhkan kapabilitas ini
Analisis terjadi di setiap proyek, ada atau tidak ada orang yang ditugaskan untuknya. Pertanyaannya adalah apakah ia dilakukan dengan sengaja atau ditemukan di tengah pengembangan. Berikut kondisi ketika melakukannya dengan sengaja biasanya terbayar.
Domainnya memuat aturan yang belum pernah dituliskan siapa pun
Pembiayaan, asuransi, logistik, payroll, kesehatan, perpajakan, harga yang diatur regulasi â bidang di mana perilaku yang benar bergantung pada kondisi yang hanya ada di kepala staf berpengalaman dan di dalam perilaku sistem lama. Engineer tidak bisa menyimpulkannya sendiri, dan meminta mereka melakukannya adalah cara aturan diimplementasikan secara kira-kira.
Tiket terus kembali
Pekerjaan dibangun sesuai spesifikasi, diterima, lalu dibuka kembali karena tidak melakukan apa yang diharapkan seseorang. Ini hampir selalu defect pada kebutuhannya, bukan pada engineering-nya, dan ia berulang karena penyebabnya berada di hulu dari tempat ia sedang diselidiki.
Software-nya menggantikan sebuah proses yang sudah berjalan
Migrasi, penggantian sistem atau otomasi pekerjaan manual menuntut seseorang menetapkan apa yang sebenarnya dilakukan proses saat ini â termasuk langkah informal dan pengecualian yang ditangani orang tanpa menyadarinya â sebelum memutuskan apa yang harus dilakukan sistem barunya. Mereproduksi proses yang belum pernah diperiksa adalah cara akal-akalan berubah menjadi fitur permanen.
Stakeholder berbeda pendapat dan tidak ada yang memunculkannya
Beberapa departemen masing-masing punya pandangan yang koheren tentang bagaimana sesuatu semestinya bekerja, dan pandangan itu saling bertentangan. Perbedaannya biasanya ditemukan saat acceptance testing, ketika biaya menyelesaikannya paling tinggi. Membuatnya eksplisit lebih awal adalah pekerjaan analisis, bukan diplomasi.
Engineer menghabiskan waktunya untuk klarifikasi
Developer berulang kali berhenti bekerja untuk memastikan arti sebuah kebutuhan, mengejar orang yang tahu, lalu menunggu. Tim terlihat sibuk dan menghasilkan sedikit, dan penyebabnya adalah pekerjaan pendefinisian yang tersebar ke semua orang dengan cara yang paling tidak efisien.
Sebuah integrasi harus merekonsiliasi dua model tentang hal yang sama
Dua sistem sama-sama menyimpan customer, atau order, atau akun, dan keduanya memaknainya secara sedikit berbeda. Memetakan field-nya mudah; menetapkan sistem mana yang otoritatif, bagaimana identitas dicocokkan dan apa yang terjadi ketika keduanya bertentangan adalah analisis, dan melewatinya menghasilkan masalah data yang muncul lama setelah rilis.
Kapabilitas inti
Penggalian 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.
Membingkai 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.
Analisis 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.
Pendefinisian 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.
Kriteria 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.
Aturan 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.
Analisis 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.
Keterlacakan
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.
Menerjemahkan 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.
Bagaimana disiplin ini bekerja
Business analysis didefinisikan oleh metode, bukan oleh technology stack, sehingga berikut ini menguraikan teknik, notasi dan hasil kerja yang menjadi ciri disiplin ini dalam praktik industri pada umumnya â gambaran tentang profesinya, bukan klaim tentang perkakas individu mana pun. Tool-nya sendiri sebagian besar bisa saling menggantikan: sebuah notasi pemodelan berpindah antar produk diagram, dan sebuah praktik pengelolaan kebutuhan bertahan melewati pergantian sistem pelacakan, sehingga seorang kandidat jauh lebih baik dinilai dari cara ia menggali dan menspesifikasikan daripada dari software yang terakhir ia pakai.
Teknik penggalian
- Wawancara stakeholder terstruktur
- Workshop kebutuhan terfasilitasi
- Observasi dan job shadowing
- Analisis dokumen dan sistem
- Survei dan kuesioner
- Prototipe untuk memancing umpan balik
Pemodelan proses dan sistem
- Model proses BPMN
- Swimlane dan value stream map
- Diagram konteks dan ruang lingkup
- Use case dan activity diagram
- State transition diagram
Artefak spesifikasi
- User story
- Kriteria penerimaan dalam bentuk given/when/then
- Deskripsi use case
- Katalog aturan bisnis
- Kebutuhan non-fungsional
- Glosarium domain yang terpelihara
Analisis data dan aturan
- Model data konseptual dan logis
- Entity relationship diagram
- Kamus data
- Decision table dan decision tree
- Matriks create, read, update dan delete
- Profiling dan penilaian kualitas data
Metode analisis dan prioritisasi
- Analisis kesenjangan
- Analisis akar masalah
- Impact mapping dan story mapping
- Pemetaan stakeholder
- MoSCoW dan kerangka prioritisasi lain
- Matriks keterlacakan kebutuhan
Kategori tool yang lazim
- Software diagram dan pemodelan
- Repositori backlog dan kebutuhan
- Wiki kolaboratif dan basis pengetahuan
- Tool wireframe dan prototipe
- Tool query dan pelaporan untuk menelusuri data
How this role works with your team
Engineers work inside your team, on your priorities, to your standards. You direct the work; Talent.ID carries the employment. The division below is the whole arrangement.
You keep
- Produk
- Prioritas bisnis
- Roadmap
- Arsitektur
- Prioritas sprint
- Standar engineering
- Kolaborasi teknis sehari-hari
Talent.ID handles
- Hubungan kerja
- Payroll
- Benefit karyawan
- Administrasi talenta
- Hubungan karyawan berkelanjutan
Yang perlu dicari saat hiring
Kandidat business analyst umumnya artikulatif, yang membuat wawancaranya mudah dijalankan dan sulit dibaca. Teknik yang andal adalah memberi mereka masalah nyata dari domain Anda sendiri lalu mengamati mereka mengerjakannya, karena kemampuan analisis tampak dari pertanyaan yang seseorang ajukan dan hampir tidak pernah dari cara mereka menjelaskan metodenya.
Kualitas pertanyaan
Gambarkan sebuah kebutuhan nyata dari bisnis Anda dalam dua kalimat lalu biarkan mereka menginterogasinya. Latihan tunggal ini lebih informatif daripada sisa wawancara digabungkan. Cari pertanyaan yang menggali hasil dan pengecualian, bukan pertanyaan yang mengumpulkan daftar fitur.
- Menanyakan mengapa sebelum menanyakan apa
- Mengejar kasus pengecualian sejak awal
- Menyadari apa yang tidak Anda katakan lalu menanyakannya
- Merangkum ulang dengan kata-kata berbeda untuk menguji pemahamannya
Membedakan keinginan dari kebutuhan
Tanyakan tentang saat seorang stakeholder meminta sesuatu yang spesifik dan sang analis menyimpulkan kebutuhan yang mendasarinya berbeda. Anda mencari bukti bahwa mereka menyelidiki permintaan alih-alih menyalinnya â dan bagaimana mereka menangani stakeholder yang melekat pada solusinya sendiri.
- Bisa memberi contoh konkret beserta penalaran yang membawanya ke sana
- Mengarahkan ulang tanpa mengecilkan keahlian stakeholder-nya
- Paham bahwa orang menggambarkan solusi karena masalah lebih sulit diutarakan
Presisi dalam tulisan
Minta melihat sebuah kebutuhan atau sekumpulan kriteria penerimaan yang mereka tulis, disunting seperlunya, atau berikan latihan tertulis singkat. Analisis disampaikan lewat tulisan, dan kefasihan dalam percakapan tidak memprediksinya. Perumusan yang kabur dan tidak bisa dibantah adalah cacat yang perlu dicari.
- Menulis kriteria yang bisa ditunjukkan gagal
- Menghindari istilah yang akan ditafsirkan berbeda oleh pembaca berbeda
- Menyatakan asumsi secara eksplisit alih-alih membiarkannya tersirat
- Menjaga solusi tetap di luar pernyataan kebutuhannya
Proporsi dalam dokumentasi
Tanyakan bagaimana mereka menentukan seberapa banyak yang perlu ditulis. Peran ini punya pola kegagalan terkenal berupa dokumen menyeluruh yang tidak dibuka siapa pun, dan kandidat terkuat menyadarinya. Takaran yang tepat bervariasi menurut risiko, regulasi, keberlanjutan tim dan seberapa mudah keputusannya dibalik.
- Menyesuaikan kedalaman dengan biaya jika keliru
- Bisa menceritakan sesuatu yang sengaja tidak mereka dokumentasikan
- Memperlakukan dokumen sebagai sarana menuju pemahaman bersama, bukan sebagai hasil kerjanya
Menangani stakeholder yang bertentangan
Tanyakan bagaimana mereka melanjutkan ketika dua bagian bisnis menginginkan hal yang tidak kompatibel. Jawaban yang berguna melibatkan membuat konfliknya eksplisit lalu membawanya ke pihak yang bisa memutuskan, alih-alih diam-diam memihak suara yang lebih senior atau menspesifikasikan kompromi yang tidak bisa dijalankan.
- Memunculkan perbedaan pendapat lebih awal alih-alih menyerapnya
- Mengidentifikasi siapa yang sebenarnya memegang keputusannya
- Bisa menceritakan keputusan yang berlawanan dengan rekomendasinya sendiri
Kenyamanan dengan data dan aturan
Sebagian besar analisis yang paling sulit adalah logika kondisional dan makna data. Tanyakan bagaimana mereka akan menetapkan aturan sebenarnya yang mengatur sebuah proses ketika dokumentasinya sudah usang dan penulis aslinya sudah pergi. Kesediaan memeriksa datanya langsung adalah sinyal positif yang kuat.
- Akan melakukan query atau memeriksa datanya alih-alih mengandalkan deskripsi
- Meraih decision table ketika kondisinya berlipat
- Menanyakan sistem mana yang otoritatif ketika keduanya menyimpan entitas yang sama
Bekerja di dalam tim engineering
Analis yang bekerja berjarak dari developer cenderung menghasilkan spesifikasi yang lengkap dan tidak membantu. Tanyakan bagaimana mereka bekerja dengan engineer selama sebuah sprint dan apa yang mereka lakukan ketika seorang engineer mengusulkan sesuatu yang tidak diantisipasi kebutuhannya.
- Tersedia untuk klarifikasi selagi pekerjaannya berjalan
- Memperlakukan pertanyaan seorang engineer sebagai sinyal bahwa kebutuhannya kurang jelas
- Bersedia sebuah kebutuhan diubah oleh wawasan teknis
Pertanyaan wawancara yang layak diajukan
Ditulis untuk menopang proses wawancara Anda sendiri. Penilaian atas seorang kandidat berada pada organisasi yang mencarinya, yang menimbangnya terhadap domain dan ekspektasinya sendiri lalu sampai pada keputusannya sendiri.
Berikut sebuah masalah dari bisnis kami, digambarkan dalam dua kalimat. Apa yang perlu Anda tanyakan kepada saya?
What a strong answer shows
Sinyal paling andal yang tersedia. Kandidat kuat mengejar hasilnya, siapa yang terdampak, proses yang berjalan sekarang dan pengecualiannya. Yang lebih lemah mengumpulkan daftar fitur lalu mulai mengusulkan desain sebelum masalahnya ditetapkan.
Ceritakan sebuah kebutuhan yang Anda rumuskan keliru. Bagaimana ia muncul, dan apa yang berubah dalam praktik Anda sesudahnya?
What a strong answer shows
Apakah mereka pernah menanggung konsekuensi spesifikasinya sendiri. Cari defect yang spesifik, penjelasan jujur tentang ambiguitas yang menyebabkannya, dan perubahan metode alih-alih tekad untuk lebih berhati-hati.
Seorang stakeholder meminta sebuah laporan dengan sekumpulan kolom tertentu. Bagaimana Anda merespons?
What a strong answer shows
Apakah mereka menyelidiki permintaan. Jawaban terkuat menanyakan keputusan apa yang ditopang laporan itu dan apa yang orang tersebut lakukan setelah membacanya, karena kebutuhan yang mendasarinya sering lebih terpenuhi oleh sesuatu selain laporan seperti yang diminta.
Bagaimana Anda menulis kriteria penerimaan untuk sesuatu yang perilaku benarnya bergantung pada beberapa kondisi yang saling berinteraksi?
What a strong answer shows
Kecermatan dengan logika kondisional. Cari decision table atau struktur setara, cakupan kombinasi yang disengaja, dan penanganan eksplisit atas kondisi batas â bukan prosa yang menggambarkan kasus yang dituju dan menyerahkan sisanya pada tafsiran.
Anda sedang mendokumentasikan proses yang berjalan dan dua orang berpengalaman menjelaskannya secara berbeda. Apa yang Anda lakukan?
What a strong answer shows
Naluri investigatif. Jawaban baik memperlakukan perbedaan itu sebagai informasi â sering keduanya benar untuk kasus yang berbeda â lalu pergi ke buktinya: mengamati pekerjaannya, memeriksa datanya, menelusuri apa yang sebenarnya dilakukan sistemnya.
Seberapa banyak dokumentasi yang tepat, dan bagaimana Anda menentukannya?
What a strong answer shows
Kesadaran akan pola kegagalan utama disiplin ini. Jawaban kuat menyesuaikan kedalaman dengan risiko, paparan regulasi, pergantian anggota tim dan seberapa mudah keputusannya dibalik, serta bisa menyebut sesuatu yang mereka pilih untuk tidak dituliskan.
Seorang engineer mengatakan kebutuhannya tidak bisa diimplementasikan sebagaimana ditulis. Bagaimana Anda menanganinya?
What a strong answer shows
Apakah mereka berkolaborasi atau bertahan. Jawaban terbaik memperlakukannya sebagai kesempatan meninjau ulang kebutuhan yang mendasarinya, karena kebutuhan yang secara teknis janggal sering kali adalah kebutuhan yang dinyatakan sebagai solusi.
Apa satu hasil analisis Anda yang tidak berdampak apa-apa, dan menurut Anda mengapa demikian?
What a strong answer shows
Kejujuran dan rasa proporsi. Setiap analis berpengalaman pernah menulis sesuatu yang tidak dipakai siapa pun. Kandidat yang bisa menjelaskan sebabnya â audiens yang keliru, waktu yang keliru, format yang keliru, keputusan yang sudah terlanjur diambil â telah mempelajari bagian pekerjaan ini yang bukan teknik.
What this looks like in practice
A hypothetical scenario, written to show how the working model applies. It does not describe a Talent.ID client or a completed project.
- Challenge
- Sebuah perusahaan mengganti sistem internal yang sudah lama berjalan. Perilaku yang penting tertanam di dalam software-nya sendiri dan di dalam kebiasaan orang yang mengoperasikannya, dokumentasinya mencerminkan versi yang lebih lama, dan penulis aslinya sudah pindah. Pengembangan sudah dimulai dan berulang kali terhenti oleh pertanyaan yang tidak bisa dijawab siapa pun dengan yakin.
- Approach
- Kapasitas analisis tambahan bekerja di dalam cara kerja yang sudah berjalan di klien â backlog mereka, definition of ready mereka, hubungan stakeholder mereka dan irama rilis mereka. Kepemilikan atas produk, atas apa yang layak dikerjakan lebih dulu, dan atas untuk apa penggantian ini pada akhirnya dilakukan tetap berada pada klien; kapasitas tambahan menetapkan aturan dan makna data yang berlaku sekarang, mencatat pengecualiannya, lalu mengubahnya menjadi kebutuhan dan kriteria penerimaan yang bisa dijadikan acuan tim untuk membangun dan memverifikasi.
- What this adds to the team
- Klien memperoleh kapasitas analisis sambil tetap memegang setiap keputusan tentang maksud bisnisnya. Apa yang harus dilakukan sistemnya, dan trade-off mana yang bisa diterima, tetap berada pada orang-orang yang bertanggung jawab atas hasil bisnisnya.
Related disciplines
Frequently asked questions
- 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.
Tell us what your team needs
Describe the gap â the work, the stack, the way your team runs â and we will tell you what we can support. If it is not something we can help with, we will say so.