PRD Writer Skill
描述
PRD 撰寫技能,協助產品與工程團隊撰寫完整、結構化且可落地執行的產品需求文件,確保需求清晰、可測試且可交付。
職責
- •引導完成 PRD 結構與內容
- •確保需求的完整性與可測試性
- •協助定義清晰的範疇（Scope）與非範疇（Out-of-scope）
- •識別風險並提供緩解策略
- •提供 PRD 模板與範例
- •進行 PRD 品質自我檢查
能力
1. PRD 結構引導
協助建立完整的 PRD 結構：
- •基本資訊：標題、狀態、作者、最後更新、相關連結
- •摘要（TL;DR）：一句話描述、關鍵資訊
- •目標與問題定義：Problem Statement、Goals、Non-goals、Success Metrics
- •使用者與情境：Personas、User Journey、Edge Cases
- •需求規格：功能需求（FR）、非功能需求（NFR）
- •解法與架構：系統架構、資料模型、相依性
- •風險與法遵：風險清單、個資隱私、法規合規、濫用情境
- •交付計畫：MVP 定義、上線策略、回滾方案
- •驗收標準：Acceptance Criteria、測試策略、監控告警
- •附錄：術語表、未決問題、變更歷史
2. 需求撰寫原則指導
確保需求品質：
- •Why before What：先解釋「為什麼要做」，再說明「做什麼」
- •Testable：所有需求都應可測試、可驗證
- •Scoped：清楚定義範圍內/外（In-scope / Out-of-scope）
- •Risk-aware：識別風險並提供緩解策略
- •Deliverable：可在合理時間內交付，支援分階段上線
3. 功能需求撰寫
協助撰寫具體的功能需求：
- •描述：清楚說明功能做什麼
- •觸發條件：何時/如何觸發
- •輸入：需要哪些輸入參數/資料
- •輸出：產生什麼結果/狀態變化
- •驗收標準：可測試的標準（Given-When-Then 格式）
4. 非功能需求撰寫
協助定義 NFR：
- •效能：回應時間、吞吐量、資料量
- •可靠性：可用性、錯誤率、資料一致性
- •可擴展性：橫向擴展、負載預估
- •安全性：認證/授權、資料加密、稽核日誌
- •可觀測性：日誌、指標、追蹤、告警
- •可維運性：部署方式、回滾策略、資料遷移
5. 風險識別與緩解
協助識別並管理風險：
- •風險清單：識別潛在風險（技術、業務、法遵）
- •嚴重性評估：評估風險的嚴重性與機率
- •緩解策略：提供具體的緩解方案
- •備援計畫：規劃 Fallback/Rollback 方案
6. 交付計畫撰寫
協助規劃可執行的交付計畫：
- •MVP 定義：清楚定義最小可行產品範圍
- •里程碑規劃：設定階段性目標
- •上線策略：Feature Flag、灰度發佈、金絲雀部署
- •回滾方案：定義回滾觸發條件與步驟
7. 驗收標準撰寫
協助撰寫可測試的驗收標準：
- •功能驗收：使用 Given-When-Then 格式
- •非功能驗收：定義效能、安全、可靠性標準
- •測試策略：規劃單元、整合、E2E 測試
- •監控告警：定義關鍵指標與告警規則
8. PRD 品質檢查
提供自我檢查清單：
- •基本品質：標題、摘要、必填區段
- •內容品質：問題陳述、目標、成功指標
- •技術可行性：相依性、風險、NFR、驗收標準
- •交付計畫：MVP、上線策略、回滾方案、監控
- •合規與安全：個資、權限、法規、濫用情境
工作流程
階段 1：需求收集
- •與使用者確認問題陳述
- •識別目標使用者（Persona）
- •釐清核心目標與成功指標
- •定義範疇（In-scope / Out-of-scope）
階段 2：PRD 框架建立
- •複製 PRD 模板
- •填寫基本資訊與摘要
- •完成目標與問題定義區段
- •撰寫使用者與情境
階段 3：需求規格撰寫
- •撰寫功能需求（FR）
- •定義非功能需求（NFR）
- •提供參考解法（選填）
- •識別相依性
階段 4：風險與交付規劃
- •建立風險清單與緩解策略
- •檢查法遵與安全需求
- •定義 MVP 與交付計畫
- •撰寫驗收標準與測試策略
階段 5：審查與迭代
- •執行品質自我檢查
- •與工程團隊 review 可行性
- •根據回饋更新 PRD
- •確認所有未決問題都已處理
PRD 模板結構
markdown
# [功能名稱] PRD **文件狀態**: Draft | In Review | Approved | Implemented **作者**: [姓名] **最後更新**: YYYY-MM-DD **相關連結**: [Jira/GitHub Issue] | [設計稿] | [技術規格] --- ## 📋 摘要 (TL;DR) **一句話描述**: [功能做什麼、為誰解決什麼問題] **關鍵資訊**: - **目標使用者**: [Persona] - **主要價值**: [解決的核心問題] - **預計交付**: [時間/里程碑] - **核心指標**: [1-2 個關鍵成功指標] --- ## 🎯 1. 目標與問題定義 ### 1.1 問題陳述 [具體描述問題，附上數據或案例] ### 1.2 目標 **核心目標**: 1. [可衡量的目標 1] ### 1.3 非目標 - ❌ [不做的功能 1] ### 1.4 成功指標 - [指標]: [目標值] --- ## 👥 2. 使用者與情境 ### 2.1 目標族群 [Persona 描述] ### 2.2 使用情境 [User Journey 步驟] ### 2.3 例外處理 [Edge Cases] --- ## 📦 3. 需求規格 ### 3.1 功能需求 #### FR1: [功能名稱] **描述**: [功能做什麼] **驗收標準**: - [ ] [Given...When...Then] ### 3.2 非功能需求 #### 效能 - **回應時間**: [目標值] #### 安全性 - **認證/授權**: [權限模型] --- ## ⚠️ 5. 風險、法遵與安全 ### 5.1 風險清單 | 風險 | 嚴重性 | 緩解策略 | |------|--------|----------| | [風險 1] | High | [策略] | ### 5.2 個資與隱私 - **個資類型**: [收集哪些] - **使用目的**: [為何需要] --- ## 🚀 6. 交付計畫 ### 6.1 MVP 定義 **Phase 1 (MVP)**: - ✅ [核心功能 1] ### 6.2 上線策略 - **灰度發佈**: [比例與時程] - **Feature Flag**: [Flag 名稱] - **回滾方案**: [觸發條件與步驟] --- ## ✅ 7. 驗收標準與測試策略 ### 7.1 驗收標準 - [ ] [Given...When...Then] ### 7.2 測試策略 - **單元測試**: [覆蓋率目標] - **整合測試**: [測試範圍] ### 7.3 監控與告警 - `metric.name`: [描述] --- ## 📄 8. 附錄 ### 8.1 術語表 | 術語 | 定義 | |------|------| | [Term] | [定義] | ### 8.2 未決問題 - [ ] **Q1**: [問題] - Owner: [@person] ### 8.3 變更歷史 | 日期 | 版本 | 變更內容 | |------|------|----------| | YYYY-MM-DD | v0.1 | 初稿 |
最佳實踐
撰寫時注意
- •使用清晰、具體的語言
- •提供數據支持問題陳述
- •區分需求與解法
- •使用可測試的驗收標準
- •考慮風險與相依性
避免的反模式
- •❌ 混淆「需求」與「解法」
- •❌ 使用模糊詞彙（「盡可能」、「更好」、「優化」）
- •❌ 缺少成功指標或驗收標準
- •❌ 忽略 Edge Cases、錯誤處理、權限管理
- •❌ 未考慮相依性與整合點
品質檢查清單
撰寫完成後自我檢查：
基本品質 (必須):
- • 標題清楚描述功能
- • 摘要能讓人快速理解
- • 所有必填區段都已完成
內容品質 (必須):
- • 問題陳述有數據支持
- • 目標可衡量（SMART）
- • 非目標明確列出
- • 成功指標定義清楚
技術可行性 (必須):
- • 相依性都已識別
- • 風險有緩解策略
- • NFR 已定義
- • 驗收標準可測試
交付計畫 (必須):
- • MVP 範圍清楚
- • 上線策略明確
- • 回滾方案可執行
- • 監控告警已規劃
合規與安全 (必須):
- • 個資處理符合法規
- • 權限模型明確
- • 濫用情境有防護