前開發團隊主管談：微軟精心打造的 Vista 系統，為什麼死得這麼快？

當時微軟負責這個專案的主管之一 Ben Fathi 在 Medium 發表了文章 What Really Happened with Vista: An Insider's Retrospective，讓我們可以明白當時這版系統到底發生了什麼事。

▲ Windows有這麼一個傳統：團隊成員在新的Windows系統版本發佈後，會在海報上簽上自己的名字（本圖是一張DVD）。而當發佈會結束的時候，海報上就會有成百上千個簽名。

經驗是你在需要的時候才會得到的東西。—— Steven Wright

從 Windows Vista 的發布日期算起，到現在，已經10年了，但這些教訓在現在比以往任何時候都更有意義。

Windows 團隊是個龐然大物，有成千上萬的開發人員、測試人員、專案經理、安全專家、界面設計人員、架構師等等，還有人力資源人員、招聘人員、銷售人員、律師，當然還有很多經理、董事和副總裁等等。然後還有成千上萬的合作團隊（在微軟內部以及外部）支撐這一整個系列的團隊的運作，範圍從底層硬體到驅動程式，再到平台上的應用程式。

▲ 微軟足球場上，Windows 團隊的照片。（航空拍攝）

從組織上來說，Windows 實際上包含了三個團隊：核心、伺服器和客戶端團隊。核心團隊負責 Windows 系統所有版本所共享的一切核心組件（內核本身、儲存、安全、網路、驅動程式、安裝和升級模組、Win32等）。而伺服器團隊則專注於伺服器市場所需的技術（終端服務、高可用性、企業管理工具等），而客戶端團隊負責與桌面和消費者相關（web 瀏覽器、媒體播放器、圖片等）的技術。

當然還有其他的組織機構，雖然 Windows 越來越受歡迎，團隊的規模也在擴大，但基本結構仍然保持不變。可以說，從文化和組織角度講，核心團隊更接近伺服器團隊而不是客戶端團隊——至少在 Vista 發佈之前是這樣。

我的微軟經歷

我是1998年入職微軟的。然後我很幸運，在這頭龐然大物裡待了十幾年——在 Windows 2000的全盛時期加入了它，並一直堅持到 Windows 7的發布。

在任期的前7年裡，我管理負責儲存、檔案系統、高可用性、網路協議、分散式檔案系統和相關技術的團隊。這與 Windows 2000、XP、Server 2003和 Longhorn 大致相同。

後來，我就調到了負責管理安全的部門，可能待了有一兩年的時間吧——大概是從 Longhorn 重啟到 Vista 發佈。我的職責範圍從 Windows 的安全技術到防毒產品，再到附加解決方案，以及安全更新等緊急計畫。病毒和蠕蟲給 Windows 帶來了巨大的打擊，讓微軟在市場上建立的安全軟體的聲譽毀於一旦。

在 Vista 發佈之後，以及 Windows 7開發之前的這段時間裡，我管理著Windows的所有核心開發事務。這意味著所有技術開發全都在後台運行，客戶端和伺服器團隊都可以使用。在Vista發佈後，Windows 各級團隊由開發、測試和專案管理三方負責組織，所以我最後跟兩人一起負責，我管理開發團隊，他們分別管理測試和專案管理團隊。

Windows 團隊曾經嘗試過許多大規模和有野心的計畫，不過這些計畫在幾年後往往被放棄或重新規劃。更早的例子是雄心勃勃的 Cairo 計畫，它最終失敗了，最後有些殘存的理念傳承至 Windows 2000中。

問題1：更新迭代的時長過久

在我看來，Windows 最大的問題在於每個版本的時長。平均而言，一個版本從開始到完成大約需要3年時間，但「新」程式的開發時間只有大約6到9個月。其餘時間都用於整合、測試之類的——每個階段持續幾個月。

一些轉案的核心開發時間要超過6個月，所以它們就齊頭並進，最後在準備就緒時與主程式合併。這意味著主幹幾乎總是支離破碎的，因為大量的功能被整合或替換掉了。在 Windows 7發佈期間，為了確保有一個持續健康和功能正常的程式庫，我們對其進行了更嚴格的控制，但之前發佈的版本都有好幾個月的不穩定期。

