3 需求管理

图 3-5 需求管理流程示意图

排序，然后根据分类和排序的结果，将需求分发到不同的业务单元进行实现。同时，还需要与需求提出者和客户保持沟通，确保需求理解正确，确认需求的实现是否能够解决客户的问题。

接下来，将逐一介绍需求管理的各个步骤。

3.3.1 需求收集

需求收集就是通过各种渠道收集高价值的需求。客户需求收集过程分三步，如表3-3 所示。

其中，需求收集渠道包括内部渠道和外部渠道。

● 内部渠道：主要是企业内部各部门。企业内部各部门可以针对产品提出需求，例如：采购部门希望物料归一化；服务部门希望产品更稳定、能够一键交付、一键定障、自动修复；销售部门希望简化销售配置；等等。

● 外部渠道：主要是外部客户和合作伙伴。企业可以与外部客户和合作伙伴沟通交流，从而获得需求。具体方式包括客户对标、技术交流、高层拜访、市场调研、参观展览、技术支持、招投标、浏览媒体信息、聘请行业专家顾问、客户满意度调查、竞品分析、概念验证、产品测试等。

需要补充说明以下几点。

● 建议通过 IT 系统进行需求收集，同时允许所有人员都可以录入需求。对于具体

65

从战略制定到产品上市集成产品开发应用实践-01.indd 65 2023/2/8 15:17:33

从战略制定到产品上市 集成产品开发（IPD）应用实践

的需求，甚至还可以让销售工程师主动追加相关的销售项目信息和金额，帮助进一步确认需求的价值，帮助产品线进行决策。

● 在需求收集过程中，需要确保需求包含必要的要素，能够支撑对需求进行分析和解释转化。这些要素包括以下方面。

√ 需求是否属实？

√ 需求是否符合企业的发展战略？

√ 需求信息是否具备较大价值？

√ 提出需求的是否是企业的重要客户？

√ 对产品的意义有多大？

√ 如果是新市场，新市场容量有多大？潜力如何？竞争程度如何？

3.3.2 需求分析

收集完各种需求后，经过需求分析团队的分析，输出解释和转化后的需求，然后分配给其他业务活动进行处理。需求分析过程包括解释、过滤、分类、排序，具体如下。

1. 解释

对于从不同源头收集的需求，需要进一步提炼，以正式的语言描述。统一语言，可以方便交流，避免歧义。需求描述有以下四个原则。

● 描述产品需要做什么，而不是应该怎么做（怎么做是方案设计）。

● 尽量原汁原味、完整、详细地陈述需求。

● 使用肯定句而非否定句，即描述客户期望的目的。

● 避免使用“必须”和“应该”，“必须”过于绝对，“应该”是一种猜测。

2. 过滤

收集到的信息有可能不是需求，需要过滤出来。例如：客户希望参观公司的请求；客户希望借几台产品试用一下；商务、法律方面的请求；等等。

3. 分类

需求有很多种分类的维度，根据这些维度将需求分类，并进行针对性的处理。参见 3.2 节，如时间维度、类型维度、层次维度、客户维度、价值维度等。

4. 排序

由于研发时间和成本是有限的，所以，需要在有限的时间和成本下，对需求进行取舍，挑选高价值、低成本的需求进行实现。常见的排序方法有 $APPEALS 方法、 Delphi 方法。

经过初步筛选后的需求信息会进入需求池，需求管理团队一般每周会对这些信息进行一次分析和处理，然后进行需求的分发。

3.3.3 需求分发

按照需求实现的重要和紧急程度的不同，可以将需求分发到不同的流程阶段进行66

从战略制定到产品上市集成产品开发应用实践-01.indd 66 2023/2/8 15:17:33

3 需求管理

处理，确保需求交付时间满足客户的要求，如图 3-6 所示。

图 3-6 需求分发流程示意图

● 对于紧急且重要的需求，需要启动研发需求变更（PCR）流程，让开发团队变更开发节奏，优先完成紧急需求。需要注意以下几点。

√ 在 PDCP（项目正式立项）前， 由于项目还未正式启动开发和设计，所以可以通过端到端的产品包需求模板汇总产品包需求。

