Pada artikel ini, saya akan mencoba berbicara tentang profesi analis bisnis untuk pemula dan mereka yang ingin memulai karir mereka.
Tanpa pengalaman dalam bidang ini, Anda mungkin mengajukan pertanyaan yang masuk akal: "Apa perbedaan antara analis bisnis dan analis sistem?" Mereka mencoba menemukan jawaban untuk pertanyaan ini berkali-kali di Habré, tidak ada yang memiliki jawaban tegas, tetapi ada banyak artikel bagus.
Salah satunya: Analis Bisnis dan Analis Sistem di TI. Kami mengerti varietasnya
pengantar
Saya telah bekerja sebagai analis Oracle Siebel CRM selama lebih dari 3 tahun, selama lebih dari satu tahun saya telah mempersiapkan pekerja magang untuk menghadapi kenyataan pahit tentang hari kerja. Sebagai aturan, gaya belajar saya terdiri dari kuliah pengantar kecil dan pemanfaatan langsung peserta pelatihan untuk tugas nyata dengan kontrol kualitas.
Dalam kondisi isolasi diri, saya menghadapi kasus yang menarik: ketika bekerja sebagai konsultan untuk perusahaan dengan persyaratan keamanan yang ketat, saya tidak memiliki kesempatan untuk mengkonsolidasikan pengetahuan teoretis yang ditransfer dengan aplikasi praktis. Ini membawa saya pada tantangan yang sangat menarik bagi mentor: perlunya mempresentasikan teori sedemikian rupa untuk meminimalkan konsep-konsep abstrak untuk peserta pelatihan, mempersiapkannya untuk masalah-masalah nyata tanpa pengalaman praktis. Saya akan mencoba menangkap pengalaman yang didapat dalam artikel ini.
Apa yang dilakukan seorang analis?
Biasanya, ketika menjawab pertanyaan tentang profesi saya, saya mengatakan bahwa seorang analis adalah penerjemah dari bahasa humaniora ke dalam bahasa teknisi. Tetapi apakah semuanya begitu sederhana di dunia?
Faktanya, analitik terdiri dari langkah-langkah berikut:
- Menerima permintaan revisi sistem
- Menyempurnakan hasil yang diinginkan pengguna pada akhir proses Anda
- Klarifikasi proses kerja saat ini
- Desain awal dari solusi
- Koordinasi dengan pelanggan mengenai langkah-langkah proses tambahan, jika diperlukan untuk mencapai hasil,
- Koreksi solusi
- Koordinasi proses dengan pelanggan
- Pendaftaran spesifikasi teknis untuk pengembang
- Menguji skenario utama fungsionalitas
- Persiapan dokumentasi, menulis instruksi pengguna
- Transfer fungsionalitas ke pelanggan
Pelajari lebih lanjut tentang setiap langkah
Menerima permintaan revisi
Sebagai aturan, pelanggan modifikasi adalah orang-orang yang jauh dari bidang TI. Persyaratan jarang sistematis, dijelaskan dengan jelas dan logis. Ini adalah sesuatu yang perlu Anda perbaiki sebelum menyerahkan tugas kepada pengembang.
Klarifikasi hasil yang diinginkan
Di sini Anda harus mengklarifikasi apa yang diinginkan pelanggan secara khusus. Itu bisa apa saja: mengubah status aplikasi, membuat dokumen, mengirim SMS atau E-mail, secara umum, semua yang dapat dilakukan sistem TI.
Selalu gunakan pedoman berikut pada tahap ini:
- Bagi Anda, seharusnya tidak ada konsep abstrak tunggal dalam pernyataan masalah dari pelanggan. Jika Anda tidak yakin apakah Anda dan pelanggan memiliki pemahaman yang sama tentang beberapa kata, pastikan Anda memahami.
- Tidak ada pertanyaan bodoh, tidak ada pertanyaan yang dirumuskan secara salah dan tidak benar. Analis bukan ahli dalam semua bidang bisnis, tetapi harus dapat dengan cepat memahami bidang baru. Jangan takut untuk bertanya.
Klarifikasi proses saat ini
Paling sering, proses kerja saat ini disebut "proses AS-IS"
Setelah menyelesaikan tahap ini, Anda harus membayangkan proses sebagai kotak hitam .
Desain awal dari solusi
Tahap ini menyiratkan definisi proses masa depan atau, seperti yang mereka katakan, "proses TO-BE".
Setelah menyelesaikan tahap ini, kotak hitam Anda akan berubah menjadi putih, yaitu, Anda harus tahu persis apa yang terjadi di dalam proses. Kelihatannya seperti ini:
Dipandu oleh prinsip-prinsip berikut:
Anda mungkin telah memperhatikan bahwa "Input 3" muncul di kotak putih. Terkadang Anda mungkin menemukan bahwa tidak ada cukup data dalam sistem untuk mencapai hasil. Mari kita ambil contoh semacam sertifikat pada kesimpulan perjanjian antara perusahaan pelanggan dan klien, yang harus mencerminkan patronimik klien, yang tidak disimpan dalam sistem Anda. Dalam hal ini, Anda harus memberi tahu pelanggan tentang hal ini dan menawarkan solusi untuk masalah tersebut, misalnya, menambahkan bidang "Patronimik" ke sistem dan memastikannya terisi. Untuk pengguna, ini berarti mengisi bidang tambahan saat bekerja dengan sistem, yang harus disepakati dengan pelanggan.
Koreksi solusi
Terkadang koordinasi langkah-langkah baru dalam proses berlangsung dengan komentar tentang keputusan Anda dari pelanggan. Dalam hal ini, Anda harus memperbaiki solusi yang diusulkan. Tetapi ini tidak selalu terjadi, yang berarti bahwa Anda adalah orang baik dan telah menyelesaikan desain pada langkah "Desain awal dari solusi"
Koordinasi proses
Setelah desain selesai, proses harus disetujui oleh pelanggan. Format perjanjian paling sering tergantung pada realitas perusahaan tertentu dan pelanggan tertentu. Ini bisa berupa deskripsi tekstual dari proses, deskripsi dalam notasi untuk menggambarkan proses bisnis, atau perjanjian verbal.
Pendaftaran spesifikasi teknis
Format penugasan teknis juga tergantung pada norma-norma yang diadopsi di perusahaan pelanggan dan pelaksana dan, sering kali, pada kompetensi pengembang: pengembang yang tidak berpengalaman membutuhkan deskripsi proses yang lebih terperinci. Selama karir saya, saya telah bertemu perusahaan-perusahaan di mana tidak ada spesifikasi teknis sama sekali dan semuanya dibahas dalam format bebas, tetapi semua pernyataan memiliki fitur umum: Anda harus menggambarkan aritmatika dan fungsi logis yang didefinisikan pada langkah desain, dalam teks atau visual, dalam bentuk blok. skema.
Pengujian fungsional
Mengantisipasi pertanyaan, ya, analis sering melakukan pengujian. Tetapi, sebagai suatu peraturan, pengujian ini dangkal untuk memastikan bahwa pengembang memahami Anda dengan benar. Biasanya, itu terbatas untuk melalui skenario kerja utama untuk mengidentifikasi keberadaan cacat kritis, yaitu bug yang tidak memungkinkan mencapai hasil yang diinginkan dengan cara apa pun. Spesialis QA terlibat dalam pencarian cacat kecil dan pengujian fungsionalitas dalam kondisi yang berbeda.
Dokumentasi
Ini mungkin tahap yang paling tidak disukai sebagian besar analis, tetapi pengetahuan ahli Anda tentang fungsi tersebut harus dicatat secara tertulis. Tulis dokumentasi dengan baik: prosesnya harus dijelaskan secara cukup rinci sehingga orang yang tidak tercerahkan dapat memahami apa yang terjadi di dalam kotak putih, dan cukup singkat sehingga Anda dapat membacanya dan tetap terjaga.
Instruksi pengguna adalah memo singkat untuk pengguna akhir dari fungsionalitas Anda, di mana tindakan pengguna dijelaskan dalam langkah-langkah. Jenis dokumentasi ini harus terdiri dari daftar tindakan, tidak boleh mengandung istilah teknis.
Format dokumen-dokumen ini juga tergantung pada norma-norma yang diadopsi dalam perusahaan pelanggan tertentu.
Transfer fungsionalitas ke pelanggan
Bagian paling menyenangkan dari pekerjaan. Di sini Anda memamerkan pekerjaan yang dilakukan kepada pelanggan, mengumpulkan kemenangan, bangga dengan pekerjaan yang dilakukan, dan mengisi diri Anda dengan emosi positif untuk tugas selanjutnya.
Keluaran
Pekerjaan seorang analis melibatkan banyak komunikasi, brainstorming, dan menggunakan semua kemungkinan logika yang telah diberikan oleh alam kepada Anda.
Jika Anda menikmati sistematisasi dan optimisasi, jika Anda ingin segalanya menjadi jelas dan logis dalam hidup, bekerja sebagai analis akan memberi Anda banyak kesenangan, dan Anda pasti akan mencapai puncak dalam karir Anda.
Saya harap artikel saya membantu Anda membentuk kesan tentang analitik dan mengarahkan pada kesadaran akan jalan hidup Anda. Semoga berhasil!