作者获得了先进的项目管理部门和PMP认证。现在，分享一下考前准备的相关试卷，这是第一篇《项目范围管理》。
2019年1月至2020年7月，我有幸参与中央某机关综合业务应用系统开发项目，投资900万元，建设周期18个月。项目分为流程业务管理、智能辅助、大数据应用分析、知识服务四个子项目。我被任命为流程业务管理子项目的项目经理。现在我已经成功上线，系统运行稳定，客户满意，验收已经完成。流程业务管理子系统是核心，用户覆盖从中央到地方的四个层级，共有七条业务线，90个业务类别。该系统计划将客户的所有业务纳入系统，使其完全实现信息化和移动业务处理。为了满足用户的需求，系统设计采用目前最流行的前端分离开发方案，后端采用java语言，并提供满足PC和移动需求的接口。我们采用目前成熟的微服务架构模式，满足客户对系统稳定性和可靠性的质量要求。应客户要求，程序运行环境采用阿里巴巴云服务部署平台，可适配华为云平台，也可在国内涉密服务器上运行，无需使用任何可能被国外卡住的工具或技术。
由于参与者规模大、范围广、角色复杂、参与部门众多、利益关注点不同。如何定义这个项目的范围，如何满足客户的不同需求，如何控制项目本身的范围，将是这个项目最大的挑战。项目成败最关键的因素之一是控制项目的范围。如果需求工作不扎实，范围分散，项目几乎不可能成功。作为项目经理，我知道控制范围是项目管理的重中之重。结合本项目的实际工作，我将解释如何管理好范围。
一.范围计划的编制
范围管理计划是项目管理计划的子计划。在制定范围管理计划时，我们邀请甲方高级管理人员参与制定，包括如何编制范围规范、需求报告模板、如何创建WBS，以及如果交付物得到确认，如何控制范围的变更。范围管理计划规定了项目范围管理的方向和方法。
二.需求收集和范围基准
需求的收集和整理是项目范围的核心。为了实现项目目标，我们需要详细收集各种需求，为定义和管理项目范围奠定基础，并创建需求跟踪矩阵，作为项目范围控制、范围确认和范围变更控制的基础。由于这个项目的复杂性远远超过了一般项目，我们在收集需求时做了以下几件事：
1.在项目中单独设置一个业务需求组，安排一个业务需求人独立负责客户的每条业务线，甚至在核心业务线安排两三个业务需求人。每一位业务需求人员都会在甲方业务办公室派驻一段时间，在办理业务时关注甲方业务人员的具体业务场景和痛点，从而做出第一版的需求分析报告。
2.需求分析报告的第一版将成为目标，或后续讨论的材料。甲方领导召集全国不同部门、不同层级的四级机关业务人员，在北京某基地集合，历时一个月，对需求报告第一版进行充分讨论，剔除不合理需求，完善实践场景。
3.由于需求提出者来自不同的层次，有不同的立场，有不同的利益，必然会出现需求不一致甚至相互冲突的情况。针对这种情况，我建议成立一个需求班工作组，由利益相关方、甲方高层管理人员和我们的业务需求人员组成。所有不能决定的要求，由专班集体讨论，形成共同意见。
第三，创作作品b
工作分解结构是完成项目目标所需工作的结构分解。精确分解是项目范围的基准，也是成本和进度估算的基础。为了做好这项工作，我们借鉴了以往同类型项目的工作分解模板，并结合当前项目进行改进。此外，考虑到项目中有很多功能需要完成，我们制定了一套分解详细程度的规则。对于一些暂时没有清晰详细的细节但目前不需要完成的工作，不需要分解得太详细，只需要保证要完成的功能都列出来就可以了。需要在一个月到一个半月内开工，必须分解到工作包的水中
平，即80个工时能完成工作。不明确的细节随着项目的进展逐步细化，直至所有项目目标完成。四、 范围确认工作
范围确认是对已完成项目范围正式确认的过程。及时的范围确认可以提高项目组成员士气，并且管理层和甲方可以直观地了解当前项目的进度，同时也为了将来的项目快速收尾。在范围管理计划中明确规定，本项目交付内容多，可以实行阶段性里程碑版本分批次上线。在每一个里程碑版本发布之后，出具相应版本清单交付甲方，甲方对照清单确认的交付成果。确认结果必须由相关干系人签字确认，即便没有通过确认，也需书面记录相关原因，以便我方做补救措施。
通常情况下，客户在见着实际的成品时，会觉得一些成果好像不是自己想要的，然后就会产生一些新的想法，这也是软件开发的常见现象，针对此种情况，我们就依据范围管理计划，走范围变更流程。这样就起到了及时调整，而需求又不至于失控的作用，保证项目整体朝着正确的方向推进。
五、 全程控制范围工作
范围控制的核心是管理变更。即影响发生变更的因素，使其朝着项目有利的方向发展，同时保证所有变更请求都按照项目整体变更控制流程处理，而且还要对已经发生的范围变更进行管理。在本项目的进展过程中，我们不出意外的经历的多次变更，其中一次甚至涉及到程序的总体设计。
软件在设计之初就定义了设计原则，即用户在办理具体业务时，是以文书驱动流程进行业务操作，弱化了流程的对业务的控制。第一个版本上线后，客户机关因组织架构的调整，强化了流程对业务的指导，流程监控部门的干系人随即提出了原有设计理念不符合新的业务场景，要求变更。此次变更影响较大，内在因素复杂，此处不细说。对于此次变更，我们严格按照项目范围管理计划和变更程序进行。我召集项目管理团队全面分析此次变更对现有已完成工作和后续其他未完成工作在成本和进度方面的影响，以及可能产生的延误风险，汇总成报告文件提交给CCB。经过CCB评审通过后，我们按照新的范围基准更新了进度和成本计划等相关项目文件。
在项目实施中，我们的业务需求人员会直接面对甲方的实际使用人员，并会建立良好的关系。良好的关系当然对工作的推进是有利的，但是也会存在关系好，就可能忽略管理流程的情况。比如一个小的改动就直接给我方需求人员口述一下，这种情况我是明令禁止的，决不允许私下答应。两个原因，其一是有一就有二，久而久之，制度就成摆设了，其次也是因为提出人员会有其自身所在岗位的局限性和利益考量，不够全面，所以任何变动都要提交专班需求小组讨论通过，最后走变更流程。
由于项目范围管理有效，虽然历经了多次变更，但整体可控，始终朝着有利的方向进行，最终项目也顺利完成验收，客户也高度评价。在项目验收总结会上，我们一致认为，得益于项目初期阶段就建立了符合大型复杂的需求管理体系和严格的变更控制流程。经过本项目的管理工作，我也积聚了中大型项目的管理经验：
第一，一定要做好需求把控工作，并且必须由甲方重要干系人参与；第二，任何变更都要跟 据流程走，切记认为影响小改动不大就嫌麻烦不走变更流程；第三，变更批准前要准确地评估相关影响，提交CCB评审；第四，变更后要及时调整进度基准和成本基准。
