🤵 👩🏿‍🤝‍👩🏾 🌑 Teknik penilaian dan prioritas backlog 🍝 🍩 🤦🏼

Nah, bagaimana rencana isolasi Anda? Hal-hal musim dingin dihapus? Sudahkah Anda menonton film-film yang diidamkan? Sudahkah Anda membaca buku-buku berdebu? Dan, seperti biasa, tidak ada waktu untuk utilitas. Ayo, jangan membuat alasan - bagi mereka yang tidak dapat membuat satu jam untuk menonton video dari saluran YouTube kami , kami telah membuat artikel yang dapat dicerna. Memiliki hati nurani, hanya 15 menit, bukan 60 :)

Hari ini kami menyentuh manajemen produk dan menganalisis prioritas backlog. Biaya manajemen produk sedikit lebih tinggi daripada manajemen proyek: ini lebih banyak tentang manajemen produk secara umum dan berkaitan erat dengan pemasaran. Untuk camilan, mari kita lihat teknik penilaian dan penilaian tugas.

Situasi

Ketika ada jaminan, manajer perlu memprioritaskannya. Scrum mengatakan bahwa tugas yang paling penting dari sudut pandang bisnis haruslah yang pertama. Namun ada dua masalah.

Yang pertama adalah momen subyektivisme yang adil: seringkali prioritas ditetapkan sebagai cara pemilik bisnis mengembara. ke kepala. Tetapi kadang-kadang pemilik dapat "berhalusinasi" dengan kuat dan membawa omong kosong, tetapi pastikan bahwa semuanya demikian.

Masalah kedua: terlalu banyak pemangku kepentingan tingkat atas di pihak bisnis pada proyek besar atau di perusahaan besar. Masing-masing dari mereka mungkin memiliki persyaratan yang saling bertentangan. Jika Anda mengumpulkan, misalnya, lima puncak perusahaan besar dan meminta mereka untuk memprioritaskan persyaratan mereka, kemungkinan besar setiap orang akan berpendapat bahwa tugasnya tidak memiliki prioritas, dan mereka harus dilakukan sekarang.

Berita baiknya adalah ada beberapa teknik yang membantu dalam hal ini:

sepakati prioritas - pilih yang lebih penting dan apa yang bisa ditunda;
menetapkan kriteria untuk prioritas backlog (sedikit kurang subyektif daripada halusinasi seseorang - sayangnya, tidak mungkin dilakukan tanpa subjektivitas).

Metode untuk Memprioritaskan Tugas

Seperti apa tampilan backlog?

Backlog adalah sebuah tabel. Dalam satu kolom - daftar sesuatu (beberapa Wishlist), ada kolom dengan taksiran (taksiran) dan ada kolom dengan prioritas. Prioritas adalah beberapa angka, biasanya besar. Besar sehingga ada "lubang" di antara prioritas, di mana Anda dapat menambahkan tugas baru (atau untuk dengan mudah mengubah prioritas).

Menurut klasik, prioritas ditetapkan dalam Nilai Bisnis (nilai bisnis) - apa yang pertama-tama dibutuhkan oleh bisnis, itu akan bekerja pada tahap pertama. Tetapi ada cara lain untuk memprioritaskan yang lebih nyaman - terutama jika Anda memiliki banyak tugas beraneka ragam.

Pemetaan cerita

Misalkan Anda memiliki banyak tugas, mereka kecil dan umumnya tanpa prioritas dan mengikat ke grup mana pun. Apa yang harus dilakukan dengan mereka? Hancurkan mereka di Story Mapping. Cara kerjanya:

Langkah 1. Kami membangun urutan bagaimana pengguna akan menggunakan produk Anda dan langkah apa yang akan mereka ambil. Contoh sederhana:

Langkah 2. Kami menuliskan pada stiker detail apa yang tersedia untuk masing-masing proses ini - semakin rendah stiker untuk setiap tahap hang, semakin rendah prioritasnya.

Hasil: seluruh daftar tugas dibagi menjadi langkah-langkah lintasan pengguna, ditambah setiap fitur memiliki prioritas (semakin rendah fitur tergantung pada sheet, semakin rendah prioritasnya dalam hal seluruh lintasan pengguna).

Di mana dan bagaimana melamar

