109 lines
5.0 KiB
Markdown
109 lines
5.0 KiB
Markdown
---
|
||
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 的時程表等同於失敗。
|