第一章 公司组织与管理 寻求既懂技术又善经营的精明人士 在公司组织和管理方面，微软始终遵循着这样一项策略，即坚持挑选那 些既懂专业技术又懂经营之道的精明人士担任领导职位。我们可以把这项策 略归结为四个原则：
・聘请一位对技术和经营管理都有极深造诣的总裁。
・围绕产品市场，超越经营职能，灵活地组织和管理。
・尽可能任用最具头脑的经理人员——既懂技术又善经营。
・聘用对专业技术和经营管理都有较深了解的一流职员。
从理论上来说，这些原则并非微软独家所创；但从实践上看，它们对整 个计算机行业有着深远的影响。很少有公司能够拥有像比尔・盖茨这样既精 通专业技术又知道如何把它们转化为数十亿美元资产的总裁。事实上，许多 公司在采用与微软类似的管理方法，即围绕产品市场，超越经营职能进行组 织和管理。但是，他们往往不能同时维持一个强大的产品市场和一系列领先 的核心技术。作为一个处于迅速发展的主导行业中的公司，微软在加强组织 管理以适应不断变化的市场方面做得颇为出色，有时甚至可以领导市场潮 流。它逐步建立起来的技术力量已经能够满足巨大且日益增加的产品系列的 需要。
许多公司雇用或提升职员的条件仅仅基于对管理能力的考虑，而并不看 重他们的技术知识和经营管理相结合的程度。微软在选拔经理人员时，把他 们的技术知识和运用技术知识去赚钱的能力放在首位。虽然这种方法可能导 致公司缺乏素质良好的中层的职员管理人员，但这对微软在竞争激烈的高科 技产业中进行软件开发是大有裨益的。此外，通过新一轮的雇用和汲取，微 软可以不断地扩大已经具备的技术基础，比如为用户的软件增加新的程序以 及开发信息高速公路产品和服务等等。
微软对筛选职员，尤其是软件开发员条件特别苛刻。在挑选软件开发员 时，往往在所有的应征者中只雇用 ２％—３％。在考虑聘任经理人员时，微软则 重视选拔那些既拥有较高的技术能力，又睿智明理，知道如何运用自己的技 术来为公司推出新产品的出色职员。
在很多方面，微软的生产单位经理们就像两千年前古罗马军团中的百夫 长那样运作。他们都精明能干，不需要过多的指示。对于突如其来的机会和 威胁反应迅速。他们在组织机构中拥有足够的资源，独立运作；百夫长们平 时各尽其责，只是偶尔进行汇报，但他们只处于一定的限度范围内而不能越 雷池一步。自然，首领也深信这些百夫长——还有他们的部属——是在为整 个团体的利益而奋斗的。微软的业绩证明：虽然无法做到使每位用户都满意，
然而毋庸置疑，微软拥有一位杰出的领导者，一支卓越的高层管理队伍，一 群勤奋努力的职员；他们不仅对专业技术和微机软件行业都有很深的了解，
也知道如何去赢得成功。
原则一：聘请一位对技术和经营管理都有极深造诣的总裁
许多成功的企业都归因于总裁的技术知识和商业敏锐感及其领导和管理 才能。在今日美国产业界，比尔・盖茨也许是最精明的企业家，同时也是最 被低估的经理。无论是在对软件和计算机技术的独到见解上，还是在创建并 维持一个庞大的盈利企业上，他都表现出了惊人的天赋。在过去，他曾被认 为是一个脾气暴躁喜好吵闹的人，经常对其职员横加指责（甚至大声咆哮），
但他终于随着公司的发展逐渐成熟起来。他持续不断地对新产品和业务的选 择进行引导，尤其注重关键产品的特性。不过现在他更多地依靠着几十名高 级管理人员和技术领导，他所创立的各种正式的和非正式的机制也正帮助他 指挥着微软这架庞大的机器。
盖茨其人
威廉・享利・盖茨 １９５５ 年出生于华盛顿州首府西雅图的一个富有家庭。
他的双亲都不是技术人员：父亲是一位律师，母亲是一位教师。从各方面来 看，少年盖茨和成年盖茨十分相像。他的传记作者把他描绘成“一个精力充 沛的年青人”，喜欢在椅子上晃来晃去，如同我们采访他时所见。教过他的 一位老师说他“彻头彻尾是一个淘气包”。他童年时兴趣广泛，喜欢玩各种 各样的游戏，其中有一个称为“冒险”，参加者们为控制地球竞相争斗。１
盖茨首次接触计算机是在 １９６８—１９６９ 年，当时他在私立湖滨中学读二年 级。学校有一个简单的电传打字电报机，可以限时接通一台计算机。盖茨在 学会了 ＢＡＳＩＣ 编程语言之后，又与一个十年级的电子专家保罗・艾伦合作学 会了更多的编程知识。当盖茨 １４ 岁时，就已和艾伦一起通过编写和测试计算 机程序来赚钱了。不久，在 １９７２ 年，两人创建了他们第一家公司“Ｔｒａｆ－Ｏ－
Ｄａｔａ”，并且销售一种用以记录和分析机动车辆交通数据的小型计算机。
１９７３ 年，盖茨被哈佛大学录取，而第二年，艾伦就中止了在华盛顿大学 攻读计算机科学学士的努力，离开了校园，在波士顿地区的豪尼威尔（Ｈｏｎｅｙ Ｗｅｌｌ）找到了一份工作。以下的故事是人们所津津乐道的：包括艾伦如何在 １９７４ 年注意到了《大众电子学》杂志为 ＭＩＴＳ 计算机公司的新型牛郎星微机 所做的广告，以及艾伦和盖茨又是如何利用哈佛大学的计算机设备编写 ＢＡＳＩＣ 的一个版本的。
盖茨在 １９７５ 年离开哈佛，全身心地投入到为牛郎星微机（后来为其他的 个人机）开发程序语言的工作中去。他和艾伦一起搬到了新墨西哥州的阿尔 伯克基市，和 ＭＩＴＳ 计算机公司相邻。同年，以盖茨为首，总共大约 ４０ 至 ６０ 名成员一起创办了微软公司，当时他在公司的第一个产品——微软 ＢＡＳＩＣ 的 开发中占有举足轻重的地位（参考附录 １，微软大事年表）。
青年盖茨有许多杰出的优点。他聪明，极富进取心，与他的朋友们一样。
他能高度集中注意力，把握住自己感兴趣的事物，尤其是计算机和为实际应 用编写程序。盖茨为人们所展现的计算机世界，不仅仅是追踪记录交通数据，
更为重要的是人们可以坐在桌旁运行他的软件。在个人微机时代即将来临之 际，这无疑是技能和雄心的伟大结合。
局外人士和微软的职员们对盖茨的描绘惊人相似。他被形容为一个幻想 家，不断地蓄积力量，疯狂地追求成功，凭着他对技术知识和产业动态的理 解大把地赚钱。正是盖茨的独特个性和高超技能造就了微软公司今天的业
绩。
盖茨是个不折不扣的幻想家。还是在个人计算机的早期发展中，他就清 晰地阐明了这个行业的未来发展方向。尽管经历了许多策略上的失败，他从 未放弃过实现自己梦寐以求的幻想的努力。２
这个家伙聪明得令人畏惧。但从一定意义上来说，他是独一无二的、地 地道道的利润导向型的人才。你怎样去赚钱呢？当然不应不择手段，唯利是 图，赚钱就像生活中许多美好的事物一样，是吧？如果你能赚钱，显然是一 件好事。他就像是一台知道如何去赚钱的巨型计算机（吉姆・康纳尔，Ｏｆｆｉｃｅ 产品单位的程序经理）。
他很疯狂，对产品的了解甚于任何人。每次开会时，你都会大汗淋漓，
因为他会马上注意到你的任何纰漏，并穷追不舍，非要打破沙锅问到底。他 是那么令人不可思议（戴夫・马里茨，前任 Ｗｉｎｄｏｗｓ／ＭＳ－ＤＯＳ 的测试主管）。
ＩＢＭ 曾经认为他们能把盖茨置于股掌之上任意摆布。他毕竟只是一个“黑 客”（ｈａｃｋｅｒ），不关痛痒，无足轻重。他们这次却看走了眼。这个怪杰的 降生，便是为了在人间攫取巨大的权力和最大利润；而作为一位律师的孩子，
他对合同语言知之甚详，驾轻就熟，甚至把 ＩＢＭ 那些自以为是的家伙弄得狼 狈不堪，不敌而走。３
管理者盖茨
在一次采访中，我们曾要求盖茨描述一下微软在管理产品开发方面获得 如此惊人成就的背后有什么秘诀。他开列的清单虽然包含了一些我们已经注 意到的因素，但还是给我们留下了十分深刻的印象。下面是一些从采访录中 剪辑出来的简短摘要，阐述了盖茨在管理产品开发方面遵循的主要原则，我 们在后面还会进一步涉及到。
・精明人士和小型团组 “我们一开始就采用最先进的管理办法，那就是 聘请一批了不起的人物并成立小型团组……我们最突出的优势是：优 秀的开发员总是喜欢与优秀的开发员在一起工作。”
・使大型团组的工作方式小型化的开发过程 “于是我们不得不拥有规模稍大 的团组……我们被迫在许多方面正规化。经过每一个里程碑式的重要 阶段时，我们都力争做到没有任何瑕疵，就像做项目评估工作那样。
以上所有的这些东西都与项目组的规模大小密切相关。”
・使团组之间相互依赖性减少的产品结构 “在微软，其良好的组织结构能 使相互依赖性降到最低限度，即使在开发组内部也是如此。”
・集中力量开发新产品 “公司所有的成员都在一块儿工作，只有少数例 外。这样，当你急需某人帮助时，你便可以与他碰头，当面求教……
这也是一个很重要的优势所在。”
・公司构造的软件产品，直接用于其工作机器 “我们的开发系统和目标系 统完全一致。就我所知，许多公司不这么做。”
・单一的主要开发语言 “员工们可以争论什么是最优的开发语言。但是，
一经确定，即是唯一。”
・大量投资以支持人们的工作 “我们乐意花费巨资为员工购买所需工具。
员工们都有自己的办公室。”
・公司内部使用自己设计的软件工具 “我们使用自己的软件工具，所以我 们能毫不费力地掌握它们……总的来说，我们从使用自己的软件工具 中获得了莫大的好处。”
・多人了解有关产品细节 “我们极少出现这样的情况：仅仅一个人熟悉 一个庞杂的代码，而其他人都嚷嚷：‘噢，上帝！咱们头儿是唯一能 修改这个代码的人’。”
・经理人员既创建产品又进行技术决策 “我们没有不懂技术的管理人员，
因此，去寻求技术和管理之间的平衡毫不费力。”
・迅速在技术和业务之间作出取舍 “［我们有］ 能力迅速进行这类决定。
如果其中出现纰漏，业务［产品］ 单位的经理会迅速作出反应，或者，
通过电子邮件由我来作出选择。这些都是在瞬息之间完成的。”
・一个范围广泛的消费者信息反馈圈 “大部分公司没有利用广大的消费者 对其软件产品的意见信息反馈……而微软仅在美国就拥有 ２０００ 人的 队伍，就我们的产品与消费者进行经常性的电话联系并记载发生的所 有事情。可以说，我们拥有包括市场在内的更为优质的信息反馈圈。”
・从过去项目中汲取经验教训 “我们对项目进行了大量的事后分析并查看
‘臭虫（ｂｕｇ，即错误）’产生的根源，进而考虑如何设计以减少‘臭 虫’以及怎样使用软件工具来‘捉虫’等。”
随着微软的发展壮大，盖茨遇到了许多前所未有的问题。他只有不懈地 努力，以使自己岿然屹立于这个迅速发展的公司和行业的最前沿；并且保持 对微软及其竞争对手不断膨胀的产品组合有一个细致的了解。他每天都得决 定什么该“管”，什么该“放”，十分忙碌。可以确信的是，盖茨有一些能 干的好帮手，虽然他和其他微软经理们都极力反对动不动就扩充人员。盖茨 本人只有一位私人行政助理和一位技术助理，都是在最近几年内雇用的。技 术助理常由年轻的程序经理或软件开发员兼任，一般任期一至两年。助理需 要复审产品构造思路和说明书，作会议笔录，追踪竞争对手的行动和展览会 最新的动态，并帮助盖茨跟上不同项目的进度。
微软领导层采用相当传统的管理方法，不过盖茨事必躬亲，始终保持高 度参与。他主持每年 ４ 月份和 １０ 月份的程序复查和计划会议，制定大批量生 产新产品的时间表并拟定预算的日程安排。１０ 月份的程序复查重点在于制定 ３ 年生产计划；每个部门都详细阐明计划上市的产品及其与其他产品之间的 相关关系。１０ 月份的复查结束之后，微软的营销人员（称为产品经理）在各 部门的生产计划基础之上进行销售预测。具体的预算计划就此展开了。经理 们对预测的销售额和费用支出预算进行分析，看其是否能达到公司的利润目 标。盖茨与其他领导人员根据这个分析，才决定在 ７ 月份开始的下一个财政 年度所要雇用的员工数目。盖茨不仅在所有重要的程序复查与计划会议中起 主导作用，而且对核心产品单位直接进行指导。
一般地，盖茨主要通过各项目小组成员与经理发出的电子邮件和产品进 度报表来定义战略性新产品（或者新的产品版本），并监督开发时间表的执 行情况。他每月从各项目组收到许多简短的进度报表——过去每两周一次—
—并且认真阅读。他参加许多项目的季度程序复查，有时也写写战略备忘录，
大约一年四到五次吧。（有一次我们去采访他时，他正奋笔疾书。他的助手 告诉我们，其备忘录内容大致为“我们正面临几个艰巨的技术挑战，谁能提 出解决疑难的方法，什么样的方法从战略角度来看是正确的”。）一年之中 有一到两次，他要过一个“思考周”。在这段时间内，他把自己与世隔绝，
思索一些问题，比如：怎样获得更多的用户支持？怎样使员工们更为合作团 结？五年之后产品世界会发生什么样的变化等等。盖茨试图从其时间花费上 获得最大效用，即赚得最多的美元：“我对构成公司 ８０％收入的产品有着最 深刻的了解。”他把大部分时间用在一些关键性的应用程序上，如 Ｏｆｆｉｃｅ 及其 Ｗｏｒｄ、Ｅｘｃｅｌ、Ｗｉｎｄｏｗｓ 等组成部分。他也十分关注快速发展的新领域，
如多媒体技术和联机信息产品与服务等。
项目进度报表
微软的每一种软件产品都相应地有一个项目进度报表。盖茨以及其他高 级行政管理人员（包括相关项目组的领导）每月都会接到从不同的项目组递 交的此类报告。这些报告在使高级管理人员全面掌握各项目组的项目实施状 况方面起到了关键性的作用。盖茨常常直接通过电子邮件与相关的经理人员 或开发员进行交流，并把所收集的信息用于正式的程序复查之中。项目组的 成员同时也通过这种报告来设定自己下一步的目标。盖茨是这么说的：
我拿到了所有的进度报表。现在恐怕有上百个项目正在铺开……［进 度报表］包括时间表、重要阶段日期、说明书中的任何变动，还有一些 评论，比如“嗨，我们不能再雇人了！”或者“去你的，如果这个 Ｍａｃ 的 ＯＬＥ（对象链接与嵌入）２ 的发布版还完不成的话，我们都死定了。”……
他们知道他们的报告会递交给相关项目组的领导，所以如果他们想表达 自己的意愿，这是一个很好的办法。如果他们不在进度报表中提出，那 么两个月后他们会以其他方式来说明，不过，这就会造成信息的中 断……内部各小组统统照此拷贝，这在一定程度上是小组成员意思一致 的表现。
进度报表言简意赅，并且有一套标准格式。盖茨能够迅速将其浏览一遍，
他敏锐的目光往往能轻易地找出一些破绽，如项目潜在的迟延或改变。有一 些项目和事件倍受其重视：“我把所有的东西全部扫描了一遍……看上百个 进度报表对我来说易如反掌……如果报告内容无关紧要，如关于邮件网关产 品的，并且报告中没有漏掉成串成串的重要东西，我会敲击‘删除’键把它 们删去。报表十分简练……大约有两屏……每个日期各占一行，如里程碑式 重要阶段日期、说明书编制日期、代码完成日期……有一栏专门写起始日期、
最后日期以及本次报表日期。”盖茨对时间表有无疏漏、是否砍去太多的产 品特性或有无必要改写说明书等事项尤为关心：
每个报告阶段，仅有 １０ 到 １５ 个报表吸引我的视线……［因为有的评 论］说：“我们砍去了一些产品的特性。”那么，请告诉我，剩下了一 些什么东西呢？又有的评论写道“你正落后于时间表的进度。”这类评 论都是隔靴搔痒，无济于事。员工们真正需要指明的是规模大小及速度
要求。或者当一个竞争对手在市场上发行了一个新的版本时，员工们就 必须在进度报表中注明：他们是继续保留原说明书呢，抑或加以修改使 其与新的时间表一致。这才是至关重要的……有时候马上就会有一些事 情跳出来，比如说，这次他们修改日期吗？……当你在阅读开发评论、
程序管理评论、测试评论、营销评论时，你会发现，虽然通常它们只有 三四句话，有时候，也会出现滔滔不绝的长篇大论。你对这些报告都有 了个大致印象后，便会禁不住信口开河，发出一个邮件说：“得了，我 让你谈一下有关拖放操作的事儿，你怎么一句也没有写上去。”或者“难 道我们不需要这玩意儿吗？我们没有答应把这东西给惠普（ＨＰ）吗？
ＲＩＳＣ 版本怎么样了？你怎么什么都没有提！”……值得庆幸的是，不止 我一个人在这些问题上明察秋毫，判断无误，另外有一批员工也深谙此 道。
程序复查
大约每过三个月，微软就召开各项目的程序复查会议。这些会议一般延 续两个小时，盖茨与其他高级管理人员通常都会参加。项目组一般从各职能 领域派遣一至两个关键人员为代表列席会议，有程序管理组（专门负责编制 产品说明书），软件开发组（编写计算机代码），软件测试组（测试代码），
产品管理组（产品策划及营销），用户培训组（准备产品文档）。盖茨告诉 我们，他所关注的问题类型与进展报表如出一辙：
你会关心项目进展是否顺利，因为这是一个基本问题。你会想知道 员工们是否团结互助……这也很重要。如果他们添加了一些东西，将会 使生产速度放慢，你就得干预，“你得给我保证速度不会下降 １０ 倍”。……
如果有些产品完工比
他们想象的时间要长，你就得考虑，是因为他们不了解有关的产品 设计吗？
……你必须仔细询问很多问题使自己清楚我们对正在做的事情是否 真正成竹在胸。你必须留心倾听项目实行过程中冒出来的好点子，兴许 它会将整个说明书的面貌彻底改造一番
……他们能否将突然闪现的灵感捕捉并使之升华？他们与其他小组 的关系处理得如何？
……我认为小组之间应该共享代码。我常有意向他们灌输这一意 识。不仅在相关小组之间应该代码共享，毫无关联的其他小组也应当如 此。如果他们提出，相互依赖会制造出大量的“臭虫”或使速度大为降 低；或者他们从未能够及时从另一小组拿到代码，那就有必要摆到桌面 上进行讨论……
如果市场环境改变了，我会让他们修改说明书，那么他们及时从我 这儿得到指示就显得十分重要。你一旦拥有充足的信息资料，你就可以 直截了当地对员工说，他们干得很出色，或者成绩平平，这样，你便营 造出了一个良好的工作氛围。有时候，在开会之前你就已经心里有数 了，因为给我的有关项目的电子邮件实在是很多很多。
史蒂文・斯诺夫斯基，是盖茨 １９９３ 年与 １９９４ 年的技术助理（现在是 Ｏｆｆｉｃｅ 的组程序经理）。他极力贬低程序复查的戏剧性效果，声称高级管理 人员通常都事先知道问题所在并且与项目成员们一起先开一个预备会议：“程 序复查唯一的作用，是让头儿们确信，大家众志成城，行动一致。他们以前 经常为麦克・梅普尔斯或史蒂夫・鲍尔莫或其他高级副总裁做此工作，然后 再为比尔精心准备，这决非突如其来。”但是盖茨极力使他的问题搅和在一 块儿。他有时会思考一些极为明显的事情，不过想得更为深入一些：“我提 出的大约有一半问题经常使人莫名其妙；但是，另一半往往相当清楚易懂。
我会提醒员工什么样的标准检查程序是真正重要的，什么样的系统配置是真 正有价值的。”在一些情况下，他也会播洒及时雨，给予相应的帮助：
在我的职位上，我实际能够控制些什么了呢？我有一批核心开发 员，在我转移到某项目视察时，帮助我检查算法［一种数学上或程序上 的方法，通过计算机代码完成特定任务］，核实代码或进行实际操作。
一个项目如果看起来岌岌可危，你就会考虑独立地复查一下代码。在过 去，我会对他们说：“嗨，给我源代码，我拿回家看去。”现在我不这 么做了。我会命令手下的 Ｄ１４ 或 Ｄ１５（公司高级技术职衔）：“给我回 去好好钻研一下，回头再告诉我。”或者，“选派更多人员，务必解决 这个问题。”他们经常就关于砍掉哪一块特性提出一些建议……因为他 们了解所有的相互依赖关系以及各部分是如何互相配合成为一体的。
盖茨也坦率地承认，他发现取消一些陷入困境的项目并不容易：
一般来说，我们不会轻易取消项目。但是，软件市场时时风起云涌，
变幻莫测，我们不得不作出相应的调整。这属于技术——业务复合型决 策。最著名的例子是我们的数据库产品。第一版本的 Ｗｉｎｄｏｗｓ 数据库并 不完善……你可以说我们是另起炉灶。有人说我们仅仅重写了其中的 ８０％，这种说法未免太过极端。而 Ｗｉｎｄｏｗｓ 的 Ｗｏｒｄ 倒不愧是一个典型。
一波三折，屡遭挫折，迟迟无法上市，成为微软发展史上的一段趣事。
在复查说明书时，盖茨把重点放在一些关键问题上。他想知道一个新产 品能引起多大轰动效应，是否能与其他微软产品兼容，他也关注质量问题（主 要以“臭虫”数目来定义）。盖茨通过对这三大问题的分析来决定是否推出 一个新产品。另外一些正越来越引起盖茨关心的问题便是小组之间的相互合 作与构件共享以及生产是否落后于时间表的进度等。对于独立性很强的产品 组们来说，这种互相依赖实非易事，而且越来越令人挠头，因为许多微软产 品可能每年都要推向市场（例如，Ｗｉｎｄｏｗｓ ９５ 和 Ｏｆｆｉｃｅ ９５）；任何项目的 失控延迟都可能导致尴尬的结局——产品重新命名。
盖茨喜欢运筹帷幄，确定总体方向，让各产品组自己解决微观问题。令 人们拍案称奇的是，他能迅速发现各小组正费尽心机设法解决的产品技术细 节问题，而不论此项目课题是属于其所擅长的专业领域（如 Ｗｏｒｄ、ＢＡＳＩＣ、
Ｅｘｃｅｌ）之内还是超出他个人经验之外（如 ＷｉｎｄｏｗｓＮＴ）。麦克・康特，以前 是 Ｅｘｃｅｌ 的产品和程序经理，现在在 Ｏｆｆｉｃｅ 工作，向我们回忆起大忙人盖茨 是如何在几分钟内就发现新特性的缺陷的。而 Ｅｘｃｅｌ 组，虽然知道有缺陷存
在但未曾告诉盖茨，已花费了整整一个月的时间来寻找问题症结所在：
在 Ｅｘｃｅｌ３．０ 中我们确立了一个重要概念，即“次最小重算”。所谓 最小重算，是指你只需要重算相关的数值；当用户改动某数值时，软件 只计算变动的单元格，而不必把全部工作表重新计算一遍。这是重算速 度上的一个重大突破。而 Ｅｘｃｅｌ３．０ 的次最小重算功能，在中间变量计 算结果未改变时，甚至允许不重算相关的数值……我们把这些情况汇报 给比尔，而……［他］说：“这种情况是怎么回事？还有这个，嗯，那个 呢？”克里斯・彼得斯，当时是我们的开发经理，说：“哎呀，真是有 意思。一个月的潜心思考，我们才发现这三个问题。我们真是好生惭 愧。”可以说，盖茨非常善于发现技术问题。
即使是老练的职员和经理也会因准备与盖茨的正面交锋而忐忑不安。克 里斯・彼得斯，现任 Ｏｆｆｉｃｅ 产品单位的副总裁，在他名噪一时的 １９９０ 年的 录像“软件推出”中给予他的同事们如下建议：
你在做什么，为什么这么做，都必须向比尔交待清楚；你从不应该 隐瞒什么，因为他很精明，能洞察一切。但是，你必须从容不迫，信心 坚定，你必须顶撞他，毫不示弱。我所能给你们的唯一建议便是在开会 的时候，带上你最最拔尖的开发员，他们能不加思索源源不断地旁征博 引，把盖茨埋葬在不容置辩的铮铮事实之中……永远不要仓促上阵，毫 无准备。但是必须要学会说“不”。这样，盖茨便会很尊重你的意见。
他很清楚得及时推出产品。我认为我们最后要说的是……对微软来说，
了解延迟推出一个产品将付出什么代价十分有用，所以，我们最好不要 做这个特性了。我想最终我们还是会制作那个特性的。但，这就是他成 其为比尔・盖茨的原因。
控制新产品开发
至于什么样的事情该放手不管，什么样的事情应牢牢控制，盖茨是这么 说的：
嗯，最初，我不让任何人编写代码。我拿走所有的其他人写的 ＢＡＳＩＣ 语句，自己再重写一遍，因为我不喜欢他们编程的方式。这其中是颇需 要技巧的，我不情愿让任何人介入其中。但是我们马上就有了新产品像 ＦＯＲＴＲＡＮ 和 ＣＯＢＯＬ。在这里，我只是确定一下软件说明书是否设计正确，
我们是否遵循基本算法等……我从来不会让别人来确立待开发产品的 总体思路。我不会说：“我不知道这儿有一个新产品组，没有人告诉我 这些。”对于一个软件公司的总裁来说，这是一个很好的控制公司的手 段，也是我现在唯一能真正把握的东西。
盖茨的一个重要角色是根据他对未来发展方向的展望，包括可能的竞争 对手的行动，来定义公司全部产品系列，并在技术和业务之间作出取舍决策。
一个例子就是盖茨在 ５ 年时间内，推进 Ｅｘｃｅｌ 与其他组采用 ＶｉｓｕａｌＢａｓｉｃ 为 通用的“宏语言”（宏是一组特殊的命令，由用户自行处理，使许多复杂的
操作仅需一两个快捷键就能激活。标准宏语言的使用，能使用户用同一种方 式来定制各种各样的微软产品）。盖茨也促使各小组采用对象链接与嵌入
（ＯＬＥ）标准使构件共享更为便利。
盖茨也积极参加关键项目的开发。他确定现有产品，并制定其未来发展 方向。Ｗｏｒｄ 的开发经理爱德・弗莱斯回忆道：
我们与比尔之间互相影响，互相启发，尤其是在产品开发的早期阶 段，我们一起仔细审查说明书并决定产品特性……比尔几个星期前就到 我们小组来了，我们围着他向他展示 Ｗｏｒｄ 的各种资源。上周是他的“思 考周”，其间，他给克里斯・彼得斯发了大约 １０ 个电子邮件，邮件中 说：“噢，这个 Ｗｏｒｄ 版本中的某些东西我不太赞赏。你得给我好好考 虑，怎么样使我们所有产品的拼写检查功能更为成熟。还有，Ｗｏｒｄ 和 Ｈｅｌｐ 等产品怎么样才能合成为一种类型。”比尔花了很多时间定义我们 产品的未来方向，他也对我们现在的进程提出批评……他经常勾画出 ５ 年后产品的概貌。我们只得在遵循其指示与满足用户需求两者之间努力 寻求平衡，寻找一个折衷方案……这便经常造成矛盾冲突。
虽然微软的经理与开发员崇尚一种高度独立的企业文化，盖茨却习惯于 事必躬亲，大包大揽，极少委托他人。据斯诺夫斯基说：“每样事情都极为 琐碎，但都各有其独到之处。”
在推进小组们采用 Ｖｉｓｕａｌ Ｂａｓｉｃ 与 ＯＬＥ 的同时，盖茨还要求在各产品中 增加一些关键的功能。包括 Ｅｘｃｅｌ 的分级特性，Ｗｏｒｄ 的表格和拖放操作以及 Ｖｉｓｕａｌ Ｂａｓｉｃ 中的自定义控制项（称为 ＶＢＸｓ）。盖茨也曾经坚持要求程序经 理与开发员采用 Ｖｉｓｕａｌ Ｂａｓｉｃ 来编写原型和特殊的软件程序；一些小组发现 Ｖｉｓｕａｌ Ｂａｓｉｃ 语言由于技术上的原因不太适用，便予以抵制，他们成功了。
公司副总裁史蒂夫・鲍尔莫在盖茨的默许下，也曾授权微软的小组们采用 Ｗｉｎｄｏｗｓ ＮＴ 的测试版而不是 Ｗｉｎｄｏｗｓ 或 ＯＳ／２ 作为其操作系统。另外，盖茨 还通知微软的商业工具小组（一项重要工作是构造语言编译器），不仅仅要 面向消费大众，还得增加特性以支持内部的软件开发员。偶尔，盖茨会中止 因为延误或出故障而难于为继的项目，比如 Ｗｉｎｄｏｗｓ 的 Ｏｍｅｇａ 数据库产品（后 来演进成为 Ａｃｃｅｓｓ）。他还把版本有异但从事同种类型功能的项目合而为 一，如 Ｗｏｒｄ、Ｅｘｃｅｌ 与 Ｍａｉｌ 中的文本处理代码。
人们屡次三番与盖茨进行争论；就克里斯・彼得斯的观察，只有这样才 能获得盖茨的尊重。但是人们必须有显明的技术根据和数据事实作为后盾。
那些基于私人的或感情上的原因，或者是内部政治而建立起来的观点，对盖 茨及其他关键人物丝毫不起作用。特别地，对于盖茨来说，需要用新型的智 力模式（其观点必须颇有见地，其世界观则需与众不同）来改变他冥顾不化 的头脑，引起其共鸣。史蒂文・斯诺夫斯基解释说：“如果他一意孤行，执 意不肯接受你的观点，你一遍又一遍地重复只会白费力气。你必须另辟蹊径 来击倒他。”
原则二：围绕产品市场，超越经营职能，灵活地组织和管理
比尔・盖茨向我们强凋，微软以产品为中心来组织管理公司。我们发现，
在很大程度上，这句话是正确的，不过，微软也非常重视其技术与专项功能
（虽然与前者有重叠交叉）。员工们在多功能小组（根据产品组织而成）内 工作，另有一些机制将这些产品小组联为一体。除了部门和产品组这两大结 构外，微软另有两类组织机构。一类是较为正式的，组成了微软的管理体系。
另一类属于非正式组织，由一些被尊称为“智囊”的管理人员和一群执行特 殊任务或项目的技术人员与经理组成，直接听命于盖茨或其他高级领导。
组织和过程演变
微软通过不断地摸索与试错，经过漫长的阶段，终于形成了今天的组织 结构和产品开发过程。在 ２０ 世纪 ８０ 年代早期，微软成立了一个名为“最终 用户组”的机构来开发应用程序，这使系统与应用组截然分开，各自循着不 同的轨迹独立发展。公司在发展过程中，始终为改善其专项功能，尤其是软 件测试，而奋斗不息着。公司也不得不克服许多难题，例如，产品小组缺乏 中心领导，质量控制与项目管理方面破绽百出，无一可取。与其他许多公司 一样，一些具有历史意义的转折点与关键人物构成了公司的发展历史（见表 １．１）。
第一个转折点是 １９８４ 年成立测试组的决定。测试组与开发部门的分离，
使得对开发员的工作进行独立的检验成为可能。第二个转折点大约在同一时 间发生。程序管理开始区别于产品管理与软件开发而成为一个独立的职能。
第三个转折，则是由 ８０ 年代中期一系列迟延产品和“臭虫”引起的。这导致 公司上下意见趋于一致，认为应当严格进行质量控制与项目管理。微软小组 们现在已形成一种制度，即在事后分析书面报告中记录项目完成的心得体 会。这反映了一个越来越为人们普遍接受的观点，那就是通过“向错误学习”，
可以把工作干得更为出色。第四个转折点，是 １９８８ 年 ＩＢＭ 的麦克・梅普尔斯 来到微软，在他的提议下，创建了小型业务单位，这使操作组增加了核心领 导，并且更易于管理。
第五个关键事件是 １９８９ 年的“休假会”。高级经理与开发员致力于减少 故障，并提出多种方案，以帮助微软小组们在软件开发与
表 １．１ 微软组织演变进程中的关键事件
─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─
１９８４ 在 各 个 部 门 内 部 建 立 独 立 的 测 试 组 。 Ｍａｃｉｎｔｏｓｈ 电 脑 用 的 Ｍｕｌｔｉｐｌａｎ１．０６ 电子表格软件产品回收。
建立除测试组之外的专项职能如程序管理和产品管理机构。
１９８６ 建立事后分析文档，鉴别产品质量与项目管理方面的问题，并提出 解决方案。
１９８７ Ｍａｃｉｎｔｏｓｈ 电脑用的 Ｗｏｒｄ ３．０ 文字处理器产品回收。
１９８８ ＩＢＭ 的麦克・梅普尔斯就职于微软，在系统部门和应用部门为每个 产品组建立独立的业务单位。
在 Ｐｕｂｌｉｓｈｅｒ１．０ 项目中采用里程碑方案。
１９８９ ５ 月份的“休假会”与 １１ 月份的“零缺陷代码”备忘录突出了“每 日构造”的重要性。
１９９０ Ｅｘｃｅｌ３．０ 项目（ １９８９ — １９９０ ）顺利完成，仅推迟 １１ 天。
采用同步一稳定过程中的关键要素（里程碑和每日构造）。
１９９２ 聚合性总裁办公室成立。
把系统与应用归于全球产品集团之下，由执行副总裁麦克・梅普尔 斯领导
１９９３ 集中营销小组（产品经理）成立独立的部门，产品策划者除外，将 业务单位改名为产品单位。
建立 Ｏｆｆｉｃｅ 产品单位，由副总裁克里斯・彼得斯领导。
１９９５ 成立平台集团，由集团副总裁保罗・马里茨领导，成立应用与内容 集团，由集团副总裁内森・梅尔沃德和皮特・赫金斯领导。
质量控制方面更为系统化。一种思路是把一个项目分解为很多个子项目或里 程碑，１９８８ 年 Ｐｕｂｌｉｓｈｅｒ１．０ 就采用了这种方法从而顺利地完成了。另一种 思路便是产品的每日构造，许多组都实行了这种方案但未执行“零缺陷”目 标。这些关键性思路都已成为同步一稳定过程中的精华部分。Ｅｘｃｅｌ３．０（１９８９ 和 １９９０ 年开发）是第一个采用这些先进技术的规模宏伟、营业额颇丰的微软 产品，它的问世仅仅推迟了 １１ 天。
第六个关键事件便是 １９９２ 年建立四人总裁办公室，并由麦克・梅普尔斯 全权负责所有的产品开发。这使计划表一直难以预测的操作系统组更为规范 化。第七，则是 １９９３ 年的重新改组。大多数营销组的产品经理们被集中起来 组成一个独立的部门，而一些产品策划者仍继续留在产品开发组里。微软还 把业务单位改名为“产品单位”来反映这种变动。此外，微软成立了 Ｏｆｆｉｃｅ 产品单位。这些变化使营销和产品策划及开发脱离，有利于在微软的核心应 用软件产品之间实现构件共享。
乔恩・薛利是麻省理工大学的中途辍学生，曾任坦迪（Ｔａｎｄｙ）公司（销 售“无线电小屋”手提电脑）的行政主管。１９８３ 年，盖茨聘任他为微软总裁。
他把软件开发分为两部门：操作系统部门以及应用软件部门。盖茨曾经规定 开发员必须向高一级的开发员而不是总经理负责，每一个开发员都必须向他 汇报工作，因为他是公司的最高开发员。盖茨也一手控制了其他的重要领域，
如营销等。现在，微软急剧扩大，产品大大增加，这种规定已是过时了。薛 利认为盖茨管得太多，公司整顿势在必然。举个例子，盖茨喜欢把开发员东 抽西调，今天来这个小组，明天去那个小组，疲于奔命。不仅如此，盖茨有
时心血来潮，随意改动说明书，虽属“神来之笔”，却因无半分预兆，令手 下人员无所适从。薛利认为盖茨应在高抽象层面上确定产品，引导开发组织 的战略性发展方向，而不应陷在项目的细枝末节中无法脱身。４盖茨同意对公 司进行大整顿，主动减轻自己的工作量，集中精力进行应用软件的监督。他 任命史蒂夫・鲍尔莫为系统部门的主管。盖茨对这一次公司组织的大整顿作 了如下描述：
在麦克・梅普尔斯来公司以前……所有的开发小组以我为中心展开 工作。当时盛行这样一种理论，即开发员不应被迫给那种一天写不了上 千行程序的人工作；否则，对于开发员来说，这是一种侮辱。所以所有 的开发管理人员全是清一色的软件开发者，每一个管理环节都安排了能 够编制程序的开发员。现在这个传统被打破了。我把软件开发分为系统 部门与应用部门，并且让史蒂夫负责［系统部门］ 。史蒂夫不是技术人 员，但他为人十分精细，品格高尚。人们都很信服他出众的才华。当进 行一项技术决策时，他总能知人善任，调度有方。他所选择的即使不是 经理人员，也是广为人们所爱戴的人士。所以我们每一回都能圆满地完 成任务。
１９８４ 年，微软决定把测试组从开发部门中分离出来。因为它的许多软件 产品都出现了“臭虫”，由此激起许多采用微软操作系统的 ＰＣ 机制造商的极 大不满（微软把这些公司称为原始设备制造商，简称为 ＯＥＭ）。比如，１９８１ 年与 ＩＢＭ ＰＣ 机一起推出的 ＢＡＳＩＣ 版本就比较粗糙，用户在用“．１”或者其他 数字除以 １０ 时，就会出错。这次事故后，ＩＢＭ 坚持要求微软改善其软件开发 和质量控制的过程。在 ２０ 世纪 ８０ 年代早期微软还有其他的未向世人公开的 问题。比如， ＦＯＲＴＲＡＮ（一种技术性的程序设计语言）上就有一种腐蚀数据 的“臭虫”。５个人用户也开始纷纷进行投诉，说他们从零售商店买回家的微 软应用软件有许多质量问题。
山雨欲来风满楼。微软的高级经理人员终于醒悟，发觉很有必要引进更 好的内部测试与质量控制的方法。但是，许多人坚持反对，包括大多数程序 设计师甚至一些高级经理（如史蒂夫・鲍尔莫）。他们认为在高校学生、秘 书或者外界订约人的协助下，开发员可以自己测试产品。在 １９８４ 年 １ 月推出 Ｍａｃｉｎｔｏｓｈ 多元计划（Ｍｕｌｔｉｐｌａｎ）电子表格软件的最新版本之前，微软就曾 特地请 Ａｒｔｈｕｒ Ａｎｄｅｒｓｅｎ 咨询公司进行测试。但外面的公司一般没有能力也 不太可能全面地精确地测试一些较为复杂的软件产品。结果，一种相当厉害 的破坏数据的“臭虫”迫使微软为它的 ２ 万名 Ｍａｃ 多元计划电子表格软件的 买主免费提供其更新的版本，代价为每个版本 １０ 美元，一共花了 ２０ 万美元，
６可谓损失惨重。
痛定思痛，微软的经理们得出结论说，如果再不成立独立的测试组，他 们就不可能达到更高的质量标准。ＩＢＭ 与其他有着更为长远更为成功的软件 开发历史的公司便是效法的榜样。戴夫・穆尔，微软的开发部门主管，回忆 道：“我们清楚我们不能再让开发部门自己来测试了。我们需要有一个单独 的小组来设计测试，运行测试，并把测试结果信息反馈给开发部门。这是一 个伟大的转折点。”微软未曾照搬 ＩＢＭ 的方法，即组织一大群人检查所有的 软件项——从说明文档到代码及测试计划——或者要求行政管理人员在各开
发阶段“停止活动”。这种官僚制度在大型电脑和容错性应用软件的生产中 较为普遍，但在 ＰＣ 机世界中却很少采用。微软也不像 ＩＢＭ 与其他的一些公司
（包括日本的软件制造厂）那样对关于开发员与测试员如何度过他们的时间 这类细节问题进行监控。微软有选择地采用一些看起来比较先进的技术，如 独立的测试小组、自动测试以及为新手与关键性构件进行代码复查等。他们 并不照搬 ＩＢＭ 的经验，而是引进，使之成为微软特色。（穆尔指出：“ＩＢＭ 经验并不适用于微软。”）
但是，穆尔接着说：“我们做错了。”自从微软在 １９８４ 年与 １９８６ 年之 间扩大测试组以后，开发员“开始变懒了”，认为他们能够“把代码扔在一 边等着测试”，他们忘了唯有开发员自己才能发现更多的错误，只有他们自 己才能防患于未然，首先阻止错误的发生。在此同时，微软历史上第二次大 灾难降临了。原定于 １９８６ 年 ７ 月与公众见面的 Ｍａｃｉｎｔｏｓｈ 版 Ｗｏｒｄ３．０，千呼 万唤方于 １９８７ 年 ２ 月问世，而且先天不足，里面竟然有大约 ７００ 多处错误—
—有的甚至破坏数据，摧毁程序。一下子微软便名声扫地了。公司不得不在 初始发布后的两个月内免费为消费者提供升级版本，其费用超过了 １００ 万美 元。７
至今，一个连公司内部的怀疑论者都深信不疑的事实是，微软在产品开 发管理方面困难重重，举步维艰。为重获消费者欢心，各小组必须更为规范 化。盖茨亲自掌管应用软件部门，但一些主要项目却是一团乱麻。除 Ｅｘｃｅｌ 外，Ｗｉｎｄｏｗｓ 的其他新应用软件开发毫无进展。而一个数据库程序（别称 Ｏｍｅｇａ 项目，以后演化为 Ａｃｃｅｓｓ）和一个 Ｗｉｄｎｏｗｓ 的项目管理应用软件严重受挫。
Ｏｐｕｓ 项目，后来更名为 Ｗｏｒｄ ｆｏｒ Ｗｉｎｄｏｗｓ，激发起工作人员的灵感，杜 撰了一个现在相当流行的新名词“无穷错误”。这个词描绘的是这样一种情 形：测试员寻找错误的速度远远快于开发员修正错误的速度，而每次错误修正 以后，又会产生新的错误。如此循环往复，错误无穷，使时间表和最终产品 上市日期难以确定。这种情况的出现，有时是因为暑假实习生在编写完代码 后未完成测试便返回大学，有时候，则由于开发员被从一个特性或项目抽调 到另一个，所以来不及完成测试工作。在微软曾经经历过的“迟缓臃肿”集 成期和测试阶段，开发员只能求助于旧代码。但遗憾的是，代码的具体内容 大多已被淡忘，或者其作者已不知去向。在重写代码以修改数不胜数的错误 中，开发员常常会重蹈旧辙，新一代的“臭虫”又大肆猖狂起来。８微软的测 试主管罗格・舍曼，向我们回忆微软历史上这一段黯然无光的日子：
人们得到消息说他们实际上把事情弄得一团糟……他们像驾着一辆 飞驰的赛车，不时地撞到墙上，不过现在他们总算知道墙在哪儿了……
人们认识到不管程序是多么地充满想象力或创造力，如果不实用，也只 能忍痛割爱。他们学会从各个角度全面观察问题并着重分析外部因素。
他们知道了他们所编写的代码必须是可测试的，并且其测试资源一定是 有限度的……他们得编写稳定性很强的代码。可以说，从 Ｏｍｅｇａ 和 Ｏｐｕｓ 的反面教训中，人们获益非浅，并逐渐走向里程碑式过程。我认为他们 从 Ａｃｃｅｓｓ 而不是 Ｗｏｒｄ 的教训中学到了更多的东西。“臭虫”数据库是 如此的硕大无比，以至于几乎不可能存放在一个服务器中。而“活性臭 虫”多如牛毛，使测试小组几乎无事可干：“急什么？开发部门必须处 理完 ２ 年的积压待办事项才能赶上咱们现在的进度。”测试员几乎把全
部时间都放在开发自动化工具上。终于，有人得出结论，说所谓的出品 时间统统都是不现实的，项目也凌乱不堪，我们永远不可能及时推出产 品。这大概意味着所有产品的定义……也是虚假的。开发员不得不专注 于一小部分产品使之性能稳定……他们削减了许多开发计划，转而务 实，力求产品具有稳定的代码基础并且可能继续开发。
盖茨招贤纳士，决定到公司外务色更多的管理型人才，以使项目不再失 控。求贤若渴则英才群集。１９８８ 年，在 ＩＢＭ 服务 ２３ 年之久，领导其软件战 略和业务评估工作的麦克・梅普尔斯投入微软门下。他还是开发 ＯＳ／２ 系统和 Ｐｒｅｓｅｎｔａｔｉｏｎ 管理器（ＩＢＭ ＰＣ 机的早期图形界面产品）的中心人物。９具有 讽刺意味的是，微软员工们经常对 ＩＢＭ 的一些现象冷嘲热讽。比如，ＩＢＭ 聘 用太多的非熟练开发员充任程序员（微软员工戏称之为“蠢驴编程”），开 发过程过于连贯且封闭等。１０微软经理们十分自信地认为微软集中几百个高 级开发员所取得的成就 ＩＢＭ 得汇合成千上万个员工才可能完成。不过，梅普 尔斯看起来与众不同，很有天份，而且盖茨希望开发过程安排更为合理，使 微软能有效地构造、推出产品并控制其质量。（所以梅普尔斯理所当然地被 重用了。） １９８９ 年的一份重要备忘录总结了五月份“休假会”以来的讨论
（由戴夫・穆尔组织），使各产品小组勇于采取正确的行动。这份名为“零 缺陷代码”的备忘录，由 Ｗｏｒｄ 组的一位开发经理克里斯・梅森撰写，主要记 录了公司现状及即将采用的新开发过程。
在操作系统领域，微软的 Ｗｉｎｄｏｗｓ 同样步履艰难。就如同盖茨的传记作 者在 １９９０ 年 Ｗｉｎｄｏｗｓ 的第三个版本问世以后所观察到的那样，产品依然显得 粗制滥造：“又一次，微软的测试者们未曾根除问题，留下了无穷后患。比 如说，无法将程序安装于某一类型的机器上，网络老是出错，鼠标无法使用，
一种第三方磁盘管理软件的数据被破坏，还有普通的假信号收集和文档错 误……软件行业中流传着这么一则笑话，说微软产品直至第三版本才开始进 行β测试。”１１
盖茨及其他微软员工还有另外的隐忧。股票期权已成为公司资金来源的 一个不可或缺的组成部分，但是经常性的产品迟延上市，使微软股票价格狂 跌不止，回升乏力。产品的迟延与反复也使用户，包括 ＯＥＭ 与零售商在内，
都疑惧不安，大失所望。有一位股东甚至因微软未能及时推出 Ｗｏｒｄ（该产品 占微软总销售额的 ２０％）而对微软起诉，欲与之对簿公堂。最后，公司在 １９９０ 年耗费 １５０ 万美元才了结此案。（该案件控告微软经理人员故意隐匿迟延交 货的消息。）至于数据库项目，当梅普尔斯 １９８８ 年到任时，原假定 ３ 个月即 告完成。而在一年半以后，他与盖茨取消了这个项目。１２
微软备忘录 送达：应用软件开发员和测试员
作者：克里斯・梅森 日期：８９／６／２０ 主题：零缺陷代码
主管：麦克・梅普尔斯，史蒂夫・鲍尔莫，应用业务单位经理和部门领导在 ５ 月 １２ 日和 １３ 日，应用软件开发部的经理们与他们的项目领导、麦克・梅普尔斯以及 其他的应用和语言的代表们一起开展了“休假会”活动。我的讨论小组对零缺陷
编写代码的技巧进行了深入调查与研究。这个备忘录就记载了我们大家所达成的 共识……导致我们产品错误越来越多的原因是多方面的，不知诸位注意到了没 有，事实上，我们的产品正越来越趋于复杂化，但我们并未曾相应地改变我们的 经营管理方法……列举出一大堆问题只是为了让大家更清楚地看到，是我们现行 的管理制度，而不是我们的员工，导致这一系列问题的发生……我们的时间表设 计和长期以来形成的企业文化鼓励我们花最少的时间来完成一项特性，从不要求 精益求精。只要它能被很好地演示，我们就觉得可以了，所有的人也都这么认为。
于是这项特性就算是按照计划圆满完成。几个月以后“臭虫”不可避免地出现了，
而我们却认定它与原来的工作毫无关联……当不能按时完成时间表规定的任务 时，我们便想走终南捷径……产品的日趋复杂怎么会成为培育“臭虫”的温床呢？
许多人也许会大惑不解。很简单，因为我们不懂得怎么样协调各部分来进行新产 品的生产，或者修改旧产品……我真正的意思是：你们的目标应该是每天生产那 种能产业化的、易于推出的产品……人无完人，人类自身的缺点都无法克服，又 怎么能强求代码中没有故障呢？当出现“臭虫”以后，你必须仔细分析并立即着 手解决……我们每天主要的工作就是编写代码，而出现“臭虫”就意味我们努力 的失败。［下面是另加的斜体字］成百成千的公司和个人用户都依赖于我们的产 品：“臭虫”将会使他们蒙受时间与金钱上的巨大损失，可以想象，电脑病毒悄 悄地在电子表格、数据库或者文字处理器中蔓延时，将会有多少家公司被迫停业！
所以，我们必须开始更加慎重地处理故障问题。
应用和系统部门不断出现的问题，为梅普尔斯改革方案的推出和贯彻创 造了一个极为有利的环境。特别地，他要求项目小组跟踪领先市场的竞争对 手及产品，如 ＷｏｒｄＰｅｒｆｅｃｔ、Ｌｏｔｕｓ１－２－３、哈佛 Ｇｒａｐｈｉｃｓ。他还要求每个小 组对软件开发、测试和项目管理的过程进行定义并且精心改进。在与盖茨讨 论之后，梅普尔斯把应用部门分成五个业务单位：Ｏｆｆｉｃｅ，分析（Ｅｘｃｅｌ），
图形（ＰｏｗｅｒＰｏｉｎｔ），数据访问（Ｄａｔａ Ａｃｃｅｓｓ）和 Ｅｎｔｒｙ（Ｗｏｒｋｓ）。这些 业务单位现在都已成为自负盈亏的盈利中心——能独立支配各种资源来为程 序管理、开发、测试、营销（产品管理和产品策划）和用户培训服务——与 ＩＢＭ 在 １９８１ 年推出最初 ＰＣ 机时采用的业务单位形式十分相似。当时，ＩＢＭ 独立业务单位的实行，获得了巨大的成功。梅普尔斯在为 ＩＢＭ 业务单位服务 时便与盖茨等一见如故。后来他回忆起他对微软重组的影响时说：
这实在是很有趣。当我初来乍到时，我参加所谓的资源计划会议。
开发、营销、程序管理还有测试部门的头头们都来了，他们对项目进行 了详细的审查。每个星期每个项目都会有变动；有的项目已经迟延了 １８ 个月，但还想将其计划完成日期往后推迟，这时他们会要求说：“我们 需要更多的测试员。”于是我们就从别的项目中抽调一些测试员过来。
第二周，我又召开资源计划会议。上周人员被抽走的小组陷入了窘境，
不得不要求增援，我们只好再次进行人员调动。公司内部员工经常被莫 名其妙地东抽西调；人们从来不隶属于一个固定项目，这便造成了一种 极为混乱的局面。于是，我们决定构造业务单位。从表面上看，它使人 员自由流动所产生的好处——高效率——丧失殆尽。比如，Ｗｏｒｄ 的测试 小组成员固定不变，即使身边没有需要测试的软件，也不予外借。事实 上，业务单位的建立，使得资源库能够保持其连续性和稳定性，人们可
以从容安排各项计划。它也给员工更加广泛的权利与责任，使得一大批 管理人才脱颖而出。它使公司在制定其发展战略时更加注意面向用户并 跟紧其竞争对手。总之，微软现在的组织机构就是以小型业务单位为基 础构建起来的。
微软一直沿用这种基本的组织结构，但也有一定改进。１９９２ 年，盖茨把 史蒂夫・鲍尔莫调离操作系统部门，转而担任销售和支持集团负责人。盖茨 还创建了一个不断扩大的全球产品集团，由麦克・梅普尔斯对应用和系统两 大领域的产品开发进行监控。这个任命使梅普尔斯有机会接触并驾驭操作系 统组，直至 １９９５ 年他辞职为止。而自梅普尔斯卸任以后，应用与操作系统又 再一次分道扬镳。１９９３ 年，微软对营销工作渐渐重视起来，建立了 Ｏｆｆｉｃｅ 产品单位。此外，微软又任命了关键职能领域如开发、测试，程序管理以及 用户培训的负责人；自 １９９４ 年以来，这些职能组都必须向产品开发的总负责 人汇报工作。各负责人并不直接监督项目的实施，也没有明确的责任分工。
他们的主要工作是帮助各小组总结并推广最佳经验。盖茨对公司组织的增减 变动作了如下说明：
这只是一种取舍关系，所有的组织建设都属于取舍关系。它优化了 产品制造的团体精神，我们会问：如何处理我们的产品？如何取舍来制 造这个产品？我们推出产品了吗？产品。顺利通过复检了吗？所以，渐 渐地，专门化的观念被破除了。
产品组织上存在两大缺陷：其一，公司虽然在面试求才、新工具开 发、新方法运用等许多方面都有着很好的经验，但这些经验明显没有在 各领域之间得到传播和推广。如果你的小组仅有一位测试员，那么就不 可能求全责备，更不可能在考察过后诘问他：“喂，你怎么能连最新的 有关测试的书籍都没有看过呢？”所以我们给每个小组都配备了一些为 数不多但熟知测试方面最新动向的人员。其二，代码共享极为不易。虽 然存在以上缺陷，但不应以一眚掩其大德，要看到公司现行组织给自身 带来的利益要远远超过其造成的弊端。如果在过去的 ８ 年中，我们不使 用业务单位来规划公司资源，微软早就分崩离析了。
微软公司组织体系的一个明显优势是它给各小组提供了充分的自由，每 个小组就是一个相对独立的开发中心，致力于把各类产品推向特定的市场。
克里斯・彼得斯解释道：
虽然我们自以为是地把业务单位当作微型公司看待，可实际上它们 是不折不扣的产品开发中心……那里没有负责销售和财务的部门——
其相关职员早已从业务单位中调离。在业务单位内部工作的每一个人的 职责都是相同的，就是不断地为公司推出新的产品。他们不需要编制代 码，也不必进行测试或撰写说明书，他们唯一的工作就是为公司推出产 品……在这里，你最好能努力避免编制代码，如果你能够不通过编码就 赚足美元，那何乐而不为呢？
特别是由于 １９８９ 年公司“休假会”活动的刺激，微软的经理们如今特别 强调开发员与测试员要留在自己所属的小组内，至少要超过一个产品周期。
他们要求开发员努力工作，争取产品“一次到位”，并且“以质量为本”。
为了达到上述标准，微软采用了“每日构造”与多里程碑技术——这就是我 们在第四、五章内将要描述的同步—稳定过程的精华。
现行的管理结构和组织体系
微软目前位于董事会之下的最高管理层，是由 １９９２ 年首次创立的“公社 制”领导班子——总裁办公室演化而来的。在 １９９５ 年 ７ 月麦克・梅普尔斯归 隐之后，又进行了一次改组。现在包括身兼主席和总裁二个主要领导职位的 比尔・盖茨以及五个分别主管微软四大业务集团的高级经理人员：集团副总 裁内森・梅尔沃德（前任高级技术部门领导）和皮特・赫金斯（前任桌面应 用部门领导），二人共同负责新成立的应用和内容集团；集团副总裁保罗・马 里茨（以前负责产品和技术战略）领导新成立的平台集团。这两个集团构成 了微软的生产、研究以及开发的基本框架。执行副总裁史蒂夫・鲍尔莫掌管 销售和支持集团，而罗伯特・赫伯德则负责营业集团并同时担任营运主管。
部门副总裁与总经理们对这些集团领导负责。他们下面是产品单位经理，产 品单位经理直接领导职能小组经理，再下面便是微软最基层的管理干部——
产品小组组长。
如图 １．１ 所示，联机应用和内容集团下设四个部门：桌面应用部门、用 户服务部门、联机系统部门以及研究部门。平台集团也分为四个部门，分别 负责个人操作系统、业务系统、开发员与数据库系统、高级用户系统。大多 数部门自身就拥有市场营销机构，其职员由产品策划者直接担任。它们之间 共享一个中央可用性测试实验室（由 ３０—３５ 个职员组成），用以测试产品特 性及原型。销售和支持集团下设有许多独立的部门，有的负责面向全球 ＯＥＭ 的销售（这些 ＯＥＭ 主要是指 ＡＳＴ、ＤＥＣ、Ｄｅｌｌ、康柏、富士、Ｇａｔｅｗａｙ、ＩＢＭ、
ＮＥＣ、好利获得、Ｐａｃｋａｒｄ Ｂｅｌｌ、东芝、优利、Ｚｅｎｉｔｈ 等大公司），有的负 责产品支持服务（简称 ＰＳＳ），还有国际营业部门（主要面向亚洲）、高级 技术销售部门、战略企划部门（为一些大公司提供咨询及特定产品）、北美 销售部门以及欧洲销售部门。营业集团则负责财务、磁盘生产、说明手册及 相关书籍的出版（微软出版社）、信息系统和人力资源管理。
在平台集团内部，个人操作系统部门生产开发 Ｗｉｎｄｏｗｓ 和 ＭＳ－ＤＯＳ，业务 系统部门则负责 ＷｉｎｄｏｗｓＮＴ 与 ＯＬＥ（对象链接及嵌入）技术的开发，它下辖 一个独立的产品单位（负责电子邮件及个人机服务器系统）。开发员及数据 库系统部门编写程序设计语言（如 Ｖｉｓｕａｌ Ｂａｓｉｃ），并为支持工具以及数据 库产品（如 Ａｃｃｅｓｓ 和 ＦｏｘＰｒｏ）编写程序。高级用户系统部门负责交互电视 系统、宽带通讯及多媒体技术的开发。在应用和内容集团，桌面应用部下设 有 Ｏｆｆｉｃｅ 产品单位，它协调 Ｗｏｒｄ 与 Ｅｘｃｅｌ 两个产品单位并与 Ｇｒａｐｈｉｃｓ 产品 单位（ＰｏｗｅｒＰｏｉｎｔ）紧密合作，以使这三个产品的功能在 Ｏｆｆｉｃｅ 应用套装软 件中能更好地协调。这个部门同时也生产 Ｐｒｏｊｅｃｔ，一种流行的项目管理工 具。用户服务部门包括微软家用软件产品组，负责生产家庭理财工具软件以 及为家庭娱乐和教育设计的多媒体应用软件；同时也生产 Ｗｏｒｋｓ 套装软件，
它集电子表
格、文字处理、数据库功能于一身，主要提供给初学电脑的人使用。（联机）
系统部门开发和管理微软网络产品。研究部则负责新产品研制和程序设计技 术创新，并与各产品组紧密配合，尽量把研究成果早日产业化（参照附录 ２、
３ 中关于微软主要应用产品与操作系统的描述）。
图 １．２ 是桌面应用部门的结构示意图，清晰地展示了微软是如何将产品 单位与专项功能结合在一起的。该部门包括多个产品单位，每个产品单位一 般都设有五个职能小组，各由独立的经理人员管理，分别负责测试、程序管 理、开发、产品策划（由委派到产品组的产品经理担任）及用户培训。微软 将这些小组按照其生产的产品不同分为几个区域，例如，在 Ｏｆｆｉｃｅ 产品单位 成立之前，Ｅｘｃｅｌ 单位的开发员被分成五个小组：重算／功能，图表，打印／
格式化，加载项（一种特殊的软件程序，如统计分析或拼字检查等）和宏／
转换。一些产品单位把他们的小组集合起来共同进行用户培训，准备培训手 册和联机文档（例如 Ｈｅｌｐ 菜单的撰写）。在桌面应用部门，由 Ｏｆｆｉｃｅ 产品 单位的用户培训小组来准备 Ｗｏｒｄ、Ｅｘｃｅｌ 与 ＰｏｗｅｒＰｏｉｎｔ 的培训手册。在开发 组内也成立了一些小组，与微软的海外分支机构一起准备产品的非英语版 本，而产品管理组一般都有国际经理来主管外国市场营销。微软的一个日本 分部微软 Ｋ．Ｋ．，则制作了桌面应用软件的日文、中文及朝鲜版本，该分部直 接向部门经理负责。
表 １．２ 将微软的 １７０００ 个雇员按其职能进行了分类。大约有 ３０％的员工
（５１００ 人）在海外 ３６ 个外国分支机构从事销售、产品支持以及制作当地语 言版本软件的工作。（海外销售额占微软零售销售额的 ７０％左右，具体数据 见前言中的表 ２）。在美国本土工作的 １３３００ 名雇员中，大约有 １８５０ 位软件
开发员，１８５０ 位软件测试工程师，４００ 位程序经理与产品策划人员。大约有 ２１００ 位员工从事消费者支持服务；４０００ 人从事销售、市场和咨询工作；６００ 人从事用户
表 １．２ 微软职员的大致分类（１９９５）
数量 职能领域
４００ 程序经理和产品策划人员 １８５０ 软件设计工程师
１８５０ 软件测试工程师 ２１００ 消费者支持工程师 ４０００ 市场、销售与咨询服务
６００ 用户培训 ２２００ 营业与行政管理
３００ 研究
４５００ 海外人员（各个职能部门，其中包括 ４００ 名开发员）
１７８００ 总计
数据来源：开发部门主管戴夫・穆尔于 １９９５ 年 ７ 月 １８ 日所发的电子邮件。
培训工作；２２００ 人从事营业与行政管理工作；３００ 人参与研究工作。
规模稍大的产品单位，如 Ｏｆｆｉｃｅ，Ｗｉｎｄｏｗｓ ＮＴ、和 Ｗｉｎｄｏｗｓ 都各自有 ３００
—４００ 名员工，其他的一些产品单位也都拥有 ２００ 名以上的员工。一般来说，
操作系统开发组拥有比应用软件开发组更多的开发员与测试员；而后者则更 需要产品策划与程序管理方面的人才，因为应用软件的各特性很直观，其市 场也多定位于非技术型顾客。总而言之，表 １．２ 的这些数字反映了近十年来 微软翻天覆地的大变化。想想看，在 ２０ 世纪 ８０ 年代早期，Ｅｘｃｅｌ、Ｗｏｒｄ、ＭＳ
－ＤＯＳ／Ｗｉｎｄｏｗｓ 等部门竟只有 １０ 位或更少的开发员！产品支持
服务部的人员在 ２０ 世纪 ８０ 年代早期也就几十个人，现在已发展到 ５０００ 人，为产品开发组提供了宝贵的信息反馈（见第 ６ 章）。微软素以高效率著 称的销售与营销队伍，包括了成百名咨询人员（他们帮助公司安装数据库和 网络系统）。这支队伍也是由 １０ 年前的寥寥数人发展到如今的 ３０００ 员工。
销售与营销开支（包括广告费用）构成了微软最大的花销，大约相当于 １９９４ 年营业收入的 ３０％。营业成本（包括产品支持）大约相当于 １９９４ 年营业 收入的 １５％，研究与开发成本（看作当期发生的费用）为 １３％，一般管理费用 为 ３％。扣除以上各项成本支出，微软的税前净利为其营业额的 ３７％（见表 １，
导论）。ＲＤ（研究与开发）、销售与市场营销以及产品支持等各项开支的急 剧增加，使盖茨、梅普尔斯与公司其他高级经理寝食难安，千方百计想办法 来削减这些费用——比如，在公司内实施更为规范的管理制度，促进产品组 之间的协调合作，提高产品质量，改进产品功能使用户使用更为方便（用以 削减用户支持费用）。但在另一方面，产品组之间相互依赖性在加强；产品 的生产规模在扩大，其复杂性也在增加；产品不断升级换代，使新版本与以 前版本之间兼容性的保持也越来越困难。这一切，都使公司管理任务更为艰 巨，有时，它们甚至使微软为在预定日期内及时推出产品上市而进行的各种 努力付之东流。Ｏｆｆｉｃｅ４．０ 与 Ｗｉｎｄｏｗｓ９５ 就是因为上述各种原因而迟迟未能 问世，对比后面我们还会详细讨论。
系统部门和应用部门的古老博弈
１９９２ 年，微软高级管理层的变动中，最引人注目的便是系统和应用部门 正式合而为一，划归麦克・梅普尔斯统一管理。这一措施很容易令人想起创 业之初，各项目组直接向盖茨负责的情形。把这两个部门划在一块儿很有意 义，因为它们之间有着长远的相互排斥的历史，但是在战略上它们之间又变 得越来越相互依赖，越来越不可分离。我们可以毫不夸张地说，只有深入了 解 Ｗｉｎｄｏｗｓ 如何运行才能写好应用软件，而对 Ｗｉｎｄｏｗｓ 与一些技术（如对象 链接与嵌入）的演进施加影响力也同样十分关键；另一方面，如果以微软为 首的应用软件开发公司不再编写应用软件，一些新的操作系统如 Ｗｉｎｄｏｗｓ ＮＴ 就绝对不可能在市场上占据一席之地。问题在于，在历史上，微软的系统与 应用部门相处并不融洽。系统人员（尤其是 Ｗｉｎｄｏｗｓ ３．１，Ｗｉｎｄｏｗｓ ９５ 的开 发者），与应用软件人员相比，更偏向于采取松散懈怠的工作方式，虽然系 统软件往往更难开发与测试，更宜采用严格的组织管理制度。
梅普尔斯成功地使应用部门做到以质量为本，管理更为规范化。他对系 统部门也进行了改革，赢得了一部分人（如原先在 ＤＥＣ 工作的戴夫・卡特勒）
的支持。遗憾的是，直至 １９９５ 年他还未曾完全成功。他总结教训时说，自己 习惯于把重点放在用户问题与产品进程上，这种作法更适用于应用软件部门 而非系统软件部门，其原因有二。其一，操作系统得在各种不同类型硬件上 运行，而对各种不同硬件的测试需要“冗长及大规模的β测试”（指从用户 的角度对初级产品版本进行测试），使用户能够使用各种不同的机器与应用
配置的组合。这种测试的进程很难预测。其二，梅普尔斯发现操作系统项目 一般来说需要更多的员工，其构件也与许多不同产品相关联，这使得项目管 理繁琐不堪。他解释说：“应用软件部门效率比较高的一个原因是他们能够 以小组形式工作，交流便利，依赖性少。而系统软件部门的队伍庞大臃肿，
相互依赖性强，往往人浮于事。这两个部门的工作过程截然不同，应用软件 部门的小伙子比系统软件部门的小伙子更易受工作过程的驱使。我之所以这 样说，不是基于主观臆断，而是基于客观事实。”
结果，在系统软件部门内部经常出现一些人所谓的混乱局面，甚至涉及 到形象极佳的 Ｗｉｎｄｏｗｓ９５ 项目，但 Ｗｉｎｄｏｗｓ ＮＴ 却是一个例外。正如梅普尔斯 所说的：“在系统软件部门，各产品开发过程之间的差异很大。Ｗｉｎｄｏｗｓ ＮＴ 组主管戴夫・卡特勒组织严密，专备了一本工作簿极有条理地记载了所有事 项……这是一种非常严格的开发程序。而相反的，Ｗｉｎｄｏｗｓ 组与 ＤＯＳ 组却更 像一群持枪抢劫的乌合之众，毫无计划可言。他们常满不在乎地说：‘让我 们开始编程吧，看看会出什么结果’。”梅普尔斯认为所有的系统软件组必 须集中精力减少产品缺陷并且提高预测完成日期的准确率。
虽然两个部门界限分明，但是两边围墙内所有富有经验的经理人员都认 为系统软件部门比应用软件部门更成问题，即使两者间的界限正在逐渐变 化。克里斯・彼得斯在成为 Ｏｆｆｉｃｅ 副总裁之前，是 ＭＳ－ＤＯＳ ２．０ 与 Ｗｉｎｄｏｗｓ１．０
（还包括 Ｅｘｃｅｌ 和 Ｗｏｒｄ 的各种版本）的开发员。他指出说明书和项目管理严 重缺乏规划：“你会发现系统软件部门比应用软件部门要远为缺乏组织性……
我从不认为他们有合适的说明书……他们会说，我们在这项目中采用的是里 程碑式的技术，而当你问他们在这一项目中一共有多少个里程碑式子项目 时，他们便会面面相觑，无言以对。”Ｗｉｎｄｏｗｓ ＮＴ 的高级产品经理理查德・巴 斯同意克里斯的上述看法，他说：“当我 １９９０ 年刚进微软时，发现应用软件 部门和系统软件部门在管理方法上委实有巨大的差异。事实上，系统软件部 门时刻关注着应用软件部门，认为他们管理有方，在那里开发过程得到更为 有效的控制。”
系统软件部门与众不同的文化氛围，与史蒂夫・鲍尔莫的管理风格密不 可分。多年来，他偏爱于营造相对宽松的环境，从不设独立的测试组，给予 程序经理和开发员创新的自由，即使到了开发环节末期也可以进行产品的变 动。前任 ＭＳ－ＤＯＳ 与 Ｗｉｎｄｏｗｓ 的测试主管戴夫・马里茨（现在已离开微软），
对他以前的上司史蒂夫・鲍尔莫作了如下评价：“他十分精明，只是在他下 面做事很困难，因为他总是随随便便……他是那种散漫不羁的人，所以他无 法控制系统软件部门。”Ｏｆｆｉｃｅ 组的高级程序经理麦克・康特，娓娓道出了 系统软件部门拥有独特文化的原由：
我认为他们正在进行着许多观念的转变：其中之一即从面向 ＯＥＭ 转 向面向最终用户……在一定程度上，这是微软历史和文化的一部分。史 蒂夫・鲍尔莫是系统软件部门的最高权威。他不是那种架子很大、官僚 气息浓重、有板有眼、一丝不苟的人。所以，系统软件部门从来也没有 在规范化方面有所进展。另一个不可忽视的原因就是他们倾向于技术主 导一切。开发员拥有极大的发言权，但他们很不理性，没有严密的组织 结构，如同一盘散沙。如果依着他们的性子去做，那决不会遵循获得用 户或增大市场占有率的原则来办事。所以系统软件部门一直没有起色。
