ICE 評分模型 ICE Scoring Model

什麼時候該用它？

ICE 最適合在「待辦清單上有 30 個功能但只能做 5 個」的時候拿出來。它不是什麼深奧的框架，就是三個維度各打分數然後相乘——但正是這種暴力的簡單性，讓它成為成長團隊最常用的排序工具。

• Sprint Planning：Backlog 裡堆了一堆 story，需要快速決定這個 sprint 做哪些
• Growth 實驗排序：成長團隊同時有 20 個 A/B test 想跑，但資源只夠跑 3 個
• 功能請求 triage：客戶回饋和業務需求源源不絕進來，需要一個一致的篩選標準
• 季度規劃：OKR 對齊後，把 Key Results 底下的具體行動排優先級
• 新創早期：資源極度有限，每個決定都是機會成本，ICE 幫你快速做出「夠好」的排序
• 跨團隊資源協調：當多個團隊搶同一組工程資源時，ICE 提供一個相對客觀的比較基準

框架結構

ICE 的結構極度簡單：三個維度，各打 1-10 分，相乘得出總分。

I — Impact（影響力）

「如果這件事成功了，影響有多大？」

• 10 分：直接影響核心指標（營收 +20%、轉換率翻倍）
• 7 分：顯著改善關鍵流程（結帳時間減半、客訴量降 30%）
• 4 分：改善使用者體驗但難以量化（介面更順、載入更快一點）
• 1 分：幾乎不影響任何人（改個內部工具的 icon）

C — Confidence（信心度）

「你有多確定上面的 Impact 評估是對的？」

• 10 分：有 A/B test 數據或市場驗證支持
• 7 分：有類似案例或使用者研究的間接證據
• 4 分：基於團隊經驗的合理推測
• 1 分：純粹是猜測或個人偏好

E — Ease（容易度）

「做這件事要花多少力氣？」

• 10 分：一個人一天內可完成
• 7 分：一個人一週內可完成
• 4 分：需要跨團隊協作，2-4 週
• 1 分：需要大規模重構或外部依賴，一個季度以上

計算方式

ICE Score = Impact × Confidence × Ease

分數範圍：1（最低）到 1,000（最高）。實務上，超過 500 分的項目通常值得立刻做。

來源與歷史

• 2010：Sean Ellis（Dropbox 早期成長負責人、GrowthHackers 創辦人）在成長駭客社群推廣 ICE 作為實驗排序工具
• 2013：GrowthHackers 平台上線，ICE 成為社群的標準排序方法，被數千個成長團隊採用
• 2015：Brian Balfour（HubSpot VP Growth）在其「Growth Machine」系列文章中強化 ICE 的使用方法，提出 Confidence 維度的量化標準
• 2017：Intercom 發表《RICE vs ICE》比較文章，推出 RICE 框架（加入 Reach 維度）作為 ICE 的進化版
• 2020s：ICE 因為夠簡單，在 AI/ML 實驗排序、No-Code 工具團隊中再度流行——需要快速迭代的場景不需要太複雜的評分框架

真實案例：Dropbox 的成長實驗引擎

Dropbox 在 2010-2012 年的爆發性成長期間，Sean Ellis 帶領的成長團隊同時維護超過 50 個實驗想法。

ICE 在 Dropbox 的運作方式：

1. 每週 Brainstorm：團隊每週產出 10-15 個新的成長實驗想法
2. ICE 評分：每個想法由提出者先打分，然後團隊校準。例如：
   • 「推薦好友送空間」：Impact 9 × Confidence 7 × Ease 8 = 504 → 優先執行
   • 「改善上傳速度」：Impact 6 × Confidence 8 × Ease 3 = 144 → 排後面
   • 「社群媒體分享按鈕」：Impact 4 × Confidence 3 × Ease 9 = 108 → 暫時不做
3. Top 3 進入執行：每週只跑 ICE 分數最高的 3 個實驗
4. 結果回饋：實驗結果回頭更新 Confidence 分數，讓團隊的預測能力持續校準

結果：「推薦好友送空間」成為 Dropbox 歷史上最成功的成長策略，用戶從 10 萬成長到 400 萬只花了 15 個月，而這個方案在 ICE 評分中就排名第一。

使用步驟

Step 1：列出所有候選項目

把 backlog、實驗清單、功能請求全部攤開。不要先過濾，先確保所有選項都在桌上。建議用 spreadsheet 或 Notion database。

Step 2：獨立評分

讓每個團隊成員獨立對每個項目的 I、C、E 各打 1-10 分。獨立打分是關鍵——先討論再打分會被最大聲的人主導。

Step 3：校準會議

把所有人的分數攤開，找出差異最大的項目（例如 A 給 Impact 9 分、B 給 3 分）。針對這些項目討論——差異背後通常是資訊落差或假設不同。

Step 4：計算排序

I × C × E 算出總分，由高到低排序。畫一條線——線以上的進入本週期的執行計畫，線以下的留在 backlog。

Step 5：執行後校準

每個項目完成後，比較「預期 Impact」和「實際 Impact」。如果團隊持續高估或低估某個維度，調整評分的校準基準。

這樣做 vs 避免這些

這樣做

• 定義團隊自己的 1-10 分量表——「7 分的 Impact 到底是什麼意思」需要團隊共識
• 每季回顧一次 ICE 的預測準確度，校準團隊的評分直覺
• 把 Confidence 當成最重要的維度——Impact 高但 Confidence 低的項目，應該先跑小實驗驗證
• 搭配 timeboxing 使用——ICE 評分本身不該花超過 1 小時，花太久就失去它「快速」的意義

避免這些

• 不要把 ICE 當成唯一的決策依據——它是排序工具不是決策工具，策略對齊、技術債、合規需求等都不在 ICE 的框架裡
• 不要讓一個人獨自打分——個人偏見會讓 ICE 變成「幫自己想做的事找理由」的工具
• 不要用小數點——1-10 的整數就夠了，打 7.3 分和 7.5 分的差別是假精確
• 不要忽略低分項目的戰略價值——有些基礎建設（如監控、CI/CD）ICE 分數很低但不做會出事