怎麼決定開發項目的優先序？- 17 產品經理的 RICEX 應用分享
在任何面試的時候，都有可能會被問到這個問題：「在有很多項目需要進行，但資源不夠的時候，會用什麼方式排優先序，挑選需要先被執行的項目呢？」
欸不是，我相信你不管是不是產品經理，面試的時候不會這樣回答 🙈
常見的答案是會考慮影響範圍的多寡、任務的緊急程度、達成目標的重要性、帶來多少商業價值等，這些都是合理的答案。但當有多個因素匯聚在一起的時候，你會怎麼判斷呢？
在產品經理的世界有幾個常見的方法論，這次想跟大家分享如何用 RICE score 來決定需求優先級。
▍RICE score 怎麼計算？
每個需求項目都可以透過下方公式計算出一個RICE score，接著 PM 就會用分數高低來作為排定開發優先序的依據。分數越高，代表優先級越高。
RICE score = (Reach*Impact*Confidence) / EffortReach 指的是這個需求會觸及到的人數。可以選用產品場景真實的觸及人數(例如 Unique viewer 這樣的數字)作為 Reach 的基準，也可以用其他的值來代替真實數字。不管選用什麼樣的數字，重點是要讓這個數字能代表被「影響的範圍」。
Impact 指的是這個項目對應到具體目標的影響力，通常會這樣定義：
- 3 = massive impact
- 2 = high impact
- 1 = medium impact
- 0.5 = low impact
- 0.25 = minimal impact
但老實說，massive impact 或是 high impact 這樣的描述是相對模糊的，每個人心中的標準可能有極大的差距。所以還是需要利用過去做過的項目成果，來抓這些形容詞的基準線。
Confidence 是指你的信心程度， 通常有三個級距： 100%、80%、50% 。如果你的信心程度低於 50% ，那這個項目就不需要被實作了。若覺得這樣就放棄很可惜，可以先透過一些用戶研究、運營、設計 MVP 、競品分析等方式（以後有機會再跟大家分享這塊），讓團隊找到對這個項目的信心，更完整的把關後續的資源運用、判斷優先級。
Effort 指的是這個項目所需的開發資源，通常會用費波那契数列（Fibonacci sequence）來設定數值。例如 1、2、3 代表所需得資源規模是小的， 5、8 是中度的， 13 以上則是大規模的。這個數字一樣可以用過去做過的具體項目作為基準，幫助你跟整個團隊擁有一致的評估標準。
比起 Impact 與 Confidence ， Reach 和 Effort 是相對客觀的指標。所以仔細觀察上方的公式後，你也會發現在大多數的情況下，它們對整體的 RICE score 影響力是相對大的。
▍在 17 ， RICE 如何被使用？
在 17 ，我們曾經是把所有會使用到的場景的 Reach 數字都抓出來，然後所有人都用同一套真實的 Reach 去計算 RICE score 。但我們後來發現，若產品在各個區域、各個場景的 Reach 數差異很大，會讓 Reach 的影響力太過強大。就算我們預期某個需求有 massive impact ，而且還有 100% 的信心，但在它的 Reach 太少的情況下，那這個項目就只能很可憐的被排在序位很低的地方。特別是當我們有多個不同的成長目標正在同步進行時，影響範圍小的目標可能就會被忽視。在同時做全球化跟在地化的決策時，在地化決策的處境也會稍微弱勢。
因此，我們後續也對 Reach 的算法做了一些調整。我們一樣把所有會使用到的場景的 Reach 數字都抓出來，接著用百分位的邏輯把數字對應成 1–100 ，稀釋真實 Reach 的極端值帶來的影響。
除了調整 Reach 的計算方式之外，我們也對 Impact 做了標準化。我們直接把過去項目的成長水準羅列出來作為基準線，並讓這些數字區間直接對應到 Impact 的指標，大大幫助了 PM 之間的溝通，也增加跨團隊之間對數值的共識，甚至能對應到後續的成效檢核。
▍不是霸道總裁，但有絕對影響力的 X 值
儘管有一個完整的方法論在幫助 PM 們排定項目的優先序，還是有可能出現一個 RICE score 很低，但你卻知道沒有它不行的項目。例如，在某個用戶數少的區域，希望可以開啟某個攸關區域生死的重要的功能，可是這個實作卻要花費不少功夫。這樣的項目若純粹用 RICE score 來排序，肯定是爹不疼娘不愛， PM 跟 Stakeholder 都為此徹夜難眠。
此時， X 值就可以出手相救了！ X 值代表的是 eXternal 的因素。若團隊有共識這個項目非常重要，但又因為 Reach 極低或 Effort 極高，導致整體價值被低估，可以直接利用 X 值把 score 往上調整。
於是計算整體分數的公式會變成：
RICEX score = ((Reach*Impact*Confidence) / Effort)*X當然，這個值是不建議常用的。若用多了，代表現在的RICE架構很可能不符合團隊的真實需求(或是總裁真的太霸道)，你需要尋求更合適方法來決定的優先級。
▍使用方法論的好處與限制
在 17 ，RICE 除了幫助 PM 用有一致性、連貫性的方式決定優先級，也是一個幫助不同團隊理解需求優先級的好方法。
我們會在 Backlog meeting 時討論每一個新項目的 RICE score，確定取得團隊內部的共識。接著把通過評審的項目放入 Roadmap 中，跟其他既存項目一起做排序，也把 Roadmap 分享給所有需要的工作做夥伴。同一份文件裡，也會讓所有團隊都看到每個項目的各項指標如何被評分、不同的產品團隊成員曾經針對評分做了什麼樣的討論。
但實際運作下來，所有的產品開發團隊也不可能全然按分數的排序來安排開發。因為總有些功能，比較適合某幾個特定團隊來開發；或是某些功能的概念很好，但排入的時機未到，還在等待概念的驗證，或跟其他項目有相依性。在這樣的時刻，我們還是會稍微地調整項目的優先序。
方法論提供便利性、幫助不同團隊找到溝通的基準，但我們無法期待它的降臨能解決所有的問題。如何讓資源被有效的利用、有彈性的調配、又讓 Stakeholders 滿意，這之間的權衡，就是 Product Manager 要練的功夫了。
▍輪到你了！
喜歡這次的分享嗎？ 歡迎跟我們分享你的產品經驗，或是你想了解的主題。
再告訴你一個好消息 😉
17 正在招募 Product Manager 。17 在台灣跟日本已經是領先的地位，我們正在努力從 Asia leader 成長到 World leader 。這位 PM 會負責到的產品就是 17 的主要產品 17 LIVE (17 直播 App)。
詳細介紹傳送門： https://17live.bamboohr.com/jobs/view.php?id=242這位 PM 需要具備：1. 能有效溝通的中英文能力2. 有 2 年以上的 B2C 或是 B2B2C 的相關軟體產業工作經驗3. 有完整的產品管理經驗
如果你覺得有朋友很適合這個職缺，請幫我分享給他。如果你覺得這一切都對到你的職涯目標了，那不管是白天黑夜，都是很適合用來改履歷跟投履歷的時機唷！
