作者結(jié)合切身經(jīng)歷，展示了他之前所在團隊軟件項目延期的種種原因，而其中印象最深刻的是各種人事紛擾乃至于勾心斗角，一地雞毛——軟件項目中的人際困局
。
六年前，畢業(yè)未久的我在一家外企工作，我所在團隊開發(fā)的軟件項目在交付到集成測試組時因種種原因延期一周。這本身根本不是什么大事情，但其間各種人事紛擾乃至于勾心斗角卻著實令我印象深刻。
公司
我的老東家是一家大型跨國電信設(shè)備開發(fā)商，曾具有輝煌的歷史。我還記得在公司110周歲的生日慶典上，一位高管致辭說：“110年，這不是奇跡，是成績”，令人不勝欷歔。遺憾的是，公司在.com泡沫中遭遇重創(chuàng)，一蹶不振。時任CEO為求擺脫困境，打起了人力成本的主意。當時，公司在美國雇用一名工程師的綜合人力成本接近中國的2.5倍【注：工資只是其中一小部分】。至于法國，成本比美國還要略高一些，而且不要忘了，人家可是35小時工作周。大家都是聰明人，很快就看到端詳：公司正在法國裁員，將項目轉(zhuǎn)移到中國。
令人尷尬的是，我所在的中國團隊恰好就在與法國團隊合作。這一項目最早完全在法國，此后幾年時間，中國團隊大規(guī)模擴張人手（我就是這樣進來的），將項目模塊逐一從法國團隊手中接過來。剛開始，法國工程師將原先的模塊移交中國之后，便轉(zhuǎn)而從事其他項目或職位，談不上什么個人損失，雙方共事可謂融洽。后來可就不是這么回事了。有一次，兩位中國工程師去巴黎接手一個項目，一位法國工程師負責培訓(xùn)，為時2~3個月。在這位法國老師兢兢業(yè)業(yè)的幫助下，兩位中國工程師成功掌握整個模塊，按期于圣誕節(jié)前夕歸國。告別巴黎時，沒有一個法國同事去跟他們寒暄話別—那位法國老師被裁掉了，他的最后一個工作日恰好就在兩位中國工程師離開的同一天，法國同事都去送他了。
到發(fā)生本文將要詳述的交付延期之時，所有模塊的開發(fā)工作都已從法國團隊移交到中國團隊，而集成測試雖然仍由法國團隊負責，但從法國到中國的移交也已開始。不妨猜猜看，法國集成測試團隊的工程師們此刻在想些什么。
團隊
我很幸運，畢業(yè)后初入職場就遇到一位好經(jīng)理H，坦率地說，她也是我到目前為止跟隨過的幾位經(jīng)理中最好的一位。中國很多女經(jīng)理都有一個共同的特點：沒有私心。她們對于自己的晉升、提薪并無多大熱情，更愿意把心思、時間和精力花在輔導(dǎo)和培養(yǎng)自己的團隊上面。
H因分娩而“暫時”離開我們團隊。經(jīng)過短暫的過渡，接任我們經(jīng)理的是T，一位新近招聘的職業(yè)經(jīng)理人。他的風格與H大為不同。僅舉一例說明。當年向H請一天年假，她總是微笑著說：“沒問題。不影響工作吧？”T則會端起架子：“不影響工作吧？沒問題。”語序上的變化，加上語氣的差別，雖然只是細微末節(jié)，卻反映了態(tài)度的不同、對員工是否尊重。除此之外，更嚴重的是工作態(tài)度問題�，F(xiàn)在我們知道，T在北京待了不到一年時間，買下兩套房、一輛車，還辦妥了到加拿大的移民和那邊的工作—而在當時，我們這些員工僅僅只是知道，我們的經(jīng)理不太在辦公室出現(xiàn)。
在團隊內(nèi)部，我所在的FM小組與另一個CM小組工作是緊密銜接的。但在CM小組的核心員工之間卻存有罅隙：小組長B與技術(shù)骨干S矛盾日增。怎么說呢，這兩位都是很好的同事，然而好人之間也會彼此鄙視的：S認為B不懂技術(shù)，瞎指揮；B認為S目空一切，難以共事。缺少一位好領(lǐng)導(dǎo)來調(diào)和，好員工也不能組成一個好團隊。
流程
我們開發(fā)的是一個龐大的電信軟件項目—3G接入網(wǎng)網(wǎng)管系統(tǒng)，采用的開發(fā)流程仍然是傳統(tǒng)的瀑布式。簡單來說，依時間順序，一個軟件工程師（首先是各小組的小組長）需要依次參與以下幾個階段。
需求階段：跟蹤和審閱由系統(tǒng)架構(gòu)師撰寫的需求文檔，必要時要求澄清，然后預(yù)估工作量，經(jīng)理據(jù)此調(diào)整人員安排。
設(shè)計階段：分析需求文檔，完成模塊設(shè)計，據(jù)此撰寫高層設(shè)計文檔和底層設(shè)計文檔，前者以定義模塊接口為主，后者則涉及更多細節(jié)。
編碼階段：根據(jù)兩份設(shè)計文檔完成實際編碼工作。
單元測試階段：是的，你沒有看錯。根據(jù)本部門正式的、成文的流程，單元測試階段在編碼階段之后安排時間進行。在實踐中倒是沒有這么僵化，大家盡可以測試先行，只要時間大致齊即可。
各開發(fā)團隊在完成各自負責的一或多個模塊的單元測試之后，將代碼提交到統(tǒng)一的代碼庫，打上標簽，然后將這些標簽連同其他注意事項寫成文檔保存到指定目錄。其后，就是集成測試階段了—集成測試團隊收集所有團隊的所有標簽，從代碼庫提出相應(yīng)的代碼進行編譯，編譯成功后即按照事先準備的測試用例進行測試，給開發(fā)團隊提Bug。
我參與了前面幾個版本3.X、4.0的開發(fā)，僅從技術(shù)角度而言，瀑布式開發(fā)流程工作得尚稱流暢。但工程師是要領(lǐng)工資的，軟件寫出來是要賣錢的，一套經(jīng)典的瀑布式流程走下來往往耗時幾個月甚至年余，等到軟件產(chǎn)品正式發(fā)布，用戶需求已然發(fā)生變化，這怎么趕得上趟呢。公司不是沒有意識到這一問題，但舍不得做傷筋動骨的巨變，只愿意在現(xiàn)有流程上做一些微調(diào)，效果甚微。
有一個例子很能說明問題。當時，中國的銷售部門向總部反映，我們在中國市場遭遇到本土廠商的強力阻擊，要想爭奪中國市場，就必須在定制化方面下更大工夫。在大中華區(qū)乃至總部高層的大力支持下，我們部門成立了一個“快速特性”開發(fā)小組，專門根據(jù)中國客戶的需求為我們的產(chǎn)品添加相應(yīng)的特性。有一個快速特性是這樣的：本來，我們的網(wǎng)管系統(tǒng)會在電腦屏幕上顯示一臺虛擬的機器，如果某個部件壞了，代表該部件的綠燈就會變成紅燈并開始閃爍，提醒操作員注意。中國客戶看過演示后說不錯，但光紅燈閃爍還不夠，還應(yīng)該放點兒警報聲出來，不然操作員離開座位了怎么辦。我們的銷售一口答應(yīng)下來。猜猜這個特性我們做了多久才交付給客戶？三個月！這就是瀑布式流程下的“快速特性”�。ó斎�，中國的銷售部門和開發(fā)部門分別向國外的上司匯報，由老外負責協(xié)調(diào)中國的事情，這也是造成拖延的一個同等重要的原因。）
這樣拖拖沓沓做出來的產(chǎn)品，其銷路如何不問可知。公司應(yīng)對的辦法，就是一方面推新版本、新特性來吸引客戶，另一方面強調(diào)開發(fā)速度的重要。很顯然，這兩者之間存在矛盾：新特性越多，開發(fā)時間就越長，客戶不會買賬；可是如果新特性太少，跟上一版本差異不大，客戶同樣不會買賬。
版本
有一天，經(jīng)理通知大家：咱們要開始做新版本4.1了。其后，像往常一樣，我們就陸續(xù)接到一批批需求文檔，開始預(yù)估工作量。然而這一次，事情一開始就有些不同：這些需求文檔寫得異�；靵y，常常不知所云。我們?nèi)绾文軌蚋鶕?jù)一份看不懂的需求文檔來預(yù)估工作量呢？我們隨后聯(lián)系法國的系統(tǒng)架構(gòu)師（他們處境安全，跟我們合作融洽）要求澄清，他們也很不好意思，有時還確實能夠做出澄清，但大多數(shù)時候要么含含糊糊地來一句“我們也在研究”，要么說“根據(jù)我的經(jīng)驗，這條需求應(yīng)該與你們模塊關(guān)系不大”云云。大家就這么半猜半蒙，在磕磕絆絆中前行，心中滿是不詳?shù)念A(yù)感。
4.1版本很倉促地做出來了。又有一天，經(jīng)理通知大家：4.1版本過于保守，連公司自己都覺得銷路不會好，決定立刻開始4.2版本計劃。于是一切都重新來過，而這一次，情況更糟：大多數(shù)需求文檔都是匆匆寫就，語焉不詳。一些需求文檔只有一個標題，正文人家根本就沒來得及寫，而經(jīng)理就要求我們根據(jù)這樣的需求文檔來預(yù)估工作量。如果你認為這樣很夸張的話，那我只能批評你想象力有限—個別文檔只有一個編號，收納到某一領(lǐng)域的寫作計劃之中，連標題都沒有，而我們?nèi)匀灰獡?jù)此預(yù)估工作量！就這樣，日復(fù)一日，我上報一些連我自己也不相信的數(shù)字給經(jīng)理，而他則努力裝出相信的樣子。
軟件工程應(yīng)該怎樣做？我本來以為CMM、TL 9000等是王道，經(jīng)歷這一風波我才深切地體會到，再好的流程與制度也經(jīng)不住扯淡啊。人和最重要。
4.2版本更倉促地做出來了，
管理資料
《一地雞毛——軟件項目中的人際困局》(http://www.lotusphilosophies.com)。又又有一天，經(jīng)理通知大家：4.2版本過于激進，工期又短，從設(shè)計到實現(xiàn)毛病多多，公司也不看好，決定立刻開始5.0版本計劃。這一次倒是沒有太荒唐的事情發(fā)生。5.0版本實際上沒有什么全新的特性，而是將4.1、4.2這兩個版本的特性做一折中，從這個意義上講，叫它4.1.5版本更合適，當然這個話不能對客戶說。就這樣，幾個月以來第一次，大家終于能夠做點兒靠譜的事情。然后，出事了。風起
第一波的事故，我是直接責任人之一：因為我的失誤，我負責的FM模塊沒有通過編譯。
我還記得前幾個版本交付時和H一起工作的情景。她會敦促我們盡量提前完成開發(fā)和測試工作，提交代碼，打上標簽，撰寫交付文檔。她會親自檢查我們的交付文檔，連一個細節(jié)也不放過。比如有一次，她就發(fā)現(xiàn)我無意中開啟了Microsoft Word的中文自動糾錯功能，把“…”（在版本配置中具有特殊含義）自動替換成了半個中文省略號“…”，讓我臉上無光。大大小小的問題被她連續(xù)抓住幾次之后，我開始小心謹慎，此后幾個版本都順利過關(guān)。印象最深的還是編譯時的一次次待命。由于時差的關(guān)系，法國同事依據(jù)標簽提出代碼開始編譯的時間是在北京的晚上，每一次，H都會帶領(lǐng)我們幾個少數(shù)技術(shù)骨干在辦公室待到夜里，直到我們團隊負責的所有模塊都成功編譯之后才離開。這可真是一件苦差事，而且在我當時看來毫無必要—我們的模塊從來都是一次編譯成功，錯誤（如果有的話）從來都屬于其他團隊。有一次，法國同事連續(xù)犯錯，導(dǎo)致編譯遲遲不能開始。當時我還保留著自校園帶出來的早睡的習慣，時間一長，上下眼皮開始打架。H就跑到我的座位，談人生，談理想，談八卦，反正就是不讓我睡著。一直堅持到凌晨兩點，編譯開始之后照例一次成功，H才領(lǐng)著饑腸轆轆的我們離開辦公室，請我們到樓下的小店吃宵夜。喝著溫暖的豆?jié){，我在心中嘀咕：“真是事兒媽啊。”
這一次，“事兒媽”不在了，新任經(jīng)理給予我們“完全的信任”，從頭至尾都放開手—這同一件事情我們都連續(xù)做了好幾遍了，還能出什么錯呢？
還真就出事了。前幾次，我們至少能夠提前一周左右的時間完成全部工作，這搶下的一周時間足夠我們反復(fù)測試、排查問題，并為應(yīng)對突發(fā)事件留下時間—盡管突發(fā)事件從未發(fā)生。而這一次，大家經(jīng)過連續(xù)幾次折騰之后疲憊不堪，工作效率低下，更何況這次的工期本來就偏緊，還被前面幾個環(huán)節(jié)擠占不少。我們FM小組勉強提前幾天完成工作，CM小組卻陷入苦戰(zhàn)，加班加點，緊趕慢趕才在最后一天完成。FM模塊依賴于CM模塊，這樣一來，我們也受到連累，不得不換上CM小組最新的標簽，重新測試FM模塊、打標簽、修改交付文檔。等到我餓著肚子敲完最后一個字符，又仔仔細細檢查了幾遍，已是周五晚上7~8點鐘的光景。我長吁一口氣，站起身來，搖搖晃晃地離開了辦公室。
等到我周一早晨回到辦公室，這才發(fā)現(xiàn)自己犯下低級錯誤：我忘記將修改后的交付文檔保存在指定目錄了！這樣一來，法國同事?lián)跃幾g的乃是先前保存的老版本的交付文檔，F(xiàn)M模塊編譯失敗！我趕緊寄出道歉信，連同最新的交付文檔。然而，晚上的編譯仍然沒有成功。根據(jù)法國同事提供的編譯錯誤日志，我很快就發(fā)現(xiàn)問題：FM模塊與其他依賴模塊之間使用了不一致的標簽。說起來還是怪我們兩邊當時掉以輕心，只是口頭約定了一下，也不知怎么就聽岔了，關(guān)鍵時刻害人。又是一番折騰，F(xiàn)M模塊在第三次編譯中順利通過，我心中一塊石頭才算是落了地。
亂戰(zhàn)
我這邊沒事了，CM小組卻開始焦頭爛額。
CM模塊幾次編譯均告失敗，而法國同事提供的編譯錯誤日志亂七八糟，毫無幫助。原來，我們項目當時尚未采用分布式編譯技術(shù)，為了縮短編譯時間（僅僅某一個子模塊單機重新編譯就需要18小時），法國的集成測試團隊自行編寫了一個腳本，開啟幾路進程并行編譯各個子目錄。這個腳本寫得過于簡單，幾路進程的輸出信息全都雜七雜八攪到了一塊兒，以至于CM小組研究了幾天，連到底哪個子目錄編譯不過都沒鬧明白！
CM小組嘗試向風雨飄搖中的法國集成測試團隊請求幫助：“你們能否用單路進程編譯CM模塊的各個子目錄，將錯誤信息提供給
我們？”
法國人回答：“請中國團隊盡快修復(fù)編譯，你們堵住了整個項目！”
CM小組解釋說：“我們正在努力，你們能不能幫忙……”
法國人回答：“請中國團隊盡快修復(fù)編譯，你們堵住了整個項目！”
CM小組再次嘗試：“這一錯誤本地不能復(fù)現(xiàn)，而編譯日志……”
法國人回答，并且抄送各路神仙：“請中國團隊盡快修復(fù)編譯，你們堵住了整個項目！”
外事不靖，內(nèi)部也不安寧：CM小組的小組長B和技術(shù)骨干S此刻正在斗氣！從一開始，B就將編譯錯誤的排查工作分配給自己和另一位同事，沒有邀請S介入，而S也不主動過問。沒想到這么一個乍看上去再簡單不過的錯誤一拖就是好幾天，這樣一來，雙方陷入僵局。站在B的角度，如果連個編譯問題自己都解決不了，還得請S來當救兵，這不是坐實了自己不懂技術(shù)的指控嗎，這張臉以后還怎么擱？再說S一直面無表情地坐在自己的電腦前做自己那一攤事情，一句問話沒有，這不擺明了是要袖手旁觀嗎？而S也有自己的苦衷：自己要是一開始就主動介入倒也罷了，如果拖到現(xiàn)在才出手，那怎么解釋自己前幾天不聞不問的態(tài)度？就算自己辯解說確實沒有端架子、看領(lǐng)導(dǎo)笑話的意思，完完全全是在服從領(lǐng)導(dǎo)安排，也得有人信�。‰p方有一點想法倒是共同的：這個編譯錯誤趕緊消失了吧……
既然CM小組遲遲不能修復(fù)編譯，順理成章地，項目經(jīng)理（一個不偏不倚的法籍華人）開始找他們的上級，也就是我們共同的經(jīng)理T。然而—她找不到T！事情就是這么湊巧，雖然T平時就神龍見首不見尾，可像這次這樣整個禮拜辦公室都不怎么見人影、寫信也不太回的情況還真不多。連續(xù)幾天，項目經(jīng)理從法國給T的座機打電話，按說這是法國的休息時間，中國的上班時間，可是法國那邊有人打，中國這邊沒人接。電話留言、電子郵件都不好使。項目經(jīng)理急了，電子郵件寫得越來越不客氣，每封信的結(jié)尾都是同一句話—“T在哪里！”……
事情終于驚動了上面，領(lǐng)導(dǎo)出來問話了：“發(fā)生了什么事？為什么會耽誤到現(xiàn)在？”法國團隊再次暗示中國團隊無能，中國團隊則強調(diào)本地無法復(fù)現(xiàn)，必須法國團隊配合，項目經(jīng)理在居中調(diào)解的同時狠狠地告了T一狀……領(lǐng)導(dǎo)不愧是領(lǐng)導(dǎo)，跳過T的事情不提，和藹可親地建議法國團隊考慮中國團隊的合理要求……事情終于走上正軌。法國團隊終于按照CM小組的建議嘗試單路編譯；與此同時，B主動去征求S的意見，問他是否愿意參與排查，而S也立刻答應(yīng)下來；T又神秘地出現(xiàn)在辦公室里，如果這有關(guān)系的話……經(jīng)過整整一周的紛擾，周五，編譯終于成功。
那么，這一編譯錯誤到底是如何產(chǎn)生的呢？說起來，這居然還與前述混亂的版本計劃有關(guān)。在4.0版本中，出于兼容舊有設(shè)備的需要，CM模塊中有些文件按照foo_V4.h的格式命名，后來升級到4.1、4.2版本后文件內(nèi)容相應(yīng)修改，文件名保持不變。可是5.0版本實際上是4.1、4.2版本的綜合，CM小組被迫把4.1、4.2這兩個版本的foo_V4.h文件都引入5.0版本，文件名分別命名為foo_V41.h和foo_V42.h以示區(qū)別。換言之，文件名變長了一個字符，而這就導(dǎo)致法國集成測試團隊的編譯腳本中的命令行超過了最大長度的限制……
尾聲
軟件工程應(yīng)該怎樣做？我本來以為CMM、TL 9000等是王道，經(jīng)歷這一風波我才深切地體會到，再好的流程與制度也經(jīng)不住扯淡啊。人和最重要。
無論版本號如何，我們的產(chǎn)品終究還是銷路不暢。新任CEO上臺后，大刀闊斧厲行改革，將整條產(chǎn)品線出售。畢竟，對于IT業(yè)來說，創(chuàng)新才是利潤之源，單純的削減成本沒有出路。基于這一認識，我轉(zhuǎn)投互聯(lián)網(wǎng)公司，從此踏上新的征程……
作者方坤，Google中國資深軟件工程師，清華大學(xué)電子工程系碩士。曾先后在創(chuàng)業(yè)公司與大型外企任職，2006年加入Google中國，先后從事過基礎(chǔ)架構(gòu)、產(chǎn)品搜索、音樂等項目的研發(fā)和運營維護。
本文選自《程序員》雜志2011年09期，更多精彩內(nèi)容敬請關(guān)注09期雜志