Salam pembuka! Nama saya Sergey, dan saya seorang analis bisnis / sistem. Saya telah bekerja di industri TI selama sekitar 8 tahun, dimulai dengan dukungan yang mengalir ke pengujian dan melanjutkan dengan analitik: baik bisnis dan sistem. Saya belum bekerja secara terpisah sebagai bisnis dan sebagai analis sistem.Dalam kegiatan profesional saya secara umum, termasuk praktik dan wawancara pribadi, dan khususnya wawancara dengan calon potensial, saya perlahan-lahan memahami keterampilan apa yang diharapkan pasar dari Analis. Habr tidak melihat artikel baru tentang hal ini untuk waktu yang lama, jadi saya memutuskan untuk menyiapkan materi sendiri.Untuk siapa, menurut pendapat saya, artikel ini akan bermanfaat:- Analis bisnis / sistem awal;
- Analis yang ingin terus memompa prof mereka. Keterampilan
- Mungkin manajer rekrutmen.
Saya harus segera mengatakan bahwa poin-poin di bawah ini adalah visi subjektif saya tentang spesialisasi analis , yang dibentuk selama latihan. Jika perusahaan Anda menjalankan scrum lengkap dengan pemilik produk yang berjarak satu meter dari Anda, dengan desainer dan arsitek yang dialokasikan untuk tim, beberapa di atas mungkin tidak diminati.Namun demikian, setidaknya semua keterampilan ini tidak akan berlebihan dan akan membuat analis semakin kompeten dalam pertanyaannya. Tentu saja, Anda perlu memahami bahwa saya tidak mencantumkan semua keterampilan dan kemampuan analis (notasi yang sama, keterampilan bisnis, sql, dan sebagainya).Analisis bisnis
- Hilangkan persyaratan ambigu pada tahap paling awal
Saat berbicara dengan pelanggan bisnis, Anda perlu menyadari bahwa bahasanya dapat berbeda secara signifikan dari bahasa Anda. Persyaratan bisnis dapat disuarakan sedemikian rupa sehingga beberapa peserta dalam proses persetujuan persyaratan memiliki pemahaman yang berbeda tentang apa arti persyaratan ini. Ambiguitas dihasilkan, yang sangat mahal bagi tim pada tahap pengembangan selanjutnya.Masalahnya paling akut ketika ada beberapa pelanggan bisnis, yang masing-masing mengajukan persyaratannya sendiri. Misalnya, ketika mengintegrasikan dua sistem, masing-masing memiliki perwakilan sendiri dari bisnis.Studi kasus: satu bulan pengembangan dihabiskan untuk fungsional mentransfer daftar kegiatan dari objek No. 1 ke objek No. 2. Pada tahap pengujian penerimaan, ditemukan bahwa pelanggan mengharapkan fungsionalitas yang sama sekali berbeda - menyalin, tidak mentransfer kegiatan. Dalam proses pengerjaan ulang fungsionalitas dan merinci ambiguitas, tim TI, pertama, setuju dengan pelanggan tentang MVP, dan, kedua, kebutuhan untuk bekerja dengan akar masalah bisnis. Dihipotesiskan bahwa fungsionalitas penyalinan itu sendiri diperlukan hanya karena fungsi yang diimplementasikan tidak cukup untuk memuat templat aktivitas.
- Jangan takut untuk menanyakan kepada pelanggan tentang persyaratan persyaratan
Saya bertemu dengan kasus ketika saya bekerja ketika pernyataan pengembangan dijelaskan tanpa menetapkan tujuan bisnis: apa sebenarnya perbaikan ini akan membantu bisnis? Rasa sakit apa yang akan disembuhkan oleh perbaikan dari bisnis ini?Seringkali, perbaikan seperti itu tanpa tujuan menyebabkan konsekuensi yang tidak menyenangkan sudah pada tahap pengujian, ketika pengembang dan tester tidak mengerti mengapa kami merancang fungsi ini. Lebih buruk lagi, pengembang dan penguji tidak menerima jawaban dari analis, dan jika mereka melakukannya, mereka sering datang dengan analis itu sendiri: tujuan yang dibentuk oleh analis itu sendiri.
Tuliskan tujuan bersama-sama dengan pelanggan, sehingga benar-benar semua peserta dalam proses setiap saat memahami mengapa mereka melakukan pekerjaan mereka.- Menuntut kehadiran pelanggan Anda di pertemuan bisnis
Dalam praktiknya, saya menemukan pelanggan yang berbeda, beberapa di antaranya tidak segera siap untuk mengundang analis ke pertemuan offline mereka. Analis juga harus bekerja dengan ini: untuk menyetujui dan menunjukkan hasil kolaborasi yang terkoordinasi dengan baik., — UX- — « », , . : , , windows-, . , .
Banyak analis, termasuk saya, dalam proses merumuskan persyaratan, dihadapkan dengan tenggat waktu yang keras, menggunakan teknik berikut: mereka menulis surat kepada para peserta proses dengan tenggat waktu di mana surat itu harus dijawab dan persyaratan yang disetujui / komentar harus dibuat. Jika tidak, persyaratan akan secara otomatis diakui sebagai disepakati.Seperti yang telah ditunjukkan oleh praktik, tidak ada yang baik dalam pendekatan ini. Jelas bahwa, bekerja di pihak vendor dan memiliki kesepakatan, Anda harus menggunakan metode seperti itu, tetapi masih mencoba untuk menghindari persetujuan diam-diam, cobalah untuk memahami mengapa para peserta tidak ingin memberi Anda jawaban sekarang, dan menyelesaikan masalah sesegera mungkin.Lebih baik untuk mendokumentasikan fakta bahwa jawabannya tidak diterima dari orang-orang ini dan itu dan Anda melihat risiko berikut untuk proyek dalam hal ini. Namun, proses kerja tidak bisa diam, karena itu Anda dipaksa untuk melanjutkan pekerjaan analitis Anda, sementara risiko yang ditetapkan sebelumnya harus jelas bagi semua peserta dalam proses.Dalam proses pengembangan integrasi dua sistem, kami dihadapkan dengan pembentukan persyaratan oleh direktur yang mencakup tindakan pengguna dalam dua sistem, tetapi kurangnya koordinasi eksplisit persyaratan yang sama dari kepala langsung unit, yang karyawannya adalah pengguna sistem.
Ternyata kemudian, kepala divisi tidak mengerti sama sekali mengapa semua perbaikan ini dan bagaimana mereka akan membantu mengoptimalkan proses dalam bidang tanggung jawabnya.
Seringkali, peserta dalam proses persetujuan hanya takut untuk membubuhkan tanda tangan, karena mereka tidak sepenuhnya memahami bagian-bagian tertentu dari proses bisnis yang diperbarui. Tugas Anda sebagai analis bisnis adalah menghilangkan kesalahpahaman ini.
- Perkenalkan area subjek ke pengembang
Luangkan beberapa jam, tetapi beri tahu pengembang Anda tentang pelanggan, proses bisnis saat ini, rasa sakit, dan rencana pengembangan. Sebagai aturan, pengembang yang bermotivasi baik tidak hanya melakukan pekerjaan mereka dengan sangat baik, memahami untuk siapa mereka menulis kode, tetapi juga memberikan kontribusi yang berharga: mereka menawarkan optimisasi, solusi, lebih bersedia untuk mengajukan pertanyaan klarifikasi.Jika perlu (dan kurangnya scrum), tarik pelanggan ke pertemuan tersebut. Sebagai aturan, perwakilan bisnis bersedia menyetujui inisiatif tersebut.- Ajari pelanggan untuk menjawab pertanyaan "Apa?" Daripada merumuskan persyaratan dalam format "Bagaimana"
Pelanggan tidak boleh merumuskan persyaratan bisnis / pengguna dari posisi "Cara": kita perlu tombol di layar ini untuk menghasilkan laporan; kita memerlukan tautan ke sistem eksternal di bagian ini; dll.Pada tahap analisis awal proses, sebelum desain itu sendiri, pelanggan tidak boleh menawarkan solusi.Alih-alih, ajarkan pelanggan untuk merumuskan masalah, "rasa sakit" mereka: kita perlu membuat laporan setiap minggu, yang secara manual ditambahkan oleh seorang karyawan dan dikirim ke manajemen; dalam proses bekerja dengan klien, kita perlu menganalisis informasi tambahan, dan karena itu tidak tersedia dalam sistem CRM, kita harus membuka tab baru di browser dan masuk ke sistem yang berdekatan.Setelah mempelajari rasa sakit pelanggan, Anda, sebagai spesialis, dapat menawarkan opsi untuk mengoptimalkan proses dan otomasinya. Misalnya, secara otomatis mengirim laporan yang dihasilkan ke surat karyawan, menyimpan karyawan dari pekerjaan manual dengan laporan, pada prinsipnya, secara otomatis mengunduh data dari sistem yang berdekatan ke CRM, dan sebagainya.Dalam banyak kasus, pendekatan ini akan menghadapi kenyataan: tenggat waktu dan prioritas. Tetapi Anda, bagaimanapun juga, dengan jujur mencoba.
- Pastikan untuk membagi pengguna menjadi beberapa kelas
Menerima persyaratan dari pengguna sistem, tanpa gagal memperhitungkan perannya dalam proses bisnis. Dalam praktiknya, sering ada kasus ketika kepala departemen membentuk persyaratan untuk fungsional yang dengannya seorang karyawan biasa akan bekerja.Bagi pengguna sistem menjadi peran, dan fungsi yang dipertajam untuk satu peran, jangan "kotorkan" di bawah peran lain.Sekali, dalam kerangka Sistem, kami menerapkan tampilan daftar transaksi dengan pelanggan.
Diasumsikan bahwa baik manajer maupun karyawan biasa akan bekerja dengan daftar tersebut. Sayangnya, kami tidak dapat memperoleh pemahaman dari pelanggan tentang perlunya membagi bagian UI revisi menjadi dua daftar / layar: satu daftar untuk manajer untuk tujuan analisis dan kontrol, daftar kedua untuk karyawan untuk tujuan melakukan kegiatan operasional.
Hasilnya adalah monster tertentu, yang kemudian harus diselesaikan dan diselesaikan.
Terapkan praktik terbaik dari UX: berolahraga karakter - model pengguna. Meyakinkan pelanggan untuk memisahkan persyaratan untuk setiap karakter.- Aktif menggunakan brainstorming analitis
Hal ini dimungkinkan bersama dengan analis kedua, mungkin juga dengan desainer UX. Dalam proses penyerangan, cobalah dua peran: satu orang pertama menghasilkan banyak ide, layak dan tidak terlalu, yang kedua mengkritik ide-ide ini, membusuknya, menuliskannya, memikirkannya; kemudian berganti peran dan melakukan pekerjaan yang sama.Seperti yang ditunjukkan oleh praktik, pendekatan ini secara signifikan akan mempercepat proses penyusunan persyaratan fungsional dan meningkatkan kualitasnya. Tetapi ada kesulitan dalam bahwa kedua spesialis harus dalam konteks tugas.- Jika Anda terjebak di Air Terjun, jangan putus asa dan bergerak menuju Scrum
Di salah satu perusahaan, secara harfiah dalam setahun, tim kami berhasil mentransfer proses memperkenalkan peningkatan dari yang sudah mapan di tingkat manajer pengelola ke Waterfall ke semacam Scrum. Ya, tenggat waktu "jelas" untuk tumpukan berlumuran sangat tinggi, yang selalu diminta pelanggan dari tim TI, mundur, sementara retorika secara bertahap dimitigasi melalui rilis dua minggu, solusi MVP dan respons cepat terhadap perubahan.- Jangan pernah menjelekkan pelanggan.
Ya, ada semua jenis pelanggan. Ada orang yang benar-benar marah. Namun demikian, seorang analis bisnis harus menyelesaikan masalah ini baik sendiri atau dengan keterlibatan manajer, dan dalam kasus apa pun ia tidak boleh mengambil "pertengkaran dari gubuk" - di tim.Tim harus termotivasi dengan baik untuk bekerja, dan peran seorang analis bisnis dalam proses pembentukan motivasi adalah salah satu kuncinya.Serius. Ketika dalam proses berkomunikasi dengan pelanggan, saya mendengar masukan verbal yang absurd dari kolega analitik saya, ketika kolega analitik saya mengganggu pelanggan tanpa mendengarkannya sampai akhir, saya ingin mengirimnya ke kursus negosiasi atau etika dasar.Cobalah dan dengarkan teman bicara, dan dengarkan dia.- Singkirkan kata-kata parasit
Cobalah untuk menghindari kata-kata parasit dan kurang "moo" dalam percakapan. Awalnya sulit, tapi, percayalah, sulit bagi pelanggan untuk mendengarkan analis seperti itu yang tidak bisa mengungkapkan pikirannya dengan jelas dan jelas. Parasit dapat dipengaruhi oleh pengembang, perancang, penguji, tetapi bukan analis bisnis yang menghubungkan tim TI dengan Bisnis. :
- " ".
- ", : ".
Analisis sistem
- Saat mengatur tugas ke depan dan belakang, cobalah untuk menggambarkan diagram urutan
Atau, dalam bahasa Rusia, diagram urutan. Diagram akan terbukti bermanfaat bahkan bukan dari sudut pandang pengembangan, tetapi dari sudut pandang verifikasi persyaratan mereka sendiri. Sangat sering, ketika menggambarkan aliran pesan, saya mengidentifikasi "lubang" dalam proses saya sendiri. Misalnya, API yang tidak relevan.Untuk "menggambar" urutan diagram dengan cepat, gunakan plugin PlantUML untuk Confluence. Sepertinya saya lebih cepat mengetik kode daripada menyesuaikan lokasi blok dan panah dengan pena. Tetapi setiap orang di bagian ini memiliki pengalaman dan preferensi mereka sendiri.
Dalam hal analisis, Editor Swagger memungkinkan Anda untuk menutup lubang Anda sendiri dalam persyaratan. Di suatu tempat mereka kehilangan atribut, di suatu tempat mereka lupa membuat tugas di JIRA untuk menyelesaikan database. Jangan mencoba mengingat sintaks Swagger, tetapi buat templat untuk berbagai jenis API (direktori, filter, dll.) Untuk menyederhanakan hidup Anda di masa mendatang.
- Gunakan alat pengembang secara aktif di browser target untuk menganalisis permintaan dan respons klien dari server
Pertama, selama proses penerimaan awal, Anda dapat memeriksa API yang Anda uraikan sendiri. Terkadang lebih cepat untuk memeriksa beberapa peningkatan dengan permintaan keluar daripada oleh UI untuk memahami akar masalah pada tahap awal.Anda, sebagai seorang analis, akan membutuhkan lebih sedikit waktu untuk memeriksa implementasi dari pengembang: data keluar, data masuk, hasil di UI.
Kedua, Anda dapat memverifikasi urutan panggilan yang benar. Bagaimanapun, Anda sendiri menggambarkannya dalam kerangka diagram urutan.Pendekatan ini memungkinkan tim kami untuk melakukan perbaikan yang cukup rumit pada prom sebagai bagian dari sprint tanpa penundaan. :
- " JavaScript". JSON, , HTML, http / https, .
- . , . " . , , ". , , , .
Sebagai tambahan
Anda bahkan mungkin menyukainya dan ingin berevolusi menuju analitik UX. Bagaimanapun, mempelajari literatur dan alat desain yang relevan akan mendapat manfaat setidaknya dalam hal menemukan bahasa yang sama dengan desainer UX dari tim Anda.Seringkali persyaratan yang Anda, sebagai analis, detail dan tuliskan, selanjutnya akan disesuaikan oleh perancang. Lagi pula, Anda tidak sendirian, sebenarnya, sedang merancang pengalaman pengguna.Untuk berada pada gelombang yang sama, latih analisis UX Anda. Misalnya, dalam waktu luang Anda dalam Sketsa atau Figma, dari waktu ke waktu menunjukkan hasilnya kepada desainer Anda. Pengalaman analitik seperti itu tidak akan pernah berlebihan. :
- " ".
- " ".
- ". ".
- ". ".
***Terima kasih telah membaca artikel! Saya akan berterima kasih, pertama, atas umpan baliknya. Kedua, untuk rekomendasi literatur, sumber, untuk praktik terbaik, pengalaman pribadi, dan rekomendasi.