【為什麼我們要挑選這篇文章】身為產品經理，決定任務優先次序是非常重要的技能，除了靠直覺之外，有沒有什麼工具，能夠更科學的安排優先次序。產品經理 Jessie Chang 在文中分享四個框架供讀者參考。（責任編輯：郭家宏）
作者：Jessie Chang
能夠排序任務的優先級一直是產品經理的重要技能，除了「你覺得」「老闆覺得」，我們需要一個有憑有據的框架讓我們的決策更準確的依循「做最重要的事」，把資源放在刀口上，產出最大化。
本篇文章是我的讀書筆記，我沒有所有的方法都用過，想整理出目前比較多人使用的方法，列出重點，如果有需要精細的計算會列出參考網頁。當然有些指標可能不適應所有的公司以及產業，所以大家可以彈性的挑選使用。即使我們要對抗人類決策上的缺陷，但在公式幫助我們之後建議還是需要產品經理 review 任務優先級的排序。
1. MoSCoW
MoSCoW 比較適合小型或中型的專案，比較沒有技術限制以及依賴性，如果你的專案複雜以及有時間上的緊迫性，可以跟著其他的方法一起服用。
先說這個方式跟俄羅斯一點關係都沒有。將任務（story/功能/任務/需求）分成四個種類，Must-have、Should-have、Could-have 以及 Won’t-have (this time)。大家一定都有經驗，每次想做的事情很多，然後搞得每次迭代（sprint）的週期變很長，為了保持「快速迭代、滿足變化」，MoSCoW 是一個方便快速的方法，尤其在跟客戶討論時（客戶通常什麼都要）讓客戶分辨他們「需要（need）」什麼以及「想要（want）」什麼。
你可能會想 Must-have 以及 Should-have 的差別在哪，可以想成是這麼產品要出產的最低限度，以相片管理 App 來說，有照相功能是 Must-have 了吧，那支援 ios 的 live photo 可能就會是 Should-have，其他的大部分其實都是 Should-have，而 Could-have 可以當作是容易做完，卻沒有緊迫性的任務，有時間就可以加減做，別忘了每次迭代前要再 review 一次每個讓 item 的類別去做調整。
詳細可以參考這篇 Purrweb 的 The MoSCoW method. How to prioritize product backlog and get most valued functionality faster
2. Kano
Kano 源於棒球隊的戰術
…好，我亂入了。
Kano 最適合使用在 UX 使用的行為體驗上，調查客戶對於產品體驗上的滿意度。Kano 可以給出直觀的數據結果，方便為論點提供數據支持。簡單來說讓客戶的滿意度調查決定新功能的開發或是對既有功能要繼續迭代/維護/以及優化的優先順序。
Kano 方法是在 1980 年代，由日本東京理工大學教授 Noriaki Kano 提出，說明需求以及客戶滿意度的關係。Kano 對應客戶滿意度對應到產品分成五個種類，Attractive（魅力屬性）、One Dimensional（期望屬性）、Must-be（必備屬性）、Reverse（反性屬性），以及 Indifferent（無差異屬性）。其實跟樓上的 MoSCoW 有類似的概念替產品分類安排優先級，差別是 Kano 是經由客戶問券的調查，而問券上的題目也很簡單，主要要問的問題有兩個：
▌如果有 xx 功能你會感到如何？（How would you feel if the product had that feature?）
▌如果沒有 xx 功能你會感到如何？（How would you feel if the product didn’t have that feature?）
並讓客戶的選擇從我喜歡到我不喜歡：Like（我喜歡）、Must be（應該要有）、Neutral（無所謂）、Live with（勉強接受）以及 Dislike（我不喜歡），並對應到上圖的表格中。
這邊有非常詳盡的計算方式，大家有興趣可以看看 杨小牙 KANO 模型及需求优先级管理最全详解
3. RICE
RICE 用做產品會遇到最重要的因素來計算出一個分數，可以用這個分數來解釋任務的優先程度，分數出來不要 A 同事覺得這個比較重要；B 同事覺得那個比較重要，分數出來你們通通給我閉嘴。以下是針對四個因素的解釋：
▌Reach，預測這個需求會觸及到的人數，也就是影響範圍。Reach 可以是你預測會影響的人數在一定的時間區間內。
比如說：1200 人將在接下來三個月受影響，Reach score 為 1200 或是推出的產品在接下來一個月可能會觸及到 1000人，其中 30% 客戶受影響，Reach Score 為 300。
▌Imapct，量化功能為我們帶來的 benefit，比如說這個功能推出後可以帶來說少的轉換率/觸及率，所以 Benefit 就是你設定的成功指標（Success Metrics）。
這個數字應該很難估計，可以用五個標準對整的數字去帶入公式；在 massive impact 跟 hight impact 或是 low impact 跟 minimal impact 間可能會很難去抉擇，但只要團隊的標準事前溝通好，是一樣的即可。
3 = massive impact
2 = high impact
1 = medium impact
0.5 = low impact
0.25 = minimal impact
▌Confidence，跟整個 team 討論這個專案的成功度分析，可以事前做使用這訪談、BD team 拿來的資料、或是製作 module 做測試，最好是可以使用一些最料去輔佐這個分數而非使用直覺；低於 50% 信心度的就可以不用做了。
100% = high confidence
80% = medium confidence
50% = low confidence
▌Effort，完成這個專案需要花費總時間，包含產品/設計/研發/測試，Effort 為一個負面的數字，所以越小越好。
他的計算方式我看到的有兩種，一種使用人-月做計算，比如說需要 3 個人一個月做完，Effort score 為 3；最小月份或是小於一個月內做完的，月份記為 0.5（3 人需要 3 個禮拜，Effort 數字為 3 x 05 =1.5）。
另一個作法是使用 Fibonacci 數列：1,2,3,5,8,13，1~3 為 effort 小、5, 8 為中等 effort、13 為 effort 高這樣去做計算。
我覺得 Effort 可以用更簡單團隊可以接受的方式做計算即可，比如說 effort 劃分為 s, m, l, xl 衣服大小去評估，每一個 size 帶入數值即可（s=0.5, m=1, l=1.5, xl=2），勁量讓計算越簡單越好，以上只是方程式內的一個 factor 讓其結果有一個參考，而不是絕對正確的數字。
4. Mic
對於事情的處理我覺得有一個快速的套路：
1. 每天晚上前想過一遍明天要做什麼，要帶什麼，記錄下來給自己一個心理準備（可以在下班前或是通勤的時候想，我發現我睡前想會睡不著）
2. 早上到辦公室後快速想過一遍今天要做什麼，哪些球可以先丟給別人，哪些事情最重要先處理，而不是先處理自己想做的那部分，最後搞得開天窗。很多時候自己的焦慮來自於不想處理的事情一直不想去面對，心倒是很誠實，哼哼……
3. 呈上，記得需要花時間「等待別人處理」又不會花多少時間的評估一下抽空優先處理，因為在等待回覆的時候我們還可以做別的事情。傳球概念，球回傳的時候不用等待就可以處理，而不是這時候才要等球回傳。
4. 那事情都很重要怎麼辦？每次我說先做最重要的事！別人都會回：「那都很重要怎麼辦？」很簡單，先處理先發生了，如果三點跟五點的會一樣重要，那先處理三點的會議，這個觀念大家應該可以理解，畢竟我們是人，不是神。
所以哪個方法比較好啊？
我覺得如果說每個方法都是好方法真的是屁話（X），以判斷標準建議你覺得簡單最快速可以判斷的方式最好，以我來說，我會喜歡用 MoSCoW 跟 RICE，可以在一個會議內解決的方法，比較複雜除非你建立了一個 excel 的公式去快速計算，不然實在傷神費時間，畢竟還有其他工作要花好多時間，沒有時間陪女友怎麼辦？
以上，敬所有累得像狗的工作者，喔不，是比狗還累……
後記：這篇我打了半年，其中是因為工作的週末極度累，只想在家擼貓；我現在的情況有點推翻我的前言，「對抗你覺得、老闆覺得，需要一個有憑有據的框架讓我們的決策更準確」有些公司真的就是不需要你排優先順序，老闆說：「沒有原因我就是要做就得做，所有任務都是 p0」，其實真的很難推動…不過盡量在一些迭代需求裡面慢慢試圖讓這些框架可以 implement 進去。
聽到一個比較好笑的事，最近在做 prd review, 有 PM 在報告的時候沒有寫 product background 被唸，直覺想到不是老闆說要做嗎？寫起來報告多尷尬 。
以上是分享讀書筆記以及 PM 日常抱怨，enjoy ：）
（本文經投稿作者 Jessie Chang 授權刊登，並同意 TechOrange 編寫導讀與修訂標題，原文標題為〈對抗人類直覺，用公式計算產品優先級，MoSCoW、RICE、KANO 框架整理〉。意投稿者可寄至：[email protected]，經編輯檯審核並評估合宜性後再行刊登。首圖來源：PxHere CC Licensed）
延伸閱讀
如何進 FAANG 當產品經理？19 個關於產品經理的大哉問
不是搞定客戶就沒事！產品經理還必須具備這 4 項數據能力
【PM 職涯面面觀】不當主管職也可以！看資深產品經理解析何謂「PPM」
