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

（1）制订拜访计划：在什么时间，完成多少访谈工作，达到什么样的目的。

（2）寻找客户：通常会在现有客户中挑选友好客户进行访谈。同时，还需要访谈不同的角色，从而确保访谈的信息充分和完整。

（3）准备访谈大纲：访谈大纲是帮助访谈人在访谈用户的过程中明确访谈目的、聚焦问题的指导文件。针对不同的被访谈角色，需要有不同的访谈大纲。访谈大纲的内容主要包括基础信息（地点、时间、时长等）、访谈目标、访谈框架与时间安排、细化的大纲问题（主题、目的、问题设置与时间安排）等。

（4）执行访谈：放下自己的预设，让自己像“小白”一样去倾听。

（5）整理访谈信息，输出访谈纪要。访谈信息包括会议纪要、用户提供的资料、录音或视频文件（如有）、现场照片（如有）等。

（6）将访谈纪要结构化归档。

2. 干系人地图

在用户访谈结束后，团队可以开始搭建干系人地图。干系人地图是梳理客户组织中每个人物与其他人物之间关系的工具，可以帮助团队梳理和理解各角色之间的关系。以软件开发的产品经理、架构师、软件工程师为例，干系人地图如图 3-10 所示。

70

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

3 需求管理

确认产品特性是否可实现

设计系统架构 提供架构设计说明, 进行代码

评审、 疑难问题攻关

图 3-10 干系人地图示意图

干系人地图的搭建步骤如下。

（1）写出相关的角色，贴在干系人图上，包括角色、名称、主要职责。

（2）在各干系人之间构建联系，例如，彼此为对方做什么。

（3）将干系人按角色进行归类，包括管理层、执行人员、使用者、审核人员等。

（4）输出完整的干系人地图。

3. 同理心地图

基于用户访谈的内容， 团队还需要构建同理心地图。同理心地图是从所说、所做、所想、所感四个方面去分析用户，帮助非用户人员建立共情，从用户的角度理解业务的工具，如图 3-11 所示。

图 3-11 同理心地图示意图

同理心地图的构建通常分两大步六小步。具体操作过程如下。

（1）创造人物画像。

①在白板或白纸的中央，画出团队需要关注的人物的画像。

②以画像为中心分出四个大的区域，分别为所说、所做、所想、所感。

③填写人物的角色，并起一个虚拟的名字。

④使用便利贴描述人物的个人状态，贴在人像旁边，包括工作状态、工作年限、

71

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

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

年龄、背景等。一个便利贴只写一个特点。

（2）丰富人物画像。

⑤使用便利贴分别从所说、所做、所想、所感四个方面分析人物。以用户的语言描述，一个便利贴只写一个内容，通常一个象限不超过 10 个点。

⑥全部完成后，团队一起查看，并聆听彼此是如何写的，相互交流、补充。

4. 场景梳理

用户场景通常指用户解决某个问题、满足需求的过程。一般来说，用户场景可以采用六要素的方式进行描述，如图 3-12 所示。

用户场景描述的六要素具体如下。

● 用户：某一特定的用户，例如，一个人、一个组织等。

● 环境：某一特定的环境，例如，空间、时间、工具、预算等。

● 时机：某一特定的时机，例如，触发用户产生目标的事件或影响用户行为改变的环境变化。

● 目标：带着一个具体的目标。

● 动作：采取了一系列的动作。

● 任务：完成了一个特定的任务。

基于用户访谈的内容，并对用户所处的行业进行充分分析，可以梳理出多个用户场景。以电商业务为例，常见的用户场景包括用户注册、用户信息修改、账户充值、商品收藏、购买商品、售后服务等。

5. 用户旅程

在用户场景梳理完后，针对每一个用户场景，可以使用用户旅程工具梳理用户当前的详细工作环节。用户旅程工具可以帮助团队理解用户当下的使用场景，理解用户的体验、感受和想法。

使用用户旅程工具需要完成的任务主要包括以下方面。

● 梳理用户完成任务的步骤：他们的工作是怎么做的？详细步骤是怎么样的？

● 梳理用户做什么（Doing）：有哪些场景？遇到了哪些问题？一般会花费多长时间？

● 梳理用户想什么（Thinking）：在每个步骤中，用户有什么想法？

● 梳理用户感觉如何（Felling）：在每个步骤中，用户感觉如何、体验如何？

72

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

3 需求管理

