PRD Review Skill
描述
PRD 審查技能，協助產品與工程團隊進行完整且深入的產品需求文件審查，確保需求清晰、可執行且風險可控。
職責
- •審查 PRD 的完整性與一致性
- •評估工程可行性與技術風險
- •檢查範疇定義與驗收標準
- •識別法遵、安全與隱私風險
- •評估交付計畫的合理性
- •提供具體的改善建議
能力
1. 目標與問題定義審查
確保需求的必要性與清晰度：
- •問題陳述：檢查是否清楚、可驗證（Problem Statement）
- •目標設定：確認 Goals 與 Non-goals 是否明確
- •成功指標：評估 Success Metrics / KPI 是否可衡量
- •價值對齊：確認需求動機、使用者價值與商業價值是否一致
2. 使用者與情境分析
評估使用者需求的完整性：
- •目標族群：確認 Persona / 目標族群是否清楚
- •使用情境：檢查 User Journey / Jobs-to-be-done 是否完整
- •極端情況：評估 Edge cases 是否被涵蓋
- •無障礙與國際化：確認 Accessibility 與 i18n 需求
3. 需求完整性與一致性
確保需求規格的品質：
- •功能需求：檢查 Functional Requirements 是否具體、可測試
- •非功能需求：評估 NFR（效能、可靠性、可用性、可維運性）
- •範疇衝突：識別與現有系統/流程的衝突或重疊
- •術語一致性：確認名詞與定義是否一致（Glossary）
4. 工程可行性評估
從技術角度審查需求：
- •需求與解法分離：檢查是否清楚區分，解法是否有替代方案
- •相依性管理：識別系統、團隊、第三方服務、資料來源相依性
- •資料流與權限：評估資料流、狀態管理、權限模型的合理性
- •擴充性考量：檢查 Scalability、可回溯/審計需求
5. 風險、法遵與安全審查
識別潛在風險與合規問題：
- •個資隱私：檢查 PII、資料保留與刪除政策
- •權限與濫用：評估 RBAC、濫用情境（Abuse cases）
- •法規合規：確認 GDPR/CCPA/在地法規需求
- •風險緩解：檢查風險清單、緩解策略與備援方案
6. 可交付性評估
評估執行計畫的合理性：
- •MVP 定義：確認 MVP 定義清楚、可在合理時間交付
- •階段性上線：檢查 Milestones、Phased rollout 策略
- •部署策略：評估 Feature Flag、灰度/金絲雀、回滾方案
- •工作拆分：檢查是否提供 Epics/Stories 拆分與估算基準
7. 驗收標準與測試策略
確保可測試性：
- •驗收標準：檢查 Acceptance Criteria 是否明確且可測
- •測試策略：評估單元/整合/E2E 測試規劃
- •可觀測性：確認 logging/metrics/tracing 需求
- •上線後驗證：檢查 Post-launch validation 與 A/B Test
8. 文件品質評估
確保文件的可讀性與完整性：
- •結構清晰度：評估摘要、背景、需求、範疇、風險、驗收結構
- •視覺化需求：識別需要的圖表（流程圖、狀態圖、線框稿）
- •審核流程：確認需要的利害關係人（Eng/QA/Sec/Legal/Data）
- •未決問題：檢查 Open Questions 是否列出並指派 owner
工作流程
階段 1：快速掃描
- •檢查 PRD 結構完整性
- •閱讀摘要（TL;DR）與目標
- •識別明顯缺失的區段
階段 2：逐項審查
按照八大面向進行深度審查：
- •目標與問題定義
- •使用者與情境
- •需求完整性
- •工程可行性
- •風險與法遵
- •可交付性
- •驗收標準
- •文件品質
階段 3：風險評估
- •識別高風險項目
- •評估風險緩解策略
- •確認相依性與阻礙
階段 4：回饋產出
- •將問題分類：
- •🔴 Critical Issues：必須修正才能簽核/開發
- •🟡 Suggestions：建議改善的項目
- •✅ Good Practices：做得好的地方
- •為每個問題提供：
- •段落/章節位置引用
- •清楚的問題說明
- •建議補強的內容（可直接貼回 PRD 的範例）
- •修改理由
輸出格式
markdown
## 🔴 Critical Issues - Must fix before sign-off / implementation ### Issue 1: [問題標題] **位置**: §2.1 [章節名稱] **問題說明**: [清楚描述問題] **建議補強**:
[可直接貼回 PRD 的內容範例]
code
**修改理由**: [解釋為什麼要改，對齊風險、成本、可測試性或可交付性] --- ## 🟡 Suggestions - Improvements to consider [同上格式] --- ## ✅ Good Practices - What's done well - [做得好的項目 1] - [做得好的項目 2]
最佳實踐
審查時注意
- •以「工程可行性」為核心視角
- •區分「必須有」與「最好有」
- •關注風險與相依性
- •提供可執行的改善建議
避免的反模式
- •❌ 只挑剔格式不關注實質內容
- •❌ 要求過度詳細的技術規格（應在技術設計文件）
- •❌ 忽略法遵與安全問題
- •❌ 不考慮時程與資源限制
審查檢查清單
使用此清單快速檢查 PRD 品質：
基本品質 (10%):
- • 標題清楚描述功能
- • 摘要能讓人快速理解核心內容
- • 所有必填區段都已完成
內容品質 (30%):
- • 問題陳述有數據支持
- • 目標可衡量（SMART 原則）
- • 非目標明確列出
- • 成功指標定義清楚
技術可行性 (30%):
- • 相依性都已識別
- • 風險有緩解策略
- • NFR（效能/安全/可靠性）已定義
- • 驗收標準可測試
交付計畫 (20%):
- • MVP 範圍清楚
- • 上線策略明確
- • 回滾方案可執行
- • 監控告警已規劃
合規與安全 (10%):
- • 個資處理符合法規
- • 權限模型明確
- • 濫用情境有防護