新書搶先看》網路時代，速度是一切勝敗的起點

中國古代有句成語叫做「兵聞拙速」，據聞出自《孫子兵法》（只不過，也有一派否定這樣的說法，不確定實際出自哪一本史籍）（編按：《孫子兵法・作戰篇》「故兵聞拙速，未睹巧之久也」），意指「即使戰法拙劣，只要用兵迅速，就能夠取得勝利」，此處引申為也有「迅速完成工作，即能搶佔優勢」。

我在美國微軟工作時，主要負責Windows 95的開發工程。由於微軟每一件大小工作，必定訂下完成的期限，加上產品（Windows 95）有既定的發行日期，所以已排定計畫的工作都必須在期限內完成。我當時採取的工作方法，會於後面詳述，在此要先告訴各位的是，微軟極為重視工作效率。

為了讓Windows 95如期發行，我全心衝刺工作進度。其後，微軟終於順利在1995年8月24日推出Windows 95國際版。

不過，發行之際，Windows 95這套電腦作業系統軟體中，其實還存有3500個Bug。我們是在知情的狀況下，仍選擇正式推出。因此，微軟之後自然陸續釋出了修正Bug的更新程式。就像現在的手機App的開發人員一樣，工程師共同度過了無數個與Bug奮戰的日子。

但在大規模的產品企畫中，Bug的總數一旦減少到某個臨界點，數量就很難再向下修正，這點在程式設計界中是十分常見的狀況。畢竟，當你修復了某個Bug，有時反而導致另一個Bug出現的副作用。亦即，要完全除盡電腦軟體的Bug是相當困難的任務。

正因為對這點有所認知，工程師通常不會以100%的完成度為目標。就算只達到90％或80％的完成度，也會努力遵守交期。所謂的「兵聞拙速」，就反映在這種工作形態上。

綜合以上因素，即便當初還存在3500個Bug，微軟最終選擇將Windows 95商品化。不過，重大的Bug當然非修正不可。例如，明明確實存下的檔案卻不翼而飛，若產品中有這樣嚴重的Bug鐵定沒有人敢使用。因此這些地方一定要經過徹底檢測，逐步完成除蟲（Debug）作業。

只不過，我們不會特意修正用戶使用過程中接觸不到的細微錯誤。例如，輸入某項一般使用者無從得知的指令後，螢幕畫面會自動消失等Bug。如果連不為人知的Bug都要完美清除，不只工作量永無止境，也絕對趕不上既定的發行日。

即便如此，誠如各位所知，Windows 95給世界帶來了相當大的衝擊。雖然Windows 95這套軟體本身，對具備程式基礎的專家來說是一件半吊子的成品，但我認為重點在於，能夠以多快的速度提供多好的產品給用戶。由於發行後還有機會逐步修正Bug，因此認清現實、掌握適當容錯範圍，即為我們的重要職責之一。 

比爾．蓋茲工作上還很重視決策力，他下決斷的速度用「光速」來形容也不為過。到底有多迅速？我為各位介紹一個具代表性的實例。

這件令我印象深刻的往事，發生在1995年1月，西雅圖下著冬季綿綿細雨的午後。當時，美國微軟總公司有隸屬不同派系的作業系統開發團隊（operating system，簡稱OS。就如同微軟發行的Windows Vista，蘋果的OS X等，讓電腦、智慧型手機運作的基本作業系統）。兩個團隊的名稱分別為「開羅」與「芝加哥」，彼此間相互競爭。

原本開羅團隊預計在前作Windows 3.1之後，開發次世代的新型作業系統，但進度遲遲未見突破，這段期間，芝加哥的開發團隊從公司內部崛起。

芝加哥團隊給人的感覺，就像是駭客雲集的職業集團，行事作風與擁有多位史丹佛大學博士的開羅團隊大相徑庭。

我原本隸屬於開羅團隊，卻因為厭倦無實質意義的會議，某次與上司爭吵後，轉調到芝加哥團隊。我認為芝加哥的風氣一定會比開羅開放，能立即讓自己的想法和點子反映在工作上。

轉調到芝加哥團隊的我，把開羅時期負責的一部分程式也帶了過去。我心想既是同一家公司，設計這個程式的人本來就是我，算不上剽竊或犯罪什麼的吧。

可是之後，開羅團隊的人得知我把點子帶去芝加哥的消息，對此大為震怒，甚至指控我是內鬼。最後還直接向比爾．蓋茲請願，希望召開內部審判。

