关键字:信息系统监理;进度控制
引言:
变更控制真的这么重要吗?变更控制难道能够和质量、进度和投资控制相提并论吗?项目中真的有那么多变更吗?
很多人都是带着这样的疑问开始认识变更控制的。在项目的开始一切都还顺利,在项目过程中一直都将质量控制作为首要任务,并防止成本的变动,按照预定的进度计划执行,一旦某一个方面发现了问题马上采取措施实施纠偏。这一切都进行得这么顺利,然而随着项目往后的推移,危险开始逼近了。
在项目一开始,谁都意料不到将来会发生一些什么事情?经验丰富的项目经理可以对将来的事情做一些预测,但是在事情发生之前,谁都没有能力把握将来可能发生的事情。正是这种对未来的不可预见性,让项目的各方干系人都是雾里看花,既看不清成功的希望,也不看到那些隐藏的危机。
直到有一天,建设单位觉得他们花费了上百万的资金做出来的东西不是很适合他们的胃口,这就如同买了最好的墙漆,请了最好的油漆工,但是刷出来的颜色不是自己所中意的一样。他们感觉到自己的钱花得不值,于是乎开始要求对系统作出一些修改,按照他们的意愿来修改,如同要求油漆工重新调色、返工一样。而这一些就是噩梦的开始。
看我三十六变
西游记中的孙行者有72变,这种变化的能力让他在斩妖除魔中总是大显身手,然而当开发中的软件也如同孙行者一样变化多端的话,那么不仅妖魔拿他没有办法,连技术高超的软件设计师和程序员也没有了办法。他们将陷入不断修改、不断弥补、不断赶进度的过程,而软件未来的形状似乎永远都没有定形。软件的三十六变化所带来的苦恼远远超过了孙行者的七十二变。
随着时间不断的流逝,系统的棱和角也开始慢慢的显现,当然很多东西已经产业了变化,软件经过建设单位的修改要求,已经换了一幅马甲,由一个“村姑”摇身一变,变成了一个“摩登女郎”了。虽然在业务实现上比不上“村姑”,但是性感的外表让建设单位的领导者着实领略了一番“高科技”的能量。
抓狂的开发团队
做一件西装并不难,但是要将一件做好的夹克改成西装就会难到全世界的裁缝。当系统刚开始编码的时候,程序员的心情是愉悦的,他们按照类图和接口说明进行类的实现,根据序列图进行软件逻辑的实现,这些都是按照平时的工作方式来进行。进度比事先预计的还要顺利,不必进行加班,大家配合也很默契,这一切都预示着这个项目将会很完满的提前完成。
当软件开发进度过半的时候,经过了头两次的迭代开发,软件的建设单位开始发现软件中的某些地方不符合他们的思想、习惯、爱好等等。随着一系列的意见的提出,项目组决定以项目业主的意见为重要参考,因为本身软件就是服务业主的。照顾他们的爱好和习惯,在下一次迭代中进行一些适应性的修改。
虽然每一个小小的变动,项目建设单位的领导都在变更书上签了字,但是他们却不知道这些改变后面的技术实施情况,一个按钮的增加、一个风格的改变、一个流程的变化都将导致开发人员增加大量的开发工作,将导致开发成本的提高。而这些变化需要多少成本,谁也没有仔细计算、谁又能够计算机的准确呢?
于是乎,整个项目组的任务变得越来越重,以至于必须每天加班还赶不上原来的进度计划,开发进度一再的拖延。建设单位可不认为他们换掉几块“砖”,将导致新建的房子变成“危房”。
扔掉一些包袱
项目组的压力越来越大,不能按时完成项目可是要支付大笔的违约金的。修改后的代码导致了系统的很多不确定因素,被修改的模块要重新进行单元测试和组装测试。很多修改并不是很必要,反而增加了系统的维护难度。