例如，对于电商业务“购买商品”场景，使用用户旅程工具分析的结论如表 3-5所示。

另外，在梳理用户旅程时，除了梳理用户做什么（Doing）、想什么（Thinking）、感觉如何（Felling）以外，根据产品形态的不同，很多产品经理还会考虑用户痛点、与用户的接触点、产品销售机会、预期结果等方面的信息，确保能够更好、更全面地理解用户。

6. 用户画像

在完成干系人地图、同理心地图和梳理用户旅程之后，团队成员可以将同类型的角色总结提炼成一个虚拟人物形象。这个虚拟的用户形象就是用户画像。用户画像一般包含用户基本信息、工作目标和内容、问题和挑战等，如图 3-13 所示。

73

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

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

（2）用户标签。通过对用户的理解，提炼出的用户行为、感情、想法等的特点。例如，对工作有热情、自信大方、善于多任务处理、善于沟通等。

（3）用户的核心问题。包括有代表性的问题、痛点、挫折等。

（4）工作目标和内容。如工作内容、操作步骤、任务目标等。

（5）用户表达的信息。引用最能代表用户角色特点或问题的 2~3 句话。

7. 场景选择

基于用户调研、市场、战略等层面输入的 高 用户

信息，产品团队成员可以通过投票，选择最核

心的场景，作为未来需求分析的范围。以电商 户 账户 核心场景

用户场景选择为例，具体如图 3-14 所示。 影 信息 充值 商品

具体的场景选择方法如下。 力

（1）从“用户影响力”和“商业价值”两 低 记录 一般场景个维度对场景进行投票。 低 商业价值 高

（2）针对用户场景进行投票，每个人票数 图 3-14 电商用户场景选择示意图相等。

（3）统计每个场景的票数，并将其放入场景选择图的恰当位置。

（4）优选核心场景，进行后续的需求陈述的撰写。

（5）进一步分析是否有某些场景更有影响力或商业价值。

8. 需求陈述

针对用户场景选择的结果，通过需求陈述来梳理该场景下用户旅程各阶段用户的真实需求。通过需求陈述可以避免直接接纳用户的浅层次需求，而忽略用户背后的真实需求。在需求陈述前，还可以通过竞品分析、5Why 等方法，进一步帮助团队理解用户的需求。

需求陈述可以使用固定的句式，常见的句式为：特定的用户角色需要一种方法，做一些事情满足他们的需求，然后用户直接地受益。例如，对老年人“购买商品”场景中的登录需求陈述为：老年人需要一种方法，更便捷快速地登录账户，然后才能够搜索和购买商品。

3.4.2 如何提取系统特性

对于同一个需求，客户、市场、研发、交付所看待的视角存在较大的差异，例如，市场关注客户价值、研发关注产品实现、交付关注能否验收通过，这导致需求沟通时缺乏共同的语言，出现沟通困难。此时，需要使用特性方法来帮助相关干系人统一语言，加强沟通。

特性是产品和系统的可销售“系统能力”的抽取，是客户可感知的“系统能力”，是产品的卖点，是满足客户业务需求的固有属性（能力）集合，是客户问题的解决方案。

特性为客户、市场、研发、交付提供了标准统一的描述语言，其作用体现在以74

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

3 需求管理

下方面。

● 拉通市场与客户：按照产品特性与客户沟通，按照特性进行销售。

● 拉通市场和研发：梳理全量特性，按照特性进行版本规划。

● 拉通研发内部的设计、开发和测试：以特性为主线，将研发碎片化任务串起来，确保按特性交付。

● 拉通交付服务与研发：按特性进行市场导入，按特性向客户交付和验收。

由于在客户界面需要按特性销售和交付，所以，所有的特性都应该具有商业价值。对特性的判断遵循四个基本原则，具体如下。

● 客户认可价值：具有客户价值，能够满足客户的业务需求。

● 客户可感知：是客户可感知的系统外部表现形式。

● 可完整应用：是可以解决客户问题的完整“解决方案”。

● 市场可销售：可以支持销售报价。

特性是从客户需求中提取出来的，需求、特性、功能之间的关系如图 3-15 所示。

图 3-15 需求 - 特性 - 功能关系图

● 通过对原始需求（RR）的分解，形成多个初始需求（IR），多对多。

● 通过对初始需求（IR）的提炼，形成系统特性（SF），通常为多对一。

● 基于系统特性（SF），使用用例方法（Use Case）识别系统需求（SR），通常一个用例（Use Case）对应一个系统需求（SR）。

