项目变更管理

1.1 什么都改客户就满意了吗—如何管理变更

　　开发阶段后期，客户可以操作实际系统了。这个过程中，客户经常感觉与最初的设想有差异，变更开始多了起来。

　　虽然有变更流程，但在进度压力下一些人觉得“太麻烦了”，往往不再申请变更，而是直接找开发人员商量现场修改。开始客户对这种高效的工作方式很赞同，而小M为了进度也就睁只眼闭只眼了。

　　但是，事态逐步失去控制，有人违反规定直接将未经测试的程序交给客户，更有甚者直接在客户的测试环境中修改程序。因为跳过了版本管理的环节，所以经常会“改好的错误重新出现”，客户对于这种混乱的现象已经开始抱怨了。

　　最近一次，一个客户要求统一修改界面风格。为了让客户满意，一个开发小组立刻动员大家抓紧时间修改。在周例会上，G总听说因修改界面而造成一个小组开发滞后非常气愤，质问小M：“为什么现在花这么多时间改界面?!不是有变更流程吗?为什么不控制?”

　　小M觉得非常委屈，“不是你们说变更流程太麻烦吗?”小M心想，客户太难伺候了，有变更流程嫌麻烦;现在有什么需求马上就改，客户却责问为什么不执行变更流程。

　　到底错在哪里了!

　　1.1.1 为什么会变更?

　　软件项目的变更确实很多!小M回想起来，项目已经遇到过几次大的变更。大概分成了几种类型：

　　第一，外部政策变化。曾经由于政策变化增加了一些报表，应对监管的要求。好在与客户有变更流程的约定，所以这部分工作量客户是认可的。项目管理培训

　　第二，灰色区域。最然对工作范围进行了梳理，但还是存在一些灰色的区间。经过双方的讨论和澄清逐步解决了。

　　上面这两类变更的次数比较少，牵扯的内容比较大，因此处理起来比较方便。最麻烦的就是第三种，需求变更。项目管理论坛

　　尽管进行了需求评审，反复确认了需求。但需求文档和实际系统还是有很多差异，客户测试时提出了很多修改要求。这些变更每次修改的内容比较小，但是挨不住次数多啊。因此，客户觉得每次都要走变更流程非常麻烦，所以总是想法绕开。刚开始还打个招呼说事后补流程，发现没有补也没事，下次就直接改。就这样逐渐地变更流程就松懈了。特别是最近的进度压力很大，执行“变更流程”更加困难，逐渐地变更流程就变得形同虚设了。转自

　　1.1.2 变更失控的后果

　　因为没有进行变更控制，已经给项目组造成了严重的后果。

　 　首先，“私下交易，总体失控”。这段时间，为了节省时间，客户与程序员都是捉对厮杀，一个客户坐在一个程序员边上边商量边改。因为程序员不做任 何记录，相关文档也来不及修改，没有记录到底改了些什么。积累到现在，需求、设计和代码已经无法保持一致，甚至没有人能说清楚现在系统“到底改成什么样 了”。

　　其次，“未达成一致，反复修改”。有的小组中多个客户 负责需求，但是他们来自不同部门，内部尚未达成一致。因此，客户甲说了方案A，程序员刚刚 改完，客户乙看到结果之后又要求程序员改成方案B，最后两个客户会对着程序员说“你到底听谁的?”，弄得程序员无所适从，不知道到底该怎么改。项目经理圈子

　 　第三，“违规操作，酿成大错”。变更流程明确要求修改和内部测试之后才能放入测试环境，但程序员有时直接就改。有一次有人甚至未经许可就擅自修 改了核心模块，造成系统运行异常缓慢，大量应用程序超时退出。事后投入了大量精力才排除了故障，但是客户一个测试团队整整等了将近1天，知道原因均表示对 这种“低级错误”无法容忍。

　　第四，“没说明影响，出力不讨好”。这次修改界面的事件就是个教训，变更都是有代价的，但是却没有告诉客户代价是什么就直接进行了修改，所以让G总非常恼火。如果提前让G总了解变更的影响，再作出判断是否需要修改，就不会发生今天的事情。转自

　　小M以前觉得变更流程是为了让客户修改起来麻烦，从而减少变更。今天发现，变更流程其实是为了让变更有序地进行，否则就会引起上面这些麻烦。

　　1.1.3 变更控制的流程

　　小M重新审视了公司变更流程，发现变更流成像个漏斗，层层过滤和筛选，通过四个关键控制点确保变更有序进行，如图4-16所示。bbs.mypm.net

　　

 

 

　　图 4-16变更控制流程

　 　授权。变更流程中规定，必须明确授权客户方哪些人员有权提出变更申请，项目组哪些人员有权受理变更，并有双方人数要求。如果严格这样做了，就不 会发生“私下交易”的情况，因为他们没有权利!另外，明确变更接口人还有一个好处是可以屏蔽客户内部的矛盾，如果只有一个接口人，如果客户甲、乙两个人尚 未达成一致，是不可能提出相互矛盾的要求来的。如果双方观点不一致而反复变更，我们就可以问：“到底按谁的意见改?”项目管理论坛

　 　审核。变更审核过程要求确定变更的优先级，并不是所有的变更都一定要修改，更不是所有变更都要立刻修改，审核的目的就是按照规则确定哪些立刻 改，那些以后逐步优化。比如案例中提到的界面风格的问题，当前完全可以不修改，等到上线之后逐步优化也没有问题。对于核心模块的修改如果有了审核就可以严 格把关，仔细权衡和严格控制，避免酿成灾难性后果。

　　评估。变更都是有代价的，应该评估一下变更对于时间、成本、质量等方面的影响，方便高层领导作出判断。

确认。评估结果一定请客户知道，并确认是否接受代价需要修改。确认过程争取到了与客户协商的机会，如果客户接受变更的代价，即使今后不需要额外支付款项，也知道项目组有“苦劳”，项目组吃就是明亏。

　　表4-22 变更申请表

 

　　只有通过了上述四个环节之后，才会开始进行变更，统一修改相关的文档和程序，进行测试和部署。变更申请表的格式见表4-22，为了便于管理分析，所有变更申请表应该有一个清单进行跟踪和管理。

　 　小M明白了今天之所以吃亏客户还不满意，完全是自己没有深刻理解变更流程的目的和作用，因此导致了执行中的偏差。如果从一开始就进行宣传和培 训，说明变更流程的意义和作用，大家就不会想办法绕过去。另外，项目过程中应该对变更控制的执行情况进行审计，发现违反规定的事件要严肃处理，就不会造成 过程逐渐失效。

　　1.1.4经验与教训

　　IT项目中变更是常见的一个难题，但变更控制不是为了让变更变得困难，而是让变更变得有序，否则就会出现很多灾难性的后果。

　　变更控制流程有四个重要控制点：授权、审核、评估和确认，只要理解每个控制点的作用，在执行过程中作出正确的判断，才能避免什么都改客户还不满意的情况发生。

　　摘自《IT项目经理成长手记》

 

 

转载于:https://www.cnblogs.com/hanhuibing/articles/4921844.html