摘要
2016年6月，本人作为项目经理开始参与北京大学餐饮安全管理综合信息系统项目的开发，担任项目经理，承担了项目管理工作，该系统具有严格的安全，稳定，和可靠性能要求，该系统由统计分析、安全督查、资质管理、知识管理、集成监管以及微信公众号服务各个子系统组成，统计分析主要实现各个业务子系统实现统一业务数据汇总功能，安全督查主要实现现场检查工作人员手持移动通讯设备，选择被检查单位和问题对应的科目和子科目，资质管理实现对食品供应商资质的管理与审核，知识管理主要实现对食品安全相关数据的发布和管理，集成监管和微信公众号服务实现对食堂操作间进行实时的监控。采用了主流的三层架构，支持三层部署，可以方便系统的维护升级。
项目的成功很大程度上归功于本人在项目过程中对范围的管理和控制，本文结合作者的经验通过范围规划、范围定义、创建WBS、范围确认和范围控制等过程的翔实论述，并就项目过程中采取的措施、方法作了介绍。最后，列举了该项目范围管理的一些不足之处。 正文
2012年6月，本人作为项目经理开始北京大学餐饮安全管理综合信息系统项目的开发，主要负责项目管理，当然还做一些设计工作，主要是公用基础代码和核心代码的编写与维护。北京大学餐饮安全管理综合信息系统是按照食品安全功能规范以及建立以食品安全为核心的信息系统的方针进行的设计，主要包括数据汇总、集成监管以及安全督查核心功能，实现食品安全业务的整合。通过与微信及食品pad端等系统的集成，从而满足餐饮人员的日常工作。系统分三层实现，中间业务层通过spring实现，数据库采用高性能的mysql数据库，客户端采用html5的实现技术。
范围管理是项目管理的基础，也是项目管理工作的重点和难点。含糊的需求和频繁变更的范围让项目的甲乙双方吃尽了苦头。如何做好项目的需求管理与范围管理常常是项目经理最头疼的问题。餐饮安全管理项目的成功，笔者一直认为得益于有效的项目范围管理机制。
该信息化建设系统投资规模较大，技术复杂，需求难以定义，质量要求高，而且该项目涉及的干系人面广人多。因此作为项目经理我认为应该将主要精力放在项目范围管理上，科学地运用相关理论知识并结合我司CMMI3项目管理过程域的具体要求，做好项目范围管理的工作，才能满足项目各方干系人对项目成功的渴求，从而带领整个项目团队走向成功。下面分别从范围规划、范围定义、创建工作分解、范围确认和范围控制等方面对项目范围管理过程和相关问题加以简要论述。
2需求开发编制范围计划：
由于该项目技术复杂，最终用户繁多的特点，为了使项目顺利实施，我认为清晰分析项目的具体范围和具体工作内容至关重要，同时也为提高项目成本，时间和资源估算的准确打好基础。前期我通过的需求调研，挖掘可用需求，进而对项目的背景有了初步的了解。同时也为后期B/S系统的开发提供参照的作用。为了能全面识别干系人期望，我进行了需求的开发，充分识别用户提出需求，并在一定的基础上平衡干系人期望，为了实现项目目标并记录干系人需求，我们邀请了主要的跨职能干系人一起参加会议，对产品的需求集中讨论和定义。
项目范围管理的一个非常重要的环节，规定了如何对项目范围进行定义、确认，如何创建工作分解结构，以及如何控制范围，是进行范围管理后续工作的依据和指南，需要在充分分析项目的特点基础上编制。首先我们翻阅了公司的组织过程资产库，将公司既有的范围管理计划模板拿出来，结合本项目的特点，制定出适合本项目的范围管理计划，包括制定范围定义、创建工作分解结构的方法，对各餐饮子项目验收过程、确认内容，以及如何做到有效的范围控制。我公司近五年来对餐饮系统集成项目建立了比较完善的档案，档案中不仅包括各大项目的范围管理实例，还包括一系列标准的模板，以及授权程序等文件，这对我们帮助很大，在此基础上结合项目章程和项目范围管理的理论我制定了项目范围计划，它规定了如何对项目的范围进行定义、确认、以及如何制定工作分解的过程
3定义范围:
范围确认是干系人正式接受已经完成的项目范围的过程，通过审查可交付成果和工作成果，实现对项目范围的验收。项目确认应该贯穿项目始终，WBS工作分解结构为确认范围提供了基础。项目范围管理包括项目的最终产品或服务以及实现这些产品或服务所需的各项具体工作。软件项目范围直接与需求相关，在范围过程中，“需求蔓延”是信息系统建设失败最常见的原因之一，范围管理不仅应该让项目管理和实施人员知道为，为了达到预期目标需要完成哪些具体工作，还要确认清楚项目相关各方在每项工作中清晰的分工界面和责任，详细清晰的分工界面和责任，不但有利于项目实施中的变更管理和对推进项目的发展，减少责任不清的事情发生，也便于项目结束时项目范围清晰的确认。
在对项目进行需求分析之后，了解到涉及项目干系人，用户要求界面友好、操作简便的，同时要求对食堂全程工作中，保持信息的快速传播和及时处理的特点，我们同北京大学餐饮中心相关项目负责人、it服务管理人员、业务代表协商一致并结合项目章程，制定了初步的范围说明书和总体技术解决方案，据此在项目干系人之间建立了一个对项目范围的共识，清晰了项目的主要目标，从而项目团队能制定更详细的范围和需求计划，这对指导团队在项目实施期间的工作具有重大意义，同时也为项目团队提供一个范围基线或边界。 4创建工作分解：
创建工作分解是指将项目主要的可交付成果细分成较小的、更易管理的组分。这个过程中，项目组要建立一个工作分解结构（WBS）。WBS的建立对项目来说意义非常重大，它使得原来看起来非常笼统、非常模糊的项目目标一下子清晰下来，使得项目管理有依据，项目团队的工作目标清楚明了。如果没有一个完善的WBS或者范围定义不明确时，变更就不可避免地出现，很可能造成返工、延长工期、降低团队士气等一系列不利的后果。制定好一个WBS的指导思想是逐层深入。我先将项目成果框架确定下来，然后每层下面再把工作分解，用滚动式规划法将所有涉及到活动都进行了排序，近期要完成的工作分布在工作分解结构的最下层，远期要完成的工作分布在工作分解结构的高层，随着项目工作的不断进展，项目工作分解结构逐步清晰、明确。这种方式的优点是结合进度划分直观，时间感强，评审中容易发现遗漏或多出的部分，也更容易被大多数人理解。（根据项目的特点，我同团队成员进行充分讨论之后确定以项目生命周期作为第一层。即需求分析、系统设计、编码、测试、验收和项目管理作为第一层，将各个系统/子系统作为分解结构的第二层） 5范围确认：项目范围管理不仅是让项目管理和实施人员知道为达到预期目标需要完成那些具体工作，还要确认清楚项目相关各方在每项工作中清晰的分工界面和责任，不但有利于项目实施中的变更管理和对推进项目的发展，减少责任不清的事情发生，也便于项目结束时项目范围清晰的确认。项目范围确认项目干系人（发起人、客户、用户）正式接受已完成的项目范围的过程，范围确认需要审查可交互物和工作成果，以保证项目中所有工作都能准确满意地完成。由于项目的范围确认贯穿于项目的始终，从WBS的确认到项目验收时的检验，为了保证做好各个阶段范围确认的工作，我在项目实施中，在完成计划中各重点里程碑之后，与项目干系人共同完成里程碑的检查与评审，目的是防止范围需求的偏差、遗漏，已达到在项目范围内干系人对阶段工作完成情况的正式验收。
例如在早期我们同客户确认了以下重要里程碑：概要设计、数据库设计、界面原型、接口设计、详细设计、B/S 部分编码、集成测试设计、集成测试、系统部署、系统上线、系统调整，在以上每个重点里程碑完成之后，我邀请了相关干系人，共同参加项目评审大会，我们通过项目评审发现偏差并及时记录，之后对评审问题给予跟踪解决，同时我们将最终的评审结果和偏差解决方案，以评审报告的形式上报到公司高层负责人及客户方的项目经理，并签字确认，最后将评审结果发给其他与会人员，使阶段的范围确认留下正式的书面记录。
5、范围确认
范围确认是干系人正式接受已经完成的项目范围的过程，通过审查可交付成果和工作成果，实现对项目范围的验收。项目确认应该贯穿项目始终，WBS工作分解结构为确认范围提供了基础。在项目的每个阶段，我都组织客户对可交付成果进行检查，通过判定是否符合质量要求决定是否验收。每一次的范围确认都使得项目更接近成功，降低了项目成果不符合客户期望而导致返工的风险。业主在每次确认可交付成果后对项目的成功也更有信心，满意度也逐渐上升。我个人感觉，在此过程中最重要的是要让业主感觉项目的进展是可掌控的，是遵循他们的意愿的，这样，随着项目的进展，风险越来越少，客户自然就对项目管理工作很满意。同时，对项目每个阶段的范围确认，也保证了项目顺利进入下个阶段。在和客户确认范围时，我非常注重获得客户的书面确认，如果无法通过确认，还要记录详细的原因，以便于寻找解决方案。在项目的实施过程中，由于我制定了详细的WBS，并和客户有良好的沟通，所以在范围确认时进展比较顺利。 6范围控制： 是监督项目和产品的范围状态，管理范围基准变更的过程。对项目管理者来说如果范围控制不好，直接关系到项目需求的蔓延，有可能造成项目成本的提高，进度的延迟，甚至影响到项目的质量。例如项目早期需求分析过程中，我们进行需求调研之后，发现甲方并没有严格定义现在系统的新功能，造成项目在项目初期项目范围没有明确界定，为了防止范围蔓延而影响项目的进度。我在项目初期制定了变更控制流程，在需求调研基本结束开展后续工作后，所有需要进行的变更，都要严格提交变更申请单，由我和其他相关干系人组成的变更控制委员会分析对现有进度和其他因素的影响，审核是否进行变更，确定后进入项目内部使用的变更信息库，作为后续修改、跟踪、查询的依据。
需求变更不可避免，但也不能一味的全盘接受，一定要在项目实施前建立好双方达成共识的游戏规则，避免项目范围失控。我在项目启动初期，就组织了由业务部门总监、项目经理、产品经理、架构师等组成CCB变更控制委员会，形成项目管理过程中相关变更事项的变更决策管理机制。包括项目范围在内的所有项目变更活动，都需要经过变更申请、变更评估、变更批准、变更实施、变更验证和信息同步等变更控制流程，保证包括范围变更在内的项目变更在CCB的控制和变更控制流程的约束下统一进行。制定常态化会议机制，定期由CCB成员共同讨论阶段性的变更需求，根据优先级及对项目整体的影响程度综合评估，来决定接受还是拒绝，通过严格的项目范围变更控制流程，在不排斥需求变更的前提下，实现项目范围的有序和控制，达到既及时响应客户需求，满足系统的实际需要，又是项目范围始终在可控的范围内，接受需求变更也要按照流程调整对项目进度、质量、资源、风险等方面的计划调整。
在项目的初期，业主并不了解变更流程，也不愿意按照变更流程去走变更，他们更希望自己的要求被无条件的执行。在我耐心的和客户沟通，说明整体变更的意义后，客户明白了整体变更控制对双方都是有利的，最终同意了建立变更控制流程，并积极的参与进来。这对以后双方对项目的监控打下了良好的根基。我自认为我做的很好，如果没有说动客户同意走整体变更控制，那么项目范围蔓延的风险就会很大。我们也必须投入更多成本做更完备的风险应对。而现在，这些风险大大的降低了。另外，我在项目过程中定期召开状态评审会议。通过对照范围基准，审查项目的范围偏差，分析原因，并采取相关纠偏措施。
经过11个月的努力，水资源实时监控与管理系统终于在2016年12月25日完成推广培训应用，系统全面上线启用和验收，并获得用户的高度评价，为用户解决了实际问题，建立起了高质量、高效率的客户服务中心，得到了业主方的好评，本项目的成功得益于我成功的范围管理。总结整个项目的实施过程中，仍然存在一些不足的地方，一是需求跟踪没有仔细去做，导致经常会为了并不特别需要的功能浪费很多精力，甚至有些功能根本用不到，二是团队成员的协作程度还不高，没能最大限度的发挥团队的战斗力，在沟通管理方面还存在一些缺陷等。三是在项目范围管理计划是还应该安排更多的预留资源，以应对项目范围变更方面风险。总之项目的范围管理是整个项目管理过程的重要环节，它与项目的质量、成本、进度密切相关，对一个项目而言，只有按照项目生命周期的要求，做好各阶段的工作，才能满足项目各方干系人对项目成功的渴求。在今后的项目管理过程中，我会积极总结经验和教训，做好项目管理工作，和同行进行交流，提升自己的业务和管理水平，力争为我国信息建设做出自己的努力。