● 针对新的初始需求（IR），需要先挂特性树（SF），再基于价值识别系统需求（SR）。

在实际工作中，提炼系统特性（SF）并进行分解的过程如下。

75

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

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

（1）需求管理团队收集原始需求（RR），分析整理初始需求（IR）。

（2）产品管理团队分析初始需求（IR）对应的系统特性（SF），将需求挂入特性树。

（3）系统工程师根据系统特性（SF），识别系统需求（SR）。

（4）系统工程师根据系统需求（SR），设计产品组件，并予以实现。

（5）测试工程师根据系统需求（SR），设计测试用例。

（6）资料开发工程师根据系统特性（SF），开发产品资料，包括产品概述、产品特性描述、用户手册等。

其中，资料开发工程师在开发产品资料时，也可以根据客户的采购阶段，分阶段描述特性内容，主要包括三个阶段，如图 3-16 所示。

图 3-16 特性描述方法示意图

● 引发兴趣：针对客户的商业环境（痛点 & 需求 & 期望），介绍产品有哪些特性，特性的目的是什么、能做什么、有何好处等。

● 打消顾虑：针对客户环境，评估应用的限制、可能的风险以及代价。需要打消客户的疑虑，推动客户购买。

● 澄清细节：当客户有了购买意向后，通常需要介绍特性更详细的功能及能力，确认是否符合客户的要求。此时需要对特性的细节进行澄清。

使用特性方法能够给企业带来很多好处，包括以下方面。

● 通过具有业务价值的特性引导客户需求，匹配客户业务发展模式，与客户共赢。

● 可以推动基于特性的销售和交付，清晰呈现客户购买产品包的“大小”，初次销售与后续升级扩容管理范围清晰。

● 瞄准目标客户群，针对目标细分市场规划价值特性，匹配客户需求，产品复用性好。

76

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

3 需求管理

● 从特性分解、特性设计、用户故事设计到特性验证一路贯通，可以看到自上而下的整体分解，有章可循，确保目标正确。

● 用系统特性主线将团队所有角色进行对齐，市场、研发等共同完成特性的识别和用例的分析，确保客户需求、规划、开发和交付一致。

3.4.3 如何编写系统需求

什么是高质量的系统需求？

高质量的系统需求至少需要满足四个方面的要求，即客户导向、完整性、可实现性、可测试性。通常可以使用检查清单来检查需求的质量。

为了编写高质量的系统需求，推荐采用系统需求编写七步法，具体步骤如下。

1. 理解用户需求

充分理解用户需求，以便顺利完成系统需求的编写。在理解用户需求的过程中，可以使用用户需求思维导图或者设计思维等方法，梳理主要用户场景及详细的工作过程，避免需求遗漏，参见本章 3.4.1 节。另外，还可以参考“用户体验要素模型”，在理解用户需求的时候，主要理解产品目标、客户场景、客户效果和收益。

2. 确定功能实现方案

与架构师确认项目总体技术方案，确认需求是否可以实现，包括技术准备度、技术风险、实现难度、备选方案等。确认需求实现所依赖的技术方案都已经确定后，输出需求的总体设计。

3. 确定产品需求矩阵初稿

根据对用户需求的理解， 以及与研发沟通的实现方案，输出大致的需求规格（需求矩阵），用于与交互设计师沟通设计方案，以及整理系统需求编写思路。需求矩阵实例如表 3-6 所示。

在描述需求的时候，可以通过用户故事来描述，用户故事是从用户角度对系统行为的简短描述。用户故事格式为：作为一个 < 角色 >，我想要 < 功能 >，以便实现 < 商业价值 >。例如，作为一个球员，我想要查看赛程安排，以便知道我下一场比赛的时间和地点。

4. 确定产品交互方案

基于产品需求矩阵，与交互设计师一起确定产品的交互方案，输出交互方案和视觉稿。其中，交互设计原则如下。

77

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

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

● 少即是多：不要一次性将所有的内容都呈现在一个界面。一个界面具体展示多少信息比较合适，没有一个绝对的标准。通常来说，越专业的决策需要的信息越多。对于 ToB 业务，需要尽量将关键信息一次性展现，避免用户在各页面反复跳转。但是，对于 ToC 业务来说，由于业务简单，可以尽量简化页面，推荐使用“向导”等方式展示信息。

