前开发团队主管谈：微软精心打造的 Vista 系统，为什么死得这么快？
在Windows历年来最受欢迎的两个版本：Windows XP、Windows 7之间，可能很多人都遗忘
了中间还有一版Windows Vista，其实从后来的观点来看，当初 Vista 都是一个超前于时
代的系统。但这个系统在当年却遭遇了前所未有的失利——究竟为什么 Vista 会失败、
死亡？
当时微软负责这个专案的主管之一 Ben Fathi 在 Medium 发表了文章 What Really
Happened with Vista: An Insider's Retrospective，让我们可以明白当时这版系统到
底发生了什么事。
经验是你在需要的时候才会得到的东西。——
从 Windows Vista 的发布日期算起，到现在，已经10年了，但这些教训在现在比以往任
何时候都更有意义。
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 版本中体现出来并“俘获”数以百万计的客户。
然而开发团队和测试团队难以保持一致，因为前者努力输入程式码，后者则致力于发现更
复杂和深奥的测试用例。至少可以说，组织内部的动态很复杂。
当然，这一切都不应该被当作借口。
我们有没有做错什么？当然有，而且错的不少。
但我们是故意犯错的吗？当然不是。
我们能做的更好吗？当然可以。
换到今天我们能做的更好吗？当然不，此一时，彼一时。
现在回望过去的时候，应该沮丧还是悔恨呢？我更喜欢把它当成经验教训。我敢确定我们
没有人在以后的项目中会犯同样的错误。前事不忘，后事之师。人非圣贤，孰能无过？
https://goo.gl/rLxeiw