《PMBOK指南第六版》第5章 项目范围管理 ——> 收集需求

第5章 项目范围管理 ——> 收集需求

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

5.2.1、收集需求：输入

5.2.1.1、项目章程

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

5.2.1.2 项目管理计划

见 4.2.3.1 节。项目管理计划组件包括（但不限于）：

• • • 范围管理计划。见 5.1.3.1 节。范围管理计划包含如何定义和制定项目范围的信息。
    • 需求管理计划。见 5.1.3.2 节。需求管理计划包含如何收集、分析和记录项目需求的信息。
    • 相关方参与计划。

见 13.2.3.1 节。从相关方参与计划中了解相关方的沟通需求和参与程度，

以便评估并适应相关方对需求活动的参与程度。

5.2.1.3 项目文件

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

• 假设日志。见 4.1.3.2 节。假设日志识别了有关产品、项目、环境、相关方以及会影响需求的其他因素的假设条件。

• 经验教训登记册。见 4.4.3.1 节。经验教训登记册提供了有效的需求收集技术，尤其针对使用迭代型或适应型产品开发方法的项目。

• 相关方登记册。见 13.1.3.1 节。相关方登记册用于了解哪些相关方能够提供需求方面的信息，及记录相关方对项目的需求和期望。

5.2.2、收集需求：工具与技术

5.2.2.1、专家判断

见 4.1.2.1 节。应该就以下主题，考虑具备相关专业知识或接受过相关培训的个人或小组的意见：

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

5.2.2.2、数据收集

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

头脑风暴。 本技术用于在短时间内获得大量创意，适用于团队环境，需要引导者进行引导。头脑风暴由两个部分构成：创意产生和创意分析。制定项目章程时可通过头脑风暴向相关方、主题专家和团队成员收集数据、解决方案或创意。 头脑风暴是一种用来产生和收集对项目需求与产品需求的多种创意的技术。

访谈。 访谈是通过与相关方直接交谈，来获取信息的正式或非正式的方法。 访谈的典型做法是向被访者提出预设和即兴的问题，并记录他们的回答。访谈经常是一个访谈者和一个被访者之间的“一对一”谈话，但也可以包括多个访谈者和/或多个被访者。访谈有经验的项目参与者、发起人和其他高管，以及主题专家，有助于识别和定义所需产品可交付成果的特征和功能。 访谈也可用于获取机密信息。

焦点小组。

焦点小组是召集预定的相关方和主题专家，了解他们对所讨论的产品、服务或成果的期望和态度。由一位受过训练的主持人引导大家进行互动式讨论。焦点小组往往比“一 对一”的访谈更热烈。

问卷调查。

问卷调查是指设计一系列书面问题，向众多受访者快速收集信息。

问卷调查方法非常适用于以下情况： 受众多样化，需要快速完成调查，受访者地理位置分散，并且适合开展统计分析。

标杆对照见。

标杆对照是将实际或计划的项目实践或项目的质量标准与可比项目的实践进行比较，以便识别最佳实践，形成改进意见，并为绩效考核提供依据。作为标杆的项目可以来自执行组织内部或外部，或者来自同一应用领域或其他应用领域。标杆对照也允许用不同应用领域或行业的项目做类比。

5.2.2.3、数据分析

　　见 4.5.2.2 节。可用于本过程的数据分析技术包括（但不限于）文件分析。文件分析包括审核和评估任何相关的文件信息。在此过程中，文件分析用于通过分析现有文件，识别与需求相关的信息来获取需求。有助于获取相关需求的文件很多。可供分析的文件包括（但不限于）：

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

5.2.2.4、决策

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

• • • 投票。投票是一种为达成某种期望结果，而对多个未来行动方案进行评估的集体决策技术和过程。本技术用于生成、归类和排序产品需求。投票技术示例包括： 
    • 一致同意。每个人都同意某个行动方案。  
      • 大多数同意。获得群体中超过 50% 人员的支持，就能做出决策。把参与决策的小组人数定为奇数，可防止因平局而无法达成决策。
      • 相对多数同意。根据群体中相对多数人的意见做出决策，即便未能获得大多数人的支持。通常在候选项超过两个时使用。
      • 独裁型决策制定。采用这种方法，将由一个人负责为整个集体制定决策。
    • 多标准决策分析。该技术借助决策矩阵，用系统分析方法建立诸如风险水平、不确定性和价值收益等多种标准，以对众多创意进行评估和排序。

• 5.2.2.5、数据表现

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

• 亲和图。用来对大量创意进行分组的技术，以便进一步审查和分析。
• 思维导图。把从头脑风暴中获得的创意整合成一张图，用以反映创意之间的共性与差异，激发新创意。