某天，芝加哥團對的上司簡明扼要地交代我：「看來得在比爾．蓋茲面前公開簡報了，這件事全權交給你處理」。縱使事態的發展令我訝異，但看到開羅送來的資料後，更是令我驚訝。400多頁的資料中，鉅細靡遺地寫著，我除了將程式資料偷渡到芝加哥團隊，工作上有多灌水又有多偷工減料。

這些指證確實有幾分道理。如同前述，我向來奉行「兵聞拙速」的工作要訣，因此無論只做到70分或80分，首要目標是以最快的速度完成整體工作。我承認，這種作風會讓程式出現大量Bug。

在我看來，開羅團隊那些光說不練的科學家，只顧著舞弄紙上的空論。太過在意細枝末節，工作永遠無法完成。這種緊要關頭，光是要完全看完那400頁的指控，我都快睡著了，所以翻了幾頁後乾脆闔起資料，直接出席審判會。

後來，即便簡報日一分一秒逼近，我仍無意準備迎戰的簡報資料。我很清楚，這並非技術面上的小鬥爭，而是關係到微軟整體企業文化的大事。我決定讓比爾．蓋茲了解開羅團隊缺乏工作效率的事實。 

審判當天，我前往高層專屬的會議室。發現除了營運長史蒂芬．巴爾默（Steve Anthony Ballmer），微軟五大巨頭都列席入座了。包括副總裁布拉德．西爾弗伯格（Brad Silverberg）與吉姆．阿爾奇（Jim Allchin）、Office 開發團隊領導人布萊恩．麥唐諾（Brian MacDonald）、高級副總裁保羅．馬瑞茲（Paul Maritz），以及執行長比爾．蓋茲。現場菁英齊聚，也令人深刻感受到這次會議的重要性。

這種情況下，與其說緊張，反而是因為欣喜而感到雀躍。畢竟，能在這些大人物面前，主張自己工作重要性的機會千載難逢。事到如今，可不能輸給只會空口說白話的開羅團隊，我頓時感到腎上腺素不斷向上飆升。

審判正式開始。首先，由開羅團對提出那400資料，敘述我工作態度有多鬆散、多敷衍行事。即便此時，我也不為沒仔細看過那四百頁資料而後悔，我已經準備好專屬自己的應戰方針。

輪到我發言了。我雖然沒有準備任何書面資料，但帶了一片裝有某些資料的光碟片。我邊展示其中內容邊正視比爾．蓋茲的雙眼說道：「開羅團隊的主張有一定道理，但若過程中只執著於完美的基礎設計，永遠也拿不出成果。Windows 95再過6個月就要正式發行了，我認為，把微軟的未來，交給不知何時才能做出成果的開羅團隊是一大錯誤。」

環繞著次世代作業系統展開的開羅對芝加哥之戰，可說是一場能否正確活用時間的賭注。

比爾．蓋茲聆聽時，只是雙手合十放置桌面上，身體稍微向前傾並微幅前後晃動。這是他認真思考時的招牌姿勢。

聽過現場人員發表過一輪之後，比爾停止了搖晃。我心想「他終於要開口了」，不由得挺直背脊。

不過，他只是轉而望向保羅．馬瑞茲，稍微使了個眼色。保羅隨即表示：「你們留在這聽候指示。」就站起身來，與比爾一同走出會議室。我猜測，比爾心中應該得出結論了，只剩與保羅再度確認，就會公布最終決定。

比爾與保羅離開的時間僅短短三分鐘，會議室瀰漫一股奇妙的沉默，我感覺像過了一個小時。在場的每一個人都明白，他們倆回來時就會發表不容任何人提出異議的裁決。

耗費高額開發資金的芝加哥與開羅計畫，命運將在下一刻揭曉。

門一打開，保羅先走了進來，兩人回到會議室。這是決定命運的瞬間。

「開羅計畫正式終止。」

比爾一開口就是這句話。

開羅計畫終止。這代表要將開羅團隊耗費四年開發的作業系統技術歸零。等於在這一瞬間，宣布解散超過四百人的開羅團隊之意。反之，芝加哥團隊開發的作業系統，必須肩負起發行微軟次世代作業系統的重責大任。

不過，什麼樣的系統才足以稱作次世代的作業系統？

答案就藏在我事先準備的那片光碟片中。裡面的內容，正是我調到芝加哥團隊後完成的Windows 95系統Beta版。

這場審判，也意味著我的工作成果，已獲得公司高層的認同。令人難以想像的是，這項無比重要的決策，竟然是在短短三分鐘之內完成的。（本文摘錄自《為什麼你的工作做不完？》第二章，商業周刊出版）