拆分需求
一句話定義
在 PRD 撰寫之前的 Discovery 階段起手式——把模糊的大需求切成「獨立、可估、有價值」的小顆粒；核心二分為水平 vs 垂直，搭配 8 種策略 + INVEST原則 檢驗清單；不是 PM 一個人的事，而是 PM + PD + RD 跨職能合作的成果。
核心要點
為什麼拆？拆得不好 → 交付延期 → 後續排程連動崩盤
「進入開發的功能比原先預期的還要花費更多的時間或是影響範圍更大，導致交付延期，壓縮到其他功能或項目開發的時間。」（盈秀）
關鍵診斷：看似 Delivery階段 出問題，實則 Discovery階段 對需求判斷失準。拆分需求是 Discovery 階段的起手式——UX Designer / Product Designer 通常是 Discovery 階段的主負責人。
提早拆分的三個收益：
- 提高團隊對下一步的共識
- 風險掌握更精準
- 顆粒度更精準
水平拆分 vs 垂直拆分（核心二分）
蛋糕比喻：產品分層（介面元件 / 體驗流程 / 前端元件 / 資料庫…）
| 拆法 | 定義 | 優點 | 缺點 / 風險 |
|---|---|---|---|
| 水平拆分 | 同一層該做的事分一起（例：「全 App 介面更新」） | 同職能集中執行 | (1) 影響範圍無限延伸——小更新爆炸成大工程 / (2) 缺少跨職能合作——後期才發現缺 API 或缺資料 / (3) 價值難以量化——優化型工作優先級難排 |
| 垂直拆分 | 每個顆粒含設計/前端/後端各層（情境或流程為單位） | (a) 每顆粒獨立可運行 / (b) 達成 MVP 概念 / (c) 跨職能投入評估時程與可行性 | — |
拆分時機（兩個時間點）
| 時點 | 對接對象 | 目的 |
|---|---|---|
| 需求剛被提出時 | 主要與 PM 合作 | 協助 PM 評估優先級 |
| 準備進入規劃前 | 主要與 RD 合作 | 確認可行性 + 估時程 |
拆分與排序是兩個相鄰動作
拆分需求 先把模糊需求切成可估、可談、可測的顆粒；產品優先級 再把這些顆粒放進商業價值、使用者價值、策略影響、信心與複雜度等維度中比較。
→ 若需求沒有先拆，prioritization 會拿「大包需求」互比，估時與價值都不準；若拆完沒有排序，團隊只是得到更多待辦，沒有得到決策。
8 種拆分策略
多數情境會多策略合併使用，不是互斥選擇。以下範例多以 點點簽 為錨點。
| # | 策略 | 適用情境 | 範例 |
|---|---|---|---|
| 1 | 依使用情境 | 需求含多個使用情境 | 簽署任務有「有序 / 無序」→ 拆 4 個獨立顆粒 |
| 2 | 依 Happy / Unhappy Case | 需求有正常與異常路徑 | OTP 驗證：Happy + 3 種 Unhappy；可決定哪些 Unhappy 不必實作 |
| 3 | 依平台 / 裝置 | 跨平台 App / 響應式 Web | 複雜建單流程先不上 Mobile Web；前提：先評估「大多數使用者在不同裝置會做什麼」 |
| 4 | 依參數 / 資料 | 多種資料類型作為選項 | 雲端硬碟搜尋的篩選條件——先實作常用必要 |
| 5 | 依操作功能（CRUD） | 同功能不同操作有不同情境 | 印鑑管理稽核——刪除 / 編輯有特殊條件，分開處理 |
| 6 | 依使用者角色 | B2B 產品多角色（管理者 / 成員） | 標籤管理：團隊共用標籤 vs 個人標籤——客戶不需要時，個人標籤優先級下調 |
| 7 | 依緊急程度 | 使用者是否會因此無法繼續使用 | 夾檔解析度壓縮——拆兩個成因（轉檔 / 合併）+ 兩個解法；測後選短解先做 |
| 8 | 其他 | 視場景組合 | 實作難度 / 外部系統整合 / SEO 需求 / 營收多寡 / Test Cases / 易用性 |
跨職能合作（誰負責拆？）
「PM 不能把需求拆乾淨再給我嗎？」「雖然我沒這麼做過，但聽起來好像不錯？」
作者結論：拆分需求是跨職能任務——
| 角色 | 熟悉的維度 |
|---|---|
| PM | 風險、市場、商業價值 |
| PD（Product Designer） | 產品架構、體驗流程 |
| RD | 系統架構、可行性 |
→ 「與其坐等 PM 拆出完美的需求，不如加入他一起拆！」
大流程先共識，細節按風險補齊
2026-05-07-Jayden-Lin-Agile增量需求溝通 補上拆分需求進入敏捷迭代前的溝通層：PM 不必一次把所有細節補完，但也不能只用「增量」當作少給脈絡的理由。
文章把 User Story Mapping / Event Storming 的共同精神壓成一個節奏：
- 先把大流程、使用者活動或要完成的里程碑拉出來。
- 讓團隊知道本輪要形成哪個 敏捷增量。
- 針對工程師有疑慮、可能影響架構 / 資料 / 估時的部分補上細節。
- 其餘細節按風險與交付順序逐步補齊。
這把「拆分需求」從顆粒切法往前推到資訊揭露策略：好的 PM 不是一次講完全部，也不是擠牙膏，而是先給足能讓團隊判斷方向的上層地圖，再把不確定性最大的地方說清楚。
INVEST 檢驗（拆得好不好的標尺）
詳見 INVEST原則。Bill Wake（2003）提出的 6 條 User Story 品質準則：
- Independent — 獨立的
- Negotiable — 可協商的
- Valuable — 有價值的
- Estimable — 可估算的
- Small — 小的（盈秀 經驗：以團隊幾個 Sprint 內可完成為參考）
- Testable — 可測量的
不限敏捷環境——任何形式的需求拆分都可用此清單檢驗。
與其他概念的關係
- 與 PRD：拆分需求是 PRD 撰寫之前的需求釐清階段——盈秀 撰 PRD 時的「使用情境」段落直接套用「依使用情境拆分」的結果（定義每個流程「起點 / 終點」）。對位：Tom-Liou PRD 七部曲是文檔交付結構 / 拆分需求是 Discovery 階段方法論——兩者構成 AAPD 系列「Discovery → 文檔」的完整工作流
- 與 INVEST原則：拆分需求是「怎麼拆」的方法論 / INVEST 原則是「拆得好不好」的檢驗清單——前者操作、後者驗收
- 與 敏捷增量：拆分需求把需求切成可操作顆粒；敏捷增量把多個顆粒整合成一輪可用軟體，兩者共同決定 delivery 是否真能短週期運作。
- 與 產品優先級：拆分需求產生可比較的顆粒；產品優先級決定這些顆粒的先後順序。兩者合起來才是「需求進開發前」的完整決策鏈。
- 與 Goal-Signal-Metric：兩者都是結構化檢驗框架，但維度不同——G-S-M 是指標的「由大到小」拆解（樹幹 → 樹枝 → 樹葉）；拆分需求是功能的「由大到小」拆解（大需求 → 顆粒）
- 與 專案管理 對位：兩者都是 「預防勝於治療」 在不同階段的具體實踐——
- 拆分需求 = Discovery 階段預防（事前釐清需求顆粒，避免進開發後爆炸）
- 專案管理 = Delivery 階段預防（事前確認時程 / feedback 預留 / 利害關係人，避免執行中失控）
- 同源精神：把延遲、犯錯、變數扼殺在發生之前
- 與 使用者研究 / 人物誌：拆分需求的「依使用者角色拆分」（策略 6）需要 Persona 已建立 才有意義——B2B 多角色產品尤其依賴
- 與 時間箱 對位（個人 vs 團隊）：時間箱 = 個人版本的「拆任務 + 排時段」/ 拆分需求 = 團隊版本的「拆需求 + 排優先級」——共享「先把大塊變小塊才能管理」的精神
- 與 微任務 對位：微任務 = 個人任務的空間拆解 / 拆分需求 = 團隊需求的空間拆解（功能維度）+ 時間拆解（優先級維度）—— 同源不同尺度
- 與 12個問題法則 對位：兩者都是結構化的篩選機制——12 問是個人 PKM 的資訊篩選器 / 拆分需求是團隊產品的需求篩選器
- 與 檢核提案的-10-個問題 對位：兩者都是事前 check 文化的具體實踐——10 問是創意提案的事前自檢 / 拆分需求是需求進入開發前的事前自檢
相關來源
- 2026-05-01-盈秀-拆分需求 — 盈秀 / AAPD-As-A-Product-Designer：vault 中第一個明確以 Story Splitting 為主軸的來源；提出水平 vs 垂直二分 + 8 拆分策略 + INVEST 檢驗；同時引介 Discovery vs Delivery 階段觀念
- 2026-05-06-Samuel-B2B產品優先級 — 補入拆分後的 B2B prioritization 層：用商業價值、使用者產品價值、策略影響、信心與複雜度做需求排序。
- 2026-05-07-Jayden-Lin-Agile增量需求溝通 — 補入敏捷增量語境下的需求揭露節奏：大流程 / 里程碑先共識，細節針對團隊不安全感與工程風險補齊。
備註
與 Tom-Liou PRD 指南構成的「AAPD Discovery → 文檔」工作流：盈秀的拆分需求文章 = Discovery 階段（需求釐清 + 顆粒切分）；Tom Liou 的 PRD 指南 = 規格化階段（七部曲文檔結構）。兩者都來自同一個 publication (AAPD-As-A-Product-Designer)，呈現 vault 中第一個「同 publication 不同作者構成完整工作流」的累積範式。
Discovery / Delivery 階段觀念暫不獨立建頁：本來源簡略提及（一句話 caption），尚未深入展開；待累積到 2+ 來源處理此概念時再考慮獨立成頁，目前作為內嵌語境保留在拆分需求頁。
「Story Splitting」國際對位：本文主軸對應英文敏捷社群的 “story splitting” 實踐；Bill Wake 的 INVEST 原則與 Mike Cohn 的 SPIDR / Humanizing Work 的 Hamburger Method 等都是同領域的西方框架。本期僅引入 Bill Wake INVEST 一條；其他框架待未來來源 ingest。
未來累積方向：
- (a) Story Splitting 的西方框架對位（SPIDR / Hamburger Method / Story Mapping）
- (b) 需求排序評量方法深化（RICE / WSJF / ICE / Kano）—— 產品優先級 已建立入口；待各框架主來源補完整公式、適用限制與反例
- (c) Discovery 階段的其他工具（Story Mapping / Event Storming / Job Stories）
- (d) 拆分後的優先級框架（MoSCoW / Eisenhower / Cost of Delay）
- (e) 反向案例：拆得太細的問題（fragmentation cost / coordination overhead）