開發過程總體來說是比較混亂的，開發人員會說服自己和他人他們的程式碼優於別的專案，他們最後能及時優化僅剩的一些小部分，這樣一來即使是半成品，這也是一個可以發佈的版本。

3年的發布週期意味著我們很少知道當我們發佈新版本時，外部的競爭環境會是什麼樣子的。錯過一場發佈意味著計畫取消，但一個團隊或主管就是不能讓自己放棄。我個人也負責過一些這樣的計畫。

問題2：團隊龐大，進度不一致且最終測試難度高

考慮到每個團隊都想把自己的東西夾在新版本中，所以他們通常花很多時間再將自己的程式與其他團隊程式的組合、用戶介面、測試以及升級等繁瑣而乏味的問題上，卻忽略了解決自己程式中真正棘手的問題。反過來，這意味著一些團隊很快變成了別人的瓶頸，因為每個人都在為最後一刻完成用戶界面設計或升級測試而努力。

在任何給定的時間點，都有多個主要的版本處於開發狀態。隨著時間的往後發展，不同的團隊負責不同情況下的程式碼開發都可能導致馬太效應——由於某種原因落後的團隊，往往會更落後。

當一個專案接近完成時，專案經理將開始關注下一個版本的需求，而「健康」團隊的開發人員將開始執行新的程式碼工作，但是組織的大部分使用者仍然要與目前的版本奮鬥。特別是測試團隊，直到一個專案真正發佈前，他們很少從舊版本中解放出來。

所以，你不難想像，新程式碼在專案開始時並沒有經過徹底的測試，因為「不健康」的團隊總是落後，忙著對當前的版本（對其它團隊來說可能已經是前一版）進行最後的修改，然後就是越來越落後。這些團隊通常是士氣最低、耗時最高的團隊，這意味著工程師們接手的是他們沒有編寫過、因而也不理解的程式碼。

問題3：與軟體供應商關於安全問題的矛盾

在 Vista/Longhorn 專案的大部分時間裡，我負責的是儲存和檔案系統技術，也就是說我參與了 WinFS 的工作，儘管它主要是由 SQL 資料庫團隊（Windows 團隊的一個姐妹組織）發起的。比爾‧蓋茲甚至親自參與這個團隊，他還被戲稱為「WinFS」專案經理。

不過事後看來，同樣的計畫，顯然 Google 他們已經輕鬆地解決了為非結構化資料提供無縫且快速搜尋的問題。不過他們這樣做是為了整個Internet，而不僅僅是為了你的磁碟容量。

當 Longhorn 被取消，Vista 殘存的一鱗半爪匆匆組裝在一起時，WinFS 專案就已經被否決了。不過，SQL 團隊將它作為一個獨立的專案依然進行了幾年。而那時 Windows 已經有了一個內建的搜尋引擎，而且完全是在不需要變更應用程式的情況下實現的。因此，WinFS 的必要性也變得更加模糊，不過，這個專案卻仍在繼續。

Longhorn 專案中大量與安全相關的架構在該專案廢止之後，被轉移為 Windows Vista 專案的一部分。我們在迅速膨脹的網路世界中學習了很多安全知識，並希望將所學到的經驗用於系統之中，以提高所有客戶的整體安全性。

我們別無選擇。

因為 Windows XP 表明了我們是自己成功產品的受害者。當面對網路時代的現實時，一個設計初衷僅為實用的系統在滿足安全性方面是遠遠不夠的。解決這些安全問題意味著創建一個並行的專案，這就是大家所知道的 Windows XP Service Pack 2，這是一項巨大的工程，而且從 Longhorn 專案中汲取了數千個資源。

在 Vista 中執行嚴格的管理邊界意味著打破 Windows 系統中的每一個應用程式。部分的解決方案是使用者帳戶控制，但這可以說是 Vista 最令人討厭的特性。當使用者要執行程式時，系統總會跳出一個視窗詢問使用者是否真的打算提高權限。由於安裝程式、清除程式，這些過程幾乎都需要提高權限，因此使用者在系統上的初體驗就是大量的使用者帳戶控制的視窗彈出。

