软件工程应该怎样做？我本来以为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小组再次尝试：“这一错误本地不能复现，而编译日志……”
法国人回答，并且抄送各路神仙：“请中国团队尽快修复编译，你们堵住了整个项目！”
外事不靖，内部也不安宁：CM小组的小组长B和技术骨干S此刻正在斗气！从一开始，B将编译错误的排查工作分配给自己和另一位同事，没有邀请S介入，而S也不主动过问。没想到这么一个乍看上去再简单不过的错误一拖是好几天，这样一来，双方陷入僵局。站在B的角度，如果连个编译问题自己都解决不了，还得请S来当救兵，这不是坐实了自己不懂技术的指控吗，这张脸以后还怎么搁？再说S一直面无表情地坐在自己的电脑前做自己那一摊事情，一句问话没有，这不摆明了是要袖手旁观吗？而S也有自己的苦衷：自己要是一开始主动介入倒也罢了，如果拖到现在才出手，那怎么解释自己前几天不闻不问的态度？算自己辩解说确实没有端架子、看领导笑话的意思，完完全全是在服从领导安排，也得有人信啊！双方有一点想法倒是共同的：这个编译错误赶紧消失了吧……
既然CM小组迟迟不能修复编译，顺理成章地，项目经理（一个不偏不倚的法籍华人）开始找他们的上级，也是我们共同的经理T。然而—她找不到T！事情是这么凑巧，虽然T平时神龙见首不见尾，可像这次这样整个礼拜办公室都不怎么见人影、写信也不太回的情况还真不多。连续几天，项目经理从法国给T的座机打电话，按说这是法国的休息时间，中国的上班时间，可是法国那边有人打，中国这边没人接。电话留言、电子邮件都不好使。项目经理急了，电子邮件写得越来越不客气，每封信的结尾都是同一句话—“T在哪里！”……
事情终于惊动了上面，领导出来问话了：“发生了什么事？为什么会耽误到现在？”法国团队再次暗示中国团队无能，中国团队则强调本地无法复现，必须法国团队配合，项目经理在居中调解的同时狠狠地告了T一状……领导不愧是领导，跳过T的事情不提，和蔼可亲地建议法国团队考虑中国团队的合理要求……事情终于走上正轨。法国团队终于按照CM小组的建议尝试单路编译；与此同时，B主动去征求S的意见，问他是否愿意参与排查，而S也立刻答应下来；T又神秘地出现在办公室里，如果这有关系的话……经过整整一周的纷扰，周五，编译终于成功。
那么，这一编译错误到底是如何产生的呢？说起来，这居然还与前述混乱的版本计划有关。在4.0版本中，出于兼容旧有设备的需要，CM模块中有些文件按照foo_V4.h的格式命名，后来升级到4.1、4.2版本后文件内容相应修改，文件名保持不变。可是5.0版本实际上是4.1、4.2版本的综合，CM小组被迫把4.1、4.2这两个版本的foo_V4.h文件都引入5.0版本，文件名分别命名为foo_V41.h和foo_V42.h以示区别。换言之，文件名变长了一个字符，而这导致法国集成测试团队的编译脚本中的命令行超过了大长度的限制……
尾声
软件工程应该怎样做？我本来以为CMM、TL 9000等是王道，经历这一风波我才深切地体会到，再好的流程与制度也经不住扯淡啊。人和重要。
无论版本号如何，我们的产品终究还是销路不畅。新任CEO上台后，大刀阔斧厉行改革，将整条产品线出售。毕竟，对于IT业来说，创新才是利润之源，单纯的削减成本没有出路。基于这一认识，我转投互联网公司，从此踏上新的征程……
