Rapat perencanaan berjalan dua jam, daftar permintaan bertambah, tetapi keputusan tentang fitur mana yang dikerjakan lebih dulu tetap menggantung. Semua pemangku kepentingan merasa kebutuhannya paling mendesak. Di titik ini, peran product owner dalam memprioritaskan backlog bukan soal memilih siapa yang paling vokal, melainkan menyediakan cara menilai yang bisa dipertanggungjawabkan kepada semua pihak.
Masalahnya jarang berupa kurangnya daftar. Kebanyakan tim sudah punya puluhan item di backlog. Yang tidak ada adalah alasan tertulis mengapa satu item berada di atas item lain, dan apa yang harus dikorbankan ketika waktu tim terbatas.
Dua model yang paling sering dipakai untuk mengisi kekosongan itu adalah Model Kano dan WSJF (Weighted Shortest Job First). Keduanya menjawab pertanyaan berbeda, sehingga pemakaiannya pun sebaiknya tidak dipertukarkan. Uraian berikut membedah keduanya secara praktis, termasuk kapan masing-masing justru menyesatkan.
Peran Product Owner dalam Memprioritaskan Backlog: Inti Tugasnya
Peran product owner dalam memprioritaskan backlog adalah memutuskan urutan pengerjaan berdasarkan nilai bagi pengguna dan biaya penundaan, lalu menjelaskan alasan keputusan itu secara terbuka. Ia bukan penerjemah permintaan, melainkan penjaga agar tim mengerjakan hal yang paling berdampak lebih dulu.
Ada tiga keluaran yang membuat peran ini terlihat nyata. Pertama, urutan item yang disepakati untuk satu periode kerja. Kedua, alasan singkat mengapa item tertentu turun peringkat. Ketiga, batas yang jelas tentang apa yang tidak dikerjakan pada periode tersebut.
Tanpa ketiganya, prioritas berubah setiap kali ada keluhan terbaru. Tim pengembang kehilangan ritme, dan pemangku kepentingan belajar bahwa menyuarakan permintaan paling keras lebih efektif daripada menyusun argumen. Pola ini mahal karena pekerjaan yang sudah dimulai sering ditinggalkan di tengah jalan.
Dalam praktiknya, product owner perlu membedakan dua jenis keputusan. Keputusan tentang nilai menyangkut apa yang penting bagi pengguna. Keputusan tentang biaya menyangkut seberapa mahal menunda pekerjaan itu. Model Kano membantu pada keputusan pertama, sedangkan WSJF membantu pada keputusan kedua.
Cara kerja tim dalam menyusun dan meninjau backlog biasanya dijelaskan lebih rinci pada halaman cara kerja kami, termasuk titik-titik ketika keputusan prioritas dievaluasi ulang bersama pemangku kepentingan.
Model Kano untuk Menilai Jenis Nilai Sebuah Fitur
Model Kano mengelompokkan fitur berdasarkan cara kehadirannya memengaruhi kepuasan pengguna, bukan berdasarkan besar kecilnya manfaat. Kategori ini membantu product owner menghindari jebakan menganggap semua fitur menambah kepuasan dengan cara yang sama.
Kategori pertama adalah must-be, yaitu fitur yang kehadirannya dianggap biasa tetapi ketiadaannya menimbulkan keluhan. Kategori kedua adalah performance, di mana semakin baik kualitasnya, semakin tinggi kepuasan. Kategori ketiga adalah attractive, fitur yang tidak diharapkan tetapi menyenangkan ketika ada.
Dua kategori sisanya sering luput: indifferent, yang kehadirannya tidak menambah maupun mengurangi kepuasan, dan reverse, yang justru mengganggu sebagian pengguna. Fitur reverse kerap muncul ketika tim menambah langkah konfirmasi berlapis demi "keamanan" tanpa mengukur dampaknya ke pengalaman pemakaian.
| Kategori Kano | Perilaku pengguna | Implikasi prioritas |
|---|---|---|
| Must-be | Diam jika ada, mengeluh jika tidak ada | Wajib ada sebelum fitur baru ditambahkan |
| Performance | Kepuasan naik seiring kualitas | Ditingkatkan bertahap sesuai target terukur |
| Attractive | Senang saat muncul, tidak menuntut saat tidak ada | Dipakai untuk pembeda, setelah must-be aman |
| Indifferent | Tidak terpengaruh | Ditunda atau dibuang dari backlog |
| Reverse | Merasa terganggu | Ditinjau ulang atau dihapus |
Wawasan yang jarang disampaikan: kategori Kano bisa berubah seiring waktu. Fitur yang dulu attractive menjadi performance, lalu berakhir sebagai must-be ketika pesaing menyediakannya. Karena itu, hasil survei Kano sebaiknya ditinjau ulang setiap beberapa kuartal, bukan disimpan sebagai keputusan permanen.
WSJF untuk Menimbang Biaya Penundaan
WSJF menilai prioritas dengan membandingkan biaya penundaan terhadap ukuran pekerjaan. Nilainya diperoleh dari biaya penundaan dibagi ukuran pekerjaan, sehingga item yang mahal jika ditunda dan relatif cepat dikerjakan akan naik peringkat.
Biaya penundaan biasanya dipecah menjadi tiga komponen: nilai bagi pengguna atau bisnis, nilai yang bergantung pada waktu, dan pengurangan risiko. Ketiganya dinilai relatif antar item, memakai deret angka sederhana, bukan perhitungan rumit.
Kekuatan WSJF terletak pada kesederhanaannya. Tim bisa membandingkan dua item dalam hitungan menit dan mencatat asumsinya. Kelemahannya, hasilnya sangat bergantung pada ketepatan perkiraan ukuran pekerjaan. Jika estimasi ukuran terlalu optimistis, item berukuran besar bisa naik peringkat tanpa alasan yang kuat.
Pada pekerjaan yang menyentuh data pelanggan, komponen pengurangan risiko sering menjadi penentu. Fitur yang memperbaiki celah akses bisa memiliki biaya penundaan tinggi meski nilainya bagi pengguna tidak langsung terlihat. Di sisi lain, sebelum item semacam ini naik prioritas, kriteria penerimaan dan skenario pengujiannya perlu disiapkan, sejalan dengan disiplin quality assurance (QA) & software testing.
Peran Product Owner dalam Memprioritaskan Backlog dengan Dua Model
Peran product owner dalam memprioritaskan backlog menjadi lebih kuat ketika dua model dipakai berurutan, bukan bersaing. Kano dipakai lebih dulu untuk memastikan tim tidak membangun fitur yang salah kategori, lalu WSJF dipakai untuk mengurutkan item yang sudah lolos saringan itu.
| Dimensi | Model Kano | WSJF |
|---|---|---|
| Pertanyaan yang dijawab | Jenis nilai apa yang dibawa fitur ini? | Item mana yang paling mahal jika ditunda? |
| Masukan utama | Persepsi pengguna atas kehadiran fitur | Perkiraan biaya penundaan dan ukuran pekerjaan |
| Keluaran | Kategori fitur | Angka urutan prioritas relatif |
| Waktu penggunaan | Berkala, saat meninjau peta produk | Rutin, setiap perencanaan periode kerja |
| Risiko penyalahgunaan | Dianggap hasil permanen | Ukuran pekerjaan ditebak terlalu optimistis |
Urutan pemakaian ini penting karena Kano tidak menghasilkan peringkat, sedangkan WSJF tidak memeriksa apakah sebuah fitur memang layak ada. Memaksakan WSJF pada daftar yang masih bercampur fitur indifferent hanya menghasilkan urutan rapi untuk pekerjaan yang tidak dibutuhkan.
Sebaliknya, berhenti pada Kano membuat tim tahu kategori fitur tanpa tahu mana yang dikerjakan lebih dulu ketika sumber daya terbatas. Kombinasi keduanya menutup dua celah tersebut secara bersamaan.
Kesalahan yang Sering Terjadi Saat Menyusun Prioritas
Kesalahan paling sering bukan pada model yang dipilih, melainkan pada cara model itu dipakai. Berikut pola yang berulang muncul di banyak tim produk.
- Menilai tanpa data pengguna. Kategori Kano ditetapkan berdasarkan dugaan tim internal, bukan tanggapan pengguna, sehingga fitur attractive dan indifferent tertukar.
- Mengabaikan ukuran pekerjaan. WSJF dihitung hanya dari biaya penundaan, sehingga item raksasa selalu menang meski butuh berbulan-bulan.
- Meninjau prioritas terlalu sering. Urutan diubah setiap minggu, membuat pekerjaan yang sedang berjalan tidak pernah selesai.
- Tidak mencatat asumsi. Angka biaya penundaan tidak disertai alasan, sehingga perdebatan berikutnya mengulang dari nol.
- Menyerahkan sepenuhnya ke satu orang. Product owner memutuskan sendiri tanpa masukan tim teknis soal ukuran pekerjaan dan risiko.
Kesalahan kelima paling mahal dalam jangka panjang. Tim teknis memegang informasi tentang kerumitan dan ketergantungan antarsistem, sementara product owner memegang informasi tentang nilai bisnis. Prioritas yang baik lahir dari pertemuan keduanya, bukan dari salah satu pihak saja.
Langkah Praktis Menyusun Prioritas yang Bisa Dipertanggungjawabkan
Mulailah dari daftar yang lebih pendek daripada yang biasa dibawa ke rapat. Terlalu banyak item membuat penilaian kehilangan fokus dan memaksa peserta menebak.
- Kelompokkan item berdasarkan kategori Kano memakai tanggapan pengguna yang sudah ada.
- Buang atau tunda item berkategori indifferent dan tinjau ulang yang reverse.
- Perkirakan ukuran pekerjaan bersama tim teknis, bukan sendiri.
- Hitung biaya penundaan relatif untuk item yang tersisa, lalu bandingkan dengan ukurannya.
- Catat alasan setiap keputusan agar bisa ditinjau pada periode berikutnya.
Jika tim Anda memerlukan kerangka penilaian yang lebih menyeluruh, pembahasan pada layanan solusi IT dan software bisnis memuat cara menyelaraskan prioritas produk dengan kesiapan teknis dan tata kelola. Untuk tim yang baru membentuk fungsi produk, pendampingan keunggulan Kruge Digital dapat dipakai sebagai rujukan praktik kerja yang sudah berjalan.
Perlu dicatat, item backlog yang menyentuh data pelanggan perlu ditinjau terhadap kewajiban pelindungan data pribadi. UU No. 27 Tahun 2022 mengatur pemrosesan yang terbatas dan aman, sehingga fitur yang memperluas akses data sebaiknya tidak hanya dinilai dari nilai bisnis, tetapi juga dari risikonya.
Apakah Model Kano dan WSJF harus dipakai bersamaan?
Tidak wajib, tetapi keduanya saling melengkapi. Kano menyaring jenis nilai, sedangkan WSJF mengurutkan berdasarkan biaya penundaan dan ukuran pekerjaan. Memakai salah satu saja meninggalkan celah yang biasanya baru terasa saat sumber daya menipis.
Berapa lama sekali prioritas backlog sebaiknya ditinjau?
Umumnya mengikuti siklus kerja tim, misalnya setiap dua sampai empat minggu. Peninjauan lebih sering membuat pekerjaan tidak pernah selesai, sedangkan peninjauan terlalu jarang membuat tim mengerjakan hal yang sudah tidak relevan.
Siapa yang sebaiknya terlibat dalam penilaian ukuran pekerjaan?
Tim teknis yang akan mengerjakannya, karena merekalah yang memahami kerumitan dan ketergantungan antarsistem. Product owner menetapkan nilai, tim teknis memberi perkiraan ukuran, lalu keduanya menyepakati urutan.
Kesimpulan
Peran product owner dalam memprioritaskan backlog bertumpu pada dua hal yang sering dianggap remeh: kejelasan jenis nilai dan kejelasan biaya penundaan. Model Kano membantu memilah fitur yang layak ada, sedangkan WSJF membantu mengurutkannya ketika waktu dan tenaga terbatas.
Mulailah dari daftar yang lebih pendek, libatkan tim teknis dalam memperkirakan ukuran, dan catat alasan setiap keputusan. Jika Anda ingin mendiskusikan cara menerapkan kedua model ini pada produk yang sedang dibangun, tim kruge.co.id dapat membantu memetakan kebutuhan dan prioritasnya.
Sumber & referensi
- Undang-Undang Republik Indonesia Nomor 27 Tahun 2022 tentang Pelindungan Data Pribadi - https://peraturan.bpk.go.id/Details/229798/uu-no-27-tahun-2022