免费亚洲欧美精品电影_国内精品偷拍福利视频_美女黄网站色视免费国产_国产不卡福利片在线观看

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

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

關鍵詞：杭州網(wǎng)站制作

公司

我的老東家是一家大型跨國電信設備開發(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)度問題?，F(xiàn)在我們知道，T在北京待了不到一年時間，買下兩套房、一輛車，還辦妥了到加拿大的移民和那邊的工作—而在當時，我們這些員工僅僅只是知道，我們的經理不太在辦公室出現(xiàn)。

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

流程

我們開發(fā)的是一個龐大的電信軟件項目—3G接入網(wǎng)網(wǎng)管系統(tǒng)，采用的開發(fā)流程仍然是傳統(tǒng)的瀑布式。簡單來說，依時間順序，一個軟件工程師（首先是各小組的小組長）需要依次參與以下幾個階段。需求階段：跟蹤和審閱由系統(tǒng)架構師撰寫的需求文檔，必要時要求澄清，然后預估工作量，經理據(jù)此調整人員安排。

設計階段：分析需求文檔，完成模塊設計，據(jù)此撰寫高層設計文檔和底層設計文檔，前者以定義模塊接口為主，后者則涉及更多細節(jié)。編碼階段：根據(jù)兩份設計文檔完成實際編碼工作。單元測試階段：是的，你沒有看錯。根據(jù)本部門正式的、成文的流程，單元測試階段在編碼階段之后安排時間進行。在實踐中倒是沒有這么僵化，大家盡可以測試先行，只要時間大致齊即可。各開發(fā)團隊在完成各自負責的一或多個模塊的單元測試之后，將代碼提交到統(tǒng)一的代碼庫，打上標簽，然后將這些標簽連同其他注意事項寫成文檔保存到指定目錄。其后，就是集成測試階段了—集成測試團隊收集所有團隊的所有標簽，從代碼庫提出相應的代碼進行編譯，編譯成功后即按照事先準備的測試用例進行測試，給開發(fā)團隊提Bug。

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

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

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

版本

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

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

軟件工程應該怎樣做？我本來以為CMM、TL 9000等是王道，經歷這一風波我才深切地體會到，再好的流程與制度也經不住扯淡啊。人和最重要。

4.2版本更倉促地做出來了。又又有一天，經理通知大家：4.2版本過于激進，工期又短，從設計到實現(xiàn)毛病多多，公司也不看好，決定立刻開始5.0版本計劃。這一次倒是沒有太荒唐的事情發(fā)生。5.0版本實際上沒有什么全新的特性，而是將4.1、4.2這兩個版本的特性做一折中，從這個意義上講，叫它4.1.5版本更合適，當然這個話不能對客戶說。就這樣，幾個月以來第一次，大家終于能夠做點兒靠譜的事情。然后，出事了。

風起

第一波的事故，我是直接責任人之一：因為我的失誤，我負責的FM模塊沒有通過編譯。

