作者结合切身经历，展示了他之前所在团队软件项目延期的种种原因，而其中印象深刻的是各种人事纷扰乃至于勾心斗角。

六年前，毕业未久的我在一家外企工作，我所在团队开发的软件项目在交付到集成测试组时因种种原因延期一周。这本身根本不是什么大事情，但其间各种人事纷扰乃至于勾心斗角却着实令我印象深刻。

公司

我的老东家是一家大型跨国电信设备开发商，曾具有辉煌的历史。我还记得在公司110周岁的生日庆典上，一位高管致辞说：“110年，这不是奇迹，是成绩”，令人不胜欷?。遗憾的是，公司在.com泡沫中遭遇重创，一蹶不振。时任CEO为求摆脱困境，打起了人力成本的主意。当时，公司在美国雇用一名工程师的综合人力成本接近中国的2.5倍【注：工资只是其中一小部分】。至于法国，成本比美国还要略高一些，而且不要忘了，人家可是35小时工作周。大家都是聪明人，很快看到端详：公司正在法国裁员，将项目转移到中国。

令人尴尬的是，我所在的中国团队恰好在与法国团队合作。这一项目早完全在法国，此后几年时间，中国团队大规模扩张人手（我是这样进来的），将项目模块逐一从法国团队手中接过来。刚开始，法国工程师将原先的模块移交中国之后，便转而从事其他项目或职位，谈不上什么个人损失，双方共事可谓融洽。后来可不是这么回事了。有一次，两位中国工程师去巴黎接手一个项目，一位法国工程师负责培训，为时2~3个月。在这位法国老师兢兢业业的帮助下，两位中国工程师成功掌握整个模块，按期于圣诞节前夕归国。告别巴黎时，没有一个法国同事去跟他们寒暄话别—那位法国老师被裁掉了，他的后一个工作日恰好在两位中国工程师离开的同，法国同事都去送他了。

到发生本文将要详述的交付延期之时，所有模块的开发工作都已从法国团队移交到中国团队，而集成测试虽然仍由法国团队负责，但从法国到中国的移交也已开始。不妨猜猜看，法国集成测试团队的工程师们此刻在想些什么。

团队

我很幸运，毕业后初入职场遇到一位好经理H，坦率地说，她也是我到目前为止跟随过的几位经理中好的一位。中国很多女经理都有一个共同的特点：没有私心。她们对于自己的晋升、提薪并无多大热情，更愿意把心思、时间和精力花在辅导和培养自己的团队上面。

H因分娩而“暂时”离开我们团队。经过短暂的过渡，接任我们经理的是T，一位新近招聘的职业经理人。他的风格与H大为不同。仅举一例说明。当年向H请年假，她总是微笑着说：“没问题。不影响工作吧？”T则会端起架子：“不影响工作吧？没问题。”语序上的变化，加上语气的差别，虽然只是细微末节，却反映了态度的不同、对员工是否尊重。除此之外，更严重的是工作态度问题。现在我们知道，T在北京待了不到一年时间，买下两套房、一辆车，还办妥了到加拿大的移民和那边的工作—而在当时，我们这些员工仅仅只是知道，我们的经理不太在办公室出现。

在团队内部，我所在的FM小组与另一个CM小组工作是紧密衔接的。但在CM小组的核心员工之间却存有罅隙：小组长B与技术骨干S矛盾日增。怎么说呢，这两位都是很好的同事，然而好人之间也会彼此鄙视的：S认为B不懂技术，瞎指挥；B认为S目空一切，难以共事。缺少一位好领导来调和，好员工也不能组成一个好团队。

流程

我们开发的是一个庞大的电信软件项目—3G接入网网管系统，采用的开发流程仍然是传统的瀑布式。简单来说，依时间顺序，一个软件工程师（首先是各小组的小组长）需要依次参与以下几个阶段。

    需求阶段：跟踪和审阅由系统架构师撰写的需求文档，必要时要求澄清，然后预估工作量，经理据此调整人员安排。
    设计阶段：分析需求文档，完成模块设计，据此撰写高层设计文档和底层设计文档，前者以定义模块接口为主，后者则涉及更多细节。
    编码阶段：根据两份设计文档完成实际编码工作。
    单元测试阶段：是的，你没有看错。根据本部门正式的、成文的流程，单元测试阶段在编码阶段之后安排时间进行。在实践中倒是没有这么僵化，大家尽可以测试先行，只要时间大致齐即可。

各开发团队在完成各自负责的一或多个模块的单元测试之后，将代码提交到统一的代码库，打上标签，然后将这些标签连同其他注意事项写成文档保存到指定目录。其后，是集成测试阶段了—集成测试团队收集所有团队的所有标签，从代码库提出相应的代码进行编译，编译成功后即按照事先准备的测试用例进行测试，给开发团队提Bug。

我参与了前面几个版本3.X、4.0的开发，仅从技术角度而言，瀑布式开发流程工作得尚称流畅。但工程师是要领工资的，软件写出来是要卖钱的，一套经典的瀑布式流程走下来往往耗时几个月甚至年余，等到软件产品正式发布，用户需求已然发生变化，这怎么赶得上趟呢。公司不是没有意识到这一问题，但舍不得做伤筋动骨的巨变，只愿意在现有流程上做一些微调，效果甚微。

有一个例子很能说明问题。当时，中国的销售部门向总部反映，我们在中国市场遭遇到本土厂商的强力阻击，要想争夺中国市场，必须在定制化方面下更大工夫。在大中华区乃至总部高层的大力支持下，我们部门成立了一个“快速特性”开发小组，专门根据中国客户的需求为我们的产品添加相应的特性。有一个快速特性是这样的：本来，我们的网管系统会在电脑屏幕上显示一台虚拟的机器，如果某个部件坏了，代表该部件的绿灯会变成红灯并开始闪烁，提醒操作员注意。中国客户看过演示后说不错，但光红灯闪烁还不够，还应该放点儿警报声出来，不然操作员离开座位了怎么办。我们的销售一口答应下来。猜猜这个特性我们做了多久才交付给客户？三个月！这是瀑布式流程下的“快速特性”！（当然，中国的销售部门和开发部门分别向国外的上司汇报，由老外负责协调中国的事情，这也是造成拖延的一个同等重要的原因。）

这样拖拖沓沓做出来的产品，其销路如何不问可知。公司应对的办法，是一方面推新版本、新特性来吸引客户，另一方面强调开发速度的重要。很显然，这两者之间存在矛盾：新特性越多，开发时间越长，客户不会买账；可是如果新特性太少，跟上一版本差异不大，客户同样不会买账。

版本

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

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