Katakanlah Anda benar-benar mendapat banyak tugas. Kemudian Anda menuliskan semuanya di stiker dan melakukan Story Mapping. Lebih baik - dalam tim.

Pilihan lain - Anda memiliki brainstorming, Anda datang dengan apa yang akan menjadi produk Anda lebih lanjut dan fitur apa yang harus digunakan. Tim memiliki banyak ide, beberapa jenis pemasaran Wishlist “dituangkan” kepada Anda - Anda perlu memahami cara mengelompokkan semuanya. Story Mapping bekerja sangat baik dalam situasi ini.

Penafian: metode ini berlaku tepat dari sudut pandang manajemen produk, ketika ada banyak tugas, tidak jelas mana dari mereka yang pertama kali dipertimbangkan. Tidak sopan ketika kita hanya memikirkan produk itu sendiri dan fungsionalitas apa yang akan dimasukkan. Kemudian sudah dipotong-potong dari mana Anda dapat membuat sprint, dan mulai bekerja.

Pro Pemetaan Cerita

Metode ini memungkinkan Anda untuk membangun koneksi dalam sistem, yang kemudian lebih mudah untuk membentuk sprint.
Ketika ada banyak pemangku kepentingan dan banyak orang yang memiliki kepentingan dalam proyek, metode ini memungkinkan Anda untuk menyepakati prioritas nyata - mana yang lebih penting dan apa yang kurang.

Nilai & Upaya (atau Lean Prioritization) untuk ide

Metode bagus lain yang memungkinkan Anda membangun prioritas dalam skala adalah Value & Effort (atau Lean Prioritization).

Langkah 1. Pertama, Anda mengambil 2 skala:

— , « » . , — . , , , Value. , , .
,

, (estimate), . Story Point- ( ) -.

Langkah 2. Anda mengevaluasi semua fitur dengan dua parameter ini: berdasarkan signifikansi dan input tenaga kerja. Ada sistem eksternal (seperti Hygger atau Airfocus Priorities & Roadmaps ) yang memungkinkan Anda untuk secara otomatis menyebarkan fitur Anda dalam beberapa cara di papan tersebut. Sumbu dalam hal ini tidak berasal dari nol - mereka beradaptasi dengan statistik yang telah Anda peroleh.

Fitur apa yang harus diambil di tempat pertama? Yang paling signifikan dan paling ringan, yang paling dekat dengan sumbu - keduanya penting di bagian atas dan nilainya memadai:

Jika di tempat pertama kita mengambil murah dan bagus, kemudian - mahal, tapi keren:

Berikut ini adalah yang lainnya. Fitur yang terlalu mahal dan tidak ada artinya, Anda tinggalkan "untuk nanti" atau membuang.

Di mana dan bagaimana menerapkannya.

Dengan pengembangan kustom, hal seperti itu masuk akal untuk dilakukan dengan klien jika:

dia sendiri jadi bingung
itu menghasilkan ide dan persyaratan aneh,
dia memiliki batasan anggaran tertentu, dan dia tidak mengerti cara terbaik untuk mendistribusikannya.

Situasi terakhir sering terjadi. Kami selalu dibatasi oleh anggaran atau sumber daya, dan kami perlu memahami atas dasar apa yang mendistribusikannya. Selain itu, mengelola proyek, kami hanya dapat mengelola perhatian tim
kami dan pelanggan kami - tidak lebih, pada kenyataannya. Metode ini memungkinkan Anda untuk berkonsentrasi pada yang paling penting dan termurah atau pada yang mahal, tetapi sangat penting, dan membantu untuk memilih apa yang tepat untuk bertaruh saat ini.

Teknik ini tidak membuat Anda membabi buta percaya pada algoritma dan mengambil tepat tugas yang direkomendasikan olehnya, tetapi berkat itu Anda setidaknya akan memiliki petunjuk di mana arah untuk bergerak. Jika Anda menambahkan tugas baru ke sistem, itu dapat dibangun kembali. Setelah semua, itu terjadi bahwa Anda sangat tidak yakin dengan perkiraan Anda, dan seiring waktu, analis memperbaikinya, atau Anda sendiri memperbaiki estimasi kompleksitas programmer - dalam hal ini, sistem juga dapat dibangun kembali dalam dinamika. Karena ini, Anda akan memiliki gambaran dunia yang lebih memadai.

