需求管理包括哪5个过程？从收集、分发到验证的交接方法

需求管理可以按收集、分析、分发、实现、验证五个过程组织。关键不是把需求依次挪过五列，而是每次流转都留下可检查的产物：原始问题、明确需求、版本决定、实现记录和验收结论。需求被记录下来，不代表已经承诺开发；功能做出来，也不等于原来的问题已经解决。

产品经理和项目经理需要持续跟踪这些变化，并与提出需求、实施需求和验收需求的人沟通。可以用在线项目看板呈现当前状态，在同一张画布中放置原始反馈、优先级讨论和版本计划；但谁批准范围、谁确认完成，仍应由团队明确约定。

下面按这五个过程，以“员工查不到报销进度，反复询问财务”为例说明。最终要管理的不是一句“增加消息提醒”，而是一条有来源、有边界、能验收的需求。

1. 收集需求：记录问题，不急着承诺解决方案

收集需求的来源可以分为内部和外部。内部包括管理层、业务部门、客服和实施团队；外部包括客户访谈、反馈、使用行为以及市场调研。头脑风暴可以帮助汇总想法，但不能代替使用者的具体经历；竞品出现某项功能，也不能单独证明本产品必须跟进。

在本例中，员工说“能不能发个提醒”，财务说“每天都有人来问走到哪一步”。先分别保留原话，再追问最近一次发生在什么情境、当时查过哪里、无法确认的是付款时间还是当前处理环节。不要直接把两个反馈合并成“开发短信通知”。

Boardmix画布可以把文字、图片、链接等材料放在同一讨论空间。需求卡只放必要摘要，原始访谈或业务记录保留可追溯入口；敏感内容按团队权限要求处理，不为了便于讨论而公开整份材料。

这一过程的完成条件：团队能说清是谁在什么情境遇到了什么问题，并找到来源。只有一句功能名称、没有使用情境的条目，先进入待澄清，而不是直接排进开发计划。

2. 分析需求：统一含义，再比较价值与成本

分析需求的两个关键点，是准确理解需求和识别需求的价值。需要将用户语言转化为团队可以讨论的规范描述，对同类反馈进行合并、分类，识别重复内容，并明确产品的边界。合并的是同一个问题的证据，不是把不同角色的权限和目标混在一起。

R17可以写为：“员工登录后，能够查看本人已提交报销单的当前处理状态；发生退回时能够查看允许展示的退回原因，并知道下一步应补充什么。”这时仍要与财务确认状态口径。例如，“审核通过”不一定等于“已付款”，页面不能把它们合成一个“已完成”。

再把需求分成三层，避免评审时各说各话：

• 业务问题：员工难以判断单据进展，财务反复解释同一状态。
• 本次功能范围：查询本人单据的状态和相应说明，不修改现有审批权限。
• 验收条件：状态名称与业务口径一致，只能查看授权范围内的单据，退回后能看到下一步动作。

排序时可以参考需求优先级矩阵。机会点矩阵比较收益与成本，痛点矩阵比较影响范围与程度；两种视角要分开看，不能因为某个便签落在右上角就自动承诺开发。

对R17，先确认状态数据是否已经存在、哪些部门受影响、能否通过完善现有页面解决。如果状态来源不稳定，优先级再高也应先处理数据依赖；如果只有极少数例外场景，可能先补一条人工查询渠道。写下取舍理由，比只保存一个“高优先级”更有价值。

3. 分发需求：落实到版本、责任人与明确边界

分发需求，是将分析确认后的需求分配到不同版本和实施责任中。长期、中期、近期和紧急需求可以作为规划视角，但不能只贴标签；每条进入近期版本的需求，都需要确认负责人、范围、前置依赖和验收人。

在R17的版本讨论中，可以把“员工主动查看进度”作为当前范围，把“主动通知员工”保留为后续候选。这样不是只做一半，而是先明确一个能够独立使用、可以验收的结果。短信、邮件或其他通知渠道的选择，需要另行评估触达、成本与隐私要求，不能在会上顺手加进本次承诺。

用产品版本迭代规划模板整理候选需求时，建议同时写上“本版纳入”“暂不纳入”“进入条件”。“以后再说”不是完整决定：暂缓项也应说明缺什么证据、什么变化发生时重新评估。

R17进入实现前，至少确认三件事：财务认可状态定义，研发确认可以取得所需数据，验收人认可当前版本不包含主动通知。若关键条件没有确认，应在计划中标记为待澄清或受依赖阻塞，不把它当作可以立即开工的任务。

4. 实现需求：让原始问题、设计与交付记录连得起来

实现需求，是把已经确认的产品需求转化为具体设计和开发任务。不同项目可能涉及系统特性、架构、模块或业务操作流程；产品经理需要跟踪需求是否得到满足，并评估变化对范围和交付的影响，而不是只询问“开发到百分之几”。

R17可以进一步拆成状态字段对照、员工查询界面、权限检查和退回说明等工作。每项工作都关联R17，而不是拆完以后失去与原问题的联系。需求卡上保留当前版本、设计入口、负责角色、阻塞事项和验收记录位置；细分任务则记录各自的交付物。

在画布上组织跟踪信息时，可以设置“待澄清、待实现、实现中、待验证、已完成”等列。移动卡片前先约定条件：设计已画好不等于实现完成，代码合并也不等于已经通过业务验收。需要人工更新的状态由责任人维护，不把白板上的位置当作其他系统自动同步的结果。

上表中的任务编号、状态、负责人和阶段成果，是可沿用的跟踪字段。需要排期时，可查看项目进度计划模板，再填入本项目的实际任务和日期；不要把模板日期当成自己的交付承诺。

实现过程中如果财务提出“主管也应查看整个部门”，这已经改变了原来“员工查看本人单据”的范围。先记录新增对象和权限影响，重新分析是否纳入本版；不能只在开发群里说一句“顺便加上”，却让需求卡、测试条件和上线说明各保留一个版本。

5. 验证需求：既检查做对没有，也检查是否解决问题

验证需求不只是列出单元测试、集成测试、α测试或β测试。这些是不同层次或阶段的测试活动，具体项目按需要安排；需求管理还要确认交付结果是否符合已约定的业务规则，并能回应最初提出的问题。

R17可以按下面三类情境验收，执行时逐项填写实际结果、未通过原因和确认人：

验收记录应包含需求编号、使用的数据或场景、实际结果、未通过项、确认人和时间。若条件未满足，记录原因并退回对应过程；若只是调整表述，也要同步需求卡与验收材料，避免下次仍按旧口径判断。

上线后的观察与发布前验收可以分开记录。R17通过功能验收后，还可以继续观察员工能否读懂状态、财务是否仍被追问同样的问题。若问题依旧存在，先查看是状态文案难懂、入口难找还是信息更新滞后，不直接假定“再加一个通知功能”就能解决。

五个过程不是只能向前走的流水线。收集时发现证据不足要补问，实现时出现新范围要重新分析，验证不通过要明确退回原因。保留同一需求编号和关键决定，团队才能知道现在做的内容为什么存在、与原始问题有什么关系，以及何时可以真正结束。