身為 Product Manager 總會收到源源不絕的 User Feedback、優化需求，甚至是新功能的發想提案，除了某些因政治因素必須完成的項目外，如何盡早推上市場測試、滿足最有潛力的需求，衍伸而來的「需求排序(Prioritization) 」往往是最艱難的課題。
為了避免老是為優先序拍頭腦，或柴米油鹽都讓老闆決策，近期研究了幾個關於 Prioritization 相關的方法論與框架，線上的資源與分享其實不少，這邊簡單地把幾個近期覺得不錯的翻譯一下推薦給大家，包含適合使用的時機，並融合幾個曾經跑過的經驗：(1) Value vs. Complexity
藉由評估兩個問題，將需求依程度擺放至由 Value 和 Efforts 展開的象限中：
- 這個需求完成後預計將帶來多少價值
- 這個需求會需要多少時程與人力去實現
若 Efforts 為 x 軸，Value 為 y 軸，定位所有需求後，優先進行左上區塊的需求，其次是右上、左下，而右下區塊的需求則可以慎重考慮實作的必要性，以及是否可以從眾多需求中取捨掉。
Value vs. Complexity 利用簡單視覺化的方式幫助 PM 與團隊成員取得共識，也便於攤開所有待辦需求，讓大家看到 Backlog 的全貌。但之前採用過的經驗發現 Value 的評估往往會拿捏得不準確，尤其是針對全新、沒有前車案例可以參考的需求，即便有預估指標可以輔助解釋擺放的位置，但對價值高低的評估往往會沒有十足把握，這也是團隊間容易發生歧見的地方。
(2) Opportunity Scoring
Opportunity Scoring 相對來說為成果取向(Outcome-driven)，不會涉及評估到實作所需要的成本，針對每個需求主題(Theme)去評估新功能重要性(Importance)、與現有滿意度(Satisfaction)之間的差異，作為機會價值的最終判斷指標，結算公式為：
Importance +(Importance - Satisfaction) = Opportunity.
舉下圖為例，Billing 現有的滿意度為 4，新功能帶來的重要性為 8，在公式的結算下： 8 + (8 – 4) = 12 ，12 分相對於其他主題來說機會價值是列在中等。Opportunity Scoring 雖不評估實作成本，但可以比較現有滿意度，讓低滿意度的主題較有機會受到關注，有時候產品端的成員往往會糾結在特定功能的優劣，但若這對一般消費者來說已可達到一定程度的滿足，就不須在資源緊縮的時刻把精力投注在這裡。另外 Opportunity Scoring 也可以作為競品分析使用，將競爭者推出的功能與現有用戶的滿意度作比較，可幫助我們進一步定義哪些是創新的需求。
Opportunity Scoring 雖以 Outcome-driven 來說是個淺顯易懂的架構，但執行上會遇到不少困難，像是要怎麼評估各主題的用戶滿意度、會遇到和 Value vs. Complexity 一樣的問題 — 如何公正並有效的評估主題的重要性，都需要仰賴團隊間的反覆溝通與實驗以達成共識。
※ 題外話前幾天看到 Atlassian PM 的分享(12:18) ，在探索未滿足的用戶需求時也是使用 Opportunity Scoring
(3) RICE Scoring Model
Intercom 延伸 ICE Model 發展了 RICE，來解決內部決策制定流程的問題，算是解決了 Value vs. Complexity 中 Value 不易評估的弱點，將價值分為三個評估元素：
- Reach：預計會接觸影響多少人，舉例若是1,200人可訂為1,200分
- Impact：對用戶的影響有多大，這邊 Itercom 提供了五個級距的參照
■ 3 = massive impact
■ 2 = high impact
■ 1 = medium impact
■ .5 = low impact
■ .25 = minimal impact - Confidence：對於上述元素評估的信心程度百分比，參考比例如下
■ 100% = high confidence
■ 80% = medium confidence
■ 50% = low confidence
並總結實作所需要耗費的成本 - Efforts：
可用人月的方式評估，例如需要3個人1個月的時間即可定為 3*1 分，少於一個月的每人都定為 0.5，最終的公式為：
Reach * Impact * Confidence / Efforts
算出來的分數不可單獨解讀，需要和其他功能進行比拚，其中當然還是少不了預估的成分，但藉由信心程度的元素可加強推估的準確性。這個方式我實際沒有跑過，但預計 Reach 人數的可能是影響預估精準的關鍵，畢竟若以一人一分的方式下去計算，總分結果容易受到人數左右。
(4) KANO Model
KANO Model 又稱狩野模型，執行前需要先進行用戶調研：簡單描述各候選需求，並讓用戶有一定的理解後 (或最好是用戶已經體驗過)，請用戶針對每個候選需求回答兩個問題：
- 正向問題：如果有這個功能，你的感受是？
- 負向問題：如果沒有這個功能時，你的感受是？
從左到右五個程度中來選擇對應兩個問題的感受：
無法接受 / 還能忍受 / 無所謂 / 理所當然的 / 非常棒
並根據下圖的 KANO 評分量表，得出 M, O, A, I, R, Q 六種需求類型
其中受 Herzberg 的雙因子理論影響，衍伸保健因子與激勵因子而得出的這四種需求類型尤為重要：
- M 基本型需求（Must-be）:
顧客對企業提供的產品／服務因素的基本要求。 - O 期望型需求（One-dimensional）：
顧客的滿意狀況與需求的滿足程度成比例關係的需求。 - A 魅力型需求（Attractive）：
不會被顧客過分期望的需求，但對於正向滿意度有幫助。 - I 無差異需求（Indifferent）：
使用者對這一需求無所謂。
找出每個需求所屬於的類型後，處理優先順序為： M > O > A > I ，如需要更進一步的排序可再執行敏感度分析。
實際採用過兩遍之後，雖然前置準備較多，但對於需求類型的定義和取得團隊共識上有很大的幫助，尤其在有一堆優化項目卻不知從何下手時，KANO 從用戶的角度協助給予一個滿明確的方向。但若是針對用戶沒有接觸過，或幾乎很難想像的新功能就比較難在 KANO 中發揮，畢竟用戶對於沒有體驗過的功能所能給的反饋不一定真實或精確。
有興趣實際執行 KANO 分析的可參考這篇文章 - 活用狩野分析搞定意見分岐 ，或參考我之前針對 KKBOX 做的優化提案。
還有一些常見的 Prioritization Model / Frameworks 像是
- Affinity Grouping：根據需求的目的性分群，再給予執行排序。
- Story Mapping & Release Phases：適用於有連貫性的需求，利用 Story mapping 的方式抓出用戶需要的功能與流程，再進一步依重要性分 Phase 執行。
- MoSCoW Prioritization：依程度將需求分級為 Must-have, Should-have, Could-have, Will-not-have，快速簡易地分出需求的價值強度，對於非產品端的同事也容易理解。
這邊就不多加描述，有興趣的朋友可參考 ProductPlan 的這篇文章 了解更多細節，也歡迎大家一起分享曾用過的 Prioritization 經驗，上述的內容若有誤，歡迎糾正與討論，一起持續成長🙌🏻
