PMBOK® 第六版 收集需求

目录

读后感—PMBOK第六版 目录

---

需求的重要性可以通过一个类比来表达：“得民心者得天下，得需求者得市场”。正如苹果公司的成功所展示的，乔布斯能够将自己的想法有效传达给设计师，并激励他们超越常规，这正是需求管理的力量所在。

需求管理是一个复杂的过程，它包括需求的收集、分析、记录、跟踪、沟通确认和管理。以软件项目为例，软件平台化的趋势带来了如山如海的需求。在这种情况下，如何保持核心功能的稳定性，同时满足其他功能需求，是一个挑战。

微信的更新策略提供了一个值得借鉴的案例：无论版本如何更新，始终以聊天界面作为用户操作的入口，同时将所有新增功能整合到一个页面，通过搜索快速供需要的客户使用，实现了核心与扩展功能的平衡。

在实际工作中，经常会遭遇客户需求不明确的状况，即便依据同类型已有的需求进行制作，客户也不予以认可。试图通过对客户现有需求和问题予以优化重构，然而最终常常是全盘推倒重来。此外，还存在诸多与需求相关的问题，如：客户难以完成对需求的确认、对需求的变更无法进行合理跟踪、设计人员与开发人员之间存在矛盾等。

个人建议是：“尽可能邀请客户参与到项目中来。如果一个产品没有人使用，不能产生价值，那么所有的工作都是无效的。”反过来说，如果无法改变现状，那么加入并适应它也是一种策略。

一、收集需求的内容

收集需求是为实现目标而确定、记录并管理相关方的需要和需求的过程（见图1）。本过程的主要作用是，为定义产品范围和项目范围奠定基础，且仅开展一次或仅在项目的预定义点开展。

图-1 收集需求：数据流向图

需求具有多样性、复杂性、隐蔽性、差异性、变化性及矛盾性，这些特点对项目的成功至关重要。为了精确定义和管理产品、服务或成果的需求，积极引导相关方参与需求的细化是关键步骤。

需求是产品、服务或成果必须满足的特定条件或能力，它们源自发起人、客户和其他相关方的量化期望。这些需求需要被详细探明、分析、记录，并纳入项目范围基准，以便在项目执行过程中进行有效的衡量。

作为项目规划的核心要素，需求将指导工作分解结构（WBS）的创建，并对成本、进度、质量和采购计划的制定产生影响。确保需求的精确定义和管理，是实现项目目标和满足所有相关方期望的基础。

二、收集需求

收集需求过程通过项目章程、管理计划和相关文件输入，运用专家判断、数据收集与分析、决策以及数据表现等工具与技术，输出需求文件和需求跟踪矩阵，确立并细化项目和产品需求（见图2）。

图-2 收集需求：输入、工具与技术和输出

2.1 收集需求：输入

收集需求输入包括：

1. 项目章程

项目章程记录了项目概述以及将用于制定详细需求的高层级需求。

2. 项目管理计划

• 范围管理计划：包含如何定义和制定项目范围的信息；
• 需求管理计划：包含如何收集、分析和记录项目需求的信息；
• 相关方参与计划：从相关方参与计划中了解相关方的沟通需求和参与程度，以便评估并适应相关方对需求活动的参与程度。
• 项目文件

可作为本过程输入的项目文件包括（但不限于）：

• 假设日志：识别了有关产品、项目、环境、相关方以及会影响需求的其他因素的假设条件；
• 经验教训登记册：提供了有效的需求收集技术，尤其针对使用迭代型或适应型产品开发方法的项目；
• 相关方登记册：用于了解哪些相关方能够提供需求方面的信息，及记录相关方对项目的需求和期望。
• 商业文件

影响收集需求过程的商业文件是商业论证，它描述了为满足业务需要而应该达到的必要、期望及可选标准。

5. 协议

包含项目和产品需求。

6. 事业环境因素

会影响收集需求过程的事业环境因素包括（但不限于）：

