【信息系统项目管理师】第五章 项目范围管理（考点汇总篇）
■考点分析与预测
项目范围管理一般上午考察3分，需求是龙头，是做项目管理的基础。没有需求就不能确定项目的范围，没有范围，项目就无从谈起，此部分在下午案例分析的几率也是比较大的。
上午历年考试的重点在范围定义的概念，产品范围和项目范围以及各自的衡量标准。详细范围说明书的内容，WBS的表现形式，分解的方法，原则，工作包的定义作用，范围确认，范围基准，范围蔓延，范围变更等知识点上。输入输出和工具与技术直接考察的并不算多。
本章在下午案例分析的命题思路主要表现为：给出某项目在范围管理方面的案例场景描述，要求指出该案例场景中存在哪些问题并说明相关原因，要求给出解决这些问题的补救措施。
■知识点回顾
高项知识点：/Last_Impression/article/details/81950945
PMBOK第六版：第五章 项目范围管理第六版_千月星跡-CSDN博客
PMBOK第五版（上）：[读书笔记]第五章 项目范围管理（上）_千月星跡-CSDN博客
PMBOK第五版（下）：[读书笔记]第五章 项目范围管理（下）_千月星跡-CSDN博客
论文攻略：/Last_Impression/article/details/88725932
论文模板：/Last_Impression/article/details/82960752
范围记忆敲出：/Last_Impression/article/details/89839137
范围思维导图：【信息系统项目管理师】第五章 范围管理思维导图_千月星跡-CSDN博客
■项目范围管理ITTO助记
■大话范围管理
制订范围管理计划
范围管理说白了就是管理做哪些事情。范围管理计划只是一个指导性的方法论，和所有程序型指南一样，都需要专家和开会来确定如何收集，定义，创建，确认和控制范围。
当不知道做什么无从下手时，从项目章程入手，章程中有项目的背景，高层级产品描述和特征。从章程中寻找信息，结合事业环境和组织过程资产，最后做成需求管理计划。
一个项目可能有多个阶段，最好每一个阶段制订各自的需求管理计划和文件，便于规划，跟踪，配置和测量。
收集需求
拿着老板的签字章程着客户收需求，定计划，记跟踪。首先要找到相关人干系人和客户，需要用到干系人登记册，找到干系人后，总要了解一下管理干系人的原则吧，于是参照了干系人管理计划。干系人太多，让相关人了解项目是什么最快也最 简单和暴力的方法就是让他们自己看项目章程。
然后得到客户的需求了，这些信息一定要写到需求文件中，其他的范围管理过程都要使用需求文件的。如果说需求文件是只是描述了客户和需求之间的对照关系的话，那么需求跟踪矩阵是描述需求与交付成果物之间的对应关系。
收集客户需求是我们系统分析师的工作，系统分析师拥有各种工具与技术来获取客户需求。
从时间上说，收集需求要面对那么多人，自然少不了方法。客户人数不多，就直接访谈，多了就得分（焦点小组），意见不统一可以开引导式研讨会引导一下，人再多就用群体创新和决策，人再再多就问卷调查，遇到不爱沟通而且说不清楚话的人，通过观察，还是说不清楚的干脆做个原型看看定义的范围，最终产品范围其实也就是这样了。所以好方法就是找个现在市面上类似的产品分析一下，简单高效。
需求是工作分解结构的基础。收集需求其实就是在定义和管理客户希望。
收集完需求将需求规格化，形成需求规格说明书。需求规格说明书以模块化描述，但会忽略人的信息。这个时候就要对需求进行跟踪，于是就有了需求跟踪矩阵。RTM还为管理产品范围变更提供了框架。
定义范围
收集完了用户需求，明确收集到的需求文件哪些属于项目的范围，哪些不是。找出范围的边界在哪里这样才可以让我们只做正确的事情。整理好后就得到最终的项目需求。翻翻项目章程，看看上面的高层级需求和审批要求，一下子就总结成一个文档：项目范围说明书。项目范围说明书对需求的描述比较粗略，在确认和控制范围的子过程中，还是得用需求文件才可以。
收集需求不需要老司机，但定义范围离不开专家老司机。对产品价值分析，对需求文件中的需求好坏备选方案分析，都对抽象成范围说明书的过程还是很有帮助的。
创建WBS
用范围说明书分解成WBS。对照需求文件拿项目范围说明书开刀。你要什么我给你分什么，最后分解成WBS和WBS词典。然后把WBS，WBS词典，范围说明书装订起来，就形成一个重要的基准文档：范围基准。当然要老板批准后，才可以算作基准。WBS最底层的叫做工作包，工作包在进度管理的时候再分解成活动。WBS分树形和列表型。大型项目优先使用列表型。WBS看不懂？请参照WBS字典。
确认范围
就是验收已完成的项目可交付成果物的过程。确认产品是否在范围内，首先要利用需求跟踪矩阵，和客户保持有效的沟通。确保产品范围没有改变，确保需求文档最新后，同时查看工作绩效数据，用他去核实已经确认过质量的产品，没有问题就验收完成生成核实的可交付成果，核实后有问题怎么办，走变更流程。于是就有了变更请求。工作绩效数据在验收完成后该整理成工作绩效信息。注意在确认范围和控制范围的时候，是没有用范围说明书的。因为范围说明书太简略和概要化了。只有拿给老板和客户看比较合适些。
那么怎么确认项目成果物呢，主要就是检查。包括了审查，产品评审，审计，走察，巡检等方式。可交付成果是项目最重要的可交付的成果，首先它在指导与管理项目工作时生成，经过质量的控制以后，变成了核实的可交付成果，核实完成后，就在本过程中验收，变成了验收的可交付成果，最后在结束项目或阶段的时候，将验收完的可交付成果打包一下，发给客户。那么项目就完成了。
控制范围
控制工作是否在范围内。首先要通过需求跟踪矩阵去保持客户联系，确定工作范围没有变。确保需求文档更新到最新。既然是控制工作本身，那就要用到每日收集的工作状况，就是工作绩效数据。去对照需求文档得到项目范围实施情况作出的效果如何，就有了工作绩效信息。有问题就产生一个变更请求，最后还要更新项目管理计划和项目文件。还有项目知识（组织过程资产）的更新。
项目范围计划编制的不够缜密，项目组织发生客户对产品要求发生变化等，这些都是范围发生变更的原因。控制范围的工具有偏差分析。在控制范围的时候，要特别注意两个概念：质量镀金和范围蔓延。
范围论文记忆敲出
BackToRoot:【信息系统项目管理师】重点整理：高项知识地图_千月星跡-CSDN博客
