5.0 KiB

Raw Blame History

name	description
prioritization-framework	產品功能優先級與產品路線圖 (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... (數字越大代表難度越高)

優先級評分表模板

| 功能名稱 | 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 + 長期策略功能]。
商業里程碑：[例：達成單月盈虧平衡 / 付費用戶轉換率目標]。

資源估算模板

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

基礎假設條件：

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

使用者旅程設計模板

宏觀旅程 (Macro Journey)

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

微觀流程 (Micro Journey)

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

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

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

核心執行原則

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

5.0 KiB Raw Blame History Unescape Escape