● 主次分明：关键信息一目了然。可以通过加强对比、突出重点、消除干扰等方法达到主次分明。例如，通过颜色对比、字体加粗等方式突出重点；通过减少颜色和字体的使用，如所有非关键信息都采用灰色、普通字体，从而消除干扰。

● 及时有效地反馈：实现反馈的方式包括颜色变化、形状变化、文字变化、图标变化、背景虚化、声音提醒、信息提醒等。例如，信息提交后，“提交”按钮的名字变更为“已提交”。

● 采用标准化的组件：建立产品标准组件库，确保相同的任务使用相同的组件，提高设计和开发效率。同时还可以保证整个产品线的交互风格一致，降低用户学习难度，提升用户体验。

● 保持一致：对于文字描述、视觉效果、组件使用、交互方式等，需要确保在整个产品线内保持一致。避免同一个图标在不同页面或不同需求上代表不同的含义，给用户带来困扰。

5. 编写系统需求文档

梳理系统需求框架和使用场景，细化系统需求，定义需求规格，并完成系统需求文档的编写。具体内容及注意点如下。

● 在用户需求场景下，产品如何使用。

● 在该场景下，分析当前产品存在的问题。

● 给出详细的交互及操作步骤。

● 定义详细的约束和限制条件。

● 除了定义正常场景外，异常和例外场景也非常重要，需要进行描述。

● 描述的时候要重点突出，便于阅读，用不同的颜色标记关键点。

6. 更新需求矩阵

根据系统需求阶段的要求进行需求细化，将系统需求更新到需求矩阵，后续的跟踪和检视工作主要借助需求矩阵来完成。

为方便读者理解“系统需求文档”和“系统需求矩阵”的关系，这里做一个对比，如表 3-7 所示。

7. 组织评审并更新系统需求

进行需求内外部评审。在进行系统需求外部评审之前，需要在项目组内部进行评审。建议至少完成一轮内部评审后，再组织外部评审。根据评审意见，更新相关文档，并确认评审意见可以闭环。

78

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

需求管理

这些团队在需求管理过程中的任务主要如下。

1. 需求分析团队（RAT）

需求分析团队（Requirement Analysis Team，RAT）负责本领域的需求分析工作，对需求进行专业分析，包括解释、过滤、分类、排序等。必要时进行市场调研，最终给出需求的评估建议，包括需求收益、工作量大小、实现难度等，并依据需求价值优先级进行排序，形成市场需求包或待定的需求列表。需求分析团队（RAT）的主要成员如图 3-17 所示。

图 3-17 需求分析团队示意图

79

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

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

需求分析团队（RAT）的主要业务活动如下。

● 例行召开需求分析例会，如周例会或双周例会等。

● 根据例会的结论，将市场需求包传递到 PDT/TDT 等相关部门进行后续处理。

● 根据例会的结论，将待定的需求列表提交 RMT 处理。

● 进行任务跟踪监控，对产品包需求进行内容验证、评审以及最终结果的确认。

● 负责监控客户需求早期确认工作。

2. 需求管理团队（RMT）

需求管理团队（Requirement Management Team，RMT）负责管理产品线的需求。需求管理团队（RMT）的主要成员如图 3-18 所示。

图 3-18 需求管理团队示意图

需求管理团队（RMT）的主要业务活动如下。

● 代表所属产品线，与相关产品线和部门沟通，对跨产品线的需求进行协调。

● 负责对需求进行动态排序与决策、管理需求的实现承诺、跟踪和管理重要需求的实现进展及风险、沟通需求的变更等。

● 为市场管理流程提供相关输入材料，如产品包定价、细分市场 $APPEALS 分析等。

● 每年初根据产品线发展战略及业务计划，确定年度需求关注重点，输出需求收集年度规划，并按照季度更新。

● 组织开展需求收集活动，完成本产品线需求信息的受理、预审工作。

3. 产品管理团队（PMT）

● 决定是否接纳需求，对于接纳的需求纳入路标规划或 PDT 的任务书。

● 支持跨产品线需求的解决方案实现。

● 将需求状态反馈给 RMT。

4. 产品开发团队（PDT）

● 决定是否接纳需求，并负责实现接纳的需求。

● 支持跨产品、跨产品族、跨产品线需求的解决方案实现。

● 对 PDCP（项目正式立项）后的需求，使用 PCR 流程进行变更。

● 将需求状态反馈给 RMT。

5. 技术开发团队（TDT）

● 与 PDT 类似，但是只针对技术和平台需求。