| 4W1H | 过程 |
|---|---|
| 做什么 | 监督项目和产品的范围状态，管理范围基准变更的过程；作用：在整个项目期间保持对范围基准的维护 |
| 为什么做 | 防止范围失控。变更实际发生时，管理变更。如果变更不可避免，必须强制实施项目整体变更控制。杜绝范围蔓延和范围镀金 |
| 谁来做 | 项目管理团队或项目团队（如果项目规模比较小） |
| 什么时候做 | 项目或阶段末，项目结束前进行。 |
| 如何做 | 数据分析（偏差分析、趋势分析）主要成果可以写防止范围蔓延和范围镀金的故事。例1：在内部审查时发现多了某项功能，然后写是产品经理或者是技术总工擅自接受了客户的某项变更，然后进行了处理，增加了变更项、更改了配置项等等。例2：设计师在设计时擅自增加了某项功能，比如一键微信转发，一健统计，一键换肤，一键扫码等。这些功能虽然很实用，很先进，但是客户并没有这个要求，这样就造成范围镀金行为。例3：客户不断的提出新的需求，这些新需求有些合理有些不合理，如:XX模块，修改XX流程设计后，其业务流程更加缜密。XX模块，客户提出的需求不现实。对于合理的需求进行详细的评估并给出具体的解决方案，走变更流程，对于不合理的需求，告知其原因等等注意事项:在写范围控制时尽量不要写某个开发人员私自接受了客户的要求导致范围蔓延或镀金等等。把开发人员换成有一定权利的管理人员会更好。 |
| 组 | 过程 | 输入 | 工具和技术 | 输出 |
|---|---|---|---|---|
| 监控 | 6.范围控制 | 1.项目管理计划（范围管理计划、需求管理计划、变更管理计划、配置管理计划、范围基准、绩效测量基准）2.项目文件（需求文件、需求跟踪矩阵、经验教训登记册）3.工作绩效数据4.组织过程资产 | 1.数据分析（偏差分析、趋势分析）1.工作绩效信息2.变更请求3.项目管理计划更新（范围管理计划、范围基准、进度基准、成本基准、绩效测量基准）4.项目文件更新（需求文件、需求跟踪矩阵、经验教训登记册） |
? 引起项目范围变更的因素主要有：①前期范围调研不充分，范围描述的不准确；②用户出现新的需求；③政策改变导致范围变更
? 如何做好项目范围控制，防止项目范围蔓延：①定义科学合理的范围变更控制流程；②甲乙双方明确范围或需求变更的接口人；③所有变更一律要求书面化；④严格按范围变更控制流程执行范围变更，绝不允许有特例
? 防止范围蔓延：①在收集需求时彻底理解客户的需求；②对所有的需求，变更请求都书面记录，不接受口头的变更申请；③事先编制项目范围管理计划，并规划定义范围控制流程；④规范确认范围过程，必须接受干系人综合评审
? 范围变更控制的主要工作有：①影响导致范围变更的因素，并尽量使这些因素朝有利的方面发展；②判断当前范围是否发生变更；③范围变更实际发生时，确保所有被请求的变更按照项目整体变更控制过程处理
【范例1】
控制范围是监督项目和产品的范围状态、管理范围基准变更的过程，其主要作用是在整个项目期间保持对范围基准的维护。在项目中，我定期组织召开项目状态审查会，审查项目的范围，通过对照范围基准、需求跟踪矩阵等文件，找出范围偏差，并做分析，严格杜绝一切的范围蔓延。针对需求的变更要求项目组必须严格执行变更控制程序，例如2021年12月初，距离系统上线仅有20多天，门诊办护士长提出自助机屏幕上需要显示专家排班信息，原因是很多患者不知道专家出诊信息，方便患者查询，由于距离上线很近，增加此功能还需要和医院号源池进行对接，自助机显示界面、后台模块代码要修改，会增加成本和拖延进度，对于护士长的申请，我带领项目组对此变更做了分析和评估，并提交给CCB审批，CCB认为自助机就是为挂号和缴费服务的，如果增加排班信息，患者会占即长时间的自助机时间查询排班时间，造成排队现象，拒绝了此申请。倘若没有变更控制流程，直接实施该项变更，就会对项目造成成本超支和进度拖延，影响上线时间。
【范例2】
控制范围是监督项目和产品的范围状态，管理范围基准变更的过程。我们根据范围管理计划、变更管理计划等文件，采用偏差分析等技术，形成了一些变更请求。在项目执行过程中，客户提出了一些新的需求，对于一些不必要的变更，我们通过沟通，使客户予以放弃，而对于一些必要的变更，严格按照变更控制流程进行，避免范围的蔓延。例如，在一次状态审查会上，我发现项目的功能模块中，综合管理平台里面多了桌面风格管理的功能，我查了下系统变更日志，未找到有类似的变更记录，于是我参照责任分配矩阵，找到这个模块开发的负责人询问原因，陆工告诉我，他增加这个功能，是因为业主方有人在一次电话中，向他提过希望增加这样一个功能。针对这种情况，我首先向陆工强调了范围基准、以及变更流程的重要性；其次，针对这一问题我要求相关人员提交正式的变更请求，走正常的变更控制流程。
【范例3】
控制范围是监督项目的范围状态，管理范围变更的过程。作用是在整个项目期间对范围基准进行保护。经过分析判断，本项目的范围变化主要发生在两种情况下:一是甲方在项目周期中提出的新需求或对原有需求的变更;二是项目团队成员对需求理解不到位造成的范围变化或镀金行为。
对于第一种情况，某次甲方在出入库核心流程验收时，提出想要增加“客户回款周期设置及收款通知”功能。我组织核心骨干进行评审，由于系统已具有“通知”模块，该功能只需针对客户设置回款周期即可，开发量不大，对项目进度影响微乎其微，故通过正式的变更流程审批，将该需求纳入范围基准。
对于第二种情况，我定期组织范围审查会，对照项目范围说明书及需求跟踪矩阵，发现范围偏差，并做分析和纠正。在一次审查中，我发现出库单模块的状态筛选变成了标签页筛选形式，而不是原先规定的下拉框筛选。我找到前端开发人员了解他这样做的原因，该人员表示他认为标签页筛选形式更高效明了，我向他说明标签页筛选支持不了出库单状态“多选”的需求，这一私自变更可能会造成用户对产品的不满，同时强调了按照范围基准做事以及走变更流程的重要性，该人员恍然大悟，这才认识到了保护项目范围的重要意义。