• 组织文化；
• 基础设施；
• 人事管理制度；
• 市场条件。
• 组织过程资产

会影响收集需求过程的组织过程资产包括（但不限于）：

• 政策和程序；
• 包含以往项目信息的历史信息和经验教训知识库。

2.2 收集需求：工具与技术

本篇章关于工具与技术的内部比较多，这里整理一个汇总表单（见图3）

图-3 收集需求：工具与技术各方法区别

1. 专家判断

由具备相关专业知识或接受过相关培训的个人或小组针对以下主题给出意见。

• 商业分析；
• 需求获取；
• 需求分析；
• 需求文件；
• 以往类似项目的项目需求；
• 图解技术；
• 引导；
• 冲突管理。

2. 数据收集

可用于本过程的数据收集技术包括（但不限于）：

头脑风暴：

头脑风暴是用于产生和收集项目需求与产品需求多种创意的技术，依靠团队成员集思广益、畅所欲言、相互启发达成目的。然而，头脑风暴会因与会人员的知识经验而受到限制。

访谈：

访谈是一种直接交流的方法，用于从相关方那里收集信息，可以是非正式对话或结构化的问答。它通常涉及一个访谈者和一个被访者之间的互动，但也适用于多人参与的情况。通过访谈项目团队成员、发起人、高管和领域专家，可以明确产品需求的特性和功能，同时获取敏感信息。

焦点小组：

召集项目相关方和主题专家，了解他们对所讨论的产品、服务或成果的期望和态度。由一位受过训练的主持人引导大家进行互动式讨论，讨论的对象一般聚焦在产品或项目的某一方面，且主题明确。

问卷调查：

问卷调查适用于多样化受众、快速需求、地理分散受访者及统计分析。设计时应针对目的和对象，注重人性化，并优先使用标准量表。

标杆对照：

标杆对照通过比较内部或外部组织的实际与计划做法，旨在识别最佳实践，提出改进建议，并作为绩效评估的标准。

3. 数据分析

数据分析技术如文件分析，涉及审查和评估相关文档以识别需求相关信息，适用于本过程。可分析的文件包括（但不限于）：

• 协议；
• 商业计划；
• 业务流程或接口文档；
• 业务规则库；
• 现行流程；
• 市场文献；
• 问题日志；
• 政策和程序；
• 法规文件，如法律、准则、法令等；
• 建议邀请书；
• 用例。
• 决策

适用于收集需求过程的决策技术包括（但不限于）：

投票：

投票是一种集体决策技术，用于评估并选择最佳行动方案，以达成期望结果，并辅助生成、分类和排序产品需求。常见的投票技术包括

• 一致同意：每个人都同意某个行动方案。
• 大多数同意：获得群体中超过 50%人员的支持即可做出决策。将参与决策的小组人数设为奇数，可避免平局导致无法决策。
• 相对多数同意：依据群体中相对多数人的意见做出决策，即便未获大多数人支持，通常在候选项超过两个时使用。

独裁型决策制定：

这种决策技术是由一个人做出最终决定，必要时可起到高效决策的作用。

多标准决策分析：

在相互冲突的多方案中进行选择，就是根据准则层的各项准则分别给方案层的各个方案打分，然后汇总分数，总分最高的方案胜出，成为目标方案。

例如，在找工作时，A、B、C 三家公司都愿意聘用您。此时，您可能需要考虑诸多因素，像“工资高”“工作不累”“离家近”“行业地位高”“领导英明”等，这些因素就是准则层里的准则。按照这些准则给三家公司打分，最终总分最高的那家公司就是您的选择目标（见图4）。

图-4 多标准决策分析

当然，如果您认为这些准则的重要性不同，那么可以给准则设置权重。比如，将“工资高”的权重设为 1，“工作不累”的权重设为 0.8，“行业地位高”的权重设为 1.2 或者 1.5。用每个准则的得分乘以相应权重，再合计总分，哪家公司总分最高，哪家公司就是您的选择目标。这种方法就是“加权多标准决策”。