MoSCoW

Cara lain untuk mengelompokkan fitur ke dalam beberapa grup adalah metode MoSCoW. Di dalamnya ada parameter yang sangat sederhana:

M - Harus Memiliki : fungsionalitas yang tidak dapat Anda lakukan sama sekali. Tanpa itu, Anda tidak akan bisa merilis, produk Anda tidak akan berfungsi dan tidak akan dibutuhkan sama sekali.

S - Should Have : fungsi yang seharusnya ada dalam proyek, tetapi hal-hal lain dianggap sama, Anda dapat melakukannya tanpa itu.

C - Could Have : fungsionalitas yang diinginkan untuk rilis.

W - Would Have : fungsi paling tidak praktis - bisa dikatakan, "segalanya".

, . Must Have , , , . Should Have — , , . Could Have — . , Must Have MVP.

Sering terjadi bahwa prioritas diturunkan dari atas, dari bisnis, dan mereka terkonsentrasi pada beberapa "Daftar Keinginan" dari Seharusnya, Bisa Memiliki, Akan Memiliki, mencetak pada hal-hal kunci (Harus Memiliki). Biasanya kita mengamati ini, misalnya, dalam pengembangan desain toko online atau desain beberapa jenis proyek, di mana kurs ditempatkan terakhir tetapi tidak sedikit pada sistem pembayaran pengiriman atau sesuatu yang benar-benar menghasilkan manfaat bagi bisnis. Mengapa? Karena bekerja dengan Must Have itu menyakitkan dan menakutkan: Anda perlu berpikir tentang bagaimana uang itu akan diuangkan, dan tidak ada yang suka melakukannya, walaupun ini salah.

Kano

Cara lain untuk mengategorikan fitur yang berasal dari pemasaran. Intinya sederhana: ada dua sumbu: "kepuasan pengguna" dan "fungsionalitas", dan ada pembagian fungsional ke dalam kelompok. Untuk setiap kelompok fitur, Anda perlu memahami bagaimana kepuasan pengguna berubah dari penambahan fungsi ini.

Grup pertama adalah fungsionalitas yang diperlukan: Must Must have from MoSCoW yang sama. Jika fitur ini - sudah bagus. Tidak ada pertanyaan tentang kepuasan: tidak ada yang membutuhkan produk tanpa mereka. Selain itu, seiring berjalannya waktu, fungsi yang menjadi sorotan proyek pada awalnya menjadi semakin wajib. Contoh: untuk perangkat lunak server, kanban-board dulunya semacam, tapi sekarang masthead yang sama.

Kelompok lain adalah fungsi satu dimensi. Ini berarti bahwa ada korelasi langsung antara kepuasan pengguna dan ketersediaan fungsi ini. Segera setelah suatu fungsi muncul, kepuasan tumbuh secara linear. Jika Anda kembali ke contoh membuat mobil, itu bisa jadi pengontrol iklim di sana.

Kelompok ketiga adalah fitur yang menarik. Ini adalah apa yang tidak diharapkan oleh pengguna, tetapi ketika dia melihat setidaknya beberapa implementasi dari ini pada produk anda, dia menjadi gila dan berkata “oh, keren!”. Mereka yang terbang dengan aeroflot mungkin melihat bagaimana anak-anak diberikan "suap" untuk secara emosional melekatkan mereka pada merek.

Hadiah untuk anak-anak di atas Aeroflot adalah sumbernya.

Begitu fungsi tersebut muncul bahkan dalam penerapan yang biasa-biasa saja, kepuasan tumbuh. Dan semakin curam implementasinya, semakin tinggi jadwal kepuasan.

Grup lain adalah fungsi yang tidak penting. Anda dapat melakukannya, Anda tidak dapat melakukannya - semua orang akan acuh tak acuh.

Grup terakhir adalah fitur yang tidak diinginkan. Ketika mereka pergi - semuanya baik-baik saja, segera setelah mereka muncul - semuanya menjadi buruk. Antifichi seperti itu :)

