# Case B｜IPD 研发需求管理：As-Is 详细描述

> 用途：课堂小组实战的现状材料。本文只描述当前业务、角色、材料、活动、痛点和约束，不提供 AI 解决方案。所有公司、人员与数据均为匿名课堂仿真设定。

## 1. 企业与业务背景

某大型高科技制造集团同时经营硬件设备、配套软件和行业解决方案。客户问题、销售建议、交付反馈、运维缺陷、研发改进和管理层专项要求不断进入研发需求池。不同来源使用不同语言：客户说“报表太慢”，销售说“这是关键客户必须做”，交付人员说“现场每周都在投诉”，研发人员则需要知道版本、环境、复现步骤、影响范围和期望指标。

课堂仿真季度中，产品线收到约 460 条新反馈，其中一部分是缺陷、一部分是配置或培训问题、一部分才是真正的新需求。需求管理团队每两周组织评审。评审会名义上用于价值、范围、资源和优先级判断，实际经常花大量时间补基本事实、寻找重复项和澄清谁代表客户作出了承诺。

## 2. 流程范围

- 开始事件：客户反馈、内部建议、缺陷或合规要求被提交。
- 结束事件：需求被归档为待澄清、待评审、已合并、已拒绝、进入规划或转缺陷处理，并留下责任人与下一步。
- 本案例重点：反馈接收、初步登记、需求澄清、查重、影响信息收集、评审准备、评审决策和行动跟踪。
- 本案例不讨论：详细产品设计、代码开发、测试发布和商业合同变更。

## 3. 当前角色

1. **客户/一线使用者**：描述问题、场景和期望，但通常不使用标准需求语言。
2. **销售或客户成功**：接收反馈，判断客户重要性，可能传递时间承诺。
3. **交付/服务人员**：掌握现场版本、配置、日志和影响范围。
4. **产品经理/需求经理**：登记、澄清、查重、准备评审材料并维护需求池。
5. **研发负责人**：判断技术影响、依赖、复杂度和实现风险。
6. **测试/质量人员**：确认复现条件、验收口径和现有缺陷关系。
7. **评审委员会/业务 Owner**：决定需求去向、优先级和责任边界。

## 4. 当前材料与系统

- 客户邮件、微信群/飞书群聊天、会议纪要、工单和售后记录。
- CRM 中的客户、合同、商机和承诺信息。
- 需求管理系统中的标题、描述、来源、产品、版本、优先级和状态。
- 缺陷系统、研发 Issue、版本计划和发布记录。
- 产品路线图、历史需求、评审纪要、字段模板和验收标准。
- 日志、截图、录屏、附件和现场配置清单。

同一个问题可能同时出现在 CRM、工单、群聊、邮件和需求池中，标题不同、编号不同、描述角度不同。系统之间没有统一关联键时，产品经理依靠关键词和个人记忆判断是否重复。

## 5. 当前流程活动

### 5.1 多渠道接收反馈

销售、客户成功、交付和客户可以通过多种渠道提交。高峰期，产品经理先把消息复制到个人待办或 Excel，之后再补录需求系统。原始附件可能没有一起迁移，来源链接也可能失效。

### 5.2 初步登记

产品经理创建需求条目，填写标题、客户、产品、描述和来源。为了尽快“先占一个编号”，常出现标题过宽、场景不明、期望结果缺失的条目。例如“优化报表性能”“支持权限配置”“增加批量能力”。

### 5.3 判断问题类型

产品经理尝试判断这是新需求、缺陷、咨询、配置、培训还是已有能力不会用。若信息不足，需要销售或交付重新找客户确认。因为责任不清，问题可能在产品、研发、交付之间往返。

### 5.4 澄清场景与事实

需要补充谁在什么情况下使用、当前怎么做、影响多大、发生频率、环境版本、现有绕行办法和期望结果。产品经理通常通过聊天逐项追问。销售转述客户回答时，原问题和答案可能分散在多段消息中，没有回到需求字段。

### 5.5 查找重复与关联