5. 数据表现

亲和图：

亲和图法也称作 KJ 法，其创始人是东京工业大学教授、人文学家川喜田二郎，KJ 是他英文名（Jiro Kawakita）的缩写。

亲和图法是借助头脑风暴法收集语言文字资料，如事实、意见和设想等，再依据资料间的亲和性进行归类，从而从复杂现象中找出规律、抓住本质、理清思路的一种方法。

例如，开发一款新手机需要满足用户哪些需求？我们能够通过头脑风暴法来收集。每个人把想到的需求写在便利贴上，然后贴在白板上（见图5）。

图-5 头脑风暴

经过分享、讨论、投票等方式，按照需求间的亲和性将其归类，形成若干组需求（见图6）。

图-6 亲和图

思维导图：

思维导图是一种表达发散性思维的高效图形思维工具，它采用图文并重的技巧，通过相互隶属与相互关联的层级图来展现各级主题的关系，并且将主题关键词与图像、颜色等建立记忆连接。

思维导图能够帮助人们在逻辑与想象之间实现平衡发展，开启人类大脑的无限潜能（见图7）。

图-7 思维导图

6. 人际关系与团队技能

可用于本过程的人际关系与团队技能包括（但不限于）：

名义小组技术：

名义小组技术是用于促进头脑风暴的一种技术，通过投票对创意进行排列，以进一步开展头脑风暴或进行优先排序。名义小组技术是一种结构化的头脑风暴形式，包含以下四个步骤：

• 向集体提出一个问题或难题。每个人在沉思后写出自己的想法；
• 主持人在活动挂图上记录所有人的想法；
• 集体讨论各个想法，直至全体成员达成明确的共识。
• 个人私下投票决定各种想法的优先排序，通常采用 5 分制，1 分最低，5 分最高。为减少想法数量、集中关注重点想法，可进行数轮投票。每轮投票后，都会清点选票，得分最高者被选出。

观察和交谈：

直接观察个人在实际环境中的工作执行和流程实施来获取需求的方法。在用户难以表达需求时，这种方法尤为重要，可以是通过旁站观察或参与观察来深入了解工作细节，从而发现潜在需求。

引导：

召集关键相关方参与研讨会，以快速梳理跨职能需求并解决差异。这种集体互动有助于建立信任、改善沟通，并促进共识，同时相较于个别会议，更能及时发现并解决问题。

适合采用引导技能的情境包括（但不限于）：联合应用设计或开发 (JAD)、质量功能展开 (QFD)、用户故事。

联合应用设计或开发 (JAD) : :

适用于软件开发行业。在这个过程中，客户会被邀请与开发团队一同通过一系列的研讨会来收集需求，并改进软件开发过程。客户的持续参与有诸多好处，既有利于客户充分了解项目并及时给出反馈，又有利于团队更深入地理解客户的真实需求。

质量功能展开 (QFD) : :

这个工具在新产品研发项目中极为常用，能够将用户需求转化为产品功能，以开发出最贴合用户需求的产品功能。质量功能展开由赤尾洋二和水野滋两位日本教授于 20 世纪 60 年代作为一项质量管理系统提出，其目的在于设计、生产出能够充分满足用户需求的产品和服务。在产品或服务的开发进程中，公司必须聆听“用户的声音”。

例如，当我们开发一款新手机时，需要先从用户需求出发，找出用户最为看重的产品功能和特点，比如“自拍美美哒”“外观高大上”等。但这些都是用户语言，开发工程师难以精确把握这些真实却“不专业”的表述，所以需要把这些用户语言转化为工程语言。那么，怎样实现“自拍美美哒”这个用户需求呢？我们需要配备像素足够高的前置摄像头、AI 美颜算法、尺寸足够大的传感器，这些就是工程性能指标（见图8）。

图-8 手机质量功能展开

