高项-范围管理知识要点

1.收集需求的工具
(1)数据收集
◆ 头脑风暴：产生多种创意的技术
◆ 访谈：直接交谈、结构(预设问题)和非结构(即兴问题)、 一对一 、多对多、获取机 密信息
◆ 标杆对照：与内部或外部可比组织的实践进行比较，以便识别最佳实践
◆ 焦点小组：召集预定主题的干系人和主题专家
◆ 问卷调查：受访者地理位置分散并且适合开展统计分析的情况
(2)数据分析
◆文件分析：审核和评估任何相关的文件信息
(3)数据展现
◆ 亲和图： 对大量创意进行分组的技术
◆ 思维导图：将创意整合成一张图，反映创意之间的共性和差异
2.需求文件描述各种单一的需求将如何满足与项目相关的业务需求。一开始可能只有高层级的需求，然后随 着有关需求信息的增加而逐步细化。
◆ 只有明确的 (可测量和可测试的)、 可跟踪的、完整的、互相协调的，且主要干系人愿意认可的需求，才 能作为基准。
3.需求跟踪矩阵是将产品需求从其来源连接到能满足需求的可交付成果的一种表格，体现了需求和后续可交 付成果的对应关系。
跟踪需求的内容：
(1)业务需要、机会、目的和目标
(2)项目目标
(3)项目范围和WBS 可交付成果
(4)产品设计
(5)产品开发
(6)测试策略和测试场景
(7)高层级需求到详细需求
4、需求跟踪矩阵中记录的典型属性有哪些?
唯一标识、需求的文字描述、收录该需求的理由、所有者、来源、优先级别、版本、当前状 态 和 状 态 日 期 。为确保干系人满意，可能需要增加一些 补充属性，如稳定性、复杂性和验收 标准。
5.范围基准：已批准的项目范围说明书、WBS、WBS 字典。项目范围的完成情况是根据项目管理计划来衡量的。产品范围的完成情况是根据产品需求来衡量的。
6.项目范围说明书明确项目应该完成的工作来确定项目的范围。
项目范围说明书包括：(默写)
◆ 产品范围描述、可交付成果、验收标准、除外责任
7.WBS 是对项目团队为实现项目目标、创建所需可交付成果而需要实施的全部工作范围的层级分解。WBS 分解结构，可以将生命周期作为第二层，也可以将主要可交付成果作为分解的第二层。
(1) 工作包： WBS 最低层，带有独特标识号的工作包。
(2) 规划包：低于控制账户而高于工作包的工作分解结构组件。
(3)控制账户：控制账户是一个管理控制点。控制账户包含两个或更多工作包，每个工作包只与一个控制账户关联； 一个控制账户可以包含一个或多个规划包。
7.WBS 分解的5个步骤：
(1)识别和分析可交付成果及相关工作；
(2)确定WBS 的结构和编排方法；
(3)自上而下逐层细化分解；
(4) 为WBS 组件制定和分配标识编码；
(5)核实可交付成果分解的程度是恰当的。

8.创建WBS应把握如下原则：
(1)WBS 必须是面向可交付成果的；
(2)WBS 必须符合项目的范围，必须包括也仅包括为了完成项目的可交付成果的活动；
100%原则：下一级的元素之和必须100%代表上一级元素
(3)WBS 的底层应该支持计划和控制；
(4)WBS 中的元素必须有人负责，而且只有一个人负责；
(5)WBS 应控制在4～6层；
(6)WBS 应包括项目管理工作，也要包括分包出去的工作；
(7)WBS 的编制需要所有项目干系人的参与；
(8)WBS 并非是一成不变的。

9 .WBS 表示形式主要有分级的树型结构 (组织结构图式)和表格形式 (列表式)。(作为补充 了解)
树型结构图的 WBS 层次清晰、直观性和结构性强，但不容易修改，对大的、复杂的项目 很难表示出项目的全貌。
表格形式的直观性比较差，但能够反映出项目所有的工作要素。
10. 确认范围是正式验收项目已完成的可交付成果的过程。
管理层关注项目范围；客户关注产品范围；项目管理人员关注项目制约因素和可交付成果；项目管队成员关 注项目范围中自己参与的元素和负责的元素。
10. 确认范围与质量控制不同之处：
(1)确认范围主要强调可交付成果获得客户或发起人的接受；质量控制强调可交付成果的正确性，并符合 为其制定的具体质量要求(质量标准)。
(2)质量控制一般在确认范围前进行，也可同时进行；确认范围一般在阶段末尾进行，而质量控制不一定 在阶段末进行。
(3)质量控制属内部检查，由执行组织的相应质量部门实施；确认范围则是由外部干系人(客户或发起人) 对项目可交付成果进行检查验收。
11、范围管理过程中存在的问题：
(1)没有制定范围管理计划和需求管理计划
(2)没做好需求收集、分析、调研等工作
(3)没有做好需求跟踪工作
(4)不能仅依据过去经验来编写现在项目的范围说明书等工作
(5)项目范围说明书内容不全面或者项目范围定义不充分
(6)项目范围说明书不应由项目经理一人来编写
(7)WBS及范围基准应让项目团队和所有关键干系人一起来创建，而不是项目经理创建，导 致工作遗漏
(8)项目范围基准未经评审和审批
(9)缺少范围确认等环节，项目成果等没有得到用户的正式确认和接受
(10)范围变更没有规范的变更控制流程
(11)项目变更实施前没有及时变更合同
(12)变更结果没有得到客户的确认
(13)未做好范围控制工作，未对范围管理中的偏差和问题进行及时纠偏

12、需求管理可能的问题：
(1)对客户(或用户)的需求获取不充分
(2)没有按照规范的需求开发与需求管理的流程及内容开展需求工作
(3)缺乏需求定义环节，没有定义出需求规格说明书
(4)缺乏需求验证环节，没有请客户代表一起进行需求评审
(5)没有制定范围和需求管理计划
(6)没有求得干系人对需求的一致理解
(7)没有求得干系人对需求的承诺
(8)没有有效地管理需求变更控制
(9)没有有效维护对需求进行跟踪管理
(10)没有及时识别项目工作与需求之间的不一致性

13、需求管理问题应对措施
(1)建立需求变更控制策略和需求变更控制流程。
(2)采用多种方式充分获取用户需求并进行详细的需求分析
(3)形成需求规格说明书并与用户进行需求验证(确认)和评审
(4)需求定稿建立基线，以后的需求变更必须走变更控制流程，并及时更新需求规格说明书 和需求跟踪矩阵
(5)编写需求跟踪矩阵，需求状态表等文档
(6)在需求规格说明书基础上编制技术方案，并进行评审
(7)定期不定期对项目绩效进行监督检查，找出问题原因并指导团队成员解决