产品经理用关键词搜索历史需求和缺陷。相同业务问题可能使用完全不同的词；相似标题也可能来自不同场景。查重往往依赖熟悉产品历史的老员工。新人容易漏掉历史项，或者把不相同的问题误合并。

### 5.6 收集影响与依赖

研发负责人评估涉及哪些模块、接口、数据和版本；测试人员判断复现和验收；交付人员补充现场约束。信息可能在不同系统评论区、表格和会议中产生。产品经理负责拼成一份评审材料。

### 5.7 准备评审

评审前，产品经理检查字段是否齐全，整理客户价值、影响范围、历史关联、候选方案和未决问题。由于时间紧，有些条目带着明显缺口进入会议，希望现场再问。参与者提前看到的材料版本不一致。

### 5.8 评审会议

会议需要判断是否做、何时做、由谁做、还要补什么证据。现实中大量时间用于追问基础事实：具体客户是谁、哪个版本、到底慢多少、是否已有功能、有没有合同承诺。真正的优先级和资源讨论被压缩。

### 5.9 记录决策与行动项

会议结论由产品经理记录。口头表述可能是“先让研发看看”“跟客户再确认”“合并到老需求”，但责任人、完成时间、验收条件未必明确。会后需要再次追问。

### 5.10 写回与跟踪

产品经理更新需求状态、关联历史条目、建立研发任务或补充客户反馈。销售还需要在 CRM 或客户沟通中同步进展。多个系统的状态可能不一致，客户看到的口径依赖销售个人维护。

## 6. 核心矛盾与痛点

1. **业务语言与研发语言断裂**：客户描述结果感受，研发需要环境、范围和验收证据，中间反复翻译。
2. **输入渠道多且缺字段**：先有消息、后补系统，原始材料和来源容易丢失。
3. **重复识别依赖老员工**：历史需求多、命名不统一，查重速度和质量取决于个人记忆。
4. **评审会变成补材料会**：基础事实不齐，参与者现场重复提问，真正决策时间不足。
5. **事实、判断、承诺混写**：客户事实、销售判断、研发估算和管理决策没有分层。
6. **行动项难闭环**：会议结论模糊，Owner、时间和下一步未固定，状态迟迟不更新。
7. **系统之间缺少关联**：CRM、工单、需求池和研发 Issue 各有编号，信息无法自然串联。
8. **优先级容易被声音大小影响**：缺少可比较证据时，重要客户、紧急口吻或高层关注会压过真实影响。

## 7. 三个典型情境

### 情境一：“报表太慢”

客户只说月底报表很慢。销售强调客户重要，交付知道客户使用旧版本，产品经理不知道报表规模和目标时间，研发要求日志与数据量。四方各有一部分事实，没有一份材料把它们串起来。

### 情境二：看起来重复的需求

历史条目写“批量导出优化”，新条目写“千行明细下载超时”。标题相似，但一个是后台任务，一个是前台交互；如果直接合并会遗漏场景，如果重新立项又可能重复建设。

### 情境三：会议作出模糊结论

评审会上决定“先研究，下次再看”。会后没有明确谁补客户样本、谁查技术依赖、下次评审日期是什么。两周后同一问题再次进入会议，大家重新回忆背景。

## 8. 小组必须进一步追问的事实

- 每类来源进入需求池时有哪些必填字段，谁负责补齐？
- 一条需求在评审前平均被退回多少次，原因分别是什么？
- 历史需求和缺陷如何关联，是否存在统一关键词或产品分类？
- 哪些信息在 CRM、工单、需求池和研发 Issue 之间重复录入？
- 评审委员会依据什么决定“进入评审”“继续澄清”或“合并”？
- 谁有权承诺排期、优先级和客户回复？
- 哪些附件包含客户隐私、日志或敏感业务数据，需要限制读取？

## 9. 课堂任务边界

请先还原 As-Is：按角色画出反馈如何进入、如何登记、如何澄清、如何查重、如何准备评审、如何决策和写回。标出等待、返工、信息重复搬运、人工判断、系统断点和证据缺口。不要先写“AI 自动处理”。后续方案必须建立在本页事实和小组补充假设上，并明确哪些假设仍需现场验证。