我還記得前幾個版本交付時和H一起工作的情景。她會敦促我們盡量提前完成開發(fā)和測試工作，提交代碼，打上標簽，撰寫交付文檔。她會親自檢查我們的交付文檔，連一個細節(jié)也不放過。比如有一次，她就發(fā)現(xiàn)我無意中開啟了Microsoft Word的中文自動糾錯功能，把“…”（在版本配置中具有特殊含義）自動替換成了半個中文省略號“…”，讓我臉上無光。大大小小的問題被她連續(xù)抓住幾次之后，我開始小心謹慎，此后幾個版本都順利過關。印象最深的還是編譯時的一次次待命。由于時差的關系，法國同事依據(jù)標簽提出代碼開始編譯的時間是在北京的晚上，每一次，H都會帶領我們幾個少數(shù)技術骨干在辦公室待到夜里，直到我們團隊負責的所有模塊都成功編譯之后才離開。這可真是一件苦差事，而且在我當時看來毫無必要—我們的模塊從來都是一次編譯成功，錯誤（如果有的話）從來都屬于其他團隊。有一次，法國同事連續(xù)犯錯，導致編譯遲遲不能開始。當時我還保留著自校園帶出來的早睡的習慣，時間一長，上下眼皮開始打架。H就跑到我的座位，談人生，談理想，談八卦，反正就是不讓我睡著。一直堅持到凌晨兩點，編譯開始之后照例一次成功，H才領著饑腸轆轆的我們離開辦公室，請我們到樓下的小店吃宵夜。喝著溫暖的豆?jié){，我在心中嘀咕：“真是事兒媽啊。”

這一次，“事兒媽”不在了，新任經理給予我們“完全的信任”，從頭至尾都放開手—這同一件事情我們都連續(xù)做了好幾遍了，還能出什么錯呢？

還真就出事了。前幾次，我們至少能夠提前一周左右的時間完成全部工作，這搶下的一周時間足夠我們反復測試、排查問題，并為應對突發(fā)事件留下時間—盡管突發(fā)事件從未發(fā)生。而這一次，大家經過連續(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模塊與其他依賴模塊之間使用了不一致的標簽。說起來還是怪我們兩邊當時掉以輕心，只是口頭約定了一下，也不知怎么就聽岔了，關鍵時刻害人。又是一番折騰，F(xiàn)M模塊在第三次編譯中順利通過，我心中一塊石頭才算是落了地。

亂戰(zhàn)

我這邊沒事了，CM小組卻開始焦頭爛額。

CM模塊幾次編譯均告失敗，而法國同事提供的編譯錯誤日志亂七八糟，毫無幫助。原來，我們項目當時尚未采用分布式編譯技術，為了縮短編譯時間（僅僅某一個子模塊單機重新編譯就需要18小時），法國的集成測試團隊自行編寫了一個腳本，開啟幾路進程并行編譯各個子目錄。這個腳本寫得過于簡單，幾路進程的輸出信息全都雜七雜八攪到了一塊兒，以至于CM小組研究了幾天，連到底哪個子目錄編譯不過都沒鬧明白！

CM小組嘗試向風雨飄搖中的法國集成測試團隊請求幫助：“你們能否用單路進程編譯CM模塊的各個子目錄，將錯誤信息提供給
我們？”

法國人回答：“請中國團隊盡快修復編譯，你們堵住了整個項目！”

CM小組解釋說：“我們正在努力，你們能不能幫忙……”

法國人回答：“請中國團隊盡快修復編譯，你們堵住了整個項目！”

CM小組再次嘗試：“這一錯誤本地不能復現(xiàn)，而編譯日志……”

法國人回答，并且抄送各路神仙：“請中國團隊盡快修復編譯，你們堵住了整個項目！”

外事不靖，內部也不安寧：CM小組的小組長B和技術骨干S此刻正在斗氣！從一開始，B就將編譯錯誤的排查工作分配給自己和另一位同事，沒有邀請S介入，而S也不主動過問。沒想到這么一個乍看上去再簡單不過的錯誤一拖就是好幾天，這樣一來，雙方陷入僵局。站在B的角度，如果連個編譯問題自己都解決不了，還得請S來當救兵，這不是坐實了自己不懂技術的指控嗎，這張臉以后還怎么擱？再說S一直面無表情地坐在自己的電腦前做自己那一攤事情，一句問話沒有，這不擺明了是要袖手旁觀嗎？而S也有自己的苦衷：自己要是一開始就主動介入倒也罷了，如果拖到現(xiàn)在才出手，那怎么解釋自己前幾天不聞不問的態(tài)度？就算自己辯解說確實沒有端架子、看領導笑話的意思，完完全全是在服從領導安排，也得有人信??！雙方有一點想法倒是共同的：這個編譯錯誤趕緊消失了吧……

既然CM小組遲遲不能修復編譯，順理成章地，項目經理（一個不偏不倚的法籍華人）開始找他們的上級，也就是我們共同的經理T。然而—她找不到T！事情就是這么湊巧，雖然T平時就神龍見首不見尾，可像這次這樣整個禮拜辦公室都不怎么見人影、寫信也不太回的情況還真不多。連續(xù)幾天，項目經理從法國給T的座機打電話，按說這是法國的休息時間，中國的上班時間，可是法國那邊有人打，中國這邊沒人接。電話留言、電子郵件都不好使。項目經理急了，電子郵件寫得越來越不客氣，每封信的結尾都是同一句話—“T在哪里！”……

事情終于驚動了上面，領導出來問話了：“發(fā)生了什么事？為什么會耽誤到現(xiàn)在？”法國團隊再次暗示中國團隊無能，中國團隊則強調本地無法復現(xiàn)，必須法國團隊配合，項目經理在居中調解的同時狠狠地告了T一狀……領導不愧是領導，跳過T的事情不提，和藹可親地建議法國團隊考慮中國團隊的合理要求……事情終于走上正軌。法國團隊終于按照CM小組的建議嘗試單路編譯；與此同時，B主動去征求S的意見，問他是否愿意參與排查，而S也立刻答應下來；T又神秘地出現(xiàn)在辦公室里，如果這有關系的話……經過整整一周的紛擾，周五，編譯終于成功。

那么，這一編譯錯誤到底是如何產生的呢？說起來，這居然還與前述混亂的版本計劃有關。在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以示區(qū)別。換言之，文件名變長了一個字符，而這就導致法國集成測試團隊的編譯腳本中的命令行超過了最大長度的限制……

尾聲

軟件工程應該怎樣做？我本來以為CMM、TL 9000等是王道，經歷這一風波我才深切地體會到，再好的流程與制度也經不住扯淡啊。人和最重要。
無論版本號如何，我們的產品終究還是銷路不暢。新任CEO上臺后，大刀闊斧厲行改革，將整條產品線出售。畢竟，對于IT業(yè)來說，創(chuàng)新才是利潤之源，單純的削減成本沒有出路?；谶@一認識，我轉投互聯(lián)網(wǎng)公司，從此踏上新的征程……