什么是项目范围管理
项目范围管理包括确保项目做且只做所需的全部工作，以成功完成项目的各个过程。它关注的焦点是:什么是包括在项目之内的，什么是不包括在项目之内的，即为项目工作明确划定边界。通俗地讲，项目范围管理就是要做范围内的事，而且只做范围内的事，既不少做也不多做。少做会影响项目既定功能的实现，多做会浪费资源。因某种原因，要改变项目的工作边界时，项目范围管理会提供一套规范的方法去处理范围变更。
什么该做什么不该做，谁做什么事都最好要确定下来，一方面工作这样就比较清晰了，另一方面也会比较由权威，免得多方势力扯皮。但实际情况下，如果没有做好需求管理，项目范围会急剧膨胀，即便有些时候做好了需求管理，范围也会出现或多或少的变更，这个时候要妥善处理变更，找到最优解。作为甲方，内部需求变更几乎是无法拒绝的，作为乙方，甲方的范围变更超出自己的可承受范围的话，该加钱就得加钱，这是没有商量余地的。
项目范围管理主要包括以下几个方面：
- 编制范围管理计划过程，对如何定义、确认和控制项目范围的过程进行描述。
- 收集需求。为实现项目目标，明确并记录项目干系人的相关需求的过程。
- 定义范围。详细描述产品范围和项目范围，编制项目范围说明书，作为以后项目决策的基础。
- 创建工作分解结构。把整个项目工作分解为较小的、易于管理的组成部分，形成一个自上而下的分解结构。
- 确认范围。正式验收已完成的可交付成果。
- 范围控制。监督项目和产品的范围状态、管理范围基准变更。
以上几个方面的核心就是明确需求和做好需求变更。
编制范围管理计划
主要是根据项目管理计划和项目章程，结合一些其他信息，描述了如何定义、制定监督、控制和确认项目范围，注意这里只是做了一些规章制度层面的事情，输出范围管理计划和需求管理计划，所谓计划，是如何做，做什么的。
重要的是需求管理计划：
- 如何规划、跟踪和报告各种需求活动。
- 配置管理活动，例如，如何启动产品变更，如何分析其影响，如何进行追溯跟踪和报告，以及变更审批权限。
- 需求优先级排序过程。
- 产品测量指标及使用这些指标的理由。
- 用来反映哪些需求属性将被列入跟踪矩阵的跟踪结构
- 收集需求过程。
收集需求
这一部分最重要的是得出需求文档，主要内容如下：
说这么多，其实一大堆废话，所谓项目，是服务于业务的，所以核心需要收集的是业务需求，也就是这个项目需要什么功能，各个功能应该怎么做，想要达到什么想的目标；其次是美观需求，运行效率需求等非核心的需求。
范围定义
本过程的主要作用是，明确所收集的需求哪些将包含在项目范围内，哪些将排除在项目范围外，从而明确项目、服务或输出的边界。
本过程的输出是项目范围说明书，项目范围说明书详细描述项目的可交付成果，以及为创建这些可交付成果而必须开展的工作。项目范围说明书可明确指出哪些工作不属于本项目范围。
其实就是对于收集来的需求，那些做，那些不做，为什么不做等都要给出文档告知所有干系人，或者开会讨论。
这点我是深有体会的，因为业务部门提出的需求大多不会站在系统建设的角度上来看，而只是想要如何快捷的操作，满足他们的业务需求，所以项目经理对需求的筛选考虑就至关重要了。比如之前业务想要在流程内资料流转的子流程，在他们的想法就是想要一个流程来操作，但是我们思考后认为没有必要，还要浪费开发开销，就选择了按钮权限+原审批流程的形式解决。
创建范围分解结构
这部分是非常重要的！！！是重要考点，也是很考验项目经理任务分解和下发的能力的。
创建工作分解结构是把项目可交付成果和项目工作分解成较小的、更易于管理的组件的过程。工作分解结构(WBS)是项目管理的基础，项目的所有规划和控制工作都必须基于工作分解结构。如果没有工作分解结构，就谈不上项目的进度计划、成本计划、质量计划、人力资源计划和风险计划等。本过程的主要作用是，对所要交付的内容提供一个结构化的视图。
WBS主要包括以下内容：
- 工作分解结构是用来确定项目范围的，项目的全部工作都必须包含在工作分解结构当中，而且不包含在工作分解结构中的任何工作都不是项目的组成部分，都不能做否则就是“镀金”。这是工作分解结构百分百规则的要求，即工作分解结构必须且只能包括100%的工作
- 工作分解结构的编制需要所有项目干系人的参与，需要项目团队成员的参与。各项目于系人站在自已的立场上，对同一个项目可能编制出差别较大的工作分解结构。项目经理应该发挥“整合者”的作用，组织他们进行讨论，以便编制出一份大家都能接受的工作分解结构。
- 工作分解结构是逐层向下分解的。工作分解结构最高层的要素总是整个项目或分项目的最终成果。每下一个层次都是上一层次相应要素的细分，上一层次是下一层次各要素之和。工作分解结构中每条分支分解层次不必相等，如某条分支分解到了第四层，而另一条可能只分解到第三层。一般情况下，工作分解结构应控制在3~6 层为宜。如果项目比较大，以至于工作分解结构要超过6层，我们可以把大项目分解成子项目，然后针对子项目来做工作分解结构。
树形结构
表格结构
实际工作中，需要我们按照项目需求和范围，制定出详细的WBS，分配任务，且最好和项目干系人讨论后最终决定，因为任务的执行需要项目干系人支持。
WBS极其考验项目经理的能力，不仅需要管理能力，还需要技术能力，业务理解能力等，因为一个工作包谁来做、怎么做、需要多少时间、要达到什么样的成果都需要项目经理做到心中有数。
项目范围确认
确认范围是正式验收已完成的项目可交付成果的过程。确认范围需要审查可交付物和工作成果，以保证项目中所有工作都能准确地、满意地完成。确认范围应该贯穿项目的始终，从 WBS的确认或合同中具体分工界面的确认，到项目验收时范围的检验。确认范围过程应该以书面文件的形式把它完成情况记录下来。
本过程的主要作用是，使验收过程具有客观性;同时通过验收每个可交付成果，提高最终产品、服务或成果获得验收的可能性。
确认范围一般需要：
- 确定需要进行确认范围的时间。
- 识别确认范围需要哪些投入。
- 确定范围正式被接受的标准和要素。
- 确定确认范围会议的组织步骤。
- 组织确认范围会议
其实就是在项目过程中对每个需求进行确认，是不是这个需求，如何确认这个需求、完成的怎么样等等。
比如有个需求是：查询房屋价格接口。确认这个需求要做以下事情：和需求提出方确认这个需求的正确性、项目经理让谁来做这个需求、这个需求要达到正确查询价格且只有XXX才有权限查询价格才算合格。
正常情况下，所有项目干系人一起确认某个或者某些需求、范围。
项目范围控制
范围控制是监督项目和产品的范围状态，管理范围基准变更的过程。范围控制涉及到影响引起范围变更的因素，确保所有被请求的变更、推荐的纠正措施或预防措施按照项目整体变更控制处理，并在范围变更实际发生时进行管理。范围控制过程应该与其他控制过程协调开展。未经控制的产品或项目范围的扩大(未对时间、成本和资源做相应调整)被称为范围蔓延。变更不可避免，因此在每个项目上，都必须以书面的形式记录并实施某种形式的变更控制管理。本过程的主要作用是，在整个项目期间保持对范围基准的维护。
其实就是需求变更的控制，变更要遵循什么流程，如何审批，谁来审批，审批通过如何变更需求，如何执行需求等。
其实需求变更在所难免，变更必须遵循一定的程序，否则需求很容易膨胀，变更后必须考虑多方面的影响，比如成本、人力、项目整体形象等等，所以项目范围控制也很考验项目经理的能力。
亲身体验，当时正在做某项功能，但是做完后业务发现不对，需要重做，那么此时我们只能跟乙方说明情况，请人家重新设计重新做，当时处于项目前期，比人还没有太多怨言，但是如果后期造成的影响可能很严重，甚至得加钱，所以，前期考虑全面非常重要，后期实在没办法，该加钱是在所难免的。这里有个门道，也就是说前期需求管理必须要所有项目干系人参与，高层领导也得签字确认，这样后期需求变更导致的加钱尴尬事项，责任就不在项目经理一人身上。
