项目管理知识体系指南 （PMBOK®指南）第六版 第五章

项目管理知识体系指南 （PMBOK®指南）第六版 第五章 项目范围管理

项目管理知识体系指南 （PMBOK®指南）

• 项目范围管理
  • 项目范围管理包括确保项目做且只做所需的全部工作以成功完成项目的各个过程。
    • • “范围”含义
        • 产品范围。某项产品、服务或成果所具有的特征和功能。
        • 项目范围。为交付具有规定特性与功能的产品、服务或成果而必须完成的工作。项目范围有时也包括产品范围。
      • 不同生命周期的范围管理对比
      • 裁剪时应考虑的因素
        • 知识和需求管理。组织是否拥有正式或非正式的知识和需求管理体系?为了在未来项目中重复使用需求，项目经理应建立哪些指南?
        • 确认和控制。组织是否拥有正式或非正式的与确认和控制相关的政策、程序和指南?
        • 开发方法。组织是否采用敏捷方法管理项目?开发方法属于迭代型还是增量型?是否采用预测型方法?混合型方法是否有效?
        • 需求的稳定性。项目中是否存在需求不稳定的领域?是否有必要采用精益、敏捷或其他适应型技术来处理不稳定的需求，直至需求稳定且定义明确?
        • 治理。组织是否拥有正式或非正式的审计和治理政策、程序和指南?
      • 商业分析师和PM在需求范围管理中有什么不同侧重？应该将商业分析的角色连同职责分配给具有足够商业分析技能和专业知识的人员。如果项目已配备商业分析师，那么与需求管理相关的活动便是该角色的职责。而PM则负责确保这些活动在项目管理计划有所安排，并且在预算内按时完成，同时能够创造价值。
  • 规划范围管理
    • 定义：为记录如何定义、确认和控制项目范围及产品范围，而创建范围管理计划的过程。
    • 作用：在整个项目期间对如何管理范围提供指南和方向。
    • ITTO
      • • 专家判断-德尔菲技术
          • 德尔菲法本质上是一种反馈匿名函询法。其大致流程是：在对所要预测的问题征得专家的意见后，进行整理、归纳、统计，再匿名反馈给各专家，再次征求意见，再集中，再反馈，直到得到一致意见。
          • 德尔菲技术可以做到在防止任何人对结果产生不适当的影响的情况下，达成各位专家的一致意见。
    • 数据流向图
    • 输出
      • 范围管理计划
        • 范围管理计划是项目或项目集管理计划的组成部分，描述将如何定义、制定、监督、控制和确认项目范围。
        • 范围管理计划要对将用于下列 工作的管理过程做出规定
          • 制定项目范围说明书
          • 根据详细项目范围说明书创建 WBS
          • 确定如何审批和维护范围基准
          • 正式验收已完成的项目可交付成果
    • 需求管理计划
      • 需求管理计划是项目管理计划的组成部分，描述将如何分析、记录和管理项目和产品需求。
      • 内容
        • 如何规划、跟踪和报告各种需求活动
        • 配置管理活动，例如，如何启动变更，如何分析其影响，如何进行追溯、跟踪和报告，以及变更审批权限
        • 需求优先级排序过程
        • 测量指标及使用这些指标的理由
        • 反映哪些需求属性将被列入跟踪矩阵的跟踪结构
    • 范围VS需求
  • 收集需求
    • 定义：为实现项目目标而确定、记录并管理相关方的需要和需求的过程。
    • 作用：为定义产品范围和项目范围奠定基础。 需求将成为工作分解结构(WBS)的基础，也将成为成本、进度、质量和采购规划的基础。
    • 需求的特点
      • 多样性 复杂性
      • 隐蔽性 差异性
      • 变化性 矛盾性
    • ITTO
    • 数据流向图
    • 工具与技术
      • 数据收集
        • 头脑风暴
          • 头脑风暴是一种用来产生和收集对项目需求与产品需求的多种创意的技术。头脑风暴受与会人员知识经验所限。
          • 如何进行头脑风暴？ 头脑风暴用于在短时间内获得大量创意，适用于团队环境，需求引导者进行引导。
          • 头脑风暴由两个部分构成：创意产生和创意分析。制定项目章程时可通过头脑风暴
          • 向相关方、主题专家和团队成员收集数据、解决方案或创意。
        • 访谈
          • 访谈是通过与相关方直接交谈，来获取信息的正式或非正式的方法。 访谈的典型做法是向被访者提出预设和即兴的问题， 并记录他们的回答。
          • 访谈经常是一个访谈者和一个被访者之间的“一对一”谈话，但也可以包括多个访谈者和/或多个被访者。
          • 访谈有经验的项目参与者、发起人和其他高管，以及主题专家，有助于识别和定义所需产品可交付成果的特征和功能。
          • 访谈也可用于获取机密信息。
        • 焦点小组
          • 焦点小组是召集预定的相关方和主题专家，了解他们对所讨论的产品、服务或成果的期望和态度。由一位受过训练的主持人引导大家进行互
          • 动式讨论。一般聚焦在产品或项目的某一方面，主题明确。
        • 问卷调查
          • 问卷调查是指设计一系列书面问题，向众多受访者快速收集信息。 问卷调查方法非常适用于以下情况:受众多样化， 需要快速完成
          • 调查，受访者地理位置分散，并且适合开展统计分析。
          • 问卷调查应紧密围绕调查目的，面向调查对象，坚持人性化，
          • 并优先选用经广泛认可的标准量表。
        • 标杆对照
          • 标杆对照将实际或计划的产品、过程和实践，与其他可比组织的实践进行比较，以便识别最佳实践，形成改进意见，并为绩效考核提供依据。标杆对照所采用的可比组织可以是内部的，也可以是外部的。
      • 决策
        • 投票
        • 独裁
        • 多标准决策分析
          • 该技术借助决策矩阵，用系统分析方法建立诸如风险水平、不确定性和价值收益等多种标准，以对众多创意进行评估和排序。
          • 在相互冲突的多方案中进行选择的决策。
      • 数据表现
        • 亲和图（KJ法）为日本川喜田二郎所创。 把具有相同特征的需求归类，用不同颜色或不同符号标示，还可建立起需求之间的逻辑关系。
        • 思维导图
          • 表达发散性思维的有效的图形思维工具。运用图文并重的技巧，把各级主题的关系用相互隶属与相关的层级图表现出来，把主题关键词与图像、颜色等建立记忆链接。
      • 人际关系与团队技能
        • 名义小组
          • 1. 小组成员先不通气，独立思考；
          • 2. 各自写下备选方案和意见；
          • 3. 轮流陈述自己的方案和意见；
          • 4. 小组成员对全部备选方案投票；
          • 5. 得票最多的备选方案入选；
          • 6.当然，管理者仍有权否决这一方案。
        • 观察和交谈
          • 观察和交谈是指直接察看个人在各自的环境中如何执行工作(或任务)和实施流程。 当产品使用者难以或不愿清晰说明他们的需求时，就特别需要通过观察来了解
          • 他们的工作细节。观察对象更适合标准化作业和体力劳动者。
        • 引导式研讨会
          • 引导与主题研讨会结合使用，把主要相关方召集在一起，通过集中讨论来定义产品需求。 研讨会可用于快速定义跨职能需求并协调相关方的需求差异。
          • 应用场景
            • 联合应用设计或开发 (JAD)。JAD 会议适用于软件开发行业。这种研讨会注重把业务 主题专家和开发团队集中在一起，以收集需求和改进软件开发过程。
            • 质量功能展开 (QFD)。制造行业则采用 QFD 这种引导技能来帮助确定新产品的关键特征。 QFD从收集客户需要(又称“客户声音”)开始，然后客观地对这些需要进行分类和排序，并为实现这些需要而设定目标。
            • 用户故事。用户故事是对所需功能的简短文字描述，经常产生于需求研讨会。 用户故事描述哪个相关方将从功能中受益(角色)，他需要实现什么(目标)，以及他期望获得什么利益(动机)。作为一个<角色>，我想要<活动>，以便于<商业价值>。
        • 故事板Story Board
          • 可视化版本
      • 系统交互图
        • 系统交互图是范围模型的一个例子，它是对产品范围的可视化描绘，显示业务系统(过程、设备、计算机系统等)及其与人和其他系统(行动者)之间的交互方式。系统交互图显示了业务系统的输入、输入提供者、业务系统的输出和输出接收者。
      • 原型法
        • 在实际制造预期产品之前，先造出该产品的模型，并据此征求对需求的早期反馈。
        • 适用情况：原型法支持渐进明细的理念，需要经历从模型创建、用户体验、反馈收集到原型修改的反复循环过程。
        • 故事板是一种原型技术，通过一系列的图像或图示来展示顺序或导航路径。故事板用于各种行业的各种项目中，如电影、广告、教学设计，以及敏捷和其他软件开发项目。在软件开发中，故事板使用实体模型来展示网页、屏幕或其他用户界面的导航路径。
    • 输出
      • 需求文件
        • 作用：需求文件描述各种单一需求将如何满足与项目相关的业务需求。
        • 内容：一开始可能只有高层级的需求，然后随着有关需求信息的增加而逐步细化。只有明确的（可测量和可测试的）、可跟踪的、完整的、相互协调的，且主要相关方愿意认可的需求，才能作为基准。需求文件的格式多种多样，既可以是一份按相关方和优先级分类列出全部需求的简单文件，也可以是一份包括内容提要、细节描述和附件等的详细文件。
      • 需求跟踪矩阵
        • 需求跟踪矩阵是把产品需求从其来源连接到能满足需求的可交付成果的一种表格。
          • 业务需要、机会、目的和目标
          • 项目目标
          • 项目范围和 WBS 可交付成果
          • 产品设计
          • 产品开发
          • 测试策略和测试场景
          • 高层级需求到详细需求
        • 作用
          • 把每个需求与业务目标或项目目标联系起来，有助于确保每个需求都具有商业价值。
          • 提供了在整个项目生命周期中跟踪需求的一种方法，有助于确保需求文件中被批准的每项需求在项目结束的时候都能交付。
          • 为管理产品范围变更提供了框架。
        • 需求跟踪矩阵中记录的典型属性包括唯一标识、需求的文字描述、收录该需求的理由、所有者、来源、优先级别、版本、当前状态(如进行中、已取消、已推迟、新增加、已批准、被分配和已完成)和状态日期。
      • 示例
  • 定义范围
    • 定义：制定项目和产品详细描述的过程。
    • 作用：描述产品、服务或成果的边界和验收标准。
    • 有了需求，为什么还要再定义范围？ 由于在收集需求过程中识别出的所有需求未必都包含在项目中，所以定义范围过程就要从需求文件（收集需求过程的输出）中选取最终的项目需求，然后制定出关于项目及其产品、服务或成果的详细描述。准备好详细的项目范围说明书，对项目成功至关重要。
    • ITTO
      • • 备选方案分析
          • 可用于评估项目章程中所述的需求和目标的各种方法。
          • 包括的技术
            • 确定采用哪些进度计划的方法，以及如何将不同方法整合到项目中。
            • 确定进度计划的详细程度、滚动式规划的持续时间，以及审查和更新频率。
        • 产品分析
          • 产品分析可用于定义产品和服务，包括针对产品或服务提问并回答，以描述要交付的产品的用途、特征及其他方面。
          • 产品分析技术
            • 产品分解
            • 需求分析
            • 系统分析
            • 系统工程
            • 价值分析
            • 价值工程
    • 数据流向图
    • 项目范围说明书
      • 完整、准确的定义范围通常是项目成功的关键。
      • 定义：项目范围说明书是对项目范围、主要可交付成果、假设条件和制约因素的描述。
      • 作用
        • 记录了整个范围，包括项目和产品范围;详细描述了项目的可交付成果; 还代表项目相关方之间就项目范围所达成的共识。为便于管理相关方
        • 的期望，项目范围说明书可明确指出哪些工作不属于本项目范围。
        • 使项目团队能进行更详细的规划，在执行过程中指导项目团队的工作， 并为评价变更请求或额外工作是否超过项目边界提供基准。
        • 项目范围说明书描述要做和不要做的工作的详细程度，决定着项目管 理团队控制整个项目范围的有效程度。
      • 内容
        • 产品范围描述。逐步细化在项目章程和需求文件中所述的产品、 服务或成果的特征。
        • 可交付成果。为完成某一过程、阶段或项目而必须产出的任何独特并可核实的产品、 成果或服务能力，可交付成果也包括各种辅助成果，如项目管理报告和文件。对可交付成果的描述可略可详。
        • 验收标准。可交付成果通过验收前必须满足的一系列条件。
        • 项目的除外责任。识别排除在项目之外的内容。明确说明哪些内容 不属于项目范围，有助于管理相关方的期望及减少范围蔓延。
        • 制约因素。列举并描述与项目范围有关且会影响 项目执行的各种内外部制约或限制条件。
        • 假设条件。
      • 项目章程VS项目范围说明书
        • 不同之处在于
          • 项目排除项
  • 创建WBS
    • 定义：将项目可交付成果和项目工作分解为较小的、更易于管理的组件的过程。
    • 作用：为所要交付的内容提供一个结构化的视图。
    • ITTO
    • 数据流向图
    • WBS
      • 定义：WBS 是对项目团队为实现项目目标、创建所需可交付成果而需要实施的全部工作范围的层级分解。
      • 作用：WBS 组织并定义了项目的总范围，代表着经批准的当前项目范围说明书中所规定的工作。
      • 示例
      • 内容
        • 子项目Subproject
          • 整个项目的一部分。一个子项目是能够相对独立地作为“项目”来管理的，可由一个专业团队或一个分包组织负责。
        • 控制账户Control Account
          • 是一个管理控制点，在该控制点上，把范围、预算、实际成本和进度加以整合，并与挣值相比较，以测量绩效。
          • 项目管理实践中，通常控制账户和专业相对应，比如，控制账户1.2.1都是设计部门的工作，控制账户1.2.2都是开发部门的工作，这样有利于统计不同专业的工时（成本）。
        • 工作包Work Package
          • WBS最低层次组件，其中包括计划的工作，通常表达为可交付成果。工作包对相关活动进行归类，以便对工作安排进度、进行估算、开展监督与控制。
        • 规划包Planning Package
          • 规划包也是WBS的最低层次组件，位于控制账户下，工作范围已知，但包含的活动或对应的工期和预算当前未知，需随项目深入进一步确定。
            • 示例
        • 活动Activity
          • 活动是工作包（或规划包）的组成部分，不属于WBS组件。 活动描述中包含一个表示其动作的动词，如“开发微信支付接口”。一个活动通常有期望的持续时间、期望成本、期望资源需求。活动经常被细分为任务。
        • 任务Task
          • 通常是活动进一步分解的组成部分，不属于WBS组件，交由某个团队成员负责。
        • 账户编码Code of Account
          • WBS每层中的每个组件都有唯一的编码（例2.1.2.3），这个编码系统被称为账户编码。
          • WBS可以通过账户编码系统与组织分解结构OBS、资金分解结构ABS、风险分解结构RBS等建立起关联，形成项目核心控制系统，是项目管理信息系统（PMIS）的基础。
      • 创建WBS的方法
        • 自上而下
        • 使用组织特定的指南
        • 使用 WBS 模板
      • WBS结构
        • 以项目生命周期的各阶段作为分解的第二层，把产品和项目可交付成果放在第三层
        • 以主要可交付成果作为分解的第二层
        • 纳入由项目团队以外的组织开发的各种较低层次组件(如外包工作)。随后，作为外包工作的一部分，卖方须制定相应的合同 WBS。
      • WBS分解
        • 分解
          • 分解是一种把项目范围和项目可交付成果逐步划分为更小、更便于管理的组成部分的技术。
          • 工作包是WBS最底层的工作，可对其成本和持续时间进行估算和管理。
          • 把整个项目工作分解为工作包需进行的活动
            • 识别和分析可交付成果及相关工作
            • 确定 WBS 的结构和编排方法
            • 自上而下逐层细化分解
            • 为 WBS 组成部分制定和分配标识编码
            • 核实可交付成果分解的程度是否恰当
          • 分解原则
            • 分解的程度取决于所需的控制程度，以实现对项目的高效管理； 工作包的详细程度则因项目规模和复杂程度而异。
          • 分解局限性
            • 过细的分解会造成管理努力的无效耗费、资源使用效率低下、 工作实施效率降低，同时造成 WBS 各层级的数据汇总困难。
          • 项目分解结构
            • 流程
            • 项目分解结构的主要用途
              • 1.明确和准确说明项目的范围；
              • 2.为各独立单元分派人员，规定这些人员的相应职责；
              • 3.针对各独立单元，进行时间、费用、资源需要量的估算；
              • 4.确定项目进度测量和控制的基准；
              • 5.将项目工作与项目的财务账目联系起来；
              • 6.自上而下将项目目标落实到具体的工作上；
              • 7.确定工作内容和工作顺序；
              • 8.估计项目整体和全过程的费用。
        • WBS分解的100%原则
          • 一个WBS元素的下一层分解（子层）必须百分百的表示上一层（父层）元素的工作，不能有重复，更不能有遗漏。
        • WBS分解的原则和逻辑
          • 1.先管理分解、后产品分解，两者的混合物；
          • 2.便于精确的估算工作包的成本和工期；
          • 3.可分配给独立的组织和人来完成，便于管理和验收；
          • 4.IT项目一般一个工作包完成时间不超过40小时。
        • 分解思路
          • 基于功能的分解
          • 基于成果的分解
          • 基于工作过程的分解
        • 分解形式
          • 树状分解
          • 目录式分解
            • 用Excel表来呈现
        • WBS无论才去何种分解方式，每个WBS元素中都只有非常有限的信息量，更加详细的信息就需要WBS词典来辅助。
        • 对 WBS 较高层组件进行分解，就是要把每个可交付成果或组件分解为最基本的组成部分，即可核实的产品、服务或成果。 如果采用敏捷方法，可以将长篇故事分解成用户故事。WBS 可以采用提纲式、组织结构图或能说明层级结构的其他形式。
        • 滚动式规划
          • 要在未来远期才完成的可交付成果或组件，当前可能无法分解。 项目管理团队因而通常需要等待对该可交付成果或组成部分达成
          • 一致意见，才能够制定出 WBS 中的相应细节。
          • 这种技术有时称做滚动式规划。
      • WBS词典
        • 针对每个WBS组件，详细描述可交付成果活动和进度信息的文件。
        • 内容
          • 账户编码标识
          • 工作描述
          • 假设条件和制约因素
          • 负责的组织
          • 进度里程碑
          • 相关的进度活动
          • 所需资源
          • 成本估算
          • 质量要求
          • 验收标准
          • 技术参考文献
          • 协议信息
        • 示例
      • WBS的价值
        • 基准的来源
        • 计划的基础
        • 工作的展现
        • 控制的依据
        • 团队的指南
    • 范围基准
      • 范围基准是经过批准的范围说明书、WBS和相应的WBS词典，只有通过正式的变更控制程序才能进行变更，它被用作比较的基础。
      • 包含
        • 项目范围说明书
        • 工作分解结构WBS
        • 工作包
        • 规划包
        • WBS 词典
          • WBS 词典是针对 WBS 中的每个组件，详细描述可交付成果、活动和进度信息的文件。
      • 需求范围线
    • 责任分配矩阵RAM
  • 确认范围
    • 定义：正式验收已完成的项目可交付成果的过程。
    • 作用：使验收过程具有客观性;同时通过确认每个可交付成果，来提高最终产品、服务或成果获得验收的可能性。
    • 由客户或发起人审查从控制质量过程输出的核实的可交付成果，确认这些可交付成果已经圆满完成并通过正式验收。
    • 确认范围过程与控制质量过程的不同之处在于，前者关注可交付成果的验收，而后者关注可交付成果的正确性及是否满足质量要求。控制质量过程通常先于确认范围过程，但二者也可同时进行。
      • 确认范围VS质量控制
    • 确认范围过程在项目每个阶段结束时都需要及时执行，不应该累积到项目结束。
    • ITTO
      • • 检查是指开展测量、审查与确认等活动，来判断工作和可交付成果是否符合需求和产品验收标准。
        • 检查有时也被称为审查、产品审查和巡检等。
    • 数据流向图
  • 控制范围
    • 定义：监督项目和产品的范围状态，管理范围基准变更的过程。
    • 作用：在整个项目期间保持对范围基准的维护。
    • 控制项目范围确保所有变更请求、推荐的纠正措施或预防措施都通过实施整体变更控制过程进行处理。 在变更实际发生时，也要采用控制范围过程来管理这些变更。控制范围过程应该与其他控制过程协调开展。变更不可避免，因此在每个项目上，都必须强制实施某种形式的变更控制。
    • 范围蔓延
      • 定义：未经控制的产品或项目范围的扩大(未对时间、成本和资源做相应调整)被称为范围蔓延。
    • 形式
      • 爬行Scope Creeping
        • 在客户要求下，未经正常的范围变更控制程序而出现的产品或项目范围的扩大。
      • 镀金Gold Plating
        • 在定义范围的工作范围以外，项目团队主动增加的额外工作，但没有经过范围控制程序。
    • ITTO
    • 数据流向图