原文知识点
（5） 确认范围
- 没做范围确认
- 范围管理没做好，导致范围出现蔓延
- 范围确认存在问题，导致 WBS 中定义的功能没有开发
- 范围确认发现的问题没有及时有效的解决
（6） 控制范围
- 没做好范围控制
- 存在镀金、范围蔓延行为
- 对于范围变更没有走变更控制流程
- 需求管理可能的问题：
（1）对客户（或用户）的需求获取不充分
（2）没有按照规范的需求开发与需求管理的流程及内容开展需求工作
（3）缺乏需求定义环节，没有定义出需求规格说明书
（4）缺乏需求验证环节，没有请客户代表一起进行需求评审
（5）没有制定范围和需求管理计划
（6）没有求得干系人对需求的一致理解
（7）没有求得干系人对需求的承诺
（8）没有有效地管理需求变更控制
（9）没有有效维护对需求进行跟踪管理
（10）没有及时识别项目工作与需求之间的不一致性
- 需求管理问题应对措施
（1）建立需求变更控制策略和需求变更控制流程。
(2) 采用多种方式充分获取用户需求并进行详细的需求分析
（3）形成需求规格说明书并与用户进行需求验证（确认）和评审
（4）需求定稿建立基线，以后的需求变更必须走变更控制流程，并及时更新需求规格说明书和需求跟踪矩阵
（5）编写需求跟踪矩阵，需求状态表等文档
（6）在需求规格说明书基础上编制技术方案，并进行评审
（7）定期不定期对项目绩效进行监督检查，找出问题原因并指导团队成员解决
- 范围管理计划的内容
范围管理计划是项目管理计划的组成部分，描述将如何定义、制定、监督、控制和确认项目范围。包括：①制定项目范围说明书；②根据详细项目范围说明书创建WBS；③确定如何审批和维护范围基准；④正式验收已完成的项目可交付成果。【可以是正式或非正式的，非常详细或高度概括的】
- 需求管理计划的内容
- 如何规划、跟踪和报告各种需求活动；②配置管理活动，例如，如何启动变更，如何分析其影响，如何进行追溯、跟踪和报告，以及变更审批权限；③需求优先级排序过程；④测量指标及使用这些指标的理由；⑤反映哪些需求属性将被列入跟踪矩阵等。
- 范围说明书内容：
- 产品范围描述
- 验收标准
- 可交付成果
- 项目的除外责任
- 制约因素
- 假设条件
【口诀】产验可除制假
- WBS 分解的方法：
- 以项目生命周期各阶段作为分解的第二层，产品和项目可交付成果放在第三层
- 以主要可交付成果作为分解的第二层
- 纳入由项目团队以外的组织开发的各种较低层次组件（如外包工作）。随后，作为外包工作的一部分，卖方须制定相应的合同 WBS。
- WBS 表示形式主要有分级的树型结构（组织结构图式）和表格形式（列表式）。（作为补充了解）
树型结构图的 WBS 层次清晰、直观性和结构性强，但不容易修改，对大的、复杂的项目很难表示出项目的全貌。
表格形式的直观性比较差，但能够反映出项目所有的工作要素。
- 在分解的过程中，应该注意以下 8 个方面：
- WBS 必须是面向可交付成果的。
- WBS 必须符合项目的范围。
- WBS 的底层应该支持计划和控制
- WBS 中的元素必须有人负责，而且只由一个人负责，尽管实际上可能需要多个人参与。
- WBS 的指导，WBS 应控制在 4～6 层。
- WBS 应包括项目管理工作（因为管理是项目具体工作的一部分），也要包括分包出去的工作。
- WBS 的编制需要所有（主要）项目干系人的参与，需要项目团队成员的参与。
- WBS 并非是一成不变的。在完成了 WBS 之后的工作中，仍然有可能需要对 WBS 进行修改。
【口诀】一个人负责，4-6层，面果，盒饭，可变，全员，吃鸡，管饱
- 需求跟踪矩阵中记录的典型属性有哪些？
唯一标识、需求的文字描述、收录该需求的理由、所有者、来源、优先级别、版本、当前状态和状态日期。为确保干系人满意，可能需要增加一些补充属性，如稳定性、复杂性和验收标准。