认识你可能会犯的错(4)

    最终，托马斯的项目小组由5人组成，包括一个兼职的学生John，史蒂夫、达考特、劳拉和托马斯自己。确定了人员后，托马斯的项目小组开始工作了。

    首先他们考查了这些功能的实现技术，大体做了设计的工作，用了整整1周的时间。紧接着，感恩节到了，John、史蒂夫和托马斯在这期间加班了一周，期间他们在公司吃住，每天都是通宵工作，然后白天睡觉，下午还一起去打一小时台球。很快的，假期结束后，他们各自的工作已经基本完成了。

    这时突然，用户由于参加了一次展会，对他们原先提出的界面设计有了新的想法，并发回给托马斯的小组展会上的一些图片。更糟糕的是，公司负责这个项目的销售人员在没有和托马斯协商的情况下便对客户做出了承诺。这个看上去十分简单的改动，实际上并不只是换换图片而已，它需要在桌面配置管理部分进行不小的代码改动。托马斯想提出异议，但是已经为时已晚了。好吧，重新进行设计和编码，好在由于原来的设计灵活度比较大，没有伤筋动骨。但是，返工还是花了几天时间。

    这时，意料之外的情况再次发生了，John由于导师布置的课题进行了调整，现在必须要花加倍的时间在他的毕业设计上了，只有晚上有几个小时可以过来、周六日可以工作。

    同时，项目进入整合阶段了。首先，托马斯在整合中发现史蒂夫和John没有充分考虑到他们两个人的工作是将会整合到同一个进程中的，他们原本设计的基础是两段程序并行的，于是，托马斯不得不花了3天的时间，把两个人的工作成果重新进行了组织，终于把它们整合到了一起。但是，这次整合让整个系统变得非常不稳定，经常发生运行错误，Bug是随机出现的而且还无法确定其发生的地点。这个Bug极大的困扰了托马斯的小组，他们整整花了一天一夜24小时连续调试和检查代码终于发现了错误。不幸的是，在John准备备份的时候，由于连续工作精神恍惚，错误的删除了新修改的代码，这不得不又花费了项目小组3个小时以上的时间，在最近一次备份的基础上重新修改并验证。

    在这个Bug解决之后，托马斯希望把整个系统提交系统测试部门进行测试。但是，测试部门拒绝了他们单一应用测试的请求，理由是他们只接受产品的测试，这个单一应用无法进行系统测试，而且这个测试应该由我们自己完成。这使托马斯火冒三丈，坚持认为系统测试部门应该进行单一程序的测试，这样及时发现Bug有助于他的小组节省开发的时间。最终，大家不欢而散。

    这期间，公司合作伙伴与之相配合的相关程序也早就应该就位了。但是，不幸的是由于合作伙伴所在的公司发生了并购，交付的时间大大的被推迟了。并且在拿到程序后，托马斯发现这些程序在测试板上经常死机，他不得不每天保持和合作公司的联络来解决这一问题。

    当完成了这一切以后，托马斯发现时间已经是12月29日了，他不得不告诉事业部经理，工作已经完成了99%，只差整合了。整合的时候，也发生了一些意外情况：由于系统不同，有的脚本需要调整；程序运行过慢，这跟系统资源紧张有很大的关系，最后不得不取消了这段程序……

    转眼1月4日了，整合工作仍然没有最终完成，托马斯与他的小组大量地设想权益之计设法让系统基本运行正常。最终，在1月12日，他们把一个伤痕累累的系统提交给了系统测试部门。

    系统测试部门进行了为期4天的测试，然后托马斯的小组又用了两天时间对所发现的Bug做了必要的修正，在1月21日把产品提交给用户了。而托马斯惊奇的发现，原来客户对于不能在12月29日交付的反应并不强烈，这让他们开始怀疑6月5日的DeadLine是如何得来的？

    最后的结果是，客户在收到产品之后不久，就放弃了这个产品……

    从上面的案例中，我们可以看到一个项目经理在项目实施过程中对突发事件糟糕的控制，他几乎完全没有预料到所发生的每一件事，在问题出现后早已经把项目计划抛在了脑后，对于托马斯来说，这真是犹如恶梦的一段经历啊。

    由此我们也能够了解到，项目控制对于整个项目的顺利进行来说是多么的重要，项目经理在这一过程中是不允许犯任何错误的。然而在现实中，许多项目经理都会像托马斯那样感到无所适从，在项目控制方面他们经常会犯的错误有：