|
历时三年,我和韩秋泉的新书《IT项目经理成长手记》终于完成了，即将出版。这本“手记”记录了项目经理小M的成长过程中的一系列案例故事，并结合案例介绍一些项目管理工具和模板的使用。项目管理者联盟
应网友的要求，发表其中一章，与大家分享。项目管理者联盟
1.1 什么都改客户就满意了吗—如何管理变更talent.mypm.net
开发阶段后期，客户可以操作实际系统了。这个过程中，客户经常感觉与最初的设想有差异，变更开始多了起来。项目管理者联盟
虽然有变更流程，但在进度压力下一些人觉得“太麻烦了”，往往不再申请变更，而是直接找开发人员商量现场修改。开始客户对这种高效的工作方式很赞同，而小M为了进度也就睁只眼闭只眼了。项目管理者联盟
但是，事态逐步失去控制，有人违反规定直接将未经测试的程序交给客户，更有甚者直接在客户的测试环境中修改程序。因为跳过了版本管理的环节，所以经常会“改好的错误重新出现”，客户对于这种混乱的现象已经开始抱怨了。项目管理者联盟
最近一次，一个客户要求统一修改界面风格。为了让客户满意，一个开发小组立刻动员大家抓紧时间修改。在周例会上，G总听说因修改界面而造成一个小组开发滞后非常气愤，质问小M：“为什么现在花这么多时间改界面?!不是有变更流程吗?为什么不控制?”项目管理者联盟
小M觉得非常委屈，“不是你们说变更流程太麻烦吗?”小M心想，客户太难伺候了，有变更流程嫌麻烦;现在有什么需求马上就改，客户却责问为什么不执行变更流程。
到底错在哪里了!项目管理者联盟
1.1.1 为什么会变更?项目管理者联盟
软件项目的变更确实很多!小M回想起来，项目已经遇到过几次大的变更。大概分成了几种类型：service.mypm.net
第一，外部政策变化。曾经由于政策变化增加了一些报表，应对监管的要求。好在与客户有变更流程的约定，所以这部分工作量客户是认可的。项目管理论坛
第二，灰色区域。最然对工作范围进行了梳理，但还是存在一些灰色的区间。经过双方的讨论和澄清逐步解决了。项目管理者联盟
上面这两类变更的次数比较少，牵扯的内容比较大，因此处理起来比较方便。最麻烦的就是第三种，需求变更。blog.mypm.net
尽管进行了需求评审，反复确认了需求。但需求文档和实际系统还是有很多差异，客户测试时提出了很多修改要求。这些变更每次修改的内容比较小，但是挨不住次数多啊。因此，客户觉得每次都要走变更流程非常麻烦，所以总是想法绕开。PgMp.mypm.net
刚开始还打个招呼说事后补流程，发现没有补也没事，下次就直接改。就这样逐渐地变更流程就松懈了。特别是最近的进度压力很大，执行“变更流程”更加困难，逐渐地变更流程就变得形同虚设了。项目管理者联盟
1.1.2 变更失控的后果转自项目管理者联盟
因为没有进行变更控制，已经给项目组造成了严重的后果。项目管理者联盟
首先，“私下交易，总体失控”。这段时间，为了节省时间，客户与程序员都是捉对厮杀，一个客户坐在一个程序员边上边商量边改。因为程序员不做任何记录，相关文档也来不及修改，没有记录到底改了些什么。积累到现在，需求、设计和代码已经无法保持一致，甚至没有人能说清楚现在系统“到底改成什么样了”。pmp.mypm.net
其次，“未达成一致，反复修改”。有的小组中多个客户负责需求，但是他们来自不同部门，内部尚未达成一致。因此，客户甲说了方案A，程序员刚刚改完，客户乙看到结果之后又要求程序员改成方案B，最后两个客户会对着程序员说“你到底听谁的?”，弄得程序员无所适从，不知道到底该怎么改。service.mypm.net
第三，“违规操作，酿成大错”。变更流程明确要求修改和内部测试之后才能放入测试环境，但程序员有时直接就改。有一次有人甚至未经许可就擅自修改了核心模块，造成系统运行异常缓慢，大量应用程序超时退出。事后投入了大量精力才排除了故障，但是客户一个测试团队整整等了将近1天，知道原因均表示对这种“低级错误”无法容忍。项目管理者联盟
第四，“没说明影响，出力不讨好”。这次修改界面的事件就是个教训，变更都是有代价的，但是却没有告诉客户代价是什么就直接进行了修改，所以让G总非常恼火。如果提前让G总了解变更的影响，再作出判断是否需要修改，就不会发生今天的事情。项目管理者联盟
小M以前觉得变更流程是为了让客户修改起来麻烦，从而减少变更。今天发现，变更流程其实是为了让变更有序地进行，否则就会引起上面这些麻烦。项目管理者联盟
1.1.3 变更控制的流程项目管理者联盟
小M重新审视了公司变更流程，发现变更流成像个漏斗，层层过滤和筛选，通过四个关键控制点确保变更有序进行，如图4-16所示。项目管理者联盟
本文为项目管理者联盟联盟会员原创文章，授权发布，非经同意不得转载！
|
