enterprise-prd-writerlisted

# 企業 PRD Writer — 施工藍圖等級的產品需求文件 ## 1. 核心定位 一份好的 PRD 不是單純的「想法整理」，也不是 PM 的個人思考筆記。 它應該是一份可供跨職能團隊共同使用的產品施工藍圖，用來明確定義： - 要解決什麼問題 - 為誰解決 - 系統必須呈現什麼行為 - 哪些商業規則不可被誤解 - 哪些異常與邊界情境必須處理 - 哪些內容本期明確不做 - 哪些地方仍是假設、待確認或需技術評估 - 如何驗收、如何監控、如何上線、如何回退 ### 完成標準 PRD 的完成，不以字數、頁數或圖表數量判斷，而以以下結果判斷： 1. 工程師可理解產品行為與商業規則，不需反覆追問本應由產品定義的內容。 2. QA 可根據文件直接拆出主要測試案例與邊界案例。 3. 設計師可理解各畫面、狀態、跳轉與例外情境。 4. 利害關係人清楚知道本期做什麼、不做什麼。 5. UAT 不應因需求語意模糊而出現大量「我以為」。 6. 所有不確定內容均被標記為 Assumption、Open Question 或 Pending Decision，而不是被 AI 擅自補成既定事實。 --- ## 2. 角色邊界 PRD 應明確區分產品需求、產品建議與技術決策，避免 PM 越界指定技術實作，也避免工程團隊誤解哪些行為不可變更。 | 類型 | 定義 | 是否可由工程團隊調整 | |------|------|----------------------| | **Product Requirement** | 必須滿足的產品行為、商業規則、使用者結果、法規要求或 SLA | 不可直接變更，需與 Product 確認 | | **UX Requirement** | 互動流程、資訊架構、提示方式與可用性要求 | 可在不影響目標與 AC 的前提下討論 | | **Product Recommendation** | PM 對實作或流程的建議，不是強制技術方案 | 可由 Design / Engineering 提出替代方�� | | **Technical Decision** | 架構、資料結構、重試演算法、Queue、Cache、服務拆分等技術設計 | 由 Engineering 在 TDD / ADR 中決定 | | **Operational Requirement** | 後台操作、客服處理、稽核、人工介入與異常處置流程 | 需由 Product、Ops、Engineering 共同確認 | ### 強制原則 - 不應將技術建議寫成不可變更的產品要求。 - 不應要求 PRD 取代 Technical Design Document。 - 若某個技術細節會直接影響 SLA、合規、資金安全或使用者體驗，則可列入 PRD，但需說明其產品理由。 - Engineering 對技術可行性、效能、架構與最終技術複雜度擁有最終評估權。 --- ## 3. 文件結構 ### 3.0 輕量模式（小案子的降級路徑） **觸發條件（符合任一即啟用）：** 個人專案、單一功能、無合規/金流/風控需求、單人或單團隊開發。 輕量模式下**只產出以下章節**，其餘章節整份標記 `N/A（輕量模式略過）`，不強制填寫： - §5 Executive Summary（可壓縮成 3–5 句） - §9 Scope（In / Out of Scope） - §13 Functional Requirements - §14 Acceptance Criteri