项目变更管理

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

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值