接下来，我们需要对用户需求和工程性能指标之间的关系进行分析。“实心圆”代表非常积极，“空心圆”意味着中等积极，“实心五角星”表示中等消极，“空心五角星”则表示非常消极。

我们能够选择几个竞品来进行对比，瞧瞧我们的产品设计在这些工程性能指标方面能够获得多少分数，竞品又能获得多少分数。

针对用户最关心的需求，我们要去验证他们对于我们的产品的体验状况，以及对竞品的体验情况，是好、中等，还是差。我们应当保证重要性相对较高的需求优先得到满足，如此我们的产品才能够具有竞争力。

上图（见图 8） 中的“冲突矩阵”指的是工程性能指标之间存在冲突。举例来说，如果追求极致的屏占比，那么就很难布置前置摄像头；如果要求电池容量大，就很难把手机做成超薄的。

这个矩阵的作用在于把用户的原始需求转化为工程性能指标，之后团队才能够进一步去设计零件、工艺等。这个矩阵的外形如同一座小房子，所以我们也将其称为“质量屋”（见图9）。

图-9 质量功能展开(QFD)四步法

质量功能展开( QFD)通常分为以下四个步骤。

第一步：产品规划矩阵，把用户需求转化为设计要求；

第二步：零件规划矩阵，把设计要求转化为零件特性；

第三步：工艺规划矩阵，把零件特性转化为工艺要求；

第四步：工艺 / 质量规划矩阵，把工艺要求转化为生产要求。

用户故事 :

用户故事是对于所需功能的简要文字阐述，常常产生于需求研讨会。用户故事会描述哪一个相关方会从功能当中受益（角色），他需要达成什么（目标），以及他期望获取什么样的利益（动机）。（注：具体可参见 第三章节：敏捷场景下的需求管理）

7. 系统交付图

系统交互图作为范围模型的一部分，提供了产品范围的可视化表示，展示了业务系统与用户及其他系统间的交互，包括系统的输入输出及其来源和接收者（见图10）。

图-10 系统交互图

8. 原型法

原型法是指在制造预期产品前，先造出其模型以征求早期需求反馈。原型包括微缩产品、计算机生成的二维和三维模型、实体模型或模拟。由于原型是有形实物，能让相关方体验最终产品模型，而非局限于讨论抽象需求描述。原型法支持渐进明细理念，需经历模型创建、用户体验、反馈收集及原型修改的反复循环。经足够反馈循环后，可从原型获取足够需求信息，进而进入设计或制造阶段。

故事板是一种原型技术，通过系列图像或图示展示顺序或导航路径，用于电影、广告、教学设计及敏捷等各种行业和项目。

2.3 收集需求：输出

1. 需求文件

需求文件详细阐述如何满足业务需求的各类单一需求，从高层级需求开始，逐步细化。需求必须明确、可追踪、完整、协调，并得到主要相关方的认可才能成为基准。需求文件形式多样，可以是简单的列表或包含详细内容和附件的复杂文档。

需求通常分为：

• 业务需求：组织层面的高层级需求，如解决业务问题或抓住机会；

• 相关方需求：特定相关方或群体的需求；

• 解决方案需求：产品、服务或成果需满足的特性，分为：

  • 功能需求：产品应执行的具体功能；

  • 非功能需求：产品运行所需的环境条件或质量标准，如性能、安全性等。

• 过渡和就绪需求：实现从当前到未来状态所需的临时能力，如培训；

• 项目需求：项目必须满足的条件，如关键日期、合同要求；

• 质量需求：确认项目成功的条件或标准，如测试和认证。

• 需求跟踪矩阵

需求跟踪矩阵是一种表格，它将产品需求与其来源和相应的可交付成果相连接，确保每个需求都与业务或项目目标相关联，具有商业价值。该矩阵提供了一种在整个项目周期内跟踪需求的方法，确保所有批准的需求在项目结束时得到满足，并为管理范围变更提供框架。