√ 在 PDCP（项目正式立项）与 TR5（少量早期发货）之间，由于项目已经启动，所以新增和改变需求必须通过需求变更（PCR）流程，确保变更得到有效控制。

√ 在 TR5（少量早期发货）后，此时版本基本定型，为了保证产品及时发布和质量稳定，禁止更新需求。

● 对于不紧急但是重要的短期需求，可以分发给产品任务书开发团队（CDT），将需求纳入下一个产品或版本开发中。在编制任务书（Charter）的时候，一般需要根据分发的需求编制初步的产品包需求列表，与任务书（Charter）一起作为IPD 开发流程的输入。

● 对于重要但是不紧急的长期需求，可以分发给路标管理团队，将需求纳入路标，进行需求排期。当组合管理团队（PMT）创建路标规划时，需要从需求池中提取需求。

● 对于既不紧急也不重要的需求，直接放弃。

● 对于一些暂时看不太清楚的需求，可以纳入需求池，由需求管理团队定期审视。

3.3.4 需求实现

需求分发到各自的流程后，便可以按照各自流程的要求进行设计和实现。在 IPD研发项目中，系统工程师需要采用系统工程的方法将产品包需求分解为设计需求和设计规格，然后依据设计规格实现产品需求。具体如图 3-7 所示。

● 当研发需求变更申请通过后，将需求加入当前的开发项目，然后进行端到端的需求跟踪和变更管理。

● 当需求纳入下一个版本开发的时候，需求将由产品任务书开发团队进行分析，

67

从战略制定到产品上市集成产品开发应用实践-01.indd 67 2023/2/8 15:17:34

从战略制定到产品上市 集成产品开发（IPD）应用实践

加入产品任务书（Charter）的包需求。

● 当需求纳入路标进行管理的时候，则发送给路标管理团队，进行需求排期。

3.3.5 需求验证

需求验证指的是通过各种渠道和方法确认客户需求的过程。为了确保正确地理解客户的需求，在需求管理的整个过程中，需要不断地进行需求验证，避免对需求产生错误的认识。

在产品规划、开发、上市过程中，当发现需求目标不清、团队认识不统一、可能存在较大的市场风险时，都可以进行需求验证，从而进一步加深对需求的理解和增加团队的共识。因此，需求验证并不是一次就能完成的，需要多次反复进行，如图 3-8所示。

需求验证的方法包括内部验证和外部确认两种。

● 内部验证：通常是通过各种评审和测试来实现，包括需求评审、需求跟踪、设计评审、系统测试、阿尔法测试等。内部验证的目的是保证需求能够严格按照描述实现，不偏离目标。

● 外部确认：目的是保证准确地理解客户需求，常见的外部确认方式包括概念验证、产品试用、市场测试等。

在具体操作方式上，产品经理需要与客户沟通对需求的理解，通过客户的反馈来确认需求理解是否准确和正确。需求验证的主要过程如下。

68

从战略制定到产品上市集成产品开发应用实践-01.indd 68 2023/2/8 15:17:35

3 需求管理

● 明确目的：描述需求验证的目的，明确需求验证需要达成的目标。

● 选择客户：外部验证通常选择可靠的、熟悉的、友好的战略合作伙伴进行验证。要确保获得有效信息，避免信息泄露。

● 确定形式：包括线下会议、单独访谈、邮件、视频会议、原型演示等。

● 确定手段：通过概念设计、功能清单、规格列表、产品原型、验证环境、系统模拟器等方法和手段，描述产品线对客户需求的理解和设想，确保对需求的理解一致。

● 制订计划：制订详细的验证计划和验证方案，包括时间、地点、人员等。

● 执行验证：按照验证计划和方案，实施验证活动，记录验证结果。

● 总结结果：对于验证结果进行分析和总结，确定需求理解是否一致，并修正需求理解的偏差。同时，还可以对需求验证过程本身进行总结，提升后续需求验证的效率。

总的来说，需求验证就是通过不同形式与客户多次反复沟通和确认，尽量确保需求理解一致。