在微軟公司工作了17年的微軟員工Tim Sneath在一篇部落格中宣佈，他將離開這個軟體巨人，進入Google工作開發Flutter移動框架。在離開之際，他強調了微軟的偉大之處，並說微軟有令人難以置信的多樣化利益，微軟內部充滿了人才。

作為前微軟專案經理開發過一系列專案的Tim Sneath，Tim Sneath談到了微軟公司從Windows Vista時代開始犯下的一系列錯誤。Tim Sneath認為，微軟未能迅速適應基於標準的網路興起以及蘋果和iPhone復甦帶來新競爭威脅。它快速增長使得它面臨著各方的攻擊困境，同時也不願犧牲現有業務尋找新的機會，微軟在解決Windows Vista遇到的挑戰上而分心。

Tim Sneath繼續解釋說Silverlight，Internet Explorer和Windows Phone都因為各種各樣的缺點，讓微軟和開發者陷入交戰狀態，最終導致客戶丟失，最好的例子就是Windows Phone，絕大多數客戶最終轉投Android和iOS。

至於他在Google的角色，這位前微軟員工解釋說，他將成為Flutter團隊的一員，致力於開發新的移動應用軟體開發工具包，使其從alpha階段到穩定的開發階段。他還提供了這個專案的一個簡短技術說明，並解釋說，它可以為Android和iOS建立應用程式，並且比以往任何時候都更加先進。

從後來的很多反饋看來，Vista都是一個超前於時代的作業系統。但這個作業系統在當年卻遭遇了前所未有的失利——究竟為什麼Vista會失敗、死亡？當時的專案團隊主管之一Ben Fathi在Medium發表了文章What Really Happened with Vista: An Insider’s Retrospective，給我們提供了內部的視角。

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

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

我喜歡讀Terry Crowley的部落格（《Vista到底怎麼了？》）。Terry“運籌帷幄之中”，雖然作為局外人，但卻把涉及到Windows Vista專案以及與之相關但已被放棄的Longhorn專案的複雜陰謀報道得精彩迭出。

他正確地指出了困擾這個專案的許多問題，不過在此我並不想重複這些問題。我認為對這種事情，只有從一個內部人士的角度提出看法才不失公允。我也不奢望能夠像Terry的文章那樣說服力強，只求大家能對可能的錯誤有所瞭解。從Windows Vista的釋出日期算起，到現在，已經10年了，但這些教訓在現在比以往任何時候都更有意義。

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

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

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

我的微軟經歷

我是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”專案經理。

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

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

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

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

在Vista中執行嚴格的管理邊界意味著打破Windows系統中的每一個應用程式。部分的解決方案是使用者帳戶控制，但這可以說是Vista最令人討厭的特性。當用戶在執行命令時，系統總會詢問使用者是否真的打算提高許可權級別。由於安裝遺留應用幾乎總是需要提升特權，因此使用者在系統上的初體驗就是大量的賬戶控制視窗彈出，毫無疑問這不會給使用者留下什麼好影響。而如果管理許可權從登入使用者中被刪除了，可以毫不誇張地說99%的Windows應用程式都無法正常安裝。

從各方面來看，Vista比微軟之前釋出的任何作業系統都要安全得多，但在這個過程中，我們也以前所未有的方式打破了應用程式和裝置驅動程式的相容性，因為我們不再支援臭名昭著的應用了，或者使用像使用者賬戶控制這樣的機制來繞過它們。客戶們討厭它，因為他們的應用程式崩潰了；系統合作伙伴討厭它，因為他們覺得他們沒有足夠的時間更新和認證應用程式，所以Vista就這樣被掃地出門。

在許多情況下，這些安全性質的更改意味著需要對第三方解決方案進行深入的系統結構改變。而且大多數系統的供應商都沒有對他們遺留的應用程式進行大量的改進投資。其中一些解決方案採用了非正統的方法來修改資料結構，甚至在核心中使用指令來實現它們的功能，這就經常性地造成嚴重破壞。而大約70%的Windows“藍色畫面”是由這些第三方驅動程式造成的，他們不願意使用支援的介面程式來實現他們的功能。防毒軟體供應商因為使用這種方法所以一向口碑不佳。

在我擔任微軟的安全主管期間，我花了數年時間向防毒軟體廠商解釋為什麼我們將不再允許他們為核心記憶體中的指令和資料結構打補丁、為什麼這是一個安全隱患，以及為什麼他們需要使用我們批准的程式介面，我們將不再支援他們的遺留應用程式與Windows核心掛鉤——因為駭客們會用同樣的方法來攻擊消費者。我們的“朋友”——防毒軟體——威脅要起訴我們，聲稱我們是在阻礙他們的生計，濫用我們的壟斷力量！簡直了，有這樣的朋友，誰還需要敵人？即使冒著降低我們共同客戶的安全的風險，他們也不願意改進本就應該改進的方法。

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

計算機行業那些年裡發生了翻天覆地的變化——手機的興起，雲計算的出現，建立新的廣告業模式，社交媒體的病毒式增長，64位計算機的成熟等等，而這些只是Windows面臨的攻擊的一小部分。

這很正常，因為這體現出了創新者的困境。我們新增的程式碼越多，專案的複雜度就越高，團隊的規模就越大，系統規模也越大，也就越難跨越競爭。

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

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

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

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

問題7：相容性難題

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

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

簡而言之，我們其實知道當一個特定的作業系統即將被髮布時，它在三四年前就已經過時了。而我們所能做的最好的事情是為新的雲服務提供增量和無摩擦的服務。但恰恰相反，我們不斷向現有的系統裡新增功能，這就需要在每次釋出之前進行數月的測試，結果就在我們最需要加速的時候速度反而變慢了。當然，我們也沒法刪除舊的功能，這些功能確保了在Windows上已經執行的應用程式的相容性。

現在想象一下，在十幾年或更長的時間裡，為數十億的客戶、數百萬的公司、成千上萬的合作伙伴、成百上千的場景和數十種形式提供一種全支援的作業系統，你就會逐漸對相容性的噩夢有所瞭解了。

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

微軟的“作戰室”，後來改成“研討室”

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

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

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

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

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

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

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

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