Kaedah MoSCoW: Susun Atur Keperluan dengan Cara yang Betul

Kaedah MoSCoW adalah salah satu rangka kerja penetapan keutamaan yang paling praktikal yang tersedia untuk pasukan projek, dan ia mengambil masa kira-kira tiga puluh minit untuk dipelajari dan seumur hidup disiplin untuk digunakan dengan baik. Kebanyakan pasukan tidak gagal kerana memilih alat yang salah. Mereka gagal kerana berkata ya kepada segalanya dan akhirnya tidak menghantar apa-apa yang berguna tepat pada masa.

Apakah kaedah MoSCoW?

Kaedah MoSCoW ialah teknik penetapan keutamaan berstruktur yang digunakan dalam pengurusan projek, pembangunan produk, dan analisis perniagaan untuk mengisih keperluan, ciri, atau tugas kepada empat kategori berdasarkan kepentingan dan kemendesakan mereka. Setiap huruf dalam akronim itu memetakan kepada satu kategori:

• Mesti ada (Must have): Keperluan yang tidak boleh dirundingkan. Projek gagal tanpa ini.
• Sepatutnya ada (Should have): Penting tetapi tidak kritikal. Ini menambah nilai yang ketara dan harus dimasukkan jika mungkin.
• Boleh ada (Could have): Ciri-ciri yang baik untuk ada. Masukkan sahaja jika masa dan bajet membenarkan tanpa berisiko terhadap Mesti ada.
• Tidak akan ada kali ini (Won't have this time): Secara eksplisit di luar skop untuk penghantaran ini. Frasa "kali ini" penting, kerana item-item ini mungkin muncul dalam lelaran masa hadapan.

Rangka kerja ini dibangunkan oleh Dai Clegg di Oracle UK pada tahun 1994 dan kemudiannya diformalkan dalam Dynamic Systems Development Method (DSDM). Huruf kecil dalam MoSCoW (huruf "o" dan "W") adalah pengisi untuk menjadikan akronim boleh disebut. Empat huruf yang bermakna adalah M, S, C, dan W.

Fakta Utama

• Laporan CHAOS Standish Group mendapati bahawa 45% ciri dalam produk perisian tidak pernah digunakan, dan 19% lagi jarang digunakan, bermakna hampir dua pertiga daripada apa yang dibina oleh pasukan menghasilkan nilai yang minima (Laporan CHAOS Standish Group, 2020).
• Projek yang menggunakan penetapan keutamaan keperluan berstruktur dua kali lebih mungkin dihantar tepat pada masa dan dalam bajet berbanding yang tanpa penetapan keutamaan formal (PMI Pulse of the Profession, 2021).
• Pasukan yang mendefinisikan item di luar skop dengan jelas pada permulaan projek mengurangkan perubahan skop pertengahan projek sehingga 30% (penyelidikan pengamal Konsortium DSDM, 2019).

Empat kategori MoSCoW

Pembahagian 60/20/15/5 adalah panduan kasar, bukan peraturan. Kekangan kritikal ialah Mesti ada tidak seharusnya melebihi kapasiti penghantaran yang disahkan oleh pasukan. Jika ya, kategorisasi itu salah, bukan kapasiti.

MoSCoW vs kaedah penetapan keutamaan lain

MoSCoW biasanya merupakan rangka kerja yang paling cepat untuk dilaksanakan dalam bengkel pihak berkepentingan kerana ia menggunakan kategori bahasa biasa berbanding skor atau lengkung. Ini menjadikannya sangat berguna apabila anda memerlukan persetujuan daripada pihak berkepentingan bukan teknikal sebelum perancangan Sprint atau permulaan penghantaran.

Faedah penetapan keutamaan MoSCoW

Ia mewujudkan bahasa bersama. Apabila pengurus produk berkata "itu adalah Sepatutnya ada," semua orang dalam pasukan tahu maksudnya. Tiada siapa yang membuang masa bertanya sama ada ciri itu "penting" (segalanya penting kepada sesiapa yang memintanya).

Ia memaksa pertukaran yang eksplisit. Kategori Tidak akan ada adalah bahagian rangka kerja yang paling berkuasa. Menulis apa yang anda tidak bina adalah lebih sukar daripada yang kedengaran, dan ia mencegah skop daripada mengembang secara senyap selepas permulaan.

Ia menyelaraskan pihak berkepentingan sebelum kerja bermula. Menjalankan bengkel MoSCoW dengan keseluruhan matriks RACI pihak berkepentingan mengeluarkan perselisihan tentang keutamaan lebih awal, apabila ia murah untuk diselesaikan. Konflik keutamaan peringkat lewat adalah mahal.

Ia sesuai secara semula jadi dengan penghantaran Agile. Rangka kerja ini berpasangan dengan baik dengan metodologi Agile kerana ia menentukan skop setiap lelaran berbanding keseluruhan projek. Pasukan menjalankan semula MoSCoW pada permulaan setiap kitaran keluaran berbanding mengunci keperluan sekali sahaja.

Ia melindungi Mesti ada. Dengan memberikan item keutamaan tertinggi baldi yang dilindungi sendiri, rangka kerja ini memudahkan secara politik untuk mengatakan tidak kepada penambahan. "Itu akan memindahkan sesuatu daripada Mesti ada" adalah hujah yang lebih sukar untuk ditolak berbanding "kami tidak mempunyai masa."

Kesilapan biasa

1. Terlalu banyak Mesti ada. Ini adalah mod kegagalan yang paling biasa. Apabila semuanya kritikal, tiada apa yang kritikal. Senarai Mesti ada yang sihat harus muat dalam kapasiti penghantaran yang disahkan dengan margin untuk yang tidak dijangka. Jika Mesti ada anda menggunakan 90 peratus kapasiti, anda tidak mempunyai penampan untuk isu teknikal, dan anda telah menjadikan Sepatutnya ada anda tidak relevan.

2. Tiada senarai Tidak akan ada. Pasukan yang melangkau baldi ini meninggalkan skop sebagai kabur. Pihak berkepentingan memenuhi kekaburan itu dengan andaian. Takrifkan senarai Tidak akan ada secara bertulis dan kongsikan dengan semua orang yang menandatangani Mesti ada.

3. Menganggap kategori sebagai kekal. MoSCoW adalah penilaian pada satu titik masa untuk tetingkap penghantaran tertentu. Boleh ada dalam keluaran satu mungkin menjadi Mesti ada dalam keluaran dua. Semak semula kategorisasi pada permulaan setiap lelaran.

4. Menggunakan MoSCoW tanpa kekangan masa. Rangka kerja ini hanya berfungsi apabila anda menetapkan keutamaan terhadap garis masa atau bajet yang tetap. Tanpa kekangan, semuanya kekal sebagai Mesti ada kerana tiada fungsi pemaksa untuk memilih.

5. Menjalankan bengkel tanpa pihak berkepentingan yang betul. Kategorisasi yang dilakukan oleh seorang penganalisis atau pengurus projek sahaja tanpa input pihak berkepentingan menghasilkan senarai yang tidak dimiliki oleh sesiapa. Sesi ini memerlukan orang yang akan hidup dengan pertukaran tersebut.

6. Mengelirukan Sepatutnya ada dengan Boleh ada. Sepatutnya ada adalah sesuatu yang perniagaan secara aktif kehilangan jika ia tidak ada. Boleh ada adalah peningkatan yang baik. Perbezaan ini penting apabila anda memutuskan apa yang perlu dipotong di bawah tekanan.

Cara menggunakan kaedah MoSCoW

Langkah 1: Kumpul keperluan

Kumpulkan semua keperluan, ciri, kisah pengguna, atau tugas yang merupakan calon untuk penghantaran. Pada peringkat ini, jangan tapis apa-apa. Anda mahukan senarai yang lengkap sebelum anda mula menyusunnya. Gunakan pernyataan skop projek sebagai dokumen sempadan untuk mengesahkan apa yang berada dalam dan di luar keseluruhan projek.

Matriks analisis pihak berkepentingan membantu mengenal pasti input siapa yang anda perlukan semasa bengkel penetapan keutamaan. Pihak berkepentingan yang berbeza memiliki keperluan yang berbeza, dan autoriti relatif mereka membentuk cara konflik diselesaikan.

Langkah 2: Persetujui definisi kategori

Sebelum pasukan mula membuat kategorisasi, luangkan lima minit untuk mengesahkan maksud setiap baldi dalam konteks khusus ini. Untuk sesetengah projek, "Mesti ada" bermakna diperlukan secara undang-undang. Untuk yang lain, ia bermakna perlu secara teknikal agar MVP berfungsi. Menyelaraskan definisi sebelum anda membuat kategorisasi mencegah sesi daripada terhenti pada setiap item kedua.

Langkah 3: Buat kategorisasi secara kolaboratif

Dengan semua keperluan yang kelihatan (papan putih, nota melekat, atau hamparan kongsi), pasukan menetapkan setiap item kepada satu baldi. Kerjakan senarai secara sistematik. Untuk setiap keperluan, tanya:

• Adakah produk tidak boleh digunakan atau tidak patuh tanpa ini? Jika ya, ia adalah Mesti ada.
• Adakah kita akan menghantar dengan rasa menyesal yang ketara jika ia tidak ada? Jika ya, ia adalah Sepatutnya ada.
• Adakah kita akan menambahnya jika kita mempunyai masa lapang? Boleh ada.
• Adakah ia di luar skop untuk penghantaran ini? Tidak akan ada (kali ini).

Perselisihan pada peringkat ini adalah sihat. Ia mendedahkan jangkaan yang tidak selaras lebih awal. Selesaikan sekarang, bukan semasa Stand-up harian Scrum tiga minggu kemudian.

Langkah 4: Semak bajet Mesti ada

Setelah kategorisasi awal selesai, tambahkan jumlah anggaran usaha untuk semua item Mesti ada. Bandingkan jumlah itu dengan kapasiti penghantaran yang disahkan anda (jam atau Story Point yang tersedia tolak penampan luar jangka 20 peratus). Jika Mesti ada melebihi kapasiti, sesuatu perlu dipindahkan. Turunkan Mesti ada yang paling lemah ke Sepatutnya ada sehingga nombor itu sesuai.

Langkah ini adalah di mana MoSCoW menunjukkan nilainya. Tanpanya, pasukan mendapati komitmen yang berlebihan pada tanda dua pertiga projek, apabila sudah terlambat untuk menyesuaikan diri dengan anggun.

Langkah 5: Semak dan semak semula setiap lelaran

Pada permulaan setiap Sprint atau kitaran keluaran, semak semula senarai. Item yang selesai dikeluarkan. Penemuan baru, keperluan perniagaan yang berubah, atau kekangan teknikal mungkin memindahkan item antara kategori. Senarai Tidak akan ada dari lelaran sebelumnya adalah sumber calon terbaik untuk kenaikan pangkat ke Boleh ada atau Sepatutnya ada dalam lelaran seterusnya.

Gelung semakan ini adalah apa yang memastikan MoSCoW sejajar dengan realiti berbanding rancangan asal. Piagam projek menetapkan sempadan strategik; MoSCoW memastikan pelaksanaan taktikal dalam sempadan tersebut.

Contoh MoSCoW

Jadual di bawah menunjukkan senarai ciri untuk MVP portal projek menghadap pelanggan, disusun mengikut kategori MoSCoW.

Mesti ada mendefinisikan produk yang berfungsi. Tidak akan ada mendefinisikan sempadan rundingan dengan pihak berkepentingan yang mahukan segalanya pada hari pertama.

Amalan terbaik

Jalankan MoSCoW sebagai bengkel, bukan latihan solo. Perbincangan semasa kategorisasi adalah di mana penyelarasan berlaku. Hamparan yang diisi oleh satu orang dan diemel tidak menghasilkan pemilikan kongsi yang sama.

Tulis Mesti ada sebagai kriteria penerimaan, bukan nama ciri. "Log masuk yang selamat" adalah samar. "Pengguna boleh log masuk dengan e-mel dan kata laluan, sesi tamat selepas 30 minit tidak aktif, dan percubaan log masuk yang gagal dihadkan kadarnya" adalah boleh diuji. Kriteria yang jelas memudahkan pengesahan apabila Mesti ada benar-benar selesai.

Pastikan senarai Tidak akan ada kelihatan sepanjang projek. Cetaknya, tampalnya, letaknya di pengepala papan Scrum vs Kanban, atau pasangkan dalam saluran pasukan. Item di luar skop mempunyai tabiat memasuki semula skop secara senyap apabila tiada siapa yang memerhati.

Gunakan MoSCoW bersama proses anggaran anda, bukan menggantikannya. Penetapan keutamaan tanpa anggaran kapasiti adalah angan-angan. Jalankan semakan waras dalam Langkah 4 setiap kali anda mengemas kini senarai.

Bersikap jujur tentang maksud "Tidak akan ada kali ini." Ia bukan penolakan sopan. Ia adalah penangguhan yang dijadualkan. Jika anda tahu item itu tidak akan pernah dibina, katakan dengan jelas berbanding meletakkannya dalam Tidak akan ada selama-lamanya. Pasukan dan pihak berkepentingan berhak mendapat kejelasan.

Soalan lazim

Apakah maksud "o" dalam MoSCoW?

Tiada apa-apa. Huruf "o" kecil adalah huruf pengisi yang ditambah untuk menjadikan akronim boleh disebut. Empat huruf yang bermakna ialah M (Mesti ada), S (Sepatutnya ada), C (Boleh ada), dan W (Tidak akan ada). Dai Clegg mencipta istilah itu di Oracle pada tahun 1994, dan huruf besar yang luar biasa adalah disengajakan, untuk memberi isyarat bahawa hanya empat daripada enam huruf membawa makna.

Apakah peratusan keperluan yang seharusnya menjadi Mesti ada?

Tiada peraturan sejagat, tetapi kebanyakan pengamal mengesyorkan agar keperluan Mesti ada tidak menggunakan lebih daripada 60 hingga 70 peratus kapasiti penghantaran yang tersedia. Ini meninggalkan ruang untuk Sepatutnya ada dan penampan luar jangka. Jika Mesti ada anda secara konsisten mencecah 80 hingga 100 peratus kapasiti, anda tidak menetapkan keutamaan, anda hanya menyenaraikan semua yang anda rancang untuk dibina.

Bolehkah keperluan berpindah antara kategori?

Ya, dan ia seharusnya begitu. MoSCoW adalah alat yang hidup. Sepatutnya ada dalam satu Sprint mungkin menjadi Mesti ada dalam Sprint seterusnya jika perubahan peraturan atau komitmen pelanggan mengubah kepentingannya. Semak dan kemas kini kategori pada permulaan setiap lelaran berbanding menganggap kategorisasi awal sebagai muktamad.

Bagaimana MoSCoW sesuai dengan penghantaran Agile?

MoSCoW sesuai secara semula jadi dengan Agile kerana kedua-dua pendekatan memeluk lelaran dan pertukaran. Dalam konteks Agile, MoSCoW menentukan skop setiap Sprint atau keluaran berbanding hala tuju produk penuh. Product Owner biasanya menjalankan bengkel kategorisasi sebelum perancangan Sprint. Backlog Sprint kemudian diambil daripada Mesti ada dahulu, Sepatutnya ada jika kapasiti membenarkan, dan Boleh ada hanya jika terdapat Slack yang disahkan.

Siapa yang harus memfasilitasi sesi MoSCoW?

Pengurus projek atau penganalisis perniagaan biasanya memfasilitasi, tetapi sesi harus memasukkan semua pihak berkepentingan dengan autoriti membuat keputusan mengenai keperluan. Itu biasanya bermakna Product Owner atau penaja, ketua teknikal utama, dan mana-mana fungsi perniagaan dengan kepentingan yang ketara dalam penghantaran. Tugas fasilitator adalah untuk memastikan perbualan bergerak maju dan memastikan perselisihan diselesaikan (bukan ditangguhkan) sebelum sesi berakhir.

---

Penetapan keutamaan bukanlah kemahiran teknikal. Ia adalah disiplin membuat keputusan, dan MoSCoW memberikan disiplin tersebut struktur yang boleh digunakan oleh kebanyakan pasukan tanpa sijil atau hamparan pemarkahan. Mulakan dengan senarai keperluan yang lengkap, jalankan bengkel dengan orang yang betul, lindungi Mesti ada daripada komitmen berlebihan, dan tulis apa yang tidak anda bina. Selebihnya mengikuti.

Bacaan berkaitan

• Apakah Metodologi Agile?
• Perancangan Sprint: Cara Menjalankan Mesyuarat Perancangan Sprint yang Berkesan
• Apakah Scrum?
• Scrum vs Kanban
• Pernyataan Skop Projek
• Matriks RACI
• Piagam Projek
• Matriks Analisis Pihak Berkepentingan