VII. 计划的执行、变更

  影响计划执行的因素可以分为主观因素和客观因素。客观因素有客户相关风险，外部环境的影响，停电，机器损坏，不能上网等原因。主观因素有：人的因素、技术因素，资源因素。如果项目计划的Breakdown或曰“粒度”不符合实际情况，也是影响计划执行的因素。 

设立里程碑，加强项目进度的检查（与进度计划比对）和控制，维护项目计划的严肃性，是规避计划执行风险的一个有效办法。但这是不够的。只有建立合理、实用的计划，计划的执行才会有可能。依照前面所提到的计划编排原则，那计划的执行应是这样进行的。在执行计划A时，应先审查计划B的内容，利用WBS方法，确定计划B的内容是不可再细分，需求在现阶段是否要作进一步的调整，功能点是否要删除、修改、添加等等，然后再确定计划B的具体执行时间，粗略调整由此引发后面的计划的变更。换句话说，也就是，迭代计划B，使计划B更你能满足现实的情况。计划B的具体执行时间已经制定，就是“死的”，不允许作调整，必须想尽一切办法按时、按质完成计划。因为这时计划是比较符合实际的，不能按时按质完成，不是态度问题，就是效率问题。完成计划A，在执行计划B时，迭代计划C……通过执行，迭代，完成整个计划。总之，就是使计划处于相对动态中，不是静态，也不是动态的，频频变化，要避免“项目失控合法化”。

  一个项目的范围计划可能制订的非常好，但是想不出现任何改变几乎是不可能的。因此对变更的管理是项目经理必备的素质之一。在这里，我们定义在执行计划A前，对计划B的修改，称为调整；执行计划A后直到完成计划B中对计划B的修改，称为计划的变更。从常识来说，对计划的调整，相对而言，成本的变化不大。因此，计划的调整是约束最少的，只要有合理的理由，对整个系统没有特别大的影响，都可以进行调整。相反，对计划变更的约束是最大的，不是哪个人，哪个领导拍个脑袋，想怎么变更就怎么变更的。谁变更，谁就应该负担变更所引发的成本。在变更之前，应该进行集体讨论。这时，千万要避免项目领导闭着门，想个三天两夜，然后对众人来个宣布，决定要怎样怎样变更。这时，来个“一言堂”，项目很容易失败的。谈论时，要明确以下目的：一，为什么要变更？二，可不可以通过其他方法来弥补，而不需要变更？三，要变更，是最少的，最优的变更吗？？四，变更造成的成本差，具体由谁来负担，这一定要明确，不能模糊。总之，抓住一个宗旨：能不变更就不变更，能少变更就少变更，变更了就应该有具体的人员来负担相应的责任、成本。一般来说，可以变更的原因有客观原因和主观原因。客观原因，如项目组成员计划外出差，生病，公司大型活动等等而造成无法按计划执行，这时的变更所造成的成本，则只能有公司来负责或整个项目组来负责。主观原因，即使是加班加点，提高工作效率，也无法按计划时间来执行计划。这种情况，是制定和调整计划的人没有做好，需求的功能比较模糊，细化得不彻底，难点估计不足。这种情况下的变更，则计划的制定和调整者，应负担相当大的责任和成本，开发人员所负担的责任和成本则相应小一些。如果是由于开发人员的责任心不够而造成的变更，则开发人员要负担大部分的成本，开发人员的领导也要负担一小部分的成本。

  不管怎么样，只要变更确定了，就应该严格执行，绝对要避免同一内容一而再，再而三地进行变更，使计划成为摆设。这时，对计划地对计划地执行，应该是专制的，“一言堂”式地进行。 

  VIII. 测试及产品的收尾阶段

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

  到了项目后期，主要是在进度和软件质量取得一个平衡点。在实际的项目质量管理中，质量管理总是围绕着质量保证(Quality Assurance)过程和质量控制(Quality Control)过程两方面。质量管理就不在这里展开，主要还是说说，编码等的修改和进度与系统测试的关系。

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

  到了项目后期，迫于公司、用户的压力、或者项目本身已经延迟了，尽早结束整个项目，就是自然而言的事情了。大多数的做法是，压缩系统测试时间。系统测试的时间少了，发现的问题也就少了，时间就更加可控了。这样做，也没大错，但必须注意，如在系统测试发现的大部分问题是low的，则压缩系统测试时间问题都不大；如发现的问题有相当一部分是影响使用的，比较hight的，则不能压缩系统测试时间，甚至要延长系统测试时间。不要抱着现在先混过验收测试，等以后有时间再详细测。从我了解的情况来说，这是不可能的，只要一过了验收测试，不管是程序员，还是测试员，其心态都已经发生变化了，不可能全身心投入测试、修改中。即使是勉为其难投入，其效率就可想而知拉。不管怎样，进行系统测试时，最后的修改，必须预备一定的时间进行较全面的测试，以避免修改而引发的错误，特别是简单的错误。经验告诉我们，很多低级错误，都是在最后修改时引入的，因为预料测试时间不足而没有被发现。

  到了项目后期，即使是进度延误得十分厉害，建议还是不要增加成员。因为，新成员得加入，熟悉业务需要，了解、理解业务需要一定的时间，除本身所消耗的时间外，还会有意无意地损耗其他成员的时间，造成进度的进一步拖延，等完全熟悉时，能上手，可能就是项目结束之日。此外，还会因为不熟悉，而引入新的错误，新的不稳定因素。

  到了项目后期，除了进度的执行外，也要特别重视和相关人员的沟通及处理相应的关系。主要沟通人员有：用户方的项目管理人员、用户方的业务人员、用户方的决策层、开发方的项目管理人员、开发方的软件编程人员等。主要的关系有：用户方与开发方的关系、用户方项目管理人员与使用人员(业务人员)及决策层的关系、项目管理人员与软件编程人员的关系、硬件与软件的关系、性能与灵活的关系。