需求跟踪包括（但不限于）：

• 业务需要、机会、目的和目标；
• 项目目标；
• 项目范围和 WBS 可交付成果；
• 产品设计；
• 产品开发；
• 测试策略和测试场景；
• 高层级需求到详细需求。

需求跟踪矩阵应记录需求的关键属性，如唯一标识、描述、理由、所有者、来源、优先级、版本、状态及日期。为提高相关方满意度，可能还需记录稳定性、复杂性和验收标准等额外属性。下图（见图11）展示了一个包含这些属性的需求跟踪矩阵示例。

图-11 需求跟踪矩阵示例

三、敏捷场景下的需求管理

3.1 产品属性

卡诺模型（Kano Model）也称作“狩野模型”，日本品牌管理大师狩野纪昭（Noriaki Kano ）博士把产品属性分为了五类（见图12）。

图-12 卡诺模型

• 魅力属性（Attractive）：这是能让用户喜出望外的属性。即便产品不具有该属性，用户的满意度也不会下降；然而，倘若产品具备此属性，用户的满意度会大幅提高。例如，对于多数用户来说，手机的无线充电功能、屏幕可折叠等功能并非不可或缺，但如果手机拥有这些炫酷功能，用户会非常开心。
• 期望属性（One-Dimensional）：也被称为线性属性，客户的满意度与产品的该属性呈线性关系。例如，手机的待机时间越长、屏占比越大，用户就越满意。
• 无差异属性（Indifference）：属于让用户不敏感的属性。不管产品具备与否，用户的满意度都不会发生改变。例如，手机的线路板是几层的，绝大多数用户并不在乎。
• 必备属性（Must-Be）：这是用户对产品的基本需求。要是产品不具备，用户的满意度会大幅降低，甚至无法接受。
• 反向属性（Reverse）：这是用户根本没有的此类需求。产品所具备的这类属性越多，用户就越不满意。例如，手机里预装的软件越多，就越令用户反感。

卡诺模型告诉我们，在我们的时间和资源有限的情况下，应当优先提升必备属性，其次是期望属性；如果我们有能力，再去提供魅力属性，以此拉开与竞品的差距；用户对无差异属性并不在意，所以我们无需刻意追求；我们应尽可能避免提供反向属性，以免弄巧成拙。

3.2 精益画布

当企业产生了一个极为美妙的想法时，众多企业会依照流程规定编制内容详尽的商业计划书、可行性研究报告。长达几十页甚至上百页的报告常常需要花费几周乃至几个月的时间。然而，在精益创业模式里，运用一张精益画布便能够解决此问题。

