4. 需求整理与分类
用户访谈结束后，产品团队往往面对大量零散、颗粒度不一的原始需求。如果没有系统的整理与分类流程，这些需求将难以形成可执行的开发输入。本章聚焦需求拆解阶段的核心产出物——用户故事地图、需求卡片与优先级矩阵，三者构成从“原始需求”到“排序后需求列表”的完整转化链。
4.1 用户故事地图：构建需求全景
用户故事地图（User Story Map）由 Jeff Patton 提出，核心价值在于将用户旅程与需求优先级可视化为一张二维地图。X 轴按时间顺序排列用户操作步骤（即骨架 Backbone），Y 轴从上到下按重要性递减排列每个步骤对应的用户故事。
| 维度 | 定义 | 产出物示例 |
|---|---|---|
| 骨架（Backbone） | 用户完成目标所需的关键活动，按时间顺序排列 | 登录 → 选择导入方式 → 上传文件 → 校验数据 → 确认导入 |
| 行走的骨架（Walking Skeleton） | Y 轴顶部优先级最高的故事集合，构成第一个可发布版本 | 邮箱登录 + 选择批量导入 + 上传 CSV + 格式校验 + 导入结果 |
| 用户故事（User Story） | 具体功能描述，格式：As a… / I want… / So that… | 作为销售运营，我希望通过 Excel 导入客户名单，以减少手动录入时间 |
4.2 需求卡片：结构化需求描述
每张用户故事需要转化为结构化的需求卡片（Requirement Card），作为后续评审、排期、开发的唯一信息载体。需求卡片必须包含清晰的定义字段与验收条件，避免歧义。
| 字段 | 类型 | 说明 | 示例值 |
|---|---|---|---|
| cardId | 唯一标识 | 需求编号，用于追溯 | REQ-2024-001 |
| title | 短文本 | 需求名称，动宾结构 | 批量导入客户名单 |
| description | 用户故事 | As a… / I want… / So that… | 作为销售运营，我希望通过 Excel 批量导入客户名单，以减少手动录入时间 |
| priority | 枚举 | P0–P3，P0 为最高 | P0 |
| status | 枚举 | 已创建 / 已评审 / 已排期 / 开发中 / 已验收 | 已评审 |
| source | 文本 | 需求来源，可追溯至访谈记录 | 销售运营团队访谈（2024-06-10） |
| acceptanceCriteria | 列表 | 可验证的验收条件 | 支持 .xlsx 和 .csv 格式；最大 10000 条；自动校验；返回导入报告 |
需求卡片的标准 JSON 模板如下，建议直接纳入团队 Wiki 或需求管理系统：
{
"cardId": "REQ-2024-001",
"title": "批量导入客户名单",
"description": "作为销售运营，我希望通过 Excel 批量导入客户名单，以减少手动录入时间",
"priority": "P0",
"status": "已评审",
"source": "销售运营团队访谈（2024-06-10）",
"acceptanceCriteria": [
"支持 .xlsx 和 .csv 格式",
"最大支持 10000 条记录",
"导入后自动校验数据格式（手机号、邮箱必填）",
"返回导入结果报告（成功条数、失败原因）"
]
}4.3 优先级矩阵：科学排序决策
当需求卡片积累到 20–50 张时，必须通过优先级矩阵进行排序决策。最常用的方法是 MoSCoW 分类法与价值 — 成本四象限。
| 分类 | 含义 | 决策标准 | 典型示例 |
|---|---|---|---|
| Must have | 必须实现，否则产品不可用 | 无此功能则核心流程断裂 | 登录、文件上传、格式校验 |
| Should have | 应该实现，但可延迟到下一版本 | 重要但不紧急，有变通方案 | 导入结果邮件通知 |
| Could have | 可以实现，但不影响核心价值 | 锦上添花，资源充裕时做 | 导入进度条动画 |
| Won't have | 本次不实现 | 明确排除，避免范围蔓延 | 客户数据去重合并 |
价值 — 成本矩阵则从两个维度评估：业务价值（高/低）与实现成本（高/低）。优先推进“高价值 — 低成本”象限的需求，其次处理“高价值 — 高成本”需求，果断抛弃“低价值 — 高成本”需求。
4.4 三阶段协同流程
用户故事地图、需求卡片、优先级矩阵并非孤立产出，而是环环相扣的递进关系：用户故事地图提供全景视角与故事颗粒度，需求卡片将故事结构化为可执行描述，优先级矩阵最终输出排序后的开发列表。下图展示完整的协同流程：
从上图可以看出：原始需求同时流向用户故事地图和需求卡片——前者用于构建用户旅程全景，后者用于结构化描述细节；随后用户故事地图与需求卡片共同输入优先级矩阵进行排序决策；最终输出排序后的需求列表，直接指导版本规划与开发排期。
4.5 交付物模板与验收标准
本章对应的核心交付物包括三类文档模板。下表列出每类交付物的验收标准：
| 交付物 | 格式 | 验收标准 |
|---|---|---|
| 用户故事地图 | Miro / Confluence 看板 | 包含 1 条完整骨架、至少 3 个关键步骤、每个步骤下 ≥2 条用户故事、已标注行走的骨架 |
| 需求卡片集 | JSON / YAML / Wiki 表格 | 每张卡片包含 cardId、title、description（用户故事格式）、priority、status、source、acceptanceCriteria |
| 优先级矩阵 | MoSCoW 表格 或 四象限图 | 所有需求卡片已分类、Must have 占比 ≤20%、分类结果已与核心干系人确认签字 |
4.6 避坑清单
- 用户故事地图变成功能列表：地图必须围绕用户旅程展开，而非罗列功能菜单。如果地图上的故事无法串联成一条完整用户路径，说明视角从“用户”滑向了“系统”。
- 需求卡片颗粒度失控：单张卡片验收条件超过 7 条时，优先拆分为多张子卡片；验收条件少于 3 条时，检查是否描述过粗。
- 优先级矩阵未对齐业务目标：MoSCoW 分类必须与产品阶段目标绑定。例如，MVP 阶段应严格限制 Must have 范围，避免将“Should have”混入首发版本。
- 跳过行走的骨架验证：排序后的需求列表应能拼接为一条可端到端演示的行走的骨架。如果排序结果无法形成最小闭环，说明分类逻辑存在问题。