4. 构建需求池管理表：需求ID、来源、描述、初步估算
4.1 业务问题：需求管理失序
产品团队在日常工作中会从多个渠道接收需求——用户访谈纪要、销售反馈、客服工单、技术优化建议、竞品分析报告等。这些需求散落在不同文档、邮件和聊天记录中，缺乏统一的结构化记录载体，导致以下问题：
- 需求遗漏：非正式渠道的需求容易被遗忘，无法进入后续评审流程。
- 重复记录：同一需求被不同角色多次提出，团队重复分析浪费资源。
- 优先级混乱：缺少统一视图，无法快速对比各需求的紧急程度与投入产出。
- 追溯困难：需求来源模糊，决策时无法回溯原始场景与用户原话。
核心矛盾：需求的“原始丰富性”与“结构化可管理性”之间存在鸿沟。构建需求池管理表是弥合这一鸿沟的第一步，也是版本规划与优先级排序的数据地基。
4.2 用户场景：产品经理的日常困境
以下是一个典型的产品经理工作片段，反映了需求管理失序的日常：
场景案例：产品经理小张周一早上打开邮箱，发现来自销售、客服、技术三个部门的7条需求描述，有的是一句话“用户希望导出报表”，有的是一段通话录音摘要，还有的是一个竞品截图的微信消息。小张需要在下周版本评审会前，将这些需求整理成可评估、可排序的条目。他面临的第一个问题是：如何用一种统一的格式把这些凌乱的信息记录到同一个地方？
需求池管理表正是为解决这一场景而生。它将散乱的原始需求转化为结构化的记录单元，让产品经理能够高效地对齐信息、消除重复、进入后续估算与排序环节。
4.3 用户访谈：需求信息的原始形态
用户访谈是需求的最重要来源之一。访谈记录通常包含大量上下文、用户原话和情绪表达，这些丰富信息需要被“翻译”成结构化的需求条目。从访谈记录到需求池记录，需要完成以下信息提取：
- 用户角色与场景：谁、在什么情境下遇到了问题。
- 核心诉求与期望：用户希望系统做什么来解决问题。
- 业务价值：满足该需求能为用户或业务带来什么可衡量的改善。
- 优先级线索：用户表达的迫切程度、使用频率、替代方案可用性。
常见陷阱：直接将用户原话复制到需求描述中，而不提炼业务逻辑。例如“我希望有个按钮能导出Excel”应转化为“作为运营人员，我希望按月导出销售报表，以便进行线下数据核对与分析”。
4.4 需求拆解：四个核心字段的定义
需求池管理表的核心由四个字段构成，它们共同为每一条需求提供了“身份-来源-内容-体量”的四维标识。以下字段说明表给出了每个字段的设计意图与填写规范：
| 字段名称 | 字段代码 | 设计意图 | 填写规范摘要 |
|---|---|---|---|
| 需求ID | ReqID | 为每条需求分配唯一标识，便于检索、追溯与版本关联 | 采用“REQ-YYYYMMDD-三位顺序号”格式，系统自动生成 |
| 来源 | Source | 记录需求提出渠道，用于分析各渠道的需求质量与分布 | 从预设分类中选择：用户访谈、业务分析、竞品研究、客服反馈、内部优化、技术债务 |
| 描述 | Description | 清晰表达需求的内容与业务价值，支撑后续评审与排序 | 采用用户故事模板：作为<角色>，我希望<功能>，以便<价值> |
| 初步估算 | Estimate | 快速标注需求的相对体量，用于优先级排序的资源约束判断 | 使用T恤尺寸（S/M/L/XL）或故事点（1/2/3/5/8），由PO或技术负责人给出 |
这四个字段的组合构成了需求池管理表的最小可行结构。在后续章节中，我们会在此基础上扩展状态、优先级、关联版本等字段，但ID、来源、描述、估算是任何需求池都不可或缺的基石。