Artikel ini menjelaskan kriteria dan metode yang digunakan oleh tim produk Zimbra untuk membentuk peta jalan Zimbra dan Bagaimana Anda memutuskan fitur dan perbaikan bug mana yang akan diprioritaskan.
Tahapan dalam Roadmap Zimbra
Sebelum kita mendalami proses pembuatan prioritas, mari kita rekap sekilas berbagai tahapan dalam peta jalan Zimbra
Dalam tinjauan: Evaluasi awal atas permintaan fitur atau bug untuk memastikan keselarasan dengan visi dan sasaran produk.
Diterima: Permintaan fitur atau bug yang memenuhi kriteria kami ditambahkan ke backlog untuk pertimbangan di masa mendatang. Bug dan fitur diprioritaskan menggunakan kerangka standar industri. Mereka kemudian ditempatkan ke dalam simpanan yang diprioritaskan.
Sedang berlangsung: Tim pengembangan mengambil bug dan fitur dari backlog sesuai prioritas. Tahap ini merupakan tahap pengembangan aktif dari proses.
Dirilis: Fitur atau perbaikan bug tersedia dalam versi produksi.
Kerangka RICE dan Prioritas Bug
Aspek penting dalam memindahkan bug atau fitur dari “Dalam Peninjauan” ke “Diterima” ke “Dalam Proses” adalah penentuan prioritas.
Di Zimbra, kami menggunakan kerangka prioritas RICE. RICE adalah singkatan dari Jangkauan, Dampak, Keyakinan, dan Upaya.
Berikut cara kami menerapkan kerangka RICE untuk mengevaluasi dan memprioritaskan permintaan fitur dan perbaikan bug:
Reach
Kami mengevaluasi berapa banyak pelanggan yang akan mendapatkan manfaat dari perbaikan bug atau fitur selama periode tertentu. Jika bug memengaruhi sebagian besar basis pengguna kami, bug tersebut mungkin mendapat prioritas lebih tinggi. Misalnya, bug yang melaporkan masalah pencarian email akan mendapat prioritas lebih tinggi daripada masalah terkait pencarian Tasks.
Impact
Kami menilai potensi dampak perbaikan bug atau fitur pada pengguna. Dampak mengukur perkiraan dampak pada pengguna individu yang terkait dengan suatu tujuan. Pada dasarnya, generalisasi tentang seberapa besar pengaruh fitur/fungsi terhadap pengguna. Misalnya, peningkatan yang menambahkan kriteria filter baru akan sangat berdampak pada produktivitas pengguna dengan memfilter email yang tidak perlu, dibandingkan dengan memberikan pesan yang lebih ramah pengguna untuk kesalahan yang jarang terjadi.
Confidence
Kami menentukan tingkat kepastian mengenai jangkauan, upaya, dan perkiraan dampak. Jika kami memiliki keyakinan tinggi bahwa perbaikan bug akan memberikan dampak positif bagi banyak pengguna, kemungkinan besar bug tersebut akan diprioritaskan.
Effort
Kami memperkirakan jumlah pekerjaan yang diperlukan untuk mengimplementasikan perbaikan bug atau fitur. Bug yang memiliki jangkauan tinggi dan dapat diselesaikan dengan cepat mungkin dapat diatasi lebih cepat.
Setelah kami menilai bug atau permintaan fitur menggunakan kriteria di atas, kami menetapkan skor RICE. Skor ini membantu dalam membandingkan dan memberi peringkat item di backlog kami. Item dengan skor tinggi kemungkinan besar akan berpindah dari tahap “Diterima” ke tahap “Dalam Proses”.
Menyeimbangkan Tujuan Bisnis dan Kebutuhan Pelanggan
Meskipun kerangka RICE memainkan peran penting dalam memprioritaskan bug dan fitur, pendekatan holistik memerlukan pertimbangan faktor tambahan yang menyeimbangkan tujuan bisnis dan kebutuhan pelanggan. Berikut ini penjelasan lebih dalam tentang sembilan faktor tersebut. Harap dicatat bahwa faktor-faktor ini tidak berada dalam urutan tertentu.
1. Penyelarasan dengan Strategi Produk Zimbra
Kami mengevaluasi seberapa selaras perbaikan bug atau fitur dengan tujuan dan visi jangka panjang Zimbra. Penyelarasan strategis memastikan bahwa upaya kami berkontribusi pada tujuan produk secara menyeluruh.
2. Umpan Balik Pelanggan
Kami sangat memperhatikan masukan dari pelanggan kami. Masalah yang sering diangkat oleh komunitas Zimbra, masalah yang memiliki beberapa kasus tenaga penjualan, atau masalah yang memiliki dampak negatif signifikan terhadap kepuasan pelanggan mungkin mendapat prioritas lebih tinggi.
3. Keamanan
Memastikan bahwa Zimbra mempertahankan tingkat keamanan tertinggi adalah hal yang terpenting. Bug yang menimbulkan risiko keamanan sering kali segera diatasi.
4. Hutang Teknis dan Pemeliharaan
Terkadang, memprioritaskan pekerjaan yang mengurangi utang teknis, mengurangi ketergantungan teknis, atau meningkatkan pemeliharaan basis kode kami diperlukan, meskipun hal tersebut tidak memberikan manfaat langsung yang terlihat bagi pelanggan. Hal ini menjamin keberlangsungan produk dalam jangka panjang.
5. Ketersediaan Sumber Daya
Ketersediaan sumber daya, termasuk bandwidth dan anggaran tim pengembangan, memengaruhi waktu perbaikan bug dan pengembangan fitur.
6. Kepatuhan terhadap Peraturan
Memastikan bahwa Zimbra tetap mematuhi berbagai standar peraturan sangatlah penting. Jika bug atau fitur melibatkan masalah kepatuhan, bug atau fitur tersebut mungkin akan segera mendapat perhatian.
7. Skalabilitas dan Kinerja
Zimbra dikenal dengan penerapan berskala sangat besar. Kami mempertimbangkan skalabilitas dan implikasi kinerja dari bug dan fitur untuk memastikan bahwa Zimbra tetap cepat dan dapat diandalkan untuk semua pelanggan.
8. Pengalaman Pengguna dan Kegunaan
Kami mungkin memprioritaskan bug atau fitur yang secara signifikan meningkatkan kegunaan dan pengalaman pengguna akhir UI Modern atau UI Klasik.
9. Penggunaan Layanan Pihak Ketiga
Kemampuan Zimbra untuk bekerja dengan dan menggunakan perpustakaan lain merupakan persyaratan fitur utama agar perangkat lunak Zimbra berfungsi dengan baik. Bug yang memengaruhi integrasi ini atau fitur yang menyempurnakannya mungkin akan diprioritaskan.
Kesimpulan
Memprioritaskan bug/fitur adalah proses kompleks yang menyeimbangkan kebutuhan pelanggan Zimbra, tujuan produk, dan sumber daya yang tersedia. Dengan menggunakan kerangka kerja ini, kami bertujuan untuk membuat peta jalan produk yang memberikan nilai terbaik bagi komunitas Zimbra kami.
Sumber: Zimbra
