📚 课程目录第1章需求采集矩阵建立

1. 需求采集矩阵建立

适用场景

需求采集矩阵适用于以下场景：

项目启动初期，跨团队干系人分散、需求来源不确定时，用于系统性收集所有潜在需求。
大型产品大版本规划、跨部门联合发布时，需要对齐各团队的需求反馈渠道与时间节奏。
从零搭建或重构需求管理体系时，用于统一需求入口、避免需求在群聊或邮件中丢失。
组织级需求治理评审与定期复盘活动，需要一份完整的需求来源清单作为依据。

前置条件

已确定产品/项目的核心业务目标与主要干系人清单。
已明确各团队的需求对接人（至少一名需求窗口负责人）。
已有统一的协同工具（如 JIRA、飞书多维表格、Notion、Confluence 或自建平台），用于承载后续需求记录与流转。
团队已约定需求描述的基本格式（标题、背景、期望效果、优先级等），并形成最小共识。

操作步骤

以下为“四步构建需求采集矩阵”的核心流程，每个步骤都须落实到特定责任人：

步骤	责任人	操作内容	要点
1. 分类需求来源	产品负责人 + 项目管理	梳理所有可能产生需求的渠道（如客户侧、运营侧、技术侧、合规侧、竞品分析、用户调研等），分别贴标签归类。	每个来源需注明团队/系统名称、对接窗口角色。
2. 设计采集模板	产品负责人或业务分析	基于需求类型设计标准化表格/表单模板，包含必填字段（需求标题、来源分类、提出人、提出日期、期望价值、接受标准初版）。	模板须与协同工具字段结构一致，避免后续重复人工整理。
3. 分配责任人	项目经理 / 需求治理组	为每个需求来源渠道指定明确的采集责任人（通常为渠道的团队接口人），并同步采集周期、更新频率与异常上报路径。	同一责任人可负责多个同质来源，但必须保证响应时效。
4. 输出《需求采集清单》	需求管理员 / 跨团队协调人	将采集到的原始需求填写至矩阵，并按优先级、来源、团队归属做初步排序与去重，生成可做评审依据的正式清单。	保留最原始提交时间戳与责任人标签，供后续追溯。清单应包含去重检查和备注栏。

提示： 如果团队刚接触矩阵采集，建议从“客户反馈 + 运营需求 + 技术债务”三类核心来源开始，后续再扩展至竞品与合规。

输入 & 输出物

类型	物名	描述
输入	干系人清单	来自项目章程或组织架构名单，包含各团队窗口人姓名、角色与联系方式。
输入	业务目标与用户故事地图（初版）	为需求价值判断提供业务上下文和优先级锚点。
输出	《需求采集清单》	一份结构化表格（可为协同工具里的看板/表格视图），字段：编号、需求标题、来源分类、提出方、提出日期、责任人、优先级初筛、备注状态。

责任边界

需求提出者（发起人）：保证需求原始描述的完整性，配合提供必要背景数据。
渠道责任人（采集人）：负责按采集周期整理本渠道原始需求，填入矩阵，确保不遗漏。
产品负责人（矩阵持有者）：维护矩阵结构定义，对来源分类的变更负责，定期发布清单版本。
项目管理 / 需求治理组：监控采集覆盖率与时效性，对跨团队协作瓶颈进行上报与协调。

记录材料

本章节需保留如下记录：

需求来源分类映射表（来源编码 + 上下级分类 + 所属团队）
采集模板字段说明文档（字段名、数据类型、必填规则、示例值）
《需求采集清单》基线版本（首次完成全部来源填充后的快照，可归档用于评审）
责任人确认记录（邮件/即时消息/工单确认截图，建议同步至项目共享空间）

异常处理

异常场景	应对措施
某一来源渠道长期零更新	追溯责任人是否缺位或不了解采集机制；成立专项对齐会，确认该渠道是否失效或需变更分类。
同一需求从多个渠道重复提交	在清单备注栏标注“重复来源/已去重”，并将原始条目标记关联，合并时保留最早提出时间。
需求模板字段与协同工具字段不匹配	停止人工转录，立即调整采集模板与工具字段映射；输出字段对齐配置文件（JSON）作为技术记录。
跨团队责任人变更或离职	更新责任人清单并重新培训模板填写规则，必要时由项目经理承担三天过渡期采集任务。

验收标准

《需求采集清单》字段完整，已覆盖所有预定来源分类字段（来源、提出方、提出日、责任人等），无缺失列。
每个来源分类至少有 1 条及以上原始需求记录（若某分类确实无需求，须在备注栏注明原因与确认人）。
清单第一条记录的时间戳为采集矩阵确立之日，最后一条记录不晚于评审会议前 1 个工作日。
所有渠道责任人已在清单中确认签字或系统留痕（如 JIRA 工单的分配记录）。
采集模板与协同工具字段映射配置已形成快照文档，可供任何人直接复用。

核心流程结构图