苹果Safari浏览器的成功，是侥幸吗？

直至今日，我仍清晰地记得那一刻我手中湿冷的感觉，史蒂夫向大家郑重宣布：苹果已经开发了自己的网络浏览器。一瞬间，我们的超级秘密——这个开发周期长达18个月的项目——成了众所周知的事情。史蒂夫向大家宣布，Safari加载网页的速度比IE浏览器快了不只一点儿，而是整整三倍。

乔布斯要的是速度更快

有消息从管理层传出来，史蒂夫·乔布斯已经决定了他评判我们浏览器项目的标准，其关键点只有一个：速度。史蒂夫希望我们的浏览器速度快，从互联网上加载网页的速度要足够快，必须远远超过Mac计算机上默认使用的微软IE浏览器才可以，因为我们的浏览器存在的目的就是完全替换IE浏览器。在苹果，我们总是试着提供开箱即用的最好的产品，除了速度这个方面，我们还需要为浏览器提供一整套功能，其中，出色的书签管理、精简的用户界面这两项在开发清单上占据了最重要的位置。不过我们的团队在当下还是把重心放在提高速度这一目标上。上述挑战给了我们明确的目标。

速度也是史蒂夫对未来互联网发展趋势的洞察的一部分，史蒂夫希望我们的浏览器能够做好准备迎接即将到来的浪潮。

要保证速度必须放弃软件的部分优化即便在程序员群体里，能称得上著名计算机科学家的人也很少，不过高德纳绝对担得起这个头衔。下面是他关于优化的言论：程序员在思考或担忧程序里非关键部分的速度上浪费了大量时间，实际上如果把调试和维护考虑进来，这些提升效率的努力实际上有非常强的负面作用。我们应该放弃微不足道的效率提升，在97%的情况下，过早的优化往往是错误的根源。我们来看一下这个例子。假设我邀请你到我家的厨房做示范，我让你：

从冰箱里拿一罐芥末。

你会很容易地完成这项任务，因为我的厨房储备了这种调味品。很显然，执行这句指令会比执行下面这句长度相当的指令更省时：

去超市买一罐芥末。

由于一些指令中包含了更复杂的命令，这些指令的执行时间比其他指令的执行时间更长。这与优化有什么关系？下面这些是完成其他厨房任务所需要的指令：

把冰箱里的所有东西都取出来。

把所有物品都放在柜台上。

通过增加一个指令来对其进行优化：

把冰箱里的所有东西都取出来。

把所有物品都放在柜台上。

用最少的往返次数完成任务。

第三个指令提出了执行该项任务关于速度的建议。将冰箱和柜台之间的往返次数视为约束条件，我们可以合理地认为，如果往返次数减少，那么整个操作流程可以更快地完成。这种方式正确吗？上述优化路径会引起以下问题。如果一次性拿取和卸载大量物品，这种方式可能有效，但事实真是这样的吗？如果我尝试把装芥末和蛋黄酱的罐子、装牛奶的纸箱、黄油棒以及盛有昨晚剩菜的盘子放在一起一次性搬运，一旦有东西掉了怎么办？这就造成了故障，不是吗？如果我洒了或者打碎了什么东西，我是不是要花时间打扫干净，才能保证任务“完成”？如果我回头仔细思考“用最少的往返次数完成任务”这句指令到底指的是什么，我可能还会认为任务的目标就是使冰箱到柜台之间的往返次数最少——但是这是真实的意图吗？我不知道，这只是我最好的猜测。实际上我并没有足够的信息来确认这项任务的目的。

这个情景告诉我们为什么像高德纳这样经验丰富的程序员会发出对优化的警告。有时，在浏览器开发过程中，即使我们拥有最好的调查结果和“创新性思维”也是不够的。很多时候我们会发现，在不影响速度的前提下，我们根本找不到增加功能的方法。没有哪种优化是简单的，也并非总是充满乐趣的。

Safari：大家都喜欢的名字

随着项目发布日的临近，苹果的市场部开始着手为我们的浏览器取名字。，在此之前的一个月，我们一直将其称为“网络浏览器”或“亚历山大”（Alexander），亚历山大会让人们联想到马其顿国王——一位著名的“征服者”（Konqueror）。我们认为Konqueror这个名字很讨巧，但是它不能作为面向消费者的名字出现在苹果产品的身上。

