软件项目管理中的人际困局(2)

　　版本

　　有一天，经理通知大家：咱们要开始做新版本4.1了。其后，像往常一样，我们就陆续接到一批批需求文档，开始预估工作量。然而这一次，事情一开始就有些不同：这些需求文档写得异常混乱，常常不知所云。我们如何能够根据一份看不懂的需求文档来预估工作量呢?我们随后联系法国的系统架构师(他们处境安全，跟我们合作融洽)要求澄清，他们也很不好意思，有时还确实能够做出澄清，但大多数时候要么含含糊糊地来一句“我们也在研究”，要么说“根据我的经验，这条需求应该与你们模块关系不大”云云。大家就这么半猜半蒙，在磕磕绊绊中前行，心中满是不详的预感。

　　4.1版本很仓促地做出来了。又有一天，经理通知大家：4.1版本过于保守，连公司自己都觉得销路不会好，决定立刻开始4.2版本计划。于是一切都重新来过，而这一次，情况更糟：大多数需求文档都是匆匆写就，语焉不详。一些需求文档只有一个标题，正文人家根本就没来得及写，而经理就要求我们根据这样的需求文档来预估工作量。如果你认为这样很夸张的话，那我只能批评你想象力有限—个别文档只有一个编号，收纳到某一领域的写作计划之中，连标题都没有，而我们仍然要据此预估工作量!就这样，日复一日，我上报一些连我自己也不相信的数字给经理，而他则努力装出相信的样子。

　　软件工程应该怎样做?我本来以为CMM、TL 9000等是王道，经历这一风波我才深切地体会到，再好的流程与制度也经不住扯淡啊。人和最重要。

　　4.2版本更仓促地做出来了。又又有一天，经理通知大家：4.2版本过于激进，工期又短，从设计到实现毛病多多，公司也不看好，决定立刻开始5.0版本计划。这一次倒是没有太荒唐的事情发生。5.0版本实际上没有什么全新的特性，而是将4.1、4.2这两个版本的特性做一折中，从这个意义上讲，叫它4.1.5版本更合适，当然这个话不能对客户说。就这样，几个月以来第一次，大家终于能够做点儿靠谱的事情。然后，出事了。

　　风起

　　第一波的事故，我是直接责任人之一：因为我的失误，我负责的FM模块没有通过编译。

　　我还记得前几个版本交付时和H一起工作的情景。她会敦促我们尽量提前完成开发和测试工作，提交代码，打上标签，撰写交付文档。她会亲自检查我们的交付文档，连一个细节也不放过。比如有一次，她就发现我无意中开启了Microsoft Word的中文自动纠错功能，把“…”(在版本配置中具有特殊含义)自动替换成了半个中文省略号“…”，让我脸上无光。大大小小的问题被她连续抓住几次之后，我开始小心谨慎，此后几个版本都顺利过关。印象最深的还是编译时的一次次待命。由于时差的关系，法国同事依据标签提出代码开始编译的时间是在北京的晚上，每一次，H都会带领我们几个少数技术骨干在办公室待到夜里，直到我们团队负责的所有模块都成功编译之后才离开。这可真是一件苦差事，而且在我当时看来毫无必要—我们的模块从来都是一次编译成功，错误(如果有的话)从来都属于其他团队。有一次，法国同事连续犯错，导致编译迟迟不能开始。当时我还保留着自校园带出来的早睡的习惯，时间一长，上下眼皮开始打架。H就跑到我的座位，谈人生，谈理想，谈八卦，反正就是不让我睡着。一直坚持到凌晨两点，编译开始之后照例一次成功，H才领着饥肠辘辘的我们离开办公室，请我们到楼下的小店吃宵夜。喝着温暖的豆浆，我在心中嘀咕：“真是事儿妈啊。”

　　这一次，“事儿妈”不在了，新任经理给予我们“完全的信任”，从头至尾都放开手—这同一件事情我们都连续做了好几遍了，还能出什么错呢?

　　还真就出事了。前几次，我们至少能够提前一周左右的时间完成全部工作，这抢下的一周时间足够我们反复测试、排查问题，并为应对突发事件留下时间—尽管突发事件从未发生。而这一次，大家经过连续几次折腾之后疲惫不堪，工作效率低下，更何况这次的工期本来就偏紧，还被前面几个环节挤占不少。我们FM小组勉强提前几天完成工作，CM小组却陷入苦战，加班加点，紧赶慢赶才在最后一天完成。FM模块依赖于CM模块，这样一来，我们也受到连累，不得不换上CM小组最新的标签，重新测试FM模块、打标签、修改交付文档。等到我饿着肚子敲完最后一个字符，又仔仔细细检查了几遍，已是周五晚上7~8点钟的光景。我长吁一口气，站起身来，摇摇晃晃地离开了办公室。

　　等到我周一早晨回到办公室，这才发现自己犯下低级错误：我忘记将修改后的交付文档保存在指定目录了!这样一来，法国同事据以编译的乃是先前保存的老版本的交付文档，FM模块编译失败!我赶紧寄出道歉信，连同最新的交付文档。然而，晚上的编译仍然没有成功。根据法国同事提供的编译错误日志，我很快就发现问题：FM模块与其他依赖模块之间使用了不一致的标签。说起来还是怪我们两边当时掉以轻心，只是口头约定了一下，也不知怎么就听岔了，关键时刻害人。又是一番折腾，FM模块在第三次编译中顺利通过，我心中一块石头才算是落了地。

　　乱战

　　我这边没事了，CM小组却开始焦头烂额。

　　CM模块几次编译均告失败，而法国同事提供的编译错误日志乱七八糟，毫无帮助。原来，我们项目当时尚未采用分布式编译技术，为了缩短编译时间(仅仅某一个子模块单机重新编译就需要18小时)，法国的集成测试团队自行编写了一个脚本，开启几路进程并行编译各个子目录。这个脚本写得过于简单，几路进程的输出信息全都杂七杂八搅到了一块儿，以至于CM小组研究了几天，连到底哪个子目录编译不过都没闹明白!

　　CM小组尝试向风雨飘摇中的法国集成测试团队请求帮助：“你们能否用单路进程编译CM模块的各个子目录，将错误信息提供给

　　我们?”

　　法国人回答：“请中国团队尽快修复编译，你们堵住了整个项目!”

　　CM小组解释说：“我们正在努力，你们能不能帮忙……”

　　法国人回答：“请中国团队尽快修复编译，你们堵住了整个项目!”

　　CM小组再次尝试：“这一错误本地不能复现，而编译日志……”

原文转自：http://www.ltesting.net