毫無疑問，這不會給用戶留下什麼好印象。而如果管理權限從登錄用戶中被刪除了，可以毫不誇張地說99%的 Windows 應用程式都無法正常安裝。

問題4、5、6：新形勢、大型公司創新難、壟斷

電腦業那些年裡發生了翻天覆地的變化——手機的興起，雲端的出現，創建新的廣告業模式，社群媒體的病毒式增長，64位元電腦的成熟等等，而這些只是 Windows 面臨的攻擊的一小部分。這很正常，因為這顯示了創新者的困境。我們添加的程式碼越多，專案的複雜度就越高，團隊的規模就越大，系統規模也越大，也就越難跨越競爭。

好像競爭的壓力還不夠似的，工程師們和專案經理們還得花無數個小時和來自司法部以及公司律師的代表們一起研究看是不是違反了反壟斷法律。

更為殘酷的是，產品的生命週期決定了大約需要3年時間才能推出一個主要的 Windows 版本，但這對於日新月異的市場來說實在是太慢了。WinFS、安全性只是 Longhorn 議程上的一些大型專案，除此之外還有數不清的的小賭注。

當你公司上下有成千上萬的人、客戶有數十億的時候，每個人就都有發言權。那些被認為能夠在未來應用到平板和手機系統的功能，現在還被要求也能用到筆電上、資料中心的伺服器上等等不一而足。當我們試圖同時在市場的各個環節上取得進展時，這些要求與團隊的努力完全是南轅北轍。

Longhorn 和 Vista 不可能被孤立地看待。它們只有在與之前及之後發佈的版本（Windows 2000和 XP, Windows Server 2008和Windows 7）結合在一起看時才有意義，這樣也能對整個行業有個更全面的瞭解。

問題7：相容性難題

Windows 是它自身成功的受害者。它已經成功地滲透到許多市場，而那些市場業務現在對系統的設計產生了一定的影響，使其設計理念常常是互相衝突的。嘗試滿足所有這些不同的需求意味著不能完全滿足其中任何一個需求。

微軟在1990年代取得過成功，但在十年後陷入困境。因為周圍的世界在不斷變化，我們在努力跟上它。說實話，這些趨勢我們都把握到了，也努力地回應它們。

簡而言之，我們其實知道當一個特定的系統即將發布時，事實上它在三、四年前就已經過時了。而我們所能做的最好的事情，是為新的雲端服務提供增量和無摩擦的服務。

但我們當時做的事恰恰相反，我們不斷向現有的系統裡添加功能，這就需要在每次發佈之前進行數月的測試，結果就在我們最需要加速的時候速度反而變慢了。當然，我們也沒法刪除舊的功能，這些功能確保了在 Windows 上已經運行的應用程式的相容性。

現在想像一下，在十幾年或更長的時間裡，為數十億的客戶、數百萬的公司、成千上萬的合作夥伴、提供一種一體適用的系統，你就會逐漸對相容性的噩夢有所瞭解了。

事後看來，Linux 在這方面更成功。開源社群和軟體開發的方法無疑是解決方案的一部分。在這方面，Unix/Linux 的模組化和可插式架構實現了體系結構的有效改進。

▲ 微軟的「作戰室」，後來改成「研討室」

內部組織的動態和個性也很重要。我們都有自己最喜歡的特性，我們合作夥伴推動我們採用新的標準，幫助它們在平台上認證。我們都有證明我們的技術和想法的野心……只要我們能在下一個 Windows 版本中體現出來並「俘獲」數以百萬計的客戶。

然而開發團隊和測試團隊難以保持一致，因為前者努力輸入程式碼，後者則致力於發現更複雜和深奧的測試用例。至少可以說，組織內部的動態很複雜。

當然，這一切都不應該被當作藉口。

我們有沒有做錯什麼？當然有，而且錯的不少。

但我們是故意犯錯的嗎？當然不是。

我們能做的更好嗎？當然可以。

換到今天我們能做的更好嗎？當然不，此一時，彼一時。

現在回望過去的時候，應該沮喪還是悔恨呢？我更喜歡把它當成經驗教訓。我敢確定我們沒有人在以後的項目中會犯同樣的錯誤。前事不忘，後事之師。人非聖賢，孰能無過？