作者結合切身經歷，展示了他之前所在團隊軟件項目延期的種種原因，而其中印象最深刻的是各種人事紛擾乃至于勾心斗角。
六年前，畢業未久的我在一家外企工作，我所在團隊開發的軟件項目在交付到集成測試組時因種種原因延期一周。這本身根本不是什么大事情，但其間各種人事紛擾乃至于勾心斗角卻著實令我印象深刻。
公司
我的老東家是一家大型跨國電信設備開發商，曾具有輝煌的歷史。我還記得在公司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的開發，僅從技術角度而言，瀑布式開發流程工作得尚稱流暢。但工程師是要領工資的，軟件寫出來是要賣錢的，一套經典的瀑布式流程走下來往往耗時幾個月甚至年余，等到軟件產品正式發布，用戶需求已然發生變化，這怎么趕得上趟呢。公司不是沒有意識到這一問題，但舍不得做傷筋動骨的巨變，只愿意在現有流程上做一些微調，效果甚微。
有一個例子很能說明問題。當時，中國的銷售部門向總部反映，我們在中國市場遭遇到本土廠商的強力阻擊，要想爭奪中國市場，就必須在定制化方面下更大工夫。在大中華區乃至總部高層的大力支持下，我們部門成立了一個“快速特性”開發小組，專門根據中國客戶的需求為我們的產品添加相應的特性。有一個快速特性是這樣的：本來，我們的網管系統會在電腦屏幕上顯示一臺虛擬的機器，如果某個部件壞了，代表該部件的綠燈就會變成紅燈并開始閃爍，提醒操作員注意。中國客戶看過演示后說不錯，但光紅燈閃爍還不夠，還應該放點兒警報聲出來，不然操作員離開座位了怎么辦。我們的銷售一口答應下來。猜猜這個特性我們做了多久才交付給客戶？三個月！這就是瀑布式流程下的“快速特性”！（當然，中國的銷售部門和開發部門分別向國外的上司匯報，由老外負責協調中國的事情，這也是造成拖延的一個同等重要的原因。）
這樣拖拖沓沓做出來的產品，其銷路如何不問可知。公司應對的辦法，就是一方面推新版本、新特性來吸引客戶，另一方面強調開發速度的重要。很顯然，這兩者之間存在矛盾：新特性越多，開發時間就越長，客戶不會買賬；可是如果新特性太少，跟上一版本差異不大，客戶同樣不會買賬。
作者結合切身經歷，展示了他之前所在團隊軟件項目延期的種種原因，而其中印象最深刻的是各種人事紛擾乃至于勾心斗角。
六年前，畢業未久的我在一家外企工作，我所在團隊開發的軟件項目在交付到集成測試組時因種種原因延期一周。這本身根本不是什么大事情，但其間各種人事紛擾乃至于勾心斗角卻著實令我印象深刻。
公司
我的老東家是一家大型跨國電信設備開發商，曾具有輝煌的歷史。我還記得在公司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的開發，僅從技術角度而言，瀑布式開發流程工作得尚稱流暢。但工程師是要領工資的，軟件寫出來是要賣錢的，一套經典的瀑布式流程走下來往往耗時幾個月甚至年余，等到軟件產品正式發布，用戶需求已然發生變化，這怎么趕得上趟呢。公司不是沒有意識到這一問題，但舍不得做傷筋動骨的巨變，只愿意在現有流程上做一些微調，效果甚微。
有一個例子很能說明問題。當時，中國的銷售部門向總部反映，我們在中國市場遭遇到本土廠商的強力阻擊，要想爭奪中國市場，就必須在定制化方面下更大工夫。在大中華區乃至總部高層的大力支持下，我們部門成立了一個“快速特性”開發小組，專門根據中國客戶的需求為我們的產品添加相應的特性。有一個快速特性是這樣的：本來，我們的網管系統會在電腦屏幕上顯示一臺虛擬的機器，如果某個部件壞了，代表該部件的綠燈就會變成紅燈并開始閃爍，提醒操作員注意。中國客戶看過演示后說不錯，但光紅燈閃爍還不夠，還應該放點兒警報聲出來，不然操作員離開座位了怎么辦。我們的銷售一口答應下來。猜猜這個特性我們做了多久才交付給客戶？三個月！這就是瀑布式流程下的“快速特性”！（當然，中國的銷售部門和開發部門分別向國外的上司匯報，由老外負責協調中國的事情，這也是造成拖延的一個同等重要的原因。）
這樣拖拖沓沓做出來的產品，其銷路如何不問可知。公司應對的辦法，就是一方面推新版本、新特性來吸引客戶，另一方面強調開發速度的重要。很顯然，這兩者之間存在矛盾：新特性越多，開發時間就越長，客戶不會買賬；可是如果新特性太少，跟上一版本差異不大，客戶同樣不會買賬。