作者結合切身經歷，展示了他之前所在團隊軟件項目延期的種種原因，而其中印象深刻的是各種人事紛擾乃至于勾心斗角。

六年前，畢業(yè)未久的我在一家外企工作，我所在團隊開發(fā)的軟件項目在交付到集成測試組時因種種原因延期一周。這本身根本不是什么大事情，但其間各種人事紛擾乃至于勾心斗角卻著實令我印象深刻。

公司

我的老東家是一家大型跨國電信設備開發(fā)商，曾具有輝煌的歷史。我還記得在公司110周歲的生日慶典上，一位高管致辭說：“110年，這不是奇跡，是成績”，令人不勝欷?。遺憾的是，公司在.com泡沫中遭遇重創(chuàng)，一蹶不振。時任CEO為求擺脫困境，打起了人力成本的主意。當時，公司在美國雇用一名工程師的綜合人力成本接近中國的2.5倍【注：工資只是其中一小部分】。至于法國，成本比美國還要略高一些，而且不要忘了，人家可是35小時工作周。大家都是聰明人，很快看到端詳：公司正在法國裁員，將項目轉移到中國。

令人尷尬的是，我所在的中國團隊恰好在與法國團隊合作。這一項目早完全在法國，此后幾年時間，中國團隊大規(guī)模擴張人手（我是這樣進來的），將項目模塊逐一從法國團隊手中接過來。剛開始，法國工程師將原先的模塊移交中國之后，便轉而從事其他項目或職位，談不上什么個人損失，雙方共事可謂融洽。后來可不是這么回事了。有一次，兩位中國工程師去巴黎接手一個項目，一位法國工程師負責培訓，為時2~3個月。在這位法國老師兢兢業(yè)業(yè)的幫助下，兩位中國工程師成功掌握整個模塊，按期于圣誕節(jié)前夕歸國。告別巴黎時，沒有一個法國同事去跟他們寒暄話別—那位法國老師被裁掉了，他的后一個工作日恰好在兩位中國工程師離開的同，法國同事都去送他了。

到發(fā)生本文將要詳述的交付延期之時，所有模塊的開發(fā)工作都已從法國團隊移交到中國團隊，而集成測試雖然仍由法國團隊負責，但從法國到中國的移交也已開始。不妨猜猜看，法國集成測試團隊的工程師們此刻在想些什么。

團隊

我很幸運，畢業(yè)后初入職場遇到一位好經理H，坦率地說，她也是我到目前為止跟隨過的幾位經理中好的一位。中國很多女經理都有一個共同的特點：沒有私心。她們對于自己的晉升、提薪并無多大熱情，更愿意把心思、時間和精力花在輔導和培養(yǎng)自己的團隊上面。

H因分娩而“暫時”離開我們團隊。經過短暫的過渡，接任我們經理的是T，一位新近招聘的職業(yè)經理人。他的風格與H大為不同。僅舉一例說明。當年向H請年假，她總是微笑著說：“沒問題。不影響工作吧？”T則會端起架子：“不影響工作吧？沒問題。”語序上的變化，加上語氣的差別，雖然只是細微末節(jié)，卻反映了態(tài)度的不同、對員工是否尊重。除此之外，更嚴重的是工作態(tài)度問題。現在我們知道，T在北京待了不到一年時間，買下兩套房、一輛車，還辦妥了到加拿大的移民和那邊的工作—而在當時，我們這些員工僅僅只是知道，我們的經理不太在辦公室出現。

在團隊內部，我所在的FM小組與另一個CM小組工作是緊密銜接的。但在CM小組的核心員工之間卻存有罅隙：小組長B與技術骨干S矛盾日增。怎么說呢，這兩位都是很好的同事，然而好人之間也會彼此鄙視的：S認為B不懂技術，瞎指揮；B認為S目空一切，難以共事。缺少一位好領導來調和，好員工也不能組成一個好團隊。

流程

我們開發(fā)的是一個龐大的電信軟件項目—3G接入網網管系統，采用的開發(fā)流程仍然是傳統的瀑布式。簡單來說，依時間順序，一個軟件工程師（首先是各小組的小組長）需要依次參與以下幾個階段。

    需求階段：跟蹤和審閱由系統架構師撰寫的需求文檔，必要時要求澄清，然后預估工作量，經理據此調整人員安排。
    設計階段：分析需求文檔，完成模塊設計，據此撰寫高層設計文檔和底層設計文檔，前者以定義模塊接口為主，后者則涉及更多細節(jié)。
    編碼階段：根據兩份設計文檔完成實際編碼工作。
    單元測試階段：是的，你沒有看錯。根據本部門正式的、成文的流程，單元測試階段在編碼階段之后安排時間進行。在實踐中倒是沒有這么僵化，大家盡可以測試先行，只要時間大致齊即可。

