RICE 優先級模型 RICE Scoring Model

什麼時候該用它？

當你面對有限的工程資源，卻有滿手的好點子時。特別是當各部門開始用「直覺」或「職級」來施壓排期，你需要一個客觀、冰冷的數字公式來當擋箭牌。

• Sprint 規劃：從 20 個候選項中挑出這個 Sprint 要做的 5 個
• 跨部門優先級爭論：業務、行銷、客服各有各的「最重要需求」
• 資源受限：只有 2 個工程師，但有 10 個待做項目
• 需要跟老闆解釋「為什麼不做 X」：有數字佐證比嘴巴說服更有效

框架結構

RICE 是一個簡單的乘除公式：

RICE Score = (Reach × Impact × Confidence) ÷ Effort

四個維度

1. Reach（觸及人數）：這功能在特定時間內（通常一季）會影響多少使用者？用實際數字，不是「很多人」
2. Impact（影響力）：對目標指標有多大幫助？
   • 3 = 巨大影響
   • 2 = 高影響
   • 1 = 中等影響
   • 0.5 = 低影響
   • 0.25 = 極低影響
3. Confidence（信心水準）：你對上述預估有多大把握？
   • 100% = 有數據佐證
   • 80% = 有信心但沒硬數據
   • 50% = 純猜測
4. Effort（投入成本）：需要多少人月（Person-Months）？

計算範例

功能 A：Reach=5000, Impact=2, Confidence=80%, Effort=3 → Score = (5000 × 2 × 0.8) ÷ 3 = 2,667

功能 B：Reach=20000, Impact=0.5, Confidence=50%, Effort=1 → Score = (20000 × 0.5 × 0.5) ÷ 1 = 5,000

結論：功能 B 優先。雖然單一使用者影響力低，但觸及面大且成本極低。

來源與歷史

• 2016：Intercom 產品團隊的 Sean McBride 在公司部落格發表 RICE，解決內部需求排序的長期痛點
• 2017-2018：隨著 Intercom 的產品思維文章廣泛傳播，RICE 成為 SaaS 圈標配
• 2020s：各種專案管理工具（Linear、Notion、ProductBoard）內建 RICE 評分欄位，從方法論變成工具功能

真實案例：SaaS 客服平台的排期翻轉

一家台灣 B2B 客服 SaaS 公司面臨典型困境：CEO 想做 AI 自動回覆（技術酷炫）、業務部想做多品牌管理（大客戶要求）、客服部想做快捷回覆範本（天天被抱怨）。

用 RICE 評分後：

結果：快捷回覆範本 Score 是其他兩個的 50-70 倍。開發只要兩週，但能幫所有客服省下每天 30 分鐘的重複打字。上線後客服團隊滿意度從 3.2 分升到 4.6 分（5 分制），客服回覆速度提升 40%。

CEO 的 AI 自動回覆？排到 Q3，等有更多數據再說。

使用步驟

Step 1：列出候選項目

把所有待排序的需求、功能、專案列成清單。通常 10-20 個為一批。

Step 2：統一 Reach 的計算基準

團隊先對齊「Reach 指的是什麼時間範圍、什麼人」。例如「每季會受影響的活躍使用者數」。不統一基準，算出來的分數沒有比較意義。

Step 3：各自打分再校準

每個人先獨立打分（避免錨定效應），然後團隊一起討論差異最大的項目。重點是「為什麼你給 Impact 3 而我給 1？」

Step 4：誠實面對 Confidence

這是最容易灌水的維度。規則：如果你說不出支撐預估的數據來源，Confidence 就不能超過 50%。

Step 5：排序並決策

按 Score 排序，但不是機械式地照做。Score 差距在 20% 以內的可以視為同級，用其他因素（策略對齊、技術債）微調。

這樣做 vs 避免這些

這樣做

• 每季重新評分 — 環境變了，Reach 和 Impact 也會變
• 用 RICE 當「討論工具」而非「決策機器」— 真正的價值在評分過程中的對話
• 把 Effort 的單位統一 — 人月、人週、Story Point 都行，但團隊要一致
• 記錄打分紀錄 — 回頭驗證預估 vs 實際，校準未來的準度

避免這些

• 不要讓 RICE 變成政治工具 — 「只要我把 Reach 灌高就能贏」
• 不要對所有類型的工作都用 RICE — 技術債、安全修復不適合跟功能需求比分數
• 不要過度精確 — Impact 給 1.73 沒有比給 2 更科學
• 不要跳過 Confidence — 沒有把握就是 50%，不要自欺欺人