---
name: prioritization-framework
description: 產品功能優先級與產品路線圖 (Roadmap) 規劃框架。包含 RICE 評分、MoSCoW 分類、Roadmap 模板、資源估算方法。
---

# 優先級排序框架技能 (Prioritization Framework Skill)

提供產品功能排序與路線圖規劃的標準化框架，確保資源投入在最具價值的項目上。

## RICE 評分法

評分公式：**RICE 分數 = (Reach × Impact × Confidence) / Effort**

| 評估維度 | 說明 | 建議評分範圍 |
|------|------|---------|
| **Reach (觸擊)** | 每月將受此功能影響的用戶數 | 根據現有數據或潛在客群估算實數 |
| **Impact (影響)** | 該功能對單一用戶的價值提升程度 | 3 (極大), 2 (高), 1 (中), 0.5 (小), 0.25 (微) |
| **Confidence (信心)** | 您對上述三項估算的準確度信心百分比 | 100% (極高), 80% (中高), 50% (低) |
| **Effort (投入)** | 實作該功能所需的人月 (Person-months) | 0.5, 1, 2, 3... (數字越大代表難度越高) |

### 優先級評分表模板

```markdown
| 功能名稱 | Reach | Impact | Confidence | Effort | RICE Score | MoSCoW | 預計階段 |
|------|-------|--------|-----------|--------|-----------|--------|-------|
| [功能 A] | 1000 | 2 | 80% | 2 | 800 | Must | MVP |
| [功能 B] | 500 | 1 | 50% | 1 | 250 | Should | Phase 2 |
```

## MoSCoW 分類法

| 分類等級 | 定義 | 典型的判斷準則 |
|------|------|---------|
| **Must Have** (必須) | 沒有此功能產品絕對無法上線 | 滿足核心需求 (JTBD)、法律/合規性必需 |
| **Should Have** (應該) | 重要但短期內延遲上線不會致命 | 顯著提升體驗，但目前尚有替代方案 |
| **Could Have** (可以) | 行有餘力再做，有它更好但非必要 | 錦上添花的小驚喜、細節優化 |
| **Won't Have** (不予) | 本次發布版本明確排除的項目 | 資源不允許、技術風險過高或不符目前定位 |

## 產品路線圖 (Roadmap) 規劃模板

### 三階段發展框架

**第一階段 — MVP (最小可行性產品)**（第 1-3 個月）
- **核心目標**：驗證產品核心假設，獲取首批種子用戶。
- **關鍵功能**：[Must Have 清單]。
- **發展里程碑**：[月 1] 原型開發 → [月 2] 內部測試 → [月 3] Beta 開放。
- **成功指標**：[具體 KPI，例如：留存率 > 40%]。

**第二階段 — 成長期 (Growth)**（第 4-6 個月）
- **核心目標**：優化使用者體驗，擴大用戶規模。
- **關鍵功能**：[Should Have 清單]。
- **成長指標**：[目標數字，例如：月活躍用戶 (MAU) 達到 10,000]。

**第三階段 — 規模化 (Scale)**（第 7-12 個月）
- **核心目標**：商業化探索與系統規模化。
- **關鍵功能**：[Could Have + 長期策略功能]。
- **商業里程碑**：[例：達成單月盈虧平衡 / 付費用戶轉換率目標]。

## 資源估算模板

```markdown
| 發展階段 | 前端工程師 | 後端工程師 | 設計/產品 | 總人月需求 | 預估總時程 |
|-------|------|------|------|--------|---------|
| MVP | 2 人月 | 3 人月 | 1 人月 | 6 人月 | 3 個月 (並行開發) |
```

**基礎假設條件**：
- **團隊規模**：[人數]（預設以 2 名工程師 + 1 名設計師/PM 為基準）。
- **可用工時**：每月 20 個工作天。
- **緩衝 (Buffer)**：建議在所有時程估算中額外保留 20% 的應急緩衝。

## 使用者旅程設計模板

### 宏觀旅程 (Macro Journey)

```markdown
| 旅程階段 | 發現階段 | 評估階段 | 首次使用 | 習慣養成 | 持續留存 |
|------|------|------|---------|---------|---------|
| 用戶行為 | ... | ... | ... | ... | ... |
| 接觸點 | ... | ... | ... | ... | ... |
| 情緒狀況 | 😐 | 😊 | 😤 | 😊 | 😊 |
| 核心痛點 | ⚠️ | | ⚠️ | | |
| 優化機會 | 💡 | | 💡 | 💡 | |
```

### 微觀流程 (Micro Journey)

```markdown
**[功能名稱] 具體使用流程**
- **用戶目標**：[使用者想透過此功能完成什麼？]
- **前置條件**：[在開始此流程前，用戶必須已完成什麼？]

**主要路徑 (Happy Path)**：
1. [步驟一] → [期望的用戶感受]
2. [步驟 B] → [執行結果]
3. [步驟 C] → [達成目標產出]

⚠️ **關鍵阻礙點**：[哪個步驟最容易失敗/放棄] → [原因分析] → [設計端的建議對策]
💡 **設計機會點**：[針對體驗細節的具體優化建議]
```

## 核心執行原則

- **MVP 應聚焦而非縮減**：MVP 的重點在於驗證關鍵路徑，而非「做一個功能簡陋、不能用的完整產品」。
- **工具輔助而非主導**：RICE 評分是為了輔助決策，最終排序應結合市場策略與技術可行性。
- **明確的拒絕**：對於 Won't Have 項目，必須說明排除理由以及「在哪個階段會重新評估」。
- **誠實評估**：情緒曲線必須誠實標示出潛在的低谷（如註冊過程、複雜設定），這些正是最需要優化之處。
- **尊重 Buffer**：任何軟體開發皆存在未知風險，無 Buffer 的時程表等同於失敗。
