Hai Nama saya Nastya, saya seorang analis di aplikasi seluler Alfa-Business. Terkadang mereka bertanya apa yang saya lakukan di tempat kerja. Teman, keluarga dan, anehnya, pengembang. Setiap kali saya menjawab secara berbeda, mencoba memberikan contoh yang paling dekat dengan teman bicara saya.
"Seorang analis sistem menerjemahkan persyaratan pengguna dari bahasa manusia ke bahasa ..." terdengar cukup dimengerti oleh orang yang tidak terhubung dengan IT. Tetapi jika Anda terlibat langsung dalam pengembangan, definisi seperti itu tidak akan cukup. Demi percobaan kecil, saya bertanya pada tim saya: "Apa yang dilakukan analis sistem?" Kami membaca di bawah potongan, apa yang terjadi.
Bagi saya, seorang analis sistem adalah orang yang dapat memberikan jawaban untuk pertanyaan apa pun: dari "Bagaimana fitur seharusnya bekerja" hingga "Mengapa Bumi bulat" (c) tester
Adapun Bumi, mungkin terlalu banyak, tetapi sebaliknya cukup akurat. Di mana menyimpan data, cara mentransfernya, cara kerja fitur, mengapa fitur itu tidak berfungsi ... Setiap kali ketika sesuatu yang tidak dapat dipahami ditemukan dalam jaminan produk, frase "analytics diperlukan" berikut.
Untuk memahami cara kerja sistem, analis beralih ke dokumen internal. Biasanya jawabannya ada di antara teks, diagram dan tabel. Tetapi kadang-kadang orang pergi tanpa menulis dokumentasi. Atau itu tidak relevan. Atau tidak bisa diandalkan. Karma analis seperti itu sangat menderita, tetapi, untungnya, ada cara lain untuk menemukan informasi.
Penggunaan sistem pencatatan yang meyakinkan dapat mengurangi fiksi dari 30 halaman TK menjadi beberapa pertanyaan. Hal utama adalah mengetahui apa yang harus dicari. Log berisi informasi tentang metode yang disebut, parameter input dan output, penyebab kesalahan. Jika layanan ini komposit - operasi langkah demi langkah. Analis perlu memahami struktur log dan dapat memfilternya: biasanya sejumlah besar data dicatat.
Informasi yang ditemukan dalam log dilengkapi dengan pencarian oleh kode aplikasi. Proyek ini berisi informasi tentang sumber data, logika pemrosesan variabel, dan banyak hal lain yang diperlukan. Keberhasilan acara tergantung pada keterampilan analis dan karakteristik perusahaan. Di beberapa organisasi, analis tidak memiliki akses ke kode. Apakah itu benar atau salah adalah pertanyaan yang sulit. Bagaimanapun, jika tidak ada akses (atau pemahaman tentang apa yang terjadi), Anda selalu dapat bertanya kepada pengembang.
Jika muncul masalah yang tidak ada yang dipecahkan, sumber eksternal digunakan. Oke Google, model kosmologis alam semesta? Segala cara baik di sini: artikel, forum, kursus pelatihan, dokumentasi untuk sistem pihak ketiga. Terkadang orang India dari YouTube datang untuk menyelamatkan, tetapi ini adalah kasus yang ekstrem. Ngomong-ngomong, seseorang harus dapat mencari dalam dua bahasa, baik, atau segera dalam bahasa Inggris
Hindu .
Sumber informasi lain adalah orang. Seorang analis yang mengetahui bidang subjek dapat menyelesaikan tugas dalam lima menit, yang Anda uraikan beberapa hari. Oleh karena itu, Anda perlu mengetahui apa yang dilakukan rekan kerja dan dapat dengan benar merumuskan pertanyaan Anda.
Analis, sebagai navigator, membuka jalan ke tujuan, menghindari rintangan, dan terus-menerus mencari jalur yang lebih pendek (c) pengembang front-end
Untuk pergi dari St. Petersburg ke Saratov, Anda memerlukan mobil yang andal dan peta mobil. Nah, jika ada kotak P3K, roda cadangan, alat. Keterampilan berkomunikasi dengan penduduk setempat tidak akan berlebihan, yah, secara umum, memahami mengapa Anda pergi ke Saratov, dan tidak ke Wilayah Krasnodar, misalnya. Dengan analitik juga. Anda harus memiliki alat untuk bekerja, kemampuan untuk berinteraksi dengan orang-orang dan pemahaman yang jelas tentang hasil yang diharapkan. Pengetahuan tentang sistem dan teknologi menjadi peta jalan.
Tugas apa pun memiliki setidaknya dua solusi. Penting untuk memilih jalur yang tidak akan lebih pendek, tetapi lebih tepat. Itu lebih tepat dalam hal arsitektur, pemenuhan persyaratan produk dan biaya implementasi. Terkadang analis hanya memberikan informasi untuk keputusan tim, dalam kasus lain, ia membuat pilihan sendiri.
Untuk menawarkan implementasi yang memadai, Anda perlu memahami struktur sistem: dari pola arsitektur hingga teknologi pengembangan. Dengan menerapkan perubahan, analis mengevaluasi dampak pada komponen aplikasi dan sistem terintegrasi lainnya. Saat mengembangkan aplikasi seluler, Anda perlu mengingat tentang pengguna dengan versi lama. Jika sistem memiliki beberapa bidang - tentang keseragaman pekerjaan mereka. Saat menggunakan beberapa sumber data - tentang konsistensi mereka. Secara umum, ada cukup
sakit kepala fitur menarik dalam pekerjaan.
Yah, saya tidak tahu, Anda hanya penguji bagi saya. Nah, atau campuran produk dengan tester, sesuatu seperti ini (c) pengembang backend
Saya setuju, kedengarannya agak ofensif, tetapi ada beberapa kebenaran di sini. Pertama, analis memeriksa sistem untuk memahami cara kerjanya. Kemudian dia yakin bahwa hasil kerja pengembang bekerja dengan benar di semua tingkatan: database berisi data yang dapat diandalkan, layanan mengembalikan jawaban yang benar, pengguna melihat hasil yang diharapkan. Jika ada kesalahan, tingkat kesalahan, penyebab perbedaan dan opsi koreksi yang mungkin ditemukan. Menilai kesesuaian sistem dengan berbagai jenis persyaratan adalah bagian integral dari analitik.
Aspek makanan lebih rumit. Pemilik produk tahu apa yang perlu dilakukan untuk membuat pengguna senang. Seorang analis sistem tahu caranya. Pendapat subyektif saya adalah bahwa analis, pada tingkat yang sama dengan anggota tim lainnya, harus (atau dapat) menangani masalah produk. Ketika seluruh tim khawatir tentang meningkatkan pengalaman pengguna dan mencapai tujuan keuangan, solusi yang lebih baik lahir daripada ketika satu atau lebih orang melakukannya.
Mengumpulkan informasi tentang produk, proyek dan sistem bank, terlibat dalam pembaruan dan penyebarannya, berada di garis depan pisau informasi (c) Scrum-master
Semuanya dimulai dengan dokumentasi, dan berakhir dengan itu. Ini disiapkan untuk penggunaan internal dan, jika berlaku, untuk Pelanggan. Dokumen dibuat sesuai dengan GOST atau standar internal. Metode dokumentasi juga dapat bervariasi antar lapisan sistem.
Saat menulis dokumen, berbagai teknik, standar, dan notasi pemodelan sistem digunakan. Jarang ketika Anda harus mengikuti aturan tanpa cela. Itu harus dapat diandalkan dan relevan. Dan jika jelas pertama kali, maka umumnya luar biasa.
Di sini , omong-omong, ada artikel yang menarik di mana masalah kualitas dokumentasi diungkapkan.
Selain dokumen sistem, analis dapat menulis materi untuk Wiki perusahaan. Mempelajari sesuatu yang baru - beri tahu orang lain. Jika Anda ingin berbagi pengalaman, buat presentasi. Sekali lagi, ini tidak selalu dan tidak di mana-mana. Tetapi jika perusahaan memiliki proses manajemen pengetahuan, analis yakin untuk mengambil bagian di dalamnya.
Ada banyak hal berbeda yang perlu diketahui oleh seorang analis agar sesuai dengan peran dan harapan tim. Bergantung pada spesifikasi produk dan industri, komposisi dan tingkat signifikansinya bervariasi. Apa yang dilakukan analis, kami tahu. Masih memahami apa yang perlu Anda ketahui untuk berhasil menyelesaikan semua tugas. Perhatian Anda diundang ke analisis peta jalan. Skema ini berisi keterampilan utama dalam arah yang berbeda, serta upaya untuk membedakan antara sistem dan analisis bisnis.
Seberapa universal kartunya, sulit bagi saya untuk menilai. Karena itu, saya menunggu komentar dari pengembang dan analis dari organisasi lain :)