各開發(fā)團隊在完成各自負責的一或多個模塊的單元測試之后，將代碼提交到統一的代碼庫，打上標簽，然后將這些標簽連同其他注意事項寫成文檔保存到指定目錄。其后，是集成測試階段了—集成測試團隊收集所有團隊的所有標簽，從代碼庫提出相應的代碼進行編譯，編譯成功后即按照事先準備的測試用例進行測試，給開發(fā)團隊提Bug。

我參與了前面幾個版本3.X、4.0的開發(fā)，僅從技術角度而言，瀑布式開發(fā)流程工作得尚稱流暢。但工程師是要領工資的，軟件寫出來是要賣錢的，一套經典的瀑布式流程走下來往往耗時幾個月甚至年余，等到軟件產品正式發(fā)布，用戶需求已然發(fā)生變化，這怎么趕得上趟呢。公司不是沒有意識到這一問題，但舍不得做傷筋動骨的巨變，只愿意在現有流程上做一些微調，效果甚微。

有一個例子很能說明問題。當時，中國的銷售部門向總部反映，我們在中國市場遭遇到本土廠商的強力阻擊，要想爭奪中國市場，必須在定制化方面下更大工夫。在大中華區(qū)乃至總部高層的大力支持下，我們部門成立了一個“快速特性”開發(fā)小組，專門根據中國客戶的需求為我們的產品添加相應的特性。有一個快速特性是這樣的：本來，我們的網管系統會在電腦屏幕上顯示一臺虛擬的機器，如果某個部件壞了，代表該部件的綠燈會變成紅燈并開始閃爍，提醒操作員注意。中國客戶看過演示后說不錯，但光紅燈閃爍還不夠，還應該放點兒警報聲出來，不然操作員離開座位了怎么辦。我們的銷售一口答應下來。猜猜這個特性我們做了多久才交付給客戶？三個月！這是瀑布式流程下的“快速特性”！（當然，中國的銷售部門和開發(fā)部門分別向國外的上司匯報，由老外負責協調中國的事情，這也是造成拖延的一個同等重要的原因。）

這樣拖拖沓沓做出來的產品，其銷路如何不問可知。公司應對的辦法，是一方面推新版本、新特性來吸引客戶，另一方面強調開發(fā)速度的重要。很顯然，這兩者之間存在矛盾：新特性越多，開發(fā)時間越長，客戶不會買賬；可是如果新特性太少，跟上一版本差異不大，客戶同樣不會買賬。

版本

有，經理通知大家：咱們要開始做新版本4.1了。其后，像往常一樣，我們陸續(xù)接到一批批需求文檔，開始預估工作量。然而這一次，事情一開始有些不同：這些需求文檔寫得異�；靵y，常常不知所云。我們如何能夠根據一份看不懂的需求文檔來預估工作量呢？我們隨后聯系法國的系統架構師（他們處境安全，跟我們合作融洽）要求澄清，他們也很不好意思，有時還確實能夠做出澄清，但大多數時候要么含含糊糊地來一句“我們也在研究”，要么說“根據我的經驗，這條需求應該與你們模塊關系不大”云云。大家這么半猜半蒙，在磕磕絆絆中前行，心中滿是不詳的預感。

4.1版本很倉促地做出來了。又有，經理通知大家：4.1版本過于保守，連公司自己都覺得銷路不會好，決定立刻開始4.2版本計劃。于是一切都重新來過，而這一次，情況更糟：大多數需求文檔都是匆匆寫，語焉不詳。一些需求文檔只有一個標題，正文人家根本沒來得及寫，而經理要求我們根據這樣的需求文檔來預估工作量。如果你認為這樣很夸張的話，那我只能批評你想象力有限—個別文檔只有一個編號，收納到某一領域的寫作計劃之中，連標題都沒有，而我們仍然要據此預估工作量！這樣，日復一日，我上報一些連我自己也不相信的數字給經理，而他則努力裝出相信的樣子。