这是《PMP考试与实践》系列文的第三篇：项目范围管理，对应《PMBOK》中的第五章的内容。无论你是正在准备PMP考试，抑或是对PMP并不了解，都没有关系，这篇系列文全部看完，肯定会对你有所帮助的。
因为其中不仅仅只有我从《PMBOK》《汪博士解读PMP考试》还有我报名的培训机构发的知识手册里的摘录下来的知识，其中也会掺杂一些我自己在日常产品工作中的对项目管理的知识运用的感悟和总结。
那么，接下来就跟着我开始，一起来复（xue）习（xi）PMP相关的知识吧！
项目范围管理的基本概念
项目范围管理是项目其他各方面管理的基础。如果范围都弄不清楚，进度、成本和质量等也就无法弄清楚。
项目范围管理就是要做范围内的事，而且只做范围内的事，既不少做也不多做。如果少做，会影响项目既定功能的实现；如果多做，又会浪费资源，并产生极高的机会成本。
PMI一个很重要的思想，就是不能镀金。镀金的项目是失败的，也是不被认可的。
项目范围管理和产品经理日常工作中的前期需求调研的工作有很多相似性，我们确定要做某款产品的似乎，首先要考虑的就是做成什么样子，做多少，边界是什么，这些都是范围，但是更多的场景下是指的产品范围。而项目范围管理中范围，更多的是指项目的范围，项目的范围除了包含产品的范围之外，还要包含做这件事涉及的范围，例如包含的管理过程，人员，资源，还有一系列的准备工作等。
产品范围是面向客户的，项目范围是面向项目团队的。
项目范围管理的过程速览
项目范围管理的实现过程有6个过程，分别是规划范围管理、收集需求、定义范围、创建WBS、确认范围和控制范围。这些过程是通过输入与输出联系起来的。它们的输入与输出关系可以概括为如图所示：
项目范围管理各过程的输入与输出关系
规划范围管理和收集需求，还有定义范围和创建WBS都属于五大管理过程组中的规划过程组。而确认范围和控制范围，则属于监控过程组。
1. 规划范围管理
规划范围管理是指先对整个范围管理的过程做一些规划，这个规划属于「总-分-总」里面的总。在整个项目期间对如何管理范围提供指南和方向。这个是PMI里面重复性很高的通用方式，无论做什么事情都会先规划一下，制定好规则和指导方向，随后按照这个指导方向来执行具体的工作。
规划范围管理过程就是要编制范围管理计划和需求管理计划。范围管理计划是关于将如何定义、制定、监控和确认产品范围与项目范围的计划。例如，将采用什么流程编制项目范围说明书、工作分解结构（WBS）和WBS词典？范围基准将由谁来审批？范围变更将按什么流程进行管理？将如何验收可交付成果？
需求管理计划是关于将如何收集、记录、分析和控制需求的计划。例如，将用什么方法收集什么人的需求？将用什么标准对需求进行优先级排序？需求文件和需求跟踪矩阵将采用什么格式？将如何跟踪需求的实现过程？需求管理计划规定收集需求过程将如何开展，范围管理计划规定定义范围、创建WBS、确认范围和控制范围过程将如何开展。
Vitamin有话说： 项目管理的十个知识领域基本上是这样的套路，先规划xxx管理，其实就是制定对xxx的一些管理计划，例如针对范围就是制定范围管理计划，而针对质量，就是制定质量管理计划。然后再加上一些相关的附加的计划，例如需求管理计划，质量测量指标等。
2. 收集需求
收集需求过程是根据范围管理计划和需求管理计划，收集项目相关方对项目的具体需求。这一块的内容作为产品经理来说是为数不多的优势，因为关于需求收集其实日常工作中算是基本功了。
收集需求旨在使需求明确化、具体化和书面化。需求必须是可测量的、文档化的。这是PMI的指导思想，在实际工作中也会有很多公司有这样的要求。
通过需求池文件是类似的，作为一个书面化的记录。
需求跟踪矩阵则说明具体需求与高层目标之间的对应关系，以及具体需求与细节层次上的项目设计、项目工作和可交付成果之间的对应关系。通过需求跟踪矩阵来确保每个具体需求都有实际意义（为高层目标服务），且都能实现（通过细节层次上的工作）。需求跟踪矩阵类似于在需求池的基础上增加了与高层目标之间的对应关系，以确保做这个需求是有效果的，是和高层级的战略匹配的，而不是盲目的。
3. 定义范围
收集到的需求，不一定都要在本项目上得到实现。定义范围过程就是确定哪些需求必须在本项目上实现，并基于这些需求编制项目范围说明书，明确项目范围边界。
这一块和产品经理日常工作中的需求管理有点差异，一般来说我们收集好了需求之后会直接分析，梳理，最后确认是否要做，在哪个迭代上做。而项目管理中，则是拆分开成为两步，先收集需求放在一边，然后再根据收集好的需求，独立的开支线，去生成一份项目范围说明书，阐述要做什么，不要做什么，项目的边界是什么。
在定义范围过程中，还要细化制定项目章程过程所列出的制约因素和假设条件，更新假设日志。制约因素没有任何不确定性，是项目团队绝对不能违反的（确定性很强）。项目的范围、进度、成本和质量要求中的任何一个先被确定下来，就会成为制约因素。假设条件则是无须验证即假设为真实的前提条件。例如，假设资金按时到位，假设某个重要技术人员按时加入项目团队。
项目范围说明书一般包含以下内容：
- 产品范围的描述，细化项目章程和需求文件中的产品范围。
- 可交付成果，项目必须提交的中间及最终可交付成果；
- 验收标准，可交付成果必须满足的标准；
- 项目的除外责任，本项目必须不做什么事情，防止相关方对项目产生不合理的期望；
4. 创建WBS（重点）
创建WBS过程就是用工作分解结构（WBS），把项目范围说明书中的项目可交付成果细分为更小、更便于完成的可交付成果，并在此基础上形成范围基准。项目范围说明书旨在确定项目范围边界，工作分解结构则要确定边界之内有什么。
工作分解结构是用来确定项目的总范围的，项目的全部工作都必须包含在工作分解结构之中。不包含在工作分解结构中的任何工作都不是项目的组成部分，都不能做，否则就是镀金。
工作分解结构中，同一层次的各要素应该相对独立，尽量不相互交叉。在编制WBS的同时，应该编制WBS词典，对每个WBS要素进行解释。WBS相当于名词汇编，WBS词典相当于名词解释，它们是孪生兄弟般的两个文件。
煮饭项目的WBS
工作分解结构中，应专列一条“项目管理”分支，使“项目管理”成为必须完成的工作之一。
控制账户/规划包/工作包也是WBS中比较重要的几个概念名词，主要是要区分其中的关系和指代的内容。
控制账户/规划包/工作包图示
控制账户是一种管理控制点，项目经理针对控制账户考核项目执行情况，即在控制账户的相应要素上，把项目执行情况与计划要求进行比较，评价执行情况的好坏，发现并纠正偏差。项目经理不直接关心低于控制账户的WBS要素的执行情况，而是把它们交给下级成员去直接关心。
规划包是在控制账户之下、工作包之上的WBS要素。虽然已经知道它是一个什么样的成果，但是尚不清楚究竟要做哪些具体活动，才能把该成果做出来。由于还无法分解出编制详细进度计划所需的进度活动，规划包只是暂时用于项目计划编制工作。随着情况的明朗，规划包最终将被分解成工作包和相应的进度活动。规划包不能直接付诸执行，必须先分解成工作包。
工作分解结构每条分支底层的要素（没有子要素的要素），称为“工作包”，除非该要素已被特别命名为“规划包”。规划包只是暂时的底层要素，而工作包是永久的底层要素。工作包是项目上的最小的可交付成果。把工作包再分解，得到的就不是可交付成果，而是进度活动。工作包的工作量一般会80小时可以完成的，工作包在WBS中不能再细分了，但是可以交由负责该工作包的人再细分为各种进度活动，只不过在范围管理中不体现到那么细。
工作分解结构在项目管理中有极其重要的作用。项目的所有规划、执行、监控和收尾工作都必须基于工作分解结构。如果没有工作分解结构，就谈不上项目的进度计划、成本计划、质量计划、资源计划和风险计划等。编制工作分解结构不仅是一项技术和管理工作，而且是重要的项目团队建设工作。在工作分解结构编制完成时，应该形成一个较好的项目管理团队。在项目管理工作中，许多技术工作（如项目计划编制、合同谈判）都不只是纯技术工作，而且是团队建设工作；不仅要取得技术上的成果，而且要取得团队建设的成果。
4. 确认范围
在可交付成果完成之后，需要进行内部的验收和外部的相关方验收。确认范围过程是由项目发起人、客户和其他主要相关方正式验收已经完成并被核实为质量合格的可交付成果。验收可交付成果是否符合需求，是否满足产品范围和项目范围。
工作分解结构所列的每个可交付成果在完成之后，都要及时进行质量合格性核实（控制质量过程），及时进行实质性验收（确认范围过程）。这种对各可交付成果的及时验收，有利于及时发现并解决问题（可交付成果不符合验收标准），提高整个项目完工时项目产品顺利通过整体验收的可能性。及时进行实质性验收，也有利于及时认可和表彰相关团队成员。必须在监控阶段完成对各个可交付成果的实质性验收，以便在还有时间解决问题时发现并解决问题。整个项目完工时，再开展项目产品的整体验收（形式验收），办理移交手续。
项目范围确认的结果是对项目范围定义工作的正式接受，其形式一般是用正式文件（项目范围核实意见书）确认。已完成并经过验收的可交付成果，或者未验收的可交付成果及原因，都需要发起人对正式文件进行签字。
5. 控制范围
控制范围过程是把项目范围执行的实际情况与项目计划中的范围要求做比较，发现偏差，分析偏差，提出解决偏差的建议。通过控制范围过程，防止范围蔓延，管理范围基准变更。
在本过程中，也需要预测未来的范围绩效，如项目完工时产品功能的实现情况。如果预测的绩效不理想，就提出变更请求。虽然控制范围与确认范围过程都是监控过程组的过程，但它们的差别很大。控制范围是由项目团队在可交付成果的完成过程中开展的。确认范围是由项目发起人或客户在可交付成果完成之后开展的。
控制质量/控制范围/确认范围的区别
Vitamin有话说： 从互联网的产品工作方式来看，《PMBOK》中的确认范围和控制范围的顺序好像搞反了，我也不知道为什么它要按这样的顺序来写。控制范围是项目团队在项目执行的时候对其监控，然后检查是否该做的都做了，与计划的是否一致。而确认范围有点类似于UAT测试（用户可接受测试），让发起人或者客户针对研发完成的可交付成果进行验收，如果通过就该子项完成，没有通过就看是否要采取变更或者BUG修复等。所以按实际工作的场景来说，应该是控制范围在前，确认范围（验收范围）在后，但是《PMBOK》是反着来的，这里需要特殊注意一下。
最后
以上大概是我整理的PMP第五章的主要知识，大多数内容都是摘录自《PMBOK》《汪博士解读PMP考试》还有我报名的培训机构发的知识手册。
第五章是项目范围管理，是属于PMP十大知识领域中的第一个。可以理解为范围是最早，最优先需要被确认清楚的，没有确认范围，就无法展开后续的工作。
对于产品经理来说，这一章阅读起来会有天然的优势，因为其中一些工作方式和指导思想其实在日常的产品工作中就已经遇到了，也用上了。例如需求的收集，分析，产品范围的确认，到后续的WBS和控制范围等，如果你是一名产品经理，想要学习一些规范的，具有章法性的产品或项目范围管理的知识，不妨深入阅读一下此章节。