Metode ini agak diragukan, karena tidak jelas bagaimana prioritas dipilih untuk fitur. Secara teori, Anda perlu mewawancarai pengguna: karena menurut mereka, fitur ini baik atau tidak, dan kemudian mengelompokkan berdasarkan pendapat pengguna. Pada saat yang sama, para pengguna itu sendiri juga harus dibagi ke dalam kelompok-kelompok sasaran dan memperhatikan bagaimana setiap fungsi termasuk dalam kelompok sasaran mana.

Orang-orang selama pemungutan suara sering berbicara omong kosong dan hanya berbohong. Mereka mungkin mengatakan bahwa ini adalah fitur yang sangat penting, tetapi pada kenyataannya mereka tidak akan pernah membayar uang untuk itu. Selain itu, jika Anda mewawancarai pengguna, umpan balik produk bisa sangat beracun.

Contoh

Anda berencana membuat rilis berikutnya dan sedang mewawancarai sekelompok orang. Beberapa dari mereka mungkin berkata: "Tapi Anda melakukan fungsi berbayar di sana, karena itu produknya menjadi lebih buruk, fii!" Hanya karena itu untuk uang, fungsi ini tampaknya tidak perlu bagi seseorang. Meskipun untuk bisnis, ini mungkin hal utama yang menghasilkan keuntungan.

Oleh karena itu, metode Kano mutlak dari pemasaran, tetapi sebagai strategi jangka panjang ada tempat untuk menjadi.

Metode klasik memprioritaskan daftar bug

Pada intinya adalah daftar prioritas dari 0 hingga 8:

0 - Bug kritis
Ketika tester muncul dan tidak dapat lagi memeriksa ketika sistem crash atau sesuatu rusak - secara umum, ketika tidak mungkin lebih jauh.

1 - Kegunaan kritis dan fitur yang terlupakan
Di sini kami menerapkan, termasuk metode pengecatan simpanan, spesifikasi teknis, atau prototipe (tergantung pada apa yang kami miliki) untuk menentukan apakah kami telah melewatkan sesuatu.

2 - Bug tidak kritis
Ada bug , tetapi mereka tidak mengganggu pengujian produk lebih lanjut, atau mereka memungkinkan Anda untuk sepenuhnya mengikuti rantai pesanan, atau sesuatu yang lain - yaitu, mereka memungkinkan kami untuk sepenuhnya memeriksa produk kami.

3 - Kegunaan tidak kritis

4 - Teks

8 -Wishlist / kami tidak akan melakukan / atas kebijakan manajer

Ya, interval antara 4 dan 8 dibuat dengan sengaja - manajer, jika perlu, dapat membuktikan tugas lain di sana.

Untuk daftar bug, metode ini bagus, tetapi memiliki masalah. Secara umum, kami mengoptimalkan metrik "siap - tidak siap" dalam daftar bug. Lingkup pekerjaannya jelas. Tetapi sering ditemukan bahwa dalam kegunaan non-kritis mereka mencoba untuk mendorong sesuatu yang ada di ambang - tampaknya seperti kegunaan dan tampaknya bagus untuk melakukannya, tetapi pada kenyataannya itu menarik beberapa fitur yang sangat serius.

Masalah lain adalah subjektivitas penguji, yang sering harus diperiksa ulang. Kadang-kadang ini adalah kisah yang agak memakan waktu ketika Anda secara pribadi memeriksa semua daftar bug: melihat apa yang dia tulis di sana, dan memutuskan apa yang harus dibuang dan apa yang harus pergi.

Metode ini tidak cocok untuk memprioritaskan jaminan simpanan - mereka membutuhkan kriteria yang sangat berbeda.

Penilaian tugas

Prioritas apa pun harus didasarkan pada penilaian yang diberikan kepada kami. Lagi pula, kompleksitas benar-benar memengaruhi prioritas fungsi. Tetapi bagaimana menentukan kerumitan dan pada titik apa layak membahas biaya tenaga kerja dengan seorang programmer? Lagi pula, sebelum ini, manajer masih perlu menetapkan setidaknya perkiraan perkiraan.

Tapi serius, biasanya ada tiga opsi.

- « » , , . , , - -, - -. :)

( ). - , - . , . , , ( - ).
: , , , .

: ( + ( * 3) + ) / 6.

, .

, , . , , , : , — . . — .

, , , . - , , , «» — . — 1 , , .

