Beberapa waktu lalu saya membaca buku Business Analyst Body of Knowledge disingkat BABOK versi 3.0. Cukup terkesima dengan isi bukunya yang terstruktur dan masuk akal untuk dipraktikan. Sekalipun memang tidak mudah untuk mempraktikannya.
Saya tidak ingin berbicara kondisi ideal atau tidak ideal, terkadang ini hanya dijadikan alasan saja untuk tidak mau mencoba agar lebih baik. Perubahan perlu pengorbanan apalagi jika ingin memperbaiki atau meningkatkan kualitas. Memang sering kali banyak yang tidak sepaham, karena ujung-ujungnya beda kepentingan. Mari kembalikan ke individu masing-masing.
Ok sekarang mari kita lihat peran Business Analyst menurut BABOK.
Business Analyst berperan dalam menyelaraskan solusi yang sudah didesain dan dibuat oleh tim pengembang dengan kebutuhan atau keingingan pemangku kepentingan (stakeholder). Beberapa aktifitas yang dilakukan oleh Business Analyst adalah sebagai berikut:
- Memahami masalah dan tujuan perusahaan
- Menganalisis kebutuhan dan solusi
- Merancang strategi
- Mendorong perubahan, dan
- Memfasilitasi kolaborasi pemangku kepentingan (stakeholder)
Peran Business Analyst dalam suatu lowongan pekerjaan biasanya juga ditulis dengan nama-nama berikut:
- Arsitek Bisnis / Business Architect
- Analis Sistem Bisnis / Business System Analyst
- Analis Data / Data Analyst
- Analis Perusahaan / Enterprise Analyst
- Konsultan Manajemen / Management Consultant
- Analis Proses / Process Analyst
- Manajer Produk / Product Manager
- Pemilik Produk / Product Owner
- Requirements Engineer
- Analis Sistem / System Analyst
Seorang Business Analyst harus memahami bagaimana siklus hidup dari suatu daftar kebutuhan. Agar dapat menghasilkan daftar kebutuhan yang tepat dan terkini. Sehingga dapat meningkatkan kinerja tim pengembang secara efektif dan efisien. Berikut adalah bagan dari siklus manajemen kebutuhan.
Ada beberapa tugas di dalam siklus tersebut, diantaranya adalah sebagai berikut:
- Trace Requirements: menganalisis dan memelihara hubungan antara requirements, desain, komponen solusi, dan produk terkait lainnya untuk analisis dampak, cakupan, dan alokasi.
- Maintain Requirements: memastikan bahwa requirements dan desain akurat dan terkini sepanjang siklus hidup dan memfasilitasi penggunaan kembali (facilitate reuse) jika sesuai.
- Prioritize Requirements: menilai nilai, urgensi, dan risiko yang terkait dengan requirements dan desain tertentu untuk memastikan bahwa analisis dan / atau delivery pekerjaan dilakukan pada yang paling penting pada waktu tertentu.
- Assess Requirements Changes: mengevaluasi persyaratan stakeholder yang baru dan yang berubah untuk menentukan apakah mereka perlu ditindaklanjuti dalam lingkup perubahan.
- Approve Requirements: bekerja dengan stakeholder yang terlibat dalam proses tata kelola atau operasional untuk mencapai persetujuan dan kesepakatan tentang persyaratan dan desain.
Di artikel kali ini saya akan fokuskan ke Maintain Requirements.
Menjaga agar requirements selalu sesuai adalah pekerjaan yang tidak mudah. Ini salah satu peran utama Business Analyst. Tujuan dari menjaga requirements adalah untuk mempertahankan akurasi dan konsistensi serta validasi requirements di dalam siklus requirements dan juga untuk mendukung penggunaan kembali (reuse) requirements dalam solusi lain.
Ada beberapa teknik yang dapat digunakan untuk menjaga requirements, diantaranya adalah sebagai berikut:
- Business Rules Analysis: digunakan untuk mengidentifikasi aturan bisnis yang mungkin serupa di seluruh perusahaan untuk memfasilitasi penggunaan kembali.
- Data Flow Diagrams: digunakan untuk mengidentifikasi aliran informasi yang mungkin serupa di seluruh perusahaan untuk memfasilitasi penggunaan kembali.
- Data Modelling: digunakan untuk mengidentifikasi struktur data yang mungkin serupa di seluruh perusahaan untuk memfasilitasi penggunaan kembali.
- Document Analysis: digunakan untuk menganalisis dokumentasi yang ada tentang sebuah perusahaan yang dapat berfungsi sebagai dasar untuk memelihara dan menggunakan kembali requirements.
- Functional Decomposition: digunakan untuk mengidentifikasi persyaratan yang terkait dengan komponen dan tersedia untuk digunakan kembali.
- Process Modeling: digunakan untuk mengidentifikasi persyaratan yang terkait dengan proses yang mungkin tersedia untuk digunakan kembali.
- Use Cases and Scenarios: digunakan untuk mengidentifikasi komponen solusi yang mungkin dimanfaatkan oleh lebih dari satu solusi.
- User Stories: digunakan untuk mengidentifikasi persyaratan yang terkait dengan story yang mungkin tersedia untuk digunakan kembali.
Teman-teman, perhatikan kata “penggunaan kembali / digunakan kembali / menggunakan kembali” pada tulisan diatas yang ditebalkan. Perhatikan baik-baik, seorang Business Analyst secara tidak langsung dapat meng-identifikasi komponen / fitur / modul yang dapat direuse / digunakan kembali dalam suatu solusi untuk proyek / divisi / aplikasi / modul lainnya. Tentunya ini akan sangat memudahkan programmer dalam menyusun struktur kode ke dalam folder-folder, file-file, dan class-class.
Pekerjaan Software engineer atau programmer akan lebih indah 🙂 tinggal bagaimana menghadapi masalah teknikal. Dan dapat mengurangi perdebatan tentang “ini kode nya mau di taruh di mana ya? nama kelasnya apa? nama variabelnya apa?” dan lain sebagainya. Karena penyusunan struktur kode cenderung akan mengikuti bentuk organisasi sesuai dengan Conway’s Law yang mana ini bisa teridentifikasi secara sengaja ataupun tidak sengaja oleh seorang Business Analyst.
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.
— Melvin E. Conway
Di dalam buku BABOK ada 50 teknik yang bisa digunakan oleh seorang Business Analyst untuk mencapai tujuannya serta memaksimalkan peranannya sebagai Business Analyst. Seorang individu yang baik tentunya ingin memberikan kontribusi yang terbaik bagi organisasinya termasuk bagi dirinya sendiri dan rekan kerjanya.
Pentingnya Peran Business Analyst
Jika teman-teman perhatikan dengan seksama, bahwa dengan adanya seorang Business Analyst yang handal maka Project Manager, Software Engineer, dan Programmer akan sangat terbantu sekali, dan bisa lebih fokus kepada peran masing-masing. Alasanya adalah:
- Untuk menentukan prioritas pekerjaan bisa memanfaatkan hasil identifikasi prioritas requirements yang telah dilakukan oleh Business Analyst.
- Untuk menentukan hubungan atau ketergantungan antar proses / modul juga bisa di identifikasi oleh Business Analyst.
- Untuk menentukan suatu komponen atau fitur yang general dan spesifik juga bisa di identifikasi oleh Business Analyst, sehingga mengurangi duplikasi kode.
- Untuk menentukan use case atau penggunaan sistem dari sisi pengguna juga sudah di identifikasi oleh Business Analyst.
Lalu apa hubungannya peran Business Analyst dengan Clean Architecture?
Jika dalam tim kita memiliki Business Analyst yang handal tersebut. Maka sebagai seorang Software Engineer atau Software Architect dapat lebih natural untuk membuat arsitektur. Yang dimaksud dengan lebih natural adalah, sejalan dengan Conway’s Law dan bersinergi dengan istilah-istilah bisnis. Sehingga dekomposisi sistem tidak over engineering. Bahkan istilah bisnis digunakan untuk nama folder, nama namespace, nama class, nama method, nama fungsi dan nama variable. Sehingga ketika harus menelusuri kode, kita bisa melihat keterkaitan diagram proses yang sudah dibuat oleh Business Analyst dengan lebih mudah. Hal tersebut akan mengurangi banyak sekali gesekan / friction. Kalau di dalam konsep DDD (Domain-Driven Design) istilahnya adalah ubiquitous language, keseragaman bahasa atau istilah, yang dibawa sampai ke low-level atau koding.
Disini saya tidak akan membahas teknis dari Clean Architecture, teman-teman bisa membacanya di buku Clean Architecture atau melalui blog Uncle Bob. Saya akan menjelaskan teori yang saya miliki yaitu hubungan peran Business Analyst dan Clean Architecture.
Sebelumnya saya sudah bahas tentang peran Business Analyst dan juga sudah menuliskan alasan-alasanya tentang pentingnya peran Business Analyst. Dari alasan-alasan tersebut saya akan coba hubungkan dengan konsep Clean Architecture.
Use case adalah salah satu inti dari konsep Clean Architecture. Pengembangan perangkat lunak bisa dimulai dari Use case. Dengan berbekal dokumentasi dari Business Analyst, tanpa ragu kita bisa langsung membuat class dengan nama yang tertera pada dokumentasi use case. Misalnya dalam dokumentasi terdapat Use Case diagram sebagai berikut:
[inprogress]
Lalu kita membuat class dengan nama file AddToCart.js yang disimpan didalam folder UseCases.
Satu Use Case = Satu Class
Kemudian di dalam dokumentasi pun sudah tersedia Data Modeling menggunakan ERD:
[inprogress]
Lalu kita membuat class entity dengan nama sesuai dengan nama tabelnya dan attribute di dalam ERD menjadi property pada class.
[inprogress]
Dalam melengkapi fungsionalitas kode disarankan menggunakan Test-Driven Development untuk memastikan bahwa class yang dibuat sesuai dengan requirements, mudah di test, dan tidak over engineering.
Pengelompokan Use case sebetulnya sudah teridentifikasi oleh Business Analyst. … dimana pengelompokan ini biasanya dilakukan oleh Software Architect untuk memastikan Software Architecture align dengan requirements….
To be continue… 🙂
Photo by Mathew Schwartz on Unsplash