第三章 需求收集阶段：渠道来源、原始需求列表、分类标签
需求收集是产品经理从“模糊问题”到“可管理需求列表”的第一步。本章聚焦于如何系统化地获取原始需求，并对其进行初步分类，为后续的RICE优先级评估提供准确的数据基础。
💡 讲师提示：收集阶段的目标不是追求完美质量，而是追求“完整覆盖+源头可追溯”。一个需求如果没有来源标记，RICE评分将失去信任基础。
3.1 需求渠道全景
需求不会自动排队进入你的Jira看板。产品经理需要主动从以下七大典型渠道捕获原始声音：
| 渠道编号 | 渠道名称 | 典型输出形式 | 常见陷阱 |
|---|---|---|---|
| C1 | 用户反馈系统 | 工单、App内评价、邮件 | 单人抱怨被放大为普遍需求 |
| C2 | 客服/CSM记录 | Excel表格、CRM备注 | 丢失关键上下文（用户行为序列） |
| C3 | 数据分析 | 漏斗异常、功能使用率下降 | 数据能指出现象，但无法解释原因 |
| C4 | 竞品监测 | 竞品更新日志、PRD摘要 | 盲目照搬，不匹配自身用户场景 |
| C5 | 内部利益相关者 | 运营需求邮件、销售会议纪要 | 业务方混淆“解决方案”与“问题” |
| C6 | 用户访谈/调研 | 访谈录音稿、问卷开放题 | 样本偏差（只访问了核心用户） |
| C7 | 行业合规/监管 | 政策文件、合规审计报告 | deadline驱动，忽略用户体验 |
✅ 最佳实践：为每个渠道分配一个两位字母前缀（如UF、CS、DA、CM、IS、UI、RG），后续需求编号自动带上前缀，实现“一码溯源”。例如：“UF-20250321-042” 代表来自用户反馈系统、2025年3月21日第42条需求。
3.2 原始需求列表：结构与规范化
原始需求是未经加工的“用户原话”。规范的列表至少包含以下字段：
- 需求编号：渠道前缀+日期+当日流水号
- 渠道来源：C1-C7之一，精确到子来源（如App内“设置页”反馈）
- 提出者/用户ID（脱敏）：可匿名化，但保留角色（普通用户、VIP、运营人员）
- 原始描述：用户原话或转述，不要代入产品经理的翻译
- 提交时间：精确到小时（时区统一为UTC+8）
- 关联场景：用户在什么情境下提出（例如“导出报表时发现缺少字段”、“收到支付失败通知但银行卡已扣款”）
- 紧急程度（提出者视角）：1-5级，非产品经理评估的优先级
⚠️ 常见错误：产品经理在收集阶段就合并相似需求、过滤“不合理”需求。正确的做法是——先收集，后分类，再清洗。合并和过滤应该在分类标签之后进行，否则会遗漏模式。
3.3 分类标签体系：从无序到结构化
分类标签不是最终的用户故事，而是为后续RICE评估建立的检索维度。推荐一个三层分类体系：
建议分类框架（可扩展）：
一级—产品域：（1）用户增长；（2）核心功能；（3）体验优化；（4）数据与报表；（5）技术基建；（6）合规与安全。
二级—功能模块：每个产品域下细分模块，例如“用户增长”下分为“邀请机制”“付费转化”“留存激励”。
三级—需求类型：功能新增 / 功能改进 / 性能优化 / 缺陷修复 / 运营工具 / 数据接入。
一级—产品域：（1）用户增长；（2）核心功能；（3）体验优化；（4）数据与报表；（5）技术基建；（6）合规与安全。
二级—功能模块：每个产品域下细分模块，例如“用户增长”下分为“邀请机制”“付费转化”“留存激励”。
三级—需求类型：功能新增 / 功能改进 / 性能优化 / 缺陷修复 / 运营工具 / 数据接入。
3.4 实践要点：让收集动作可重复、可审计
- 要点一：固定模板降低认知负荷。使用统一的Google Sheet或Airtable模板，包含上文列出的所有字段。团队中所有成员（包括实习生）必须使用相同结构录入，杜绝“我记在邮件里后面补”的做法。
- 要点二：建立渠道质量评分。在原始需求列表中增加一列“渠道可信度”（1-3星），例如：用户访谈录音转录为3星，客服二手转述为1星。该评分将直接带入RICE的“Confidence”因子。
- 要点三：每周做一次“无过滤原始快照”。每周五下班前，冻结当前原始需求列表并导入版本管理（如Git）。这不仅是RICE的历史追溯依据，更能防止后期人为修改需求描述导致的偏差。
3.5 分类标签的常见避坑
| 错误做法 | 后果 | 正确做法 |
|---|---|---|
| 按“重要性”分类（如：P0/P1/P2） | 与RICE的优先级评分重复，造成认知冲突 | 只按业务域和功能模块分类，优先级留给RICE计算 |
| 只给一个一级标签（例如“体验优化”） | 后续分析时无法区分是“加载速度问题”还是“文案不清” | 至少打满一级+二级+需求类型三个标签 |
| 标签体系不可扩展 | 新业务域出现时，旧需求无法重新归类 | 保留“其他”类别，每季度回顾并补充新标签 |
📌 实战案例：某SaaS产品在需求收集周内共获得247条原始需求。经过规范化列表和三级分类后，发现“数据导出异常”需求重复43条，集中在“核心功能→报表→缺陷修复”标签下。RICE评估前该类别被识别为高影响低置信度区域，团队紧急追加了3次用户访谈，最终将置信度从2分提升到4分。
完成本章后，你的团队应拥有一份结构化、可溯源、带分类标签的原始需求池，为第四章“RICE维度拆解”提供干净的数据输入。