项目管理实施体会（三）

文章作者 100test 发表时间 2007:01:15 18:07:23
来源 100Test.Com百考试题网

VII. 计划的执行、变更
影响计划执行的因素可以分为主观因素和客观因素。客观因素有客户相关风险，外部环境的影响，停电，机器损坏，不能上网等原因。主观因素有：人的因素、技术因素，资源因素。如果项目计划的Breakdown或曰“粒度”不符合实际情况，也是影响计划执行的因素。
设立里程碑，加强项目进度的检查（与进度计划比对）和控制，维护项目计划的严肃性，是规避计划执行风险的一个有效办法。但这是不够的。只有建立合理、实用的计划，计划的执行才会有可能。依照前面所提到的计划编排原则，那计划的执行应是这样进行的。在执行计划A时，应先审查计划B的内容，利用WBS方法，确定计划B的内容是不可再细分，需求在现阶段是否要作进一步的调整，功能点是否要删除、修改、添加等等，然后再确定计划B的具体执行时间，粗略调整由此引发后面的计划的变更。换句话说，也就是，迭代计划B，使计划B更你能满足现实的情况。计划B的具体执行时间已经制定，就是“死的”，不允许作调整，必须想尽一切办法按时、按质完成计划。因为这时计划是比较符合实际的，不能按时按质完成，不是态度问题，就是效率问题。完成计划A，在执行计划B时，迭代计划C……通过执行，迭代，完成整个计划。总之，就是使计划处于相对动态中，不是静态，也不是动态的，频频变化，要避免“项目失控合法化”。
一个项目的范围计划可能制订的非常好，但是想不出现任何改变几乎是不可能的。因此对变更的管理是项目经理必备的素质之一。在这里，我们定义在执行计划A前，对计划B的修改，称为调整；执行计划A后直到完成计划B中对计划B的修改，称为计划的变更。从常识来说，对计划的调整，相对而言，成本的变化不大。因此，计划的调整是约束最少的，只要有合理的理由，对整个系统没有特别大的影响，都可以进行调整。相反，对计划变更的约束是最大的，不是哪个人，哪个领导拍个脑袋，想怎么变更就怎么变更的。谁变更，谁就应该负担变更所引发的成本。在变更之前，应该进行集体讨论。这时，千万要避免项目领导闭着门，想个三天两夜，然后对众人来个宣布，决定要怎样怎样变更。这时，来个“一言堂”，项目很容易失败的。谈论时，要明确以下目的：一，为什么要变更？二，可不可以通过其他方法来弥补，而不需要变更？三，要变更，是最少的，最优的变更吗？？四，变更造成的成本差，具体由谁来负担，这一定要明确，不能模糊。总之，抓住一个宗旨：能不变更就不变更，能少变更就少变更，变更了就应该有具体的人员来负担相应的责任、成本。一般来说，可以变更的原因有客观原因和主观原因。客观原因，如项目组成员计划外出差，生病，公司大型活动等等而造成无法按计划执行，这时的变更所造成的成本，则只能有公司来负责或整个项目组来负责。主观原因，即使是加班加点，提高工作效率，也无法按计划时间来执行计划。这种情况，是制定和调整计划的人没有做好，需求的功能比较模糊，细化得不彻底，难点估计不足。这种情况下的变更，则计划的制定和调整者，应负担相当大的责任和成本，开发人员所负担的责任和成本则相应小一些。如果是由于开发人员的责任心不够而造成的变更，则开发人员要负担大部分的成本，开发人员的领导也要负担一小部分的成本。
不管怎么样，只要变更确定了，就应该严格执行，绝对要避免同一内容一而再，再而三地进行变更，使计划成为摆设。这时，对计划地对计划地执行，应该是专制的，“一言堂”式地进行。

VIII. 测试及产品的收尾阶段
目前市场竞争的激烈和市场的成熟度不足，可能导致应用开发项目的恶性竞争风险。客户希望物美价廉而加需求、压价格、压进度；厂商惟恐出局而拍胸脯、打包票。这是很多项目经理面临的类似的情况，特别是在项目后期。

到了项目后期，主要是在进度和软件质量取得一个平衡点。在实际的项目质量管理中，质量管理总是围绕着质量保证(Quality Assurance)过程和质量控制(Quality Control)过程两方面。质量管理就不在这里展开，主要还是说说，编码等的修改和进度与系统测试的关系。
一般而言，随着项目的深入，环境各方面的变化，具体实现总是和原先的设计或多或少地出现偏差。这是很正常，不必惊慌。原则上是，能不修改则尽可能不修改。实在要修改，则只要不是原则性的错误，尽量不要推倒前面所做的一切，重新做，毕竟以前做的时候也是考虑了方方面面的因素的，现在出现的问题只是在某方面考虑不周而已，一切都作废，太浪费了。还有，要是数据库字段已存在，除非万不得已，千万不要修改数据库字段，实在不行就添加字段。因为已经存在的字段，很有可能已被软件开发小组的其他成员在使用，不要因为你的修改而令其他人也要跟你做相应的修改。最后，软件界面的修改要慎重，界面的修改很容易使你忽略修改相应的内容，造成软件大问题没有，小问题一大堆。要尽量避免出现以下两种情况：一，不顾进度、成果，尽量修改，务必做到尽可能和预设功能一致；二，为了尽快完成项目，以时间点为准，做些表面修改，也就是不负责任的修改，以求尽快完整，早日解脱这个项目的苦海。这种情况，在管理过程中，出现波折，有大量、频繁的修改的项目，出现得特别多。