精益画布是从商业模式画布(见图13）中发展而来的，包含9个部分（见图14）。

图-13 商业模式画布

图-14 老人打车项目精益画布

3.3 最小可发布版本( Minimum Marketable Release，MMR)

产品开发要经历漫长的过程。对于创新产品而言，如果企业未曾发布过一个版本，就无法验证这款产品究竟有没有真正的客户。

虽然在商业论证阶段，产品创意已经通过最小可行性产品（Minimum Viable Product，MVP）得到了验证，但 MVP 与真正的产品有所不同，MVP 是用于验证假设的试验品，而 MMR 才是真正能够被客户购买的产品。企业没有生产出真正的产品，只是用 MVP 验证出客户的“购买意愿”，这并不意味着客户见到产品后会真正购买。

团队需要从产品待办事项列表中精心挑选出最具价值的特性，并制作出一个成本最小的产品迅速投放至市场上。

MMR 的原则如下：

• 最简特性清单：依据精益画布，舍弃不属于核心价值主张的特性；依据卡诺模型，去除产品非必需的特性。团队针对每个特性都要自问：没有它会怎样？如果没有它并不影响用户使用，那么它就不应出现；
• 最小特性颗粒：竭尽全力把产品特性拆分成子特性，一直拆分到无法拆分的程度（倘若继续拆分，就无法为用户提供独立的价值）；
• 最少特性组合：根据莫斯科法则（MoSCoW），对梳理出来的特性清单进一步排出优先级，只开发最基本的特性，也就是产品必须具备的特性。

莫斯科法则（MoSCoW）如下：

• 必须有的特性（Must Have）：若没有，产品不可行；
• 应该有的特性（Should Have）：非常重要但并非必需的特性，可以通过其他方法替代或暂时不提供；
• 可以有的特性（Could Have）：有了更好，没有也行。只有在时间允许、资源充裕的情况下，企业才会考虑；
• 不该有的特性（Would not Have）：不关键、不必要，且不应在这个版本中考虑的特性。

下图（见图 15）展示的是运用莫斯科法则对某银行移动客户端（App）进行的需求分析。对用户来说，必须有的特性是“注册/登录”“查询余额”“转账汇款”，应该有的特性是“收支明细”“指纹登录”，可以有的特性是“投资理财”“个人贷款”，不该有的特性是“手机充值”“水电缴费”。最小可发布版本（MMR）所具备的正是“必须有的特性”。

图-15 莫斯科法则

3.4 产品待办事项列表( Product Backlog )

产品待办事项列表具有如下特征：

• 详略适当（Detailed appropriately）：优先级越高的待办事项，其描述就越详细；反之，描述则越简略；
• 经过估算（Estimated）：产品待办事项列表中的条目是经过估算的，不过这些估算是粗颗粒度的，通常以故事点或者理想人天的形式来表达；
• 涌现的（Emergent）：产品待办事项列表中的条目是动态的、持续演化的。依据客户和用户的反馈，能够随时增减和调整待办事项的优先级，并且，现有的条目能够不断被修订、细化，甚至移除；
• 按优先级排序（Prioritized）：最重要的事项优先级最高，位于产品待办事项列表的最顶层，最先被实施。

分解和细化产品待办事项列表中的条目：

在下一次迭代开始之前，虽然产品负责人应当准备充足的细颗粒条目，但无需将所有条目都分解细化，这样做的目的是将花费在描述产品上的时间和资源降至最低。由于条目是动态且变化的，所以分解和细化条目的工作也是周期性的（见图16）。

图-16 产品待办事项列表的优先级

如果产品待办事项列表中存在同样重要的活动，那么团队应该先开展哪一个呢？

我们可以采用 WSJF 原则，也就是“最短作业优先”原则。通过公式“WSJF = 延期满足的代价 / 这项活动的历时估算”来计算每项活动 WSJF 的分数，分数最高的活动就是我们应该优先进行的。

如下图（见图17），如果我们按照 WSJF 分数从高到低的顺序依次进行 A、B、C，那么与按照 C、B、A 的顺序相比，虽然总历时相同，但是总体延期的代价（黄色面积）却要小得多。

图-17 WSJF原则

3.5 用户故事( User Story )

用户故事是一种表述用户需求的固定语法：

作为一个<角色>，我想要<活动>，以便于<商业价值>。

通常团队在识别用户需求时，会使用便利贴依照上述语法将用户的需求表达出来，用于看板或产品待办事项列表的分析，如下图所示（见图18）：

图-18 用户故事卡片

用户故事地图：

绘制用户故事地图，需要召开一次用户故事会议，参加会议的人员必须是各岗位的关键角色，涵盖产品负责人、项目负责人、业务负责人、技术人员以及老板。会议人数需控制在 7 人以内，但不能少于 3 人。这些人员均代表了产品开发的主要角色。

如下图所示（见图19），横轴代表业务流程，即从时间维度上用户使用产品的一般顺序；竖轴代表故事的颗粒度大小，由上到下，按照一级故事、二级故事、细节故事进行分解，或者竖轴代表商业价值，商业价值高的故事排在上面，并且优先实现发布。发布 1 所代表的版本就是我们上面探讨过的 MMR，即最小可发布版本。

图-19 用户地图故事