, « », . , .
Planning Poker

«» , - , , . .

Planning Poker — , . Story Mapping, ( , — ).

Planning Poker
1. , ;
2. , — ( , «»).

Mereka membantu memprioritaskan tugas dalam tumpukan dalam kondisi ketidakpastian - ketika Anda hanya merencanakan dan mengevaluasi efek dari memperkenalkan fungsi tertentu.

Penilaian ICE

Singkatan terdiri dari tiga parameter:

Dampak - dampak pada produk, baik dari sudut pandang bisnis, atau berapa banyak uang yang akan dihasilkan, atau apa yang akan diberikan fitur ini, betapa kerennya itu. Parameter diatur dalam kisaran dari 1 hingga 10.
Keyakinan - keyakinan dalam menilai kompleksitas atau dalam menilai dampak fitur. Misalnya, Anda membuat semacam fungsi dan berpikir bahwa itu akan memiliki efek yang baik pada proyek. Tidak ada analitik, datanya tidak akurat dan sejauh ini prioritasnya hanya didasarkan pada pendapat pribadi Anda. Semakin rendah kepercayaan pada pendapat pribadi Anda, semakin rendah nilainya. Ini juga diatur dalam kisaran 1 hingga 10.
Kemudahan - biaya tenaga kerja atau kemudahan implementasi. Ini juga dapat diatur dari 1 hingga 10. Semakin sederhana fungsinya, semakin tinggi skornya.

Dampak

Untuk mengevaluasi efek fitur tertentu, ada baiknya mempertimbangkan beberapa kriteria:

itu meningkatkan konversi,
dia menarik pengguna baru
itu membuat pengguna yang ada
dia menambah nilai pada produk.

Jika fungsi menjawabnya, maka itu berdampak tinggi pada produk. Untuk penilaian, Anda dapat mengambil skala dari 1 hingga 10, Anda dapat mengambil dari 1 hingga 100. Yang terakhir lebih nyaman, karena ada akselerasi.

Keyakinan

Mungkin didasarkan pada:

pendapat pribadi, pendapat tim, pendapat ahli eksternal;
Penelitian UX;
jajak pendapat
wawancara;
pengamatan, termasuk pesaing;
MVP
Tes A / B;
penelitian pihak ketiga;
analitik;
panggilan atas untuk dukungan teknis;
permintaan teratas dari manajer penjualan;
permintaan pelanggan teratas.

Lebih baik menggunakan yang ada metrik dan angka tertentu, meninggalkan pendapat orang untuk "nanti".

Bagaimana mengukur tingkat kepercayaan - sumber

Untuk mendapatkan ICE, Anda perlu melipatgandakan tiga parameter ini - ini akan menjadi prioritas untuk implementasi.

Pro : cepat dan mudah.

Cons : metode ini memiliki skala yang agak terbatas - Anda bisa mendapatkan banyak tugas dengan prioritas tinggi, karena pernyataannya akan jelas pada mereka, tugas itu sendiri akan sederhana dan akan tampak penting.

Penilaian PADI

4 parameter digunakan di sini:

Jangkauan jangkauan: berapa banyak pengguna dari fitur ini yang akan mendapatkan setidaknya beberapa kepuasan, baik memperhatikan fitur ini atau menggunakannya. Dapat diukur secara kuantitatif: misalnya, 500 juta pengguna akan mengalami fitur ini. Ini dapat diukur sebagai persentase - misalnya, 30% pengguna akan menggunakan fitur ini.
Dampak - pengaruh: seberapa besar kita benar-benar membutuhkan fungsi ini, seberapa besar itu akan membantu kita, betapa kerennya fungsi ini.
Keyakinan - keyakinan: mirip dengan ICE Scoring, keyakinan pada perkiraan kami dan perkiraan pengaruh.
Usaha - kesusahan.

Fungsi-fungsi yang memberikan cakupan luas, yang kami yakini dan yang memiliki efek baik pada produk dan pada saat yang sama murah dalam hal biaya tenaga kerja, berada di urutan teratas berdasarkan prioritas dalam jaminan.

Perangkat lunak untuk penentuan prioritas

Ada beberapa program untuk penentuan prioritas otomatis - misalnya, Hygger . Ini adalah sistem untuk Pemilik Produk, di mana ada banyak model berbeda yang memungkinkan Anda untuk "bermain-main" dengan tugas.

