项目需求变更控制技术---技术性论文

摘要
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
 项目需求变更控制技术是保证项目成果于客户期望一致，控制项目成本，按期完成项目进度的关键性保障之一。本文从某市应急联动指挥系统的实际建设出发，介绍我在该项目建设过程中需求变更控制技术的应用。在该项目中，我担任项目经理，在项目变更控制技术应用上，为团队思想意识，说话态度，及其处理步骤上都建立一套标准。意识上要求从团队在意识上树立正确的认识，态度上在团队内部形成对待项目变更的沟通态度。步骤上建立对变更控制的步骤和控制方法技巧，其一是建立需求变更的处理流程，让所有的干系人认同根据此流程进行需求变更；其二要求团队对变更的需求有充分的理解并形成各类文档，还有进行全面的变更风险分析；其三坚持以文档的形式将需求实施方案经客户确认。经过我对待项目变更意识、态度、方法步骤的全面合理应用，项目成果与客户期望没有发生偏移，团队开发工作也建立在一个反工率不高的基础上，变更引起的各类风险也基本得到控制。现在我对在该项目中变更技术应用细节一一做个详细阐述，以供相互学习，共同进步。技术分析员 李海 －－－nclihai@tom.com

正文
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
2007年，我作为项目经理，参与了某市应急联动指挥系统的建设。该项目是由该市发改委市政府领导，该市是公安局主持的项目。该市是奥运会帆船比赛城市，为了提高整个城市对突发事件的处置响应能力，建设了该项目。其业务范围包括110、119、122三警合一平台，各联动单位如地震、人防、海事等16个联动单位的应急协作业务。项目组成包括网络、机房、接警处警工作台、调度台、视频监控、地理信息系统、电话话务系统、短信系统、计算机综合调度系统、决策分析系统等。我公司负责的是用于业务处理的电话话务系统、短信系统、计算机综合调度系统、决策支持系统。我公司项目从2007年5月开始，由于奥运会在2008年8月份开幕，工期十分紧张。而最大的麻烦是项目需求不十分明确，为迎接奥运，又三警联动，发改委、市政府、公安局都在深入学习。奥运会头一次在家门口开，谁也没有成熟的经验。在此项目中，需求的充分调研、研究，对需求变化的记录、分析、跟踪、评估、设计、确认等技术十分重要。我作为业务软件系统的负责人和项目经理，运用了很多变更控制技术在这个项目中。
项目变更主要体现方式是项目的需求变更，客户的要求有前后不一样的，有新增的。所谓的变更控制，就是做到项目成果和客户最终需求一致，完成项目需求变更与项目成果的双向跟踪。项目变更，其含义不是说不让变更，而是让变更朝着有利项目建设的方向发展。在该市项目中由于软件功能需求不明确，客户随着对项目深入的了解和知识的积累，那么对软件功能及建设环境都可能产生前后不一致的需求，我主要负责软件方面的工作，本文也只谈对软件需求变更的控制和管理。
该市项目中，我首先从开发团队内部对待变更的意识态度调整思想：
一、要求自己和团队成员树立对需求变更的正确认识。
首先，我告诉大家，该市项目是为某市在12月内完成的特定的任务（需求）。项目建设过程中，客户是随着我方一样，有一个逐步熟悉的过程。随着对业务的深入理解，当初的要求肯定发生变化。所以该市项目发生变更是一种必然现象，无法回避，必须认真正确处理。
其次，我告诉自己和团队成员，需求变更具有很大的危险性。需求变更处理不好，不停地变，项目结项遥遥无期，成本无限制地被扩大，项目注定要失败。
二、要求团队成员学会处理需求变更的正确沟通态度，总结相应的注意事项。 该市项目的客户是很有特点的，他们都是一些政府官员，第一、有一定语气命令式的强硬态度；第二：听不管别人老是说“不”；对于他们所要的东西，总想马上可以立竿见影式地做好；对于我方来说，客户要的越多，我方就做得越多，而且有一定周期。所以我在团队制定一个标准，不要直接当面对客户说“不”，也不能当场答应下来，说“好”，记录整理好客户意见后，就说“在计划安排”。
以上两点为对待变更的意识和态度，我处理变更的步骤是这样的：
一、 建立需求变更的标准 。
为应对变更工作的有效开展，我找公安局客户代表，客户聘请的技术顾问，监理方，商讨了需求变更处理流程，并达成一个共识，其核心思想是这样的：
客户提出意见—》团队成员详细记录――》理解写成文档，同时进行各类风险分析
――》交付由公安局客户、技术顾问、监理方、我方团队四方组成变更委员会审核，达成一致意见――》我方设计实施，形成方案文档――》交付变更委员会确认――》开发、测试、发布。
根据此流程，使变更处置方法在各方之间形成共识。对待需求变更，无论是客户，还是监理，都知道按照此方法处理，进行有效的接受或者驳回。我们对变更的实施过程，也有一套标准保证设计结果与客户确认，发布前必须经过测试，来预防各类风险的发生。
不过有时候，有的客户领导不愿意参加确认会议，对于自己提交的需求，认为说的很清楚了。我只能找到客户代表（负责统建项目的客户方领导），让他帮助我们协调，通过多次跑腿上门解释确认的方式，来完成需求的确认。这个过程中，经常发生需求理解的差异，我通过这个差异向项目客户方代表反映，确认的重要性，让他理解并更支持我方的工作。
二、充分理解变更要求。 我在项目建设过程中发现，客户经常对自己的意见难以表达清楚，或者有时候我们难以全面理解客户的话。其问题在于两方面，其一，客户的表达和他对业务的理解上，需要我方人员给与提醒，来帮助客户充分表达；其二，客户意见经过理解和传递，发生一定信息丢失和误解。对此，我要求团队完整记录客户的意见，并形成文字描述，经过客户确认后，方视为需求表达工作完成。然后还要求团队将理解写成文字向客户反馈，经过确认后，方视为理解工作完成。 这样就保证了需求变更的充分准确理解。
三、全面分析需求变更风险及对应步骤。 在项目建设过程中，为了提高119的接警效率。消防部门提出改变119接警模式，将原来的接处合一统一接警模式变成119只顾自己，不参与统一接警。这个问题一引起合同变换，二、引起项目周期变化 ，三、违背三警联动的建设目标。
我发现，客户经常提出需求仅站在自己的角度思考问题，具有一定的局部性。我需要站在全局高度全面分析客户需求风险，来了解客户需求到实现的整个过程有没有冲突，会不会引起其它已经完成任务发生问题。于是我申请召开变更控制会议。经过会议，我为项目建设申请到17人月的建设成本。试想，如果不进行风险分析，匆匆了事。我无人力资源负责任务，公司成本无缘无故地扩大，那么项目失败将势在必行。
四、需求变更确认。 客户提出的需求，虽然我执行了充分理解、全面分析这些步骤，但是是否真正理解了客户的需求，还需要客户来一起验证确认。我在这个项目建设过程中，坚持了两个层面的确认。首先，需求功能层确认；其次，软件实现界面操作层确认。这样做的目的，是为了能够准确把握对需求的理解，然后再开始开发，从而让开发工作尽量减少反工。因为代码层的反工，比文档层功能设计反工成本要高得多。试想在文档上把变更功能，及操作界面都定义好之后，经过客户确认，接下来的编码工作就水到渠成，反工会几率大大降低。
另外我还使用了一个工具SharePoint，来管理各类变更文件。此工具可以将各类Word、EXCEL等文件，以表记录形式建立配置库，方便访问查询。对于一个需求的变更，可以为每一个版本建立一条数据记录（可自动添加属性：摘要，日期等），并将文件以附件的形式绑定在改记录上，很方便。
以上是我在该市应急项目中，对需求控制技术运用的介绍。经过我们近一年的努力，该市项目如期上线了。奥运期间，是我们的系统在为民众服务。现在回想起来，成功运用需求控制技术为我的工作真是带来了很大帮助。
不过对自己的需求控制技术，我还并不满意，就是有时候被客户强行施压时，我无法找到技巧坚定不移地执行相应的标准。有一次客户提出一个变更，必须在几天内完成。我快速地经过理解、分析、确认后，提交会议评审。会议上我分析了各类风险，监理公司也认可风险。但是客户强行要求通过评审，我签署完个人保留意见后，也不得不同意执行了，但同时申明无法承担相应的风险。变更后，果然出了大问题，全市110瘫痪了，虽然很快回复，心里很是后怕，如果110瘫痪时有人求助无法响应而发生人命，将叫人悔恨终生。目前我还在学习应对此类事件的处理技巧和方法，希望有朝一日可以轻松自如处置好此类问题。