RICE 優先序：四個數字讓爭論結束

在產品開發的世界裡，有一個永遠打不完的仗：所有東西看起來都重要，所有人都認為自己的需求最優先。

RICE 是 Intercom 的產品團隊發展出來的一個框架，用來終結這場仗——不是靠資歷，而是靠分數。

四個字母各代表什麼

R — Reach（觸及）：這個功能在特定時間內影響多少人？不是「所有使用者」這種模糊答案，而是一個具體數字。每月有 500 位使用者會用到這條功能？那 Reach = 500。

I — Impact（影響）：每個觸及到的使用者，會受到多大影響？Intercom 用 0.25 到 3 的係數——0.25 是「輕微影響」，3 是「大幅改變使用體驗」。

C — Confidence（信心）：你對以上估計有多確定？如果你有使用者研究支持，Confidence 可以到 100%；如果只是直覺，可能只有 50%。Confidence 是一個折現率，逼你誠實面對自己的估計有多少依據。

E — Effort（投入）：這個功能大概需要多少人月（person-months）完成？估計越保守越好——大多數工程師的時間估算都會低估。

計算公式：RICE = (R × I × C) / E

為什麼 Effort 在分母

這是 RICE 最關鍵的洞見：同樣好的功能，花更少時間做的永遠更值得優先。

很多優先排序系統只看「功能好不好」，卻忘了資源是有限的。一個 RICE 分數高的功能，是在「觸及廣、影響大、信心高」和「成本低」之間取得的平衡——而不只是其中一邊。

它解決的真正問題：讓爭論有共同語言

RICE 分數不是真相，但它提供了一個讓大家用同一套邏輯爭論的平台。

當設計師說「這個功能很重要」，和工程師說「這個功能很重要」，他們說的可能是完全不同的維度。RICE 強迫每個人把「重要」翻譯成四個可以量化的子問題，讓爭論從「我覺得 vs. 我覺得」變成「你的 Reach 假設是什麼」。

實際使用時的常見陷阱

把 Confidence 設太高：第一次做 RICE 的團隊往往把所有功能的信心都設 100%，因為大家都相信自己的判斷。試試把它降到 50%，看看你的排序有沒有改變。如果改變很大，表示你的估計需要更多驗證。

Effort 用工時而不是人月：工時估計太細、太容易膨脹。人月（一個人一個月的工作量）是粒度更適合的單位。

只做一次就固化：RICE 不是一次性排序，是活的文件。每次有新資訊——使用者研究、功能測試結果、市場變化——就更新對應的估計，讓優先序動起來。

RICE 的適用邊界

RICE 在「有多個功能需要排序、資源有限、需要跨角色對齊」的情境下最有效。如果你只有一個功能要決定「做不做」，用 RICE 可能是過度分析。如果決策的本質是策略方向（進這個市場還是那個市場），RICE 也無法取代策略判斷。

把 RICE 想成是執行層的工具，而不是策略層的工具。策略定方向，RICE 在方向之內排順序。

完整的 RICE 引導問題在 Apexhone 的框架介紹頁裡。