Seperti apa Hygger dari dalam - sumber

Hal yang sama untuk dilakukan di Google Dock mana pun: cukup tambahkan tiga parameter, kumpulkan data - itu akan dihitung. Ini akan menjadi prioritas Anda. Dan kemudian Anda sendiri memilih apa yang harus diambil dalam sprint.

Terkadang manajer menggunakan Jira untuk menyimpan semua tiket dan tugas. Sayangnya, tidak terlalu mudah untuk memprioritaskan - itu disesuaikan dengan kenyataan bahwa seseorang memprioritaskan secara manual dengan hanya menyeret tiket naik dan turun backlog. Keren jika backlog tidak panjang 1000 baris, tetapi pada titik tertentu akan membosankan bagi Anda untuk melakukan ini dengan tangan Anda.

Jira memiliki cara tertentu untuk mengklasifikasikan tugas ke dalam epos, komponen, rilis, dan Anda dapat menandai tugas dengan beberapa tag. Ada beberapa plugin untuk penilaian ( Issue Score untuk Jira ,Kalkulator Skor Prioritas ), tetapi mereka tidak terlalu fungsional.

Kurang lebih memadai - sistem eksternal Hygger dan Airfocus . Mereka berintegrasi dengan Jira, tetapi harganya hampir sama dengan dirinya. Oleh karena itu, cara termudah adalah dengan mengintegrasikan Google Dock dan Jira: unggah backlog di sana secara sinkron dan terapkan rumus Anda di sana sesuai kebutuhan.

Cara berteman Jira dan Google Documents untuk diprioritaskan

Selain prioritas, selalu ada masalah bagaimana mendistribusikan implementasi tugas tertentu dalam waktu. Ketika hanya ada prioritas, tidak ada jaminan bahwa kami akan mendapatkan sistem yang terhubung (misalnya, Anda berencana membuat keranjang, tetapi ternyata belum ada katalog). Karena itu, selain prioritas, ada baiknya menggunakan diagram Gantt untuk melihat koneksi dalam sistem, seberapa benar kerjanya oleh komponen dan seberapa optimal Anda mendistribusikan sumber daya tim dari waktu ke waktu.

Di Jira, sayangnya, dari "kotak" opsi ini tidak diimplementasikan dengan sangat baik, sehingga beberapa plugin juga berguna:

Portofolio (juga mahal);
Gambar Besar (berat);
Proyek MS ;
Proyek Merlin untuk MacOS.

Hasil dari

Kami tidak menghilangkan subjektivitas - itu tetap di semua tingkatan. Pada saat kita mengatakan "ini adalah fungsi yang penting" atau "ini adalah fungsi yang tidak penting" dan ketika kita memberikan beberapa penilaian, subjektivitas dipertahankan. Namun berkat metode di atas, kita dapat memecah subjektivitas ini menjadi komponen: setidaknya gambar akan lebih jelas.

Jika Anda menggunakan parameter seperti "kepercayaan pada penilaian", Anda dapat "memelintir" kepercayaan ini dari waktu ke waktu. Misalnya, Anda memiliki fungsi yang baik yang mempengaruhi produk secara positif dan murah, dan cakupan memberi banyak, tetapi kepercayaan di dalamnya rendah. Periksa melalui metrik, analitik, permintaan dari pakar, pertanyaan untuk programmer - dan tentukan.

Bagus untuk peringkat Perencanaan Poker, ditambah kami melihat beberapa metode untuk mengkategorikan tugas. Jika Anda memiliki sesi strategis dengan klien, coba Pemetaan Cerita dengan stiker dan bagikan sesuai dengan langkah-langkah pengguna. Pada produk internal, metode yang sama akan membantu Anda memilih fitur yang layak diambil dalam rilis mendatang. Untuk jaminan simpanan, RICE Scoring lebih baik daripada yang lain untuk mengevaluasi tugas mana yang akan dituju.

Tapi ingat bahwa keputusan akhir selalu terserah manajer, dan angka yang diperoleh dengan menggunakan metode hanya mengatur arah.

Sampai jumpa di video baru di saluran YouTube kami !

Teknik penilaian dan prioritas backlog