史蒂夫·乔布斯想到了一些名字，当第一次听到它们时，我哭了。最开始，史蒂夫喜欢“闪电”（Thunder），但很快他喜欢上了“自由”（Freedom）。我觉得两个名字都很糟糕，我无法想象我告诉人们“我在为自由工作”这一场景，这听起来好像我是那种漫画书里面想成为超级英雄的人。

最终，斯科特提出了一个可行的名字：Safari。这个单词传达了一种“环游世界”的感觉，就如同其他知名浏览器——Navigator（航海家）、Explorer（探险家）、Konqueror（征服者）——带给人们的感觉一样，但Safari又绝不是它们的盲从者，是令人耳目一新的。唐也很喜欢这个名字，当然最重要的是，史蒂夫也很喜欢。Safari是我发布的第一个苹果产品。

在后来的日子里，我对史蒂夫如何准备这种重磅产品的发布会有了更多了解。在演讲开始前的三周或一个月，史蒂夫就开始在苹果公司的场地里结合幻灯片进行练习，地点通常是无限循环总部的礼堂。随着日复一日的练习，他按照他想在主题演讲中展示的方式逐步完善这个演讲。

这是史蒂夫成为成功演讲者的重要秘诀之一。他反复练习，一遍又一遍地打磨，直到他觉得自己的演讲足够精彩。

我仍清晰地记得那一刻我手中湿冷的感觉，史蒂夫向大家郑重宣布：苹果已经开发了自己的网络浏览器。一瞬间，我们的超级秘密——这个开发周期长达18个月的项目——成了众所周知的事情。史蒂夫向大家宣布，Safari加载网页的速度比IE浏览器快了不只一点儿，而是整整三倍。

史蒂夫展示完Safari图标后，点击了下一张幻灯片，上面只有一个单词：Why（为什么）？史蒂夫认为十分有必要向大家解释，苹果为什么要推出自己的浏览器，他把“速度”作为解释的重中之重。有些人可能认为推出Safari浏览器的举动仅仅是一种营销手段，是把产品里恰好表现出众的功能当作卖点。

对于任何一种复杂工作，确定清晰的愿景和自己要做的事都是解决问题的开始。尽管确定这样的愿景是很困难的，但毫无疑问，完成整个工作更加困难。

你需要想出解决问题的办法，提出实现构想的计划，然后高标准地完成计划，不陷入困境，也不改变努力方向或彻底失败。最令人紧张和不安的可能是你的办法、语言以及愿景没有一个好的开始，即便你全力以赴，它们也不会带领你走向成功。

在浏览器项目开始的初期，史蒂夫告诉我们他想让浏览器的速度足够快。唐给我们制定了实现这个目标的规则：永远不做任何让浏览器变慢的改动。

此外，PLT使我们有了实现目标的方法。浏览器团队将PLT嵌入了日常工作流程，我们利用测试结果来衡量和监测我们的进度。差不多一年后，当我们做好发布Safari的准备时，史蒂夫可以在舞台上，用非常直接的方式，告诉全世界我们成功了。

在宣布测试版本之前，我们的Safari团队仅有10人负责编辑代码，iPhone的949专利上列出的发明者只有25人。两个团队都不是具有几百名或者几千名开发人员的软件团队。从史蒂夫开始，公司自上而下隐藏了一个实用的管理哲学。

我们的领导想要得到高质量的结果，他们设置了各种各样的规则，包括管理者要与工作在一线、亲自制作示例程序的员工直接交流等。这个要求限制了团队人数，并且产生了更深层次的影响，我们的开发团队必须要求每位成员都足够优秀且有团队凝聚力。

这些因素十分重要，因为它们可以使人们始终保持足够的动力，而这正是超大型团队的主管一直努力的方向。沟通效率高则是小型团队与生俱来的另一个难得的特点。小型团队的沟通路径短，这些被缩短的沟通路径就好像路上的坚果，使得通往目的地的旅途更加轻松。我们总是在努力尽可能快地到达目的地，拒绝犹豫和拖延。