5.2.2.6、人际关系与团队技能

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

　　名义小组技术。

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

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

　　观察和交谈。

　　观察和交谈是指直接察看个人在各自的环境中如何执行工作（或任务）和实施流程。当产品使用者难以或不愿清晰说明他们的需求时，就特别需要通过观察来了解他们的工作细节。观察，也称为“工作跟随”，通常由旁站观察者观察业务专家如何执行工作，但也可以由“参与观察者”来观察，通过实际执行一个流程或程序，来体验该流程或程序是如何实施的，以便挖掘隐藏的需求。

　　引导。

　　见 4.1.2.3 节。引导与主题研讨会结合使用，把主要相关方召集在一起定义产品需求。研讨会可用于快速定义跨职能需求并协调相关方的需求差异。因为具有群体互动的特点，有效引导的研讨会有助于参与者之间建立信任、改进关系、改善沟通，从而有利于相关方达成一致意见。此外，与分别召开会议相比，研讨会能够更早发现并解决问题。

　　适合采用引导技能的情境包括（但不限于）：

• • 联合应用设计或开发(JAD)。JAD 会议适用于软件开发行业。这种研讨会注重把业务主题专家和开发团队集中在一起，以收集需求和改进软件开发过程。
  • 质量功能展开(QFD)。制造行业则采用QFD 这种引导技能来帮助确定新产品的关键特征。QFD从收集客户需要（又称“客户声音”）开始，然后客观地对这些需要进行分类和排序，并为实现这些需要而设定目标。
  • 用户故事。用户故事是对所需功能的简短文字描述，经常产生于需求研讨会。用户故事描述哪个相关方将从功能中受益（角色），他需要实现什么（目标），以及他期望获得什么利益（动机）。

5.2.2.7、系统交互图

　　系统交互图是范围模型的一个例子，它是对产品范围的可视化描绘，显示业务系统（过程、设备、计算机系统等）及其与人和其他系统（行动者）之间的交互方式（见图5-6）。系统交互图显示了业务系统的输入、输入提供者、业务系统的输出和输出接收者。

5.2.2.8、原型法

　　原型法是指在实际制造预期产品之前，先造出该产品的模型，并据此征求对需求的早期反馈。原型包括微缩产品、计算机生成的二维和三维模型、实体模型或模拟。因为原型是有形的实物，它使得相关方可以体验最终产品的模型，而不是仅限于讨论抽象的需求描述。原型法支持渐进明细的理念，需要经历从模型创建、用户体验、反馈收集到原型修改的反复循环过程。在经过足够的反馈循环之后，就可以通过原型获得足够的需求信息，从而进入设计或制造阶段。

　　故事板是一种原型技术，通过一系列的图像或图示来展示顺序或导航路径。故事板用于各种行业的各种项目中，如电影、广告、教学设计，以及敏捷和其他软件开发项目。在软件开发中，故事板使用实体模型来展示网页、屏幕或其他用户界面的导航路径。

5.2.3、收集需求：输出

5.2.3.1、需求文件 

　　需求文件 描述各种单一需求将如何满足与项目相关的业务需求。一开始可能只有高层级的需求，然后随着有关需求信息的增加而逐步细化。只有明确的（可测量和可测试的）、可跟踪的、完整的、相互协调的，且主要相关方愿意认可的需求，才能作为基准。需求文件的格式多种多样，既可以是一份按相关方和优先级分类列出全部需求的简单文件，也可以是一份包括内容提要、细节描述和附件等的详细文件。

5.2.3.2、需求跟踪矩阵

　　需求跟踪矩阵 是把产品需求从其来源连接到能满足需求的可交付成果的一种表格。使用需求跟踪矩阵，把每个需求与业务目标或项目目标联系起来，有助于确保每个需求都具有商业价值。需求跟踪矩阵提供了在整个项目生命周期中跟踪需求的一种方法，有助于确保需求文件中被批准的每项需求在项目结束的时候都能交付。最后，需求跟踪矩阵还为管理产品范围变更提供了框架。

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

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

　　应在需求跟踪矩阵中记录每个需求的相关属性，这些属性有助于明确每个需求的关键信息。需求跟踪矩阵中记录的典型属性包括唯一标识、需求的文字描述、收录该需求的理由、所有者、来源、优先级别、版本、当前状态（如进行中、已取消、已推迟、新增加、已批准、被分配和已完成）和状态日期。为确保相关方满意，可能需要增加一些补充属性，如稳定性、复杂性和验收标准。