寻求既懂技术又善经营的精明人士在公司组织和管理方面，微软始终遵循着这样一项策略，即坚持挑选那些既懂专业技术又懂经营之道的精明人士担任领导职位。我们可以把这项策略归结为四个原则：
·聘请一位对技术和经营管理都有极深造诣的总裁。
·围绕产品市场，超越经营职能，灵活地组织和管理。
·尽可能任用最具头脑的经理人员——既懂技术又善经营。
·聘用对专业技术和经营管理都有较深了解的一流职员。
从理论上来说，这些原则并非微软独家所创；但从实践上看，它们对整个计算机行业有着深远的影响。很少有公司能够拥有像比尔·盖茨这样既精通专业技术又知道如何把它们转化为数十亿美元资产的总裁。事实上，许多公司在采用与微软类似的管理方法，即围绕产品市场，超越经营职能进行组织和管理。但是，他们往往不能同时维持一个强大的产品市场和一系列领先的核心技术。作为一个处于迅速发展的主导行业中的公司，微软在加强组织管理以适应不断变化的市场方面做得颇为出色，有时甚至可以领导市场潮流。它逐步建立起来的技术力量已经能够满足巨大且日益增加的产品系列的需要。
许多公司雇用或提升职员的条件仅仅基于对管理能力的考虑，而并不看重他们的技术知识和经营管理相结合的程度。微软在选拔经理人员时，把他们的技术知识和运用技术知识去赚钱的能力放在首位。虽然这种方法可能导致公司缺乏素质良好的中层的职员管理人员，但这对微软在竞争激烈的高科技产业中进行软件开发是大有裨益的。此外，通过新一轮的雇用和汲取，微软可以不断地扩大已经具备的技术基础，比如为用户的软件增加新的程序以及开发信息高速公路产品和服务等等。
微软对筛选职员，尤其是软件开发员条件特别苛刻。在挑选软件开发员时，往往在所有的应征者中只雇用2%-3%。在考虑聘任经理人员时，微软则重视选拔那些既拥有较高的技术能力，又睿智明理，知道如何运用自己的技术来为公司推出新产品的出色职员。
在很多方面，微软的生产单位经理们就像两千年前古罗马军团中的百夫长那样运作。他们都精明能干，不需要过多的指示。对于突如其来的机会和威胁反应迅速。他们在组织机构中拥有足够的资源，独立运作；百夫长们平时各尽其责，只是偶尔进行汇报，但他们只处于一定的限度范围内而不能越雷池一步。自然，首领也深信这些百夫长——还有他们的部属——是在为整个团体的利益而奋斗的。微软的业绩证明：虽然无法做到使每位用户都满意，然而毋庸置疑，微软拥有一位杰出的领导者，一支卓越的高层管理队伍，一群勤奋努力的职员；他们不仅对专业技术和微机软件行业都有很深的了解，也知道如何去赢得成功。
原则一：聘请一位对技术和经营管理都有极深造诣的总裁许多成功的企业都归因于总裁的技术知识和商业敏锐感及其领导和管理才能。在今日美国产业界，比尔·盖茨也许是最精明的企业家，同时也是最被低估的经理。无论是在对软件和计算机技术的独到见解上，还是在创建并维持一个庞大的盈利企业上，他都表现出了惊人的天赋。在过去，他曾被认为是一个脾气暴躁喜好吵闹的人，经常对其职员横加指责（甚至大声咆哮），但他终于随着公司的发展逐渐成熟起来。他持续不断地对新产品和业务的选择进行引导，尤其注重关键产品的特性。不过现在他更多地依靠着几十名高级管理人员和技术领导，他所创立的各种正式的和非正式的机制也正帮助他指挥着微软这架庞大的机器。
盖茨其人威廉·享利·盖茨1955年出生于华盛顿州首府西雅图的一个富有家庭。他的双亲都不是技术人员：父亲是一位律师，母亲是一位教师。从各方面来看，少年盖茨和成年盖茨十分相像。他的传记作者把他描绘成“一个精力充沛的年青人”，喜欢在椅子上晃来晃去，如同我们采访他时所见。教过他的一位老师说他“彻头彻尾是一个淘气包”。他童年时兴趣广泛，喜欢玩各种各样的游戏，其中有一个称为“冒险”，参加者们为控制地球竞相争斗。
盖茨首次接触计算机是在1968-1969年，当时他在私立湖滨中学读二年级。学校有一个简单的电传打字电报机，可以限时接通一台计算机。盖茨在学会了BASIC编程语言之后，又与一个十年级的电子专家保罗·艾伦合作学会了更多的编程知识。当盖茨14岁时，就已和艾伦一起通过编写和测试计算机程序来赚钱了。不久，在1972年，两人创建了他们第一家公司“Traf-O-Data”，并且销售一种用以记录和分析机动车辆交通数据的小型计算机。
年，盖茨被哈佛大学录取，而第二年，艾伦就中止了在华盛顿大学攻读计算机科学学士的努力，离开了校园，在波士顿地区的豪尼威尔（Honey Well）找到了一份工作。以下的故事是人们所津津乐道的：包括艾伦如何在1974年注意到了《大众电子学》杂志为MITS计算机公司的新型牛郎星微机所做的广告，以及艾伦和盖茨又是如何利用哈佛大学的计算机设备编写BASIC的一个版本的。
盖茨在1975年离开哈佛，全身心地投入到为牛郎星微机（后来为其他的个人机）开发程序语言的工作中去。他和艾伦一起搬到了新墨西哥州的阿尔伯克基市，和MITS计算机公司相邻。同年，以盖茨为首，总共大约40至60名成员一起创办了微软公司，当时他在公司的第一个产品——微软BASIC的开发中占有举足轻重的地位（参考附录1，微软大事年表）。
青年盖茨有许多杰出的优点。他聪明，极富进取心，与他的朋友们一样。他能高度集中注意力，把握住自己感兴趣的事物，尤其是计算机和为实际应用编写程序。盖茨为人们所展现的计算机世界，不仅仅是追踪记录交通数据，更为重要的是人们可以坐在桌旁运行他的软件。在个人微机时代即将来临之际，这无疑是技能和雄心的伟大结合。
局外人士和微软的职员们对盖茨的描绘惊人相似。他被形容为一个幻想家，不断地蓄积力量，疯狂地追求成功，凭着他对技术知识和产业动态的理解大把地赚钱。正是盖茨的独特个性和高超技能造就了微软公司今天的业绩。
盖茨是个不折不扣的幻想家。还是在个人计算机的早期发展中，他就清晰地阐明了这个行业的未来发展方向。尽管经历了许多策略上的失败，他从未放弃过实现自己梦寐以求的幻想的努力。
这个家伙聪明得令人畏惧。但从一定意义上来说，他是独一无二的、地地道道的利润导向型的人才。你怎样去赚钱呢？当然不应不择手段，唯利是图，赚钱就像生活中许多美好的事物一样，是吧？如果你能赚钱，显然是一件好事。他就像是一台知道如何去赚钱的巨型计算机（吉姆·康纳尔，Office产品单位的程序经理）。
他很疯狂，对产品的了解甚于任何人。每次开会时，你都会大汗淋漓，因为他会马上注意到你的任何纰漏，并穷追不舍，非要打破沙锅问到底。他是那么令人不可思议（戴夫·马里茨，前任Windows/MS-DOS的测试主管）。
曾经认为他们能把盖茨置于股掌之上任意摆布。他毕竟只是一个“黑客”（hacker），不关痛痒，无足轻重。他们这次却看走了眼。这个怪杰的降生，便是为了在人间攫取巨大的权力和最大利润；而作为一位律师的孩子，他对合同语言知之甚详，驾轻就熟，甚至把IBM那些自以为是的家伙弄得狼狈不堪，不敌而走。
管理者盖茨在一次采访中，我们曾要求盖茨描述一下微软在管理产品开发方面获得如此惊人成就的背后有什么秘诀。他开列的清单虽然包含了一些我们已经注意到的因素，但还是给我们留下了十分深刻的印象。下面是一些从采访录中剪辑出来的简短摘要，阐述了盖茨在管理产品开发方面遵循的主要原则，我们在后面还会进一步涉及到。
·精明人士和小型团组“我们一开始就采用最先进的管理办法，那就是聘请一批了不起的人物并成立小型团组我们最突出的优势是：优秀的开发员总是喜欢与优秀的开发员在一起工作。”
·使大型团组的工作方式小型化的开发过程“于是我们不得不拥有规模稍大的团组我们被迫在许多方面正规化。经过每一个里程碑式的重要阶段时，我们都力争做到没有任何瑕疵，就像做项目评估工作那样。以上所有的这些东西都与项目组的规模大小密切相关。”
·使团组之间相互依赖性减少的产品结构“在微软，其良好的组织结构能使相互依赖性降到最低限度，即使在开发组内部也是如此。”
·集中力量开发新产品“公司所有的成员都在一块儿工作，只有少数例外。这样，当你急需某人帮助时，你便可以与他碰头，当面求教这也是一个很重要的优势所在。”
·公司构造的软件产品，直接用于其工作机器“我们的开发系统和目标系统完全一致。就我所知，许多公司不这么做。”
·单一的主要开发语言“员工们可以争论什么是最优的开发语言。但是，一经确定，即是唯一。”
·大量投资以支持人们的工作“我们乐意花费巨资为员工购买所需工具。员工们都有自己的办公室。”
·公司内部使用自己设计的软件工具“我们使用自己的软件工具，所以我们能毫不费力地掌握它们总的来说，我们从使用自己的软件工具中获得了莫大的好处。”
·多人了解有关产品细节“我们极少出现这样的情况：仅仅一个人熟悉一个庞杂的代码，而其他人都嚷嚷：‘噢，上帝！咱们头儿是唯一能修改这个代码的人’。”
·经理人员既创建产品又进行技术决策“我们没有不懂技术的管理人员，因此，去寻求技术和管理之间的平衡毫不费力。”
·迅速在技术和业务之间作出取舍“[我们有]能力迅速进行这类决定。如果其中出现纰漏，业务[产品]单位的经理会迅速作出反应，或者，通过电子邮件由我来作出选择。这些都是在瞬息之间完成的。”
·一个范围广泛的消费者信息反馈圈“大部分公司没有利用广大的消费者对其软件产品的意见信息反馈而微软仅在美国就拥有2000人的队伍，就我们的产品与消费者进行经常性的电话联系并记载发生的所有事情。可以说，我们拥有包括市场在内的更为优质的信息反馈圈。”
·从过去项目中汲取经验教训“我们对项目进行了大量的事后分析并查看‘臭虫（bug，即错误）’产生的根源，进而考虑如何设计以减少‘臭虫’以及怎样使用软件工具来‘捉虫’等。”
随着微软的发展壮大，盖茨遇到了许多前所未有的问题。他只有不懈地努力，以使自己岿然屹立于这个迅速发展的公司和行业的最前沿；并且保持对微软及其竞争对手不断膨胀的产品组合有一个细致的了解。他每天都得决定什么该“管”，什么该“放”，十分忙碌。可以确信的是，盖茨有一些能干的好帮手，虽然他和其他微软经理们都极力反对动不动就扩充人员。盖茨本人只有一位私人行政助理和一位技术助理，都是在最近几年内雇用的。技术助理常由年轻的程序经理或软件开发员兼任，一般任期一至两年。助理需要复审产品构造思路和说明书，作会议笔录，追踪竞争对手的行动和展览会最新的动态，并帮助盖茨跟上不同项目的进度。
微软领导层采用相当传统的管理方法，不过盖茨事必躬亲，始终保持高度参与。他主持每年4月份和10月份的程序复查和计划会议，制定大批量生产新产品的时间表并拟定预算的日程安排。10月份的程序复查重点在于制定3年生产计划；每个部门都详细阐明计划上市的产品及其与其他产品之间的相关关系。10月份的复查结束之后，微软的营销人员（称为产品经理）在各部门的生产计划基础之上进行销售预测。具体的预算计划就此展开了。经理们对预测的销售额和费用支出预算进行分析，看其是否能达到公司的利润目标。盖茨与其他领导人员根据这个分析，才决定在7月份开始的下一个财政年度所要雇用的员工数目。盖茨不仅在所有重要的程序复查与计划会议中起主导作用，而且对核心产品单位直接进行指导。
一般地，盖茨主要通过各项目小组成员与经理发出的电子邮件和产品进度报表来定义战略性新产品（或者新的产品版本），并监督开发时间表的执行情况。他每月从各项目组收到许多简短的进度报表——过去每两周一次——并且认真阅读。他参加许多项目的季度程序复查，有时也写写战略备忘录，大约一年四到五次吧。（有一次我们去采访他时，他正奋笔疾书。他的助手告诉我们，其备忘录内容大致为“我们正面临几个艰巨的技术挑战，谁能提出解决疑难的方法，什么样的方法从战略角度来看是正确的”。）一年之中有一到两次，他要过一个“思考周”。在这段时间内，他把自己与世隔绝，思索一些问题，比如：怎样获得更多的用户支持？怎样使员工们更为合作团结？五年之后产品世界会发生什么样的变化等等。盖茨试图从其时间花费上获得最大效用，即赚得最多的美元：“我对构成公司80%收入的产品有着最深刻的了解。”他把大部分时间用在一些关键性的应用程序上，如Office及其Word、Excel、Windows等组成部分。他也十分关注快速发展的新领域，如多媒体技术和联机信息产品与服务等。
项目进度报表微软的每一种软件产品都相应地有一个项目进度报表。盖茨以及其他高级行政管理人员（包括相关项目组的领导）每月都会接到从不同的项目组递交的此类报告。这些报告在使高级管理人员全面掌握各项目组的项目实施状况方面起到了关键性的作用。盖茨常常直接通过电子邮件与相关的经理人员或开发员进行交流，并把所收集的信息用于正式的程序复查之中。项目组的成员同时也通过这种报告来设定自己下一步的目标。盖茨是这么说的：
我拿到了所有的进度报表。现在恐怕有上百个项目正在铺开[进度报表]包括时间表、重要阶段日期、说明书中的任何变动，还有一些评论，比如“嗨，我们不能再雇人了！”或者“去你的，如果这个Mac的OLE（对象链接与嵌入）2的发布版还完不成的话，我们都死定了。”他们知道他们的报告会递交给相关项目组的领导，所以如果他们想表达自己的意愿，这是一个很好的办法。如果他们不在进度报表中提出，那么两个月后他们会以其他方式来说明，不过，这就会造成信息的中断内部各小组统统照此拷贝，这在一定程度上是小组成员意思一致的表现。
进度报表言简意赅，并且有一套标准格式。盖茨能够迅速将其浏览一遍，他敏锐的目光往往能轻易地找出一些破绽，如项目潜在的迟延或改变。有一些项目和事件倍受其重视：“我把所有的东西全部扫描了一遍看上百个进度报表对我来说易如反掌如果报告内容无关紧要，如关于邮件网关产品的，并且报告中没有漏掉成串成串的重要东西，我会敲击‘删除’键把它们删去。报表十分简练大约有两屏每个日期各占一行，如里程碑式重要阶段日期、说明书编制日期、代码完成日期有一栏专门写起始日期、最后日期以及本次报表日期。”盖茨对时间表有无疏漏、是否砍去太多的产品特性或有无必要改写说明书等事项尤为关心：
每个报告阶段，仅有10到15个报表吸引我的视线[因为有的评论]说：“我们砍去了一些产品的特性。”那么，请告诉我，剩下了一些什么东西呢？又有的评论写道“你正落后于时间表的进度。”这类评论都是隔靴搔痒，无济于事。员工们真正需要指明的是规模大小及速度要求。或者当一个竞争对手在市场上发行了一个新的版本时，员工们就必须在进度报表中注明：他们是继续保留原说明书呢，抑或加以修改使其与新的时间表一致。这才是至关重要的有时候马上就会有一些事情跳出来，比如说，这次他们修改日期吗？当你在阅读开发评论、程序管理评论、测试评论、营销评论时，你会发现，虽然通常它们只有三四句话，有时候，也会出现滔滔不绝的长篇大论。你对这些报告都有了个大致印象后，便会禁不住信口开河，发出一个邮件说：“得了，我让你谈一下有关拖放操作的事儿，你怎么一句也没有写上去。”或者“难道我们不需要这玩意儿吗？我们没有答应把这东西给惠普（HP）吗？RISC版本怎么样了？你怎么什么都没有提！”值得庆幸的是，不止我一个人在这些问题上明察秋毫，判断无误，另外有一批员工也深谙此道。
程序复查大约每过三个月，微软就召开各项目的程序复查会议。这些会议一般延续两个小时，盖茨与其他高级管理人员通常都会参加。项目组一般从各职能领域派遣一至两个关键人员为代表列席会议，有程序管理组（专门负责编制产品说明书），软件开发组（编写计算机代码），软件测试组（测试代码），产品管理组（产品策划及营销），用户培训组（准备产品文档）。盖茨告诉我们，他所关注的问题类型与进展报表如出一辙：
你会关心项目进展是否顺利，因为这是一个基本问题。你会想知道员工们是否团结互助这也很重要。如果他们添加了一些东西，将会使生产速度放慢，你就得干预，“你得给我保证速度不会下降10倍”。如果有些产品完工比他们想象的时间要长，你就得考虑，是因为他们不了解有关的产品设计吗？
你必须仔细询问很多问题使自己清楚我们对正在做的事情是否真正成竹在胸。你必须留心倾听项目实行过程中冒出来的好点子，兴许它会将整个说明书的面貌彻底改造一番他们能否将突然闪现的灵感捕捉并使之升华？他们与其他小组的关系处理得如何？
我认为小组之间应该共享代码。我常有意向他们灌输这一意识。不仅在相关小组之间应该代码共享，毫无关联的其他小组也应当如此。如果他们提出，相互依赖会制造出大量的“臭虫”或使速度大为降低；或者他们从未能够及时从另一小组拿到代码，那就有必要摆到桌面上进行讨论如果市场环境改变了，我会让他们修改说明书，那么他们及时从我这儿得到指示就显得十分重要。你一旦拥有充足的信息资料，你就可以直截了当地对员工说，他们干得很出色，或者成绩平平，这样，你便营造出了一个良好的工作氛围。有时候，在开会之前你就已经心里有数了，因为给我的有关项目的电子邮件实在是很多很多。
史蒂文·斯诺夫斯基，是盖茨1993年与1994年的技术助理（现在是Office的组程序经理）。他极力贬低程序复查的戏剧性效果，声称高级管理人员通常都事先知道问题所在并且与项目成员们一起先开一个预备会议：
“程序复查唯一的作用，是让头儿们确信，大家众志成城，行动一致。他们以前经常为麦克·梅普尔斯或史蒂夫·鲍尔莫或其他高级副总裁做此工作，然后再为比尔精心准备，这决非突如其来。”但是盖茨极力使他的问题搅和在一块儿。他有时会思考一些极为明显的事情，不过想得更为深入一些：“我提出的大约有一半问题经常使人莫名其妙；但是，另一半往往相当清楚易懂。我会提醒员工什么样的标准检查程序是真正重要的，什么样的系统配置是真正有价值的。”在一些情况下，他也会播洒及时雨，给予相应的帮助：
在我的职位上，我实际能够控制些什么了呢？我有一批核心开发员，在我转移到某项目视察时，帮助我检查算法[一种数学上或程序上的方法，通过计算机代码完成特定任务]，核实代码或进行实际操作。一个项目如果看起来岌岌可危，你就会考虑独立地复查一下代码。在过去，我会对他们说：“嗨，给我源代码，我拿回家看去。”现在我不这么做了。我会命令手下的D14或D15（公司高级技术职衔）：“给我回去好好钻研一下，回头再告诉我。”或者，“选派更多人员，务必解决这个问题。”他们经常就关于砍掉哪一块特性提出一些建议因为他们了解所有的相互依赖关系以及各部分是如何互相配合成为一体的。
盖茨也坦率地承认，他发现取消一些陷入困境的项目并不容易：
一般来说，我们不会轻易取消项目。但是，软件市场时时风起云涌，变幻莫测，我们不得不作出相应的调整。这属于技术——业务复合型决策。最著名的例子是我们的数据库产品。第一版本的Windows数据库并不完善你可以说我们是另起炉灶。有人说我们仅仅重写了其中的80%，这种说法未免太过极端。而Windows的Word倒不愧是一个典型。一波三折，屡遭挫折，迟迟无法上市，成为微软发展史上的一段趣事。
在复查说明书时，盖茨把重点放在一些关键问题上。他想知道一个新产品能引起多大轰动效应，是否能与其他微软产品兼容，他也关注质量问题（主要以“臭虫”数目来定义）。盖茨通过对这三大问题的分析来决定是否推出一个新产品。另外一些正越来越引起盖茨关心的问题便是小组之间的相互合作与构件共享以及生产是否落后于时间表的进度等。对于独立性很强的产品组们来说，这种互相依赖实非易事，而且越来越令人挠头，因为许多微软产品可能每年都要推向市场（例如，Windows95和Office95）；任何项目的失控延迟都可能导致尴尬的结局——产品重新命名。
盖茨喜欢运筹帷幄，确定总体方向，让各产品组自己解决微观问题。令人们拍案称奇的是，他能迅速发现各小组正费尽心机设法解决的产品技术细节问题，而不论此项目课题是属于其所擅长的专业领域（如Word、BASIC、Excel）之内还是超出他个人经验之外（如Windows NT）。麦克·康特，以前是Excel的产品和程序经理，现在在Office工作，向我们回忆起大忙人盖茨是如何在几分钟内就发现新特性的缺陷的。而Excel组，虽然知道有缺陷存在但未曾告诉盖茨，已花费了整整一个月的时间来寻找问题症结所在：
在Excel3.0中我们确立了一个重要概念，即“次最小重算”。所谓最小重算，是指你只需要重算相关的数值；当用户改动某数值时，软件只计算变动的单元格，而不必把全部工作表重新计算一遍。这是重算速度上的一个重大突破。而Excel3.0的次最小重算功能，在中间变量计算结果未改变时，甚至允许不重算相关的数值我们把这些情况汇报给比尔，而[他]说：“这种情况是怎么回事？还有这个，嗯，那个呢？”克里斯·彼得斯，当时是我们的开发经理，说：“哎呀，真是有意思。一个月的潜心思考，我们才发现这三个问题。我们真是好生惭愧。”可以说，盖茨非常善于发现技术问题。
即使是老练的职员和经理也会因准备与盖茨的正面交锋而忐忑不安。克里斯·彼得斯，现任Office产品单位的副总裁，在他名噪一时的1990年的录像“软件推出”中给予他的同事们如下建议：
你在做什么，为什么这么做，都必须向比尔交待清楚；你从不应该隐瞒什么，因为他很精明，能洞察一切。但是，你必须从容不迫，信心坚定，你必须顶撞他，毫不示弱。我所能给你们的唯一建议便是在开会的时候，带上你最最拔尖的开发员，他们能不加思索源源不断地旁征博引，把盖茨埋葬在不容置辩的铮铮事实之中永远不要仓促上阵，毫无准备。但是必须要学会说“不”。这样，盖茨便会很尊重你的意见。他很清楚得及时推出产品。我认为我们最后要说的是对微软来说，了解延迟推出一个产品将付出什么代价十分有用，所以，我们最好不要做这个特性了。我想最终我们还是会制作那个特性的。但，这就是他成其为比尔·盖茨的原因。
控制新产品开发至于什么样的事情该放手不管，什么样的事情应牢牢控制，盖茨是这么说的：
嗯，最初，我不让任何人编写代码。我拿走所有的其他人写的BASIC语句，自己再重写一遍，因为我不喜欢他们编程的方式。这其中是颇需要技巧的，我不情愿让任何人介入其中。但是我们马上就有了新产品像FORTRAN和COBOL。在这里，我只是确定一下软件说明书是否设计正确，我们是否遵循基本算法等我从来不会让别人来确立待开发产品的总体思路。我不会说：“我不知道这儿有一个新产品组，没有人告诉我这些。”对于一个软件公司的总裁来说，这是一个很好的控制公司的手段，也是我现在唯一能真正把握的东西。
盖茨的一个重要角色是根据他对未来发展方向的展望，包括可能的竞争对手的行动，来定义公司全部产品系列，并在技术和业务之间作出取舍决策。
一个例子就是盖茨在5年时间内，推进Excel与其他组采用Visual Basic为通用的“宏语言”（宏是一组特殊的命令，由用户自行处理，使许多复杂的操作仅需一两个快捷键就能激活。标准宏语言的使用，能使用户用同一种方式来定制各种各样的微软产品）。盖茨也促使各小组采用对象链接与嵌入（OLE）标准使构件共享更为便利。
盖茨也积极参加关键项目的开发。他确定现有产品，并制定其未来发展方向。Word的开发经理爱德·弗莱斯回忆道：
我们与比尔之间互相影响，互相启发，尤其是在产品开发的早期阶段，我们一起仔细审查说明书并决定产品特性比尔几个星期前就到我们小组来了，我们围着他向他展示Word的各种资源。上周是他的“思考周”，其间，他给克里斯·彼得斯发了大约10个电子邮件，邮件中说：“噢，这个Word版本中的某些东西我不太赞赏。你得给我好好考虑，怎么样使我们所有产品的拼写检查功能更为成熟。还有，Word和Help等产品怎么样才能合成为一种类型。”比尔花了很多时间定义我们产品的未来方向，他也对我们现在的进程提出批评他经常勾画出5年后产品的概貌。我们只得在遵循其指示与满足用户需求两者之间努力寻求平衡，寻找一个折衷方案这便经常造成矛盾冲突。
虽然微软的经理与开发员崇尚一种高度独立的企业文化，盖茨却习惯于事必躬亲，大包大揽，极少委托他人。据斯诺夫斯基说：“每样事情都极为琐碎，但都各有其独到之处。”
在推进小组们采用Visual Basic与OLE的同时，盖茨还要求在各产品中增加一些关键的功能。包括Excel的分级特性，Word的表格和拖放操作以及Visual Basic中的自定义控制项（称为VBXs）。盖茨也曾经坚持要求程序经理与开发员采用Visual Basic来编写原型和特殊的软件程序；一些小组发现Visual Basic语言由于技术上的原因不太适用，便予以抵制，他们成功了。公司副总裁史蒂夫·鲍尔莫在盖茨的默许下，也曾授权微软的小组们采用Windows NT的测试版而不是Windows或OS/2作为其操作系统。另外，盖茨还通知微软的商业工具小组（一项重要工作是构造语言编译器），不仅仅要面向消费大众，还得增加特性以支持内部的软件开发员。偶尔，盖茨会中止因为延误或出故障而难于为继的项目，比如Windows的Omega数据库产品（后来演进成为Access）。他还把版本有异但从事同种类型功能的项目合而为一，如Word、Excel与Mail中的文本处理代码。
人们屡次三番与盖茨进行争论；就克里斯·彼得斯的观察，只有这样才能获得盖茨的尊重。但是人们必须有显明的技术根据和数据事实作为后盾。那些基于私人的或感情上的原因，或者是内部政治而建立起来的观点，对盖茨及其他关键人物丝毫不起作用。特别地，对于盖茨来说，需要用新型的智力模式（其观点必须颇有见地，其世界观则需与众不同）来改变他冥顾不化的头脑，引起其共鸣。史蒂文·斯诺夫斯基解释说：“如果他一意孤行，执意不肯接受你的观点，你一遍又一遍地重复只会白费力气。你必须另辟蹊径来击倒他。”
原则二：围绕产品市场，超越经营职能，灵活地组织和管理比尔·盖茨向我们强调，微软以产品为中心来组织管理公司。我们发现，在很大程度上，这句话是正确的，不过，微软也非常重视其技术与专项功能（虽然与前者有重叠交叉）。员工们在多功能小组（根据产品组织而成）内工作，另有一些机制将这些产品小组联为一体。除了部门和产品组这两大结构外，微软另有两类组织机构。一类是较为正式的，组成了微软的管理体系。另一类属于非正式组织，由一些被尊称为“智囊”的管理人员和一群执行特殊任务或项目的技术人员与经理组成，直接听命于盖茨或其他高级领导。
组织和过程演变微软通过不断地摸索与试错，经过漫长的阶段，终于形成了今天的组织结构和产品开发过程。在20世纪80年代早期，微软成立了一个名为“最终用户组”的机构来开发应用程序，这使系统与应用组截然分开，各自循着不同的轨迹独立发展。公司在发展过程中，始终为改善其专项功能，尤其是软件测试，而奋斗不息着。公司也不得不克服许多难题，例如，产品小组缺乏中心领导，质量控制与项目管理方面破绽百出，无一可取。与其他许多公司一样，一些具有历史意义的转折点与关键人物构成了公司的发展历史。
第一个转折点是1984年成立测试组的决定。测试组与开发部门的分离，使得对开发员的工作进行独立的检验成为可能。第二个转折点大约在同一时间发生。程序管理开始区别于产品管理与软件开发而成为一个独立的职能。第三个转折，则是由80年代中期一系列迟延产品和“臭虫”引起的。这导致公司上下意见趋于一致，认为应当严格进行质量控制与项目管理。微软小组们现在已形成一种制度，即在事后分析书面报告中记录项目完成的心得体会。这反映了一个越来越为人们普遍接受的观点，那就是通过“向错误学习”，可以把工作干得更为出色。第四个转折点，是1988年IBM的麦克·梅普尔斯来到微软，在他的提议下，创建了小型业务单位，这使操作组增加了核心领导，并且更易于管理。
第五个关键事件是1989年的“休假会”。高级经理与开发员致力于减少故障，并提出多种方案，以帮助微软小组们在软件开发与微软组织演变进程中的关键事件——在各个部门内部建立独立的测试组。Macintosh电脑用的电子表格软件产品回收。
建立除测试组之外的专项职能如程序管理和产品管理机构。
建立事后分析文档，鉴别产品质量与项目管理方面的问题，并提出解决方案。
电脑用的Word3.0文字处理器产品回收。
的麦克·梅普尔斯就职于微软，在系统部门和应用部门为每个产品组建立独立的业务单位。
在Publisher1.0项目中采用里程碑方案。
月份的“休假会”与11月份的“零缺陷代码”备忘录突出了“每日构造”的重要性。
项目（1989-1990）顺利完成，仅推迟11天。
采用同步一稳定过程中的关键要素（里程碑和每日构造）。
聚合性总裁办公室成立。
把系统与应用归于全球产品集团之下，由执行副总裁麦克·梅普尔斯领导集中营销小组（产品经理）成立独立的部门，产品策划者除外，将业务单位改名为产品单位。
建立Office产品单位，由副总裁克里斯·彼得斯领导。
成立平台集团，由集团副总裁保罗·马里茨领导，成立应用与内容集团，由集团副总裁内森·梅尔沃德和皮特·赫金斯领导。
质量控制方面更为系统化。一种思路是把一个项目分解为很多个子项目或里程碑，1988年Publisher1.0就采用了这种方法从而顺利地完成了。另一种思路便是产品的每日构造，许多组都实行了这种方案但未执行“零缺陷”目标。这些关键性思路都已成为同步一稳定过程中的精华部分。Excel3.0（1989和1990年开发）是第一个采用这些先进技术的规模宏伟、营业额颇丰的微软产品，它的问世仅仅推迟了11天。
第六个关键事件便是1992年建立四人总裁办公室，并由麦克·梅普尔斯全权负责所有的产品开发。这使计划表一直难以预测的操作系统组更为规范化。第七，则是1993年的重新改组。大多数营销组的产品经理们被集中起来组成一个独立的部门，而一些产品策划者仍继续留在产品开发组里。微软还把业务单位改名为“产品单位”来反映这种变动。此外，微软成立了Office产品单位。这些变化使营销和产品策划及开发脱离，有利于在微软的核心应用软件产品之间实现构件共享。
乔恩·薛利是麻省理工大学的中途辍学生，曾任坦迪（Tandy）公司（销售“无线电小屋”手提电脑）的行政主管。1983年，盖茨聘任他为微软总裁。他把软件开发分为两部门：操作系统部门以及应用软件部门。盖茨曾经规定开发员必须向高一级的开发员而不是总经理负责，每一个开发员都必须向他汇报工作，因为他是公司的最高开发员。盖茨也一手控制了其他的重要领域，如营销等。现在，微软急剧扩大，产品大大增加，这种规定已是过时了。薛利认为盖茨管得太多，公司整顿势在必然。举个例子，盖茨喜欢把开发员东抽西调，今天来这个小组，明天去那个小组，疲于奔命。不仅如此，盖茨有时心血来潮，随意改动说明书，虽属“神来之笔”，却因无半分预兆，令手下人员无所适从。薛利认为盖茨应在高抽象层面上确定产品，引导开发组织的战略性发展方向，而不应陷在项目的细枝末节中无法脱身。4盖茨同意对公司进行大整顿，主动减轻自己的工作量，集中精力进行应用软件的监督。他任命史蒂夫·鲍尔莫为系统部门的主管。盖茨对这一次公司组织的大整顿作了如下描述：
在麦克·梅普尔斯来公司以前所有的开发小组以我为中心展开工作。当时盛行这样一种理论，即开发员不应被迫给那种一天写不了上千行程序的人工作；否则，对于开发员来说，这是一种侮辱。所以所有的开发管理人员全是清一色的软件开发者，每一个管理环节都安排了能够编制程序的开发员。现在这个传统被打破了。我把软件开发分为系统部门与应用部门，并且让史蒂夫负责[系统部门]。史蒂夫不是技术人员，但他为人十分精细，品格高尚。人们都很信服他出众的才华。当进行一项技术决策时，他总能知人善任，调度有方。他所选择的即使不是经理人员，也是广为人们所爱戴的人士。所以我们每一回都能圆满地完成任务。
1984年，微软决定把测试组从开发部门中分离出来。因为它的许多软件产品都出现了“臭虫”，由此激起许多采用微软操作系统的PC机制造商的极大不满（微软把这些公司称为原始设备制造商，简称为OEM）。比如，1981年与IBMPC机一起推出的BASIC版本就比较粗糙，用户在用“。1”或者其他数字除以10时，就会出错。这次事故后，IBM坚持要求微软改善其软件开发和质量控制的过程。在20世纪80年代早期微软还有其他的未向世人公开的问题。比如，FORTRAN（一种技术性的程序设计语言）上就有一种腐蚀数据的“臭虫”。5个人用户也开始纷纷进行投诉，说他们从零售商店买回家的微软应用软件有许多质量问题。
山雨欲来风满楼。微软的高级经理人员终于醒悟，发觉很有必要引进更好的内部测试与质量控制的方法。但是，许多人坚持反对，包括大多数程序设计师甚至一些高级经理（如史蒂夫·鲍尔莫）。他们认为在高校学生、秘书或者外界订约人的协助下，开发员可以自己测试产品。在1984年1月推出Macintosh多元计划（Multiplan）电子表格软件的最新版本之前，微软就曾特地请Arthur Andersen咨询公司进行测试。但外面的公司一般没有能力也不太可能全面地精确地测试一些较为复杂的软件产品。结果，一种相当厉害的破坏数据的“臭虫”迫使微软为它的2万名Mac多元计划电子表格软件的买主免费提供其更新的版本，代价为每个版本10美元，一共花了20万美元，6可谓损失惨重。
痛定思痛，微软的经理们得出结论说，如果再不成立独立的测试组，他们就不可能达到更高的质量标准。IBM与其他有着更为长远更为成功的软件开发历史的公司便是效法的榜样。戴夫·穆尔，微软的开发部门主管，回忆道：“我们清楚我们不能再让开发部门自己来测试了。我们需要有一个单独的小组来设计测试，运行测试，并把测试结果信息反馈给开发部门。这是一个伟大的转折点。”微软未曾照搬IBM的方法，即组织一大群人检查所有的软件项——从说明文档到代码及测试计划——或者要求行政管理人员在各开发阶段“停止活动”。这种官僚制度在大型电脑和容错性应用软件的生产中较为普遍，但在PC机世界中却很少采用。微软也不像IBM与其他的一些公司（包括日本的软件制造厂）那样对关于开发员与测试员如何度过他们的时间这类细节问题进行监控。微软有选择地采用一些看起来比较先进的技术，如独立的测试小组、自动测试以及为新手与关键性构件进行代码复查等。他们并不照搬IBM的经验，而是引进，使之成为微软特色。（穆尔指出：“IBM经验并不适用于微软。”）但是，穆尔接着说：“我们做错了。”自从微软在1984年与1986年之间扩大测试组以后，开发员“开始变懒了”，认为他们能够“把代码扔在一边等着测试”，他们忘了唯有开发员自己才能发现更多的错误，只有他们自己才能防患于未然，首先阻止错误的发生。在此同时，微软历史上第二次大灾难降临了。原定于1986年7月与公众见面的Macintosh版Word3.0，千呼万唤方于1987年2月问世，而且先天不足，里面竟然有大约700多处错误——有的甚至破坏数据，摧毁程序。一下子微软便名声扫地了。公司不得不在初始发布后的两个月内免费为消费者提供升级版本，其费用超过了100万美元。
至今，一个连公司内部的怀疑论者都深信不疑的事实是，微软在产品开发管理方面困难重重，举步维艰。为重获消费者欢心，各小组必须更为规范化。盖茨亲自掌管应用软件部门，但一些主要项目却是一团乱麻。除Excel外，Windows的其他新应用软件开发毫无进展。而一个数据库程序（别称Omega项目，以后演化为Access）和一个Widnows的项目管理应用软件严重受挫。
项目，后来更名为Wordfor Windows，激发起工作人员的灵感，杜撰了一个现在相当流行的新名词“无穷错误”。这个词描绘的是这样一种情形：测试员寻找错误的速度远远快于开发员修正错误的速度，而每次错误修正以后，又会产生新的错误。如此循环往复，错误无穷，使时间表和最终产品上市日期难以确定。这种情况的出现，有时是因为暑假实习生在编写完代码后未完成测试便返回大学，有时候，则由于开发员被从一个特性或项目抽调到另一个，所以来不及完成测试工作。在微软曾经经历过的“迟缓臃肿”集成期和测试阶段，开发员只能求助于旧代码。但遗憾的是，代码的具体内容大多已被淡忘，或者其作者已不知去向。在重写代码以修改数不胜数的错误中，开发员常常会重蹈覆辙，新一代的“臭虫”又大肆猖狂起来。8微软的测试主管罗格·舍曼，向我们回忆微软历史上这一段黯然无光的日子：
人们得到消息说他们实际上把事情弄得一团糟他们像驾着一辆飞驰的赛车，不时地撞到墙上，不过现在他们总算知道墙在哪儿了人们认识到不管程序是多么地充满想象力或创造力，如果不实用，也只能忍痛割爱。他们学会从各个角度全面观察问题并着重分析外部因素。他们知道了他们所编写的代码必须是可测试的，并且其测试资源一定是有限度的他们得编写稳定性很强的代码。可以说，从Omega和Opus的反面教训中，人们获益非浅，并逐渐走向里程碑式过程。我认为他们从Access而不是Word的教训中学到了更多的东西。“臭虫”数据库是如此的硕大无比，以至于几乎不可能存放在一个服务器中。而“活性臭虫”多如牛毛，使测试小组几乎无事可干：“急什么？开发部门必须处理完2年的积压待办事项才能赶上咱们现在的进度。”测试员几乎把全部时间都放在开发自动化工具上。终于，有人得出结论，说所谓的出品时间统统都是不现实的，项目也凌乱不堪，我们永远不可能及时推出产品。这大概意味着所有产品的定义也是虚假的。开发员不得不专注于一小部分产品使之性能稳定他们削减了许多开发计划，转而务实，力求产品具有稳定的代码基础并且可能继续开发。
盖茨招贤纳士，决定到公司外务色更多的管理型人才，以使项目不再失控。求贤若渴则英才群集。1988年，在IBM服务23年之久，领导其软件战略和业务评估工作的麦克·梅普尔斯投入微软门下。他还是开发OS/2系统和Presentation管理器（IBMPC机的早期图形界面产品）的中心人物。9具有讽刺意味的是，微软员工们经常对IBM的一些现象冷嘲热讽。比如，IBM聘用太多的非熟练开发员充任程序员（微软员工戏称之为“蠢驴编程”），开发过程过于连贯且封闭等。10微软经理们十分自信地认为微软集中几百个高级开发员所取得的成就IBM得汇合成千上万个员工才可能完成。不过，梅普尔斯看起来与众不同，很有天份，而且盖茨希望开发过程安排更为合理，使微软能有效地构造、推出产品并控制其质量。（所以梅普尔斯理所当然地被重用了。）1989年的一份重要备忘录总结了五月份“休假会”以来的讨论（由戴夫·穆尔组织），使各产品小组勇于采取正确的行动。这份名为“零缺陷代码”的备忘录，由Word组的一位开发经理克里斯·梅森撰写，主要记录了公司现状及即将采用的新开发过程。
在操作系统领域，微软的Windows同样步履艰难。就如同盖茨的传记作者在1990年Windows的第三个版本问世以后所观察到的那样，产品依然显得粗制滥造：“又一次，微软的测试者们未曾根除问题，留下了无穷后患。比如说，无法将程序安装于某一类型的机器上，网络老是出错，鼠标无法使用，一种第三方磁盘管理软件的数据被破坏，还有普通的假信号收集和文档错误软件行业中流传着这么一则笑话，说微软产品直至第三版本才开始进行β测试。”
盖茨及其他微软员工还有另外的隐忧。股票期权已成为公司资金来源的一个不可或缺的组成部分，但是经常性的产品迟延上市，使微软股票价格狂跌不止，回升乏力。产品的迟延与反复也使用户，包括OEM与零售商在内，都疑惧不安，大失所望。有一位股东甚至因微软未能及时推出Word（该产品占微软总销售额的20%）而对微软起诉，欲与之对簿公堂。最后，公司在1990年耗费150万美元才了结此案。（该案件控告微软经理人员故意隐匿迟延交货的消息。）至于数据库项目，当梅普尔斯1988年到任时，原假定3个月即告完成。而在一年半以后，他与盖茨取消了这个项目。
微软备忘录送达：应用软件开发员和测试员作者：克里斯·梅森日期：
主题：零缺陷代码主管：麦克·梅普尔斯，史蒂夫·鲍尔莫，应用业务单位经理和部门领导在5月日和13日，应用软件开发部的经理们与他们的项目领导、麦克·梅普尔斯以及其他的应用和语言的代表们一起开展了“休假会”活动。我的讨论小组对零缺陷编写代码的技巧进行了深入调查与研究。这个备忘录就记载了我们大家所达成的共识导致我们产品错误越来越多的原因是多方面的，不知诸位注意到了没有，事实上，我们的产品正越来越趋于复杂化，但我们并未曾相应地改变我们的经营管理方法列举出一大堆问题只是为了让大家更清楚地看到，是我们现行的管理制度，而不是我们的员工，导致这一系列问题的发生我们的时间表设计和长期以来形成的企业文化鼓励我们花最少的时间来完成一项特性，从不要求精益求精。只要它能被很好地演示，我们就觉得可以了，所有的人也都这么认为。于是这项特性就算是按照计划圆满完成。几个月以后“臭虫”不可避免地出现了，而我们却认定它与原来的工作毫无关联当不能按时完成时间表规定的任务时，我们便想走终南捷径产品的日趋复杂怎么会成为培育“臭虫”的温床呢？许多人也许会大惑不解。很简单，因为我们不懂得怎么样协调各部分来进行新产品的生产，或者修改旧产品我真正的意思是：你们的目标应该是每天生产那种能产业化的、易于推出的产品人无完人，人类自身的缺点都无法克服，又怎么能强求代码中没有故障呢？当出现“臭虫”以后，你必须仔细分析并立即着手解决我们每天主要的工作就是编写代码，而出现“臭虫”就意味我们努力的失败。[下面是另加的斜体字]成百成千的公司和个人用户都依赖于我们的产品：“臭虫”将会使他们蒙受时间与金钱上的巨大损失，可以想象，电脑病毒悄悄地在电子表格、数据库或者文字处理器中蔓延时，将会有多少家公司被迫停业！所以，我们必须开始更加慎重地处理故障问题。
应用和系统部门不断出现的问题，为梅普尔斯改革方案的推出和贯彻创造了一个极为有利的环境。特别地，他要求项目小组跟踪领先市场的竞争对手及产品，如Word Perfect、Lotus1-2-3、哈佛Graphics。他还要求每个小组对软件开发、测试和项目管理的过程进行定义并且精心改进。在与盖茨讨论之后，梅普尔斯把应用部门分成五个业务单位：Office，分析（Excel），图形（Power Point），数据访问（Data Access）和Entry（Works）。这些业务单位现在都已成为自负盈亏的盈利中心——能独立支配各种资源来为程序管理、开发、测试、营销（产品管理和产品策划）和用户培训服务——与在1981年推出最初PC机时采用的业务单位形式十分相似。当时，独立业务单位的实行，获得了巨大的成功。梅普尔斯在为IBM业务单位服务时便与盖茨等一见如故。后来他回忆起他对微软重组的影响时说：
这实在是很有趣。当我初来乍到时，我参加所谓的资源计划会议。开发、营销、程序管理还有测试部门的头头们都来了，他们对项目进行了详细的审查。每个星期每个项目都会有变动；有的项目已经迟延了18个月，但还想将其计划完成日期往后推迟，这时他们会要求说：“我们需要更多的测试员。”于是我们就从别的项目中抽调一些测试员过来。第二周，我又召开资源计划会议。上周人员被抽走的小组陷入了窘境，不得不要求增援，我们只好再次进行人员调动。公司内部员工经常被莫名其妙地东抽西调；人们从来不隶属于一个固定项目，这便造成了一种极为混乱的局面。于是，我们决定构造业务单位。从表面上看，它使人员自由流动所产生的好处——高效率——丧失殆尽。比如，Word的测试小组成员固定不变，即使身边没有需要测试的软件，也不予外借。事实上，业务单位的建立，使得资源库能够保持其连续性和稳定性，人们可以从容安排各项计划。它也给员工更加广泛的权利与责任，使得一大批管理人才脱颖而出。它使公司在制定其发展战略时更加注意面向用户并跟紧其竞争对手。总之，微软现在的组织机构就是以小型业务单位为基础构建起来的。
微软一直沿用这种基本的组织结构，但也有一定改进。1992年，盖茨把史蒂夫·鲍尔莫调离操作系统部门，转而担任销售和支持集团负责人。盖茨还创建了一个不断扩大的全球产品集团，由麦克·梅普尔斯对应用和系统两大领域的产品开发进行监控。这个任命使梅普尔斯有机会接触并驾驭操作系统组，直至1995年他辞职为止。而自梅普尔斯卸任以后，应用与操作系统又再一次分道扬镳。1993年，微软对营销工作渐渐重视起来，建立了Office产品单位。此外，微软又任命了关键职能领域如开发、测试，程序管理以及用户培训的负责人；自1994年以来，这些职能组都必须向产品开发的总负责人汇报工作。各负责人并不直接监督项目的实施，也没有明确的责任分工。他们的主要工作是帮助各小组总结并推广最佳经验。盖茨对公司组织的增减变动作了如下说明：
这只是一种取舍关系，所有的组织建设都属于取舍关系。它优化了产品制造的团体精神，我们会问：如何处理我们的产品？如何取舍来制造这个产品？我们推出产品了吗？产品。顺利通过复检了吗？所以，渐渐地，专门化的观念被破除了。
产品组织上存在两大缺陷：其一，公司虽然在面试求才、新工具开发、新方法运用等许多方面都有着很好的经验，但这些经验明显没有在各领域之间得到传播和推广。如果你的小组仅有一位测试员，那么就不可能求全责备，更不可能在考察过后诘问他：“喂，你怎么能连最新的有关测试的书籍都没有看过呢？”所以我们给每个小组都配备了一些为数不多但熟知测试方面最新动向的人员。其二，代码共享极为不易。虽然存在以上缺陷，但不应以一眚掩其大德，要看到公司现行组织给自身带来的利益要远远超过其造成的弊端。如果在过去的8年中，我们不使用业务单位来规划公司资源，微软早就分崩离析了。
微软公司组织体系的一个明显优势是它给各小组提供了充分的自由，每个小组就是一个相对独立的开发中心，致力于把各类产品推向特定的市场。克里斯·彼得斯解释道：
虽然我们自以为是地把业务单位当作微型公司看待，可实际上它们是不折不扣的产品开发中心那里没有负责销售和财务的部门——其相关职员早已从业务单位中调离。在业务单位内部工作的每一个人的职责都是相同的，就是不断地为公司推出新的产品。他们不需要编制代码，也不必进行测试或撰写说明书，他们唯一的工作就是为公司推出产品在这里，你最好能努力避免编制代码，如果你能够不通过编码就赚足美元，那何乐而不为呢？
特别是由于1989年公司“休假会”活动的刺激，微软的经理们如今特别强调开发员与测试员要留在自己所属的小组内，至少要超过一个产品周期。他们要求开发员努力工作，争取产品“一次到位”，并且“以质量为本”。为了达到上述标准，微软采用了“每日构造”与多里程碑技术——这就是我们在第四、五章内将要描述的同步-稳定过程的精华。
现行的管理结构和组织体系微软目前位于董事会之下的最高管理层，是由1992年首次创立的“公社制”领导班子——总裁办公室演化而来的。在1995年7月麦克·梅普尔斯归隐之后，又进行了一次改组。现在包括身兼主席和总裁二个主要领导职位的比尔·盖茨以及五个分别主管微软四大业务集团的高级经理人员：集团副总裁内森·梅尔沃德（前任高级技术部门领导）和皮特·赫金斯（前任桌面应用部门领导），二人共同负责新成立的应用和内容集团；集团副总裁保罗·马里茨（以前负责产品和技术战略）领导新成立的平台集团。这两个集团构成了微软的生产、研究以及开发的基本框架。执行副总裁史蒂夫·鲍尔莫掌管销售和支持集团，而罗伯特·赫伯德则负责营业集团并同时担任营运主管。部门副总裁与总经理们对这些集团领导负责。他们下面是产品单位经理，产品单位经理直接领导职能小组经理，再下面便是微软最基层的管理干部——产品小组组长。
联机应用和内容集团下设四个部门：桌面应用部门、用户服务部门、联机系统部门以及研究部门。平台集团也分为四个部门，分别负责个人操作系统、业务系统、开发员与数据库系统、高级用户系统。大多数部门自身就拥有市场营销机构，其职员由产品策划者直接担任。它们之间共享一个中央可用性测试实验室（由30-35个职员组成），用以测试产品特性及原型。销售和支持集团下设有许多独立的部门，有的负责面向全球OEM的销售（这些OEM主要是指AST、DEC、Dell、康柏、富士、Gateway、IBM、NEC、好利获得、Packard Bell、东芝、优利、Zenith等大公司），有的负责产品支持服务（简称PSS），还有国际营业部门（主要面向亚洲）、高级技术销售部门、战略企划部门（为一些大公司提供咨询及特定产品）、北美销售部门以及欧洲销售部门。营业集团则负责财务、磁盘生产、说明手册及相关书籍的出版（微软出版社）、信息系统和人力资源管理。
在平台集团内部，个人操作系统部门生产开发Windows和MS-DOS，业务系统部门则负责Windows NT与OLE（对象链接及嵌入）技术的开发，它下辖一个独立的产品单位（负责电子邮件及个人机服务器系统）。开发员及数据库系统部门编写程序设计语言（如Visual Basic），并为支持工具以及数据库产品（如Access和Fox Pro）编写程序。高级用户系统部门负责交互电视系统、宽带通讯及多媒体技术的开发。在应用和内容集团，桌面应用部下设有Office产品单位，它协调Word与Excel两个产品单位并与Graphics产品单位（Power Point）紧密合作，以使这三个产品的功能在Office应用套装软件中能更好地协调。这个部门同时也生产Project，一种流行的项目管理工具。用户服务部门包括微软家用软件产品组，负责生产家庭理财工具软件以及为家庭娱乐和教育设计的多媒体应用软件；同时也生产Works套装软件，它集电子表格、文字处理、数据库功能于一身，主要提供给初学电脑的人使用。（联机）系统部门开发和管理微软网络产品。研究部则负责新产品研制和程序设计技术创新，并与各产品组紧密配合，尽量把研究成果早日产业化（参照附录2、3中关于微软主要应用产品与操作系统的描述）。
桌面应用部门的结构示意图，清晰地展示了微软是如何将产品单位与专项功能结合在一起的。该部门包括多个产品单位，每个产品单位一般都设有五个职能小组，各由独立的经理人员管理，分别负责测试、程序管理、开发、产品策划（由委派到产品组的产品经理担任）及用户培训。微软将这些小组按照其生产的产品不同分为几个区域，例如，在Office产品单位成立之前，Excel单位的开发员被分成五个小组：重算/功能，图表，打印/格式化，加载项（一种特殊的软件程序，如统计分析或拼字检查等）和宏/转换。一些产品单位把他们的小组集合起来共同进行用户培训，准备培训手册和联机文档（例如Help菜单的撰写）。在桌面应用部门，由Office产品单位的用户培训小组来准备Word、Excel与Power Point的培训手册。在开发组内也成立了一些小组，与微软的海外分支机构一起准备产品的非英语版本，而产品管理组一般都有国际经理来主管外国市场营销。微软的一个日本分部微软K。K。，则制作了桌面应用软件的日文、中文及朝鲜版本，该分部直接向部门经理负责。
将微软的17000个雇员按其职能进行了分类。大约有30%的员工（5100人）在海外36个外国分支机构从事销售、产品支持以及制作当地语言版本软件的工作。（海外销售额占微软零售销售额的70%左右，具体数据见前言中）。在美国本土工作的13300名雇员中，大约有1850位软件开发员，1850位软件测试工程师，400位程序经理与产品策划人员。大约有2100位员工从事消费者支持服务；4000人从事销售、市场和咨询工作；600人从事用户微软职员的大致分类（1995）数量职能领域程序经理和产品策划人员软件设计工程师软件测试工程师消费者支持工程师市场、销售与咨询服务用户培训营业与行政管理研究海外人员（各个职能部门，其中包括400名开发员）总计数据来源：开发部门主管戴夫·穆尔于1995年7月18日所发的电子邮件。培训工作；2200人从事营业与行政管理工作；300人参与研究工作。规模稍大的产品单位，如Office，Windows NT、和Windows都各自有300-400名员工，其他的一些产品单位也都拥有200名以上的员工。一般来说，操作系统开发组拥有比应用软件开发组更多的开发员与测试员；而后者则更需要产品策划与程序管理方面的人才，因为应用软件的各特性很直观，其市场也多定位于非技术型顾客。总而言之，这些数字反映了近十年来微软翻天覆地的大变化。想想看，在20世纪80年代早期，Excel、Word、MS-DOS/Windows等部门竟只有10位或更少的开发员！产品支持服务部的人员在20世纪80年代早期也就几十个人，现在已发展到5000人，为产品开发组提供了宝贵的信息反馈（见第6章）。微软素以高效率著称的销售与营销队伍，包括了成百名咨询人员（他们帮助公司安装数据库和网络系统）。这支队伍也是由10年前的寥寥数人发展到如今的3000员工。
销售与营销开支（包括广告费用）构成了微软最大的花销，大约相当于1994年营业收入的30%。营业成本（包括产品支持）大约相当于1994年营业收入的15%，研究与开发成本（看作当期发生的费用）为13%，一般管理费用为3%。扣除以上各项成本支出，微软的税前净利为其营业额的37%。RD（研究与开发）、销售与市场营销以及产品支持等各项开支的急剧增加，使盖茨、梅普尔斯与公司其他高级经理寝食难安，千方百计想办法来削减这些费用——比如，在公司内实施更为规范的管理制度，促进产品组之间的协调合作，提高产品质量，改进产品功能使用户使用更为方便（用以削减用户支持费用）。但在另一方面，产品组之间相互依赖性在加强；产品的生产规模在扩大，其复杂性也在增加；产品不断升级换代，使新版本与以前版本之间兼容性的保持也越来越困难。这一切，都使公司管理任务更为艰巨，有时，它们甚至使微软为在预定日期内及时推出产品上市而进行的各种努力付之东流。Office4.0与Windows95就是因为上述各种原因而迟迟未能问世，对比后面我们还会详细讨论。
系统部门和应用部门的古老博弈年，微软高级管理层的变动中，最引人注目的便是系统和应用部门正式合而为一，划归麦克·梅普尔斯统一管理。这一措施很容易令人想起创业之初，各项目组直接向盖茨负责的情形。把这两个部门划在一块儿很有意义，因为它们之间有着长远的相互排斥的历史，但是在战略上它们之间又变得越来越相互依赖，越来越不可分离。我们可以毫不夸张地说，只有深入了解Windows如何运行才能写好应用软件，而对Windows与一些技术（如对象链接与嵌入）的演进施加影响力也同样十分关键；另一方面，如果以微软为首的应用软件开发公司不再编写应用软件，一些新的操作系统如Windows NT就绝对不可能在市场上占据一席之地。问题在于，在历史上，微软的系统与应用部门相处并不融洽。系统人员（尤其是Windows3.1，Windows95的开发者），与应用软件人员相比，更偏向于采取松散懈怠的工作方式，虽然系统软件往往更难开发与测试，更宜采用严格的组织管理制度。
梅普尔斯成功地使应用部门做到以质量为本，管理更为规范化。他对系统部门也进行了改革，赢得了一部分人（如原先在DEC工作的戴夫·卡特勒）的支持。遗憾的是，直至1995年他还未曾完全成功。他总结教训时说，自己习惯于把重点放在用户问题与产品进程上，这种作法更适用于应用软件部门而非系统软件部门，其原因有二。其一，操作系统得在各种不同类型硬件上运行，而对各种不同硬件的测试需要“冗长及大规模的β测试”（指从用户的角度对初级产品版本进行测试），使用户能够使用各种不同的机器与应用配置的组合。这种测试的进程很难预测。其二，梅普尔斯发现操作系统项目一般来说需要更多的员工，其构件也与许多不同产品相关联，这使得项目管理繁琐不堪。他解释说：“应用软件部门效率比较高的一个原因是他们能够以小组形式工作，交流便利，依赖性少。而系统软件部门的队伍庞大臃肿，相互依赖性强，往往人浮于事。这两个部门的工作过程截然不同，应用软件部门的小伙子比系统软件部门的小伙子更易受工作过程的驱使。我之所以这样说，不是基于主观臆断，而是基于客观事实。”
结果，在系统软件部门内部经常出现一些人所谓的混乱局面，甚至涉及到形象极佳的Windows95项目，但Windows NT却是一个例外。正如梅普尔斯所说的：“在系统软件部门，各产品开发过程之间的差异很大。Windows NT组主管戴夫·卡特勒组织严密，专备了一本工作簿极有条理地记载了所有事项这是一种非常严格的开发程序。而相反的，Windows组与DOS组却更像一群持枪抢劫的乌合之众，毫无计划可言。他们常满不在乎地说：‘让我们开始编程吧，看看会出什么结果’。”梅普尔斯认为所有的系统软件组必须集中精力减少产品缺陷并且提高预测完成日期的准确率。
虽然两个部门界限分明，但是两边围墙内所有富有经验的经理人员都认为系统软件部门比应用软件部门更成问题，即使两者间的界限正在逐渐变化。克里斯·彼得斯在成为Office副总裁之前，是MS-DOS2.0与Windows1.0（还包括Excel和Word的各种版本）的开发员。他指出说明书和项目管理严重缺乏规划：
“你会发现系统软件部门比应用软件部门要远为缺乏组织性我从不认为他们有合适的说明书他们会说，我们在这项目中采用的是里程碑式的技术，而当你问他们在这一项目中一共有多少个里程碑式子项目时，他们便会面面相觑，无言以对。”Windows NT的高级产品经理理查德·巴斯同意克里斯的上述看法，他说：“当我1990年刚进微软时，发现应用软件部门和系统软件部门在管理方法上委实有巨大的差异。事实上，系统软件部门时刻关注着应用软件部门，认为他们管理有方，在那里开发过程得到更为有效的控制。”
系统软件部门与众不同的文化氛围，与史蒂夫·鲍尔莫的管理风格密不可分。多年来，他偏爱于营造相对宽松的环境，从不设独立的测试组，给予程序经理和开发员创新的自由，即使到了开发环节末期也可以进行产品的变动。前任MS-DOS与Windows的测试主管戴夫·马里茨（现在已离开微软），对他以前的上司史蒂夫·鲍尔莫作了如下评价：“他十分精明，只是在他下面做事很困难，因为他总是随随便便他是那种散漫不羁的人，所以他无法控制系统软件部门。”Office组的高级程序经理麦克·康特，娓娓道出了系统软件部门拥有独特文化的缘由：
我认为他们正在进行着许多观念的转变：其中之一即从面向OEM转向面向最终用户在一定程度上，这是微软历史和文化的一部分。史蒂夫·鲍尔莫是系统软件部门的最高权威。他不是那种架子很大、官僚气息浓重、有板有眼、一丝不苟的人。所以，系统软件部门从来也没有在规范化方面有所进展。另一个不可忽视的原因就是他们倾向于技术主导一切。开发员拥有极大的发言权，但他们很不理性，没有严密的组织结构，如同一盘散沙。如果依着他们的性子去做，那决不会遵循获得用户或增大市场占有率的原则来办事。所以系统软件部门一直没有起色。虽然应用软件部门以前也如同未开发的西部一样没有秩序，但麦克·梅普尔斯却将它治理得井井有条。以上的观点来自于应用软件部门的一个职员，所以你可以对此持怀疑态度。史蒂夫·鲍尔莫在公司内具有很高的威望，尽管已经离开系统软件部门，但仍然保持着强大的影响力。盖茨对他也是言听计从，倚为股肱但麦克却是一位深谋远虑的人物，他不会下车伊始就发号施令：“好吧，让我们打破一切旧规，按我的方式从头开始。”恰恰相反，他做事很有策略，极有分寸，我认为他是在潜移默化地改变公司。
康特的这个观点在微软各阶层的员工之间引起了共鸣，他们认为除此之外，还有其他许多理由，其中之一便是地域上的差异：应用软件部门坐落在整个微软园区内更具现代风格的北部地区，一条大路把“宏伟豪华的棕色大厦与南部郊区”分隔开来（戴夫·马里茨如此描述）。（尽管应用软件部门条件更为优越，但盖茨仍然将他的办公室与系统软件部门设在一处。）产品的不同技术特性也使这两大部门之间差别很大，不过，由于操作系统中用户界面和特性越来越重要，这种差别已在逐渐变化。产品开发主管克里斯·威廉姆斯认为系统软件部门的员工在取得更多的实践经验后会逐步改变，他说：
系统软件部门的员工仍然觉得一个产品在成熟之前，不应进入市场，所以他们开发软件的方法全然不同你将不得不熬过三个或四个项目周期，不得不数次忍受糟糕的管理过程所带来的痛苦而系统软件部门员工的周期比应用软件部门的要长两倍。刚从Windows NT组离开的家伙跑到我这儿来抱怨：“我们实在不想再干了！”至于在Chicago（Windows95项目）组的那一帮人，我估计等产品推出以后，也会有一部分跑到我这儿来说同样的话这就是两个部门的本质差别。我认为另一个重大差异就是在系统软件部门总是由那些过去获得成功的人来具体负责项目。Windows3.1毫无疑问是个相当成功的项目，人们用老一套的方法成功地开发了这个软件。既然它并没有失败，你怎么能指望他们去改变做法呢？
新市场和技术微软并不仅仅注重操作系统与应用软件的开发和生产，虽然这两大领域给微软带来了丰厚的利润，构成了公司营业收入的绝大部分。新的用户产品和联机系统的市场增长最为迅猛，这两个部门有着截然不同的另一种文化，它们更关注于前沿科学技术和用户日常生活的结合。集团副总裁内森·麦尔沃德（曾任微软的高级技术主管）在最近的一次采访中对他的主要工作任务进行了描述：（1）帮助盖茨制定公司的技术策略，比如对一种技术作出购买还是自己开发的决定等；（2）创造未来的产品；（3）开展研究活动，重点集中在计算机科学领域，以支持微软各产品组，并努力使盖茨对未来个人机的想象变为现实。
从一个更为广泛的意义上来说，麦尔沃德所扮演的角色就是为微软进行“拳头产品的转换”，正如他所描述的：
大部分公司都面临着这样一个传统问题，就是它们都有自己的拳头产品，但却难以再进一步地发展。微软的特别之处就在于它从来都不惧怕改变自己的拳头产品，其中主要的原因就是我们的高级经理都是技术型人才，我们都懂得技术，而技术的力量是无穷的，一天之内就可使整个产业发生巨变。也许你在商业上很精明，但是无论你有多么能干，如果不懂技术，就无法保证自己在技术革命的浪潮中安然无恙，它会使你在顷刻之间粉身碎骨。
高级用户系统部门是平台集团的一个组成部分，在战略上显得极为重要。它在研究、宽带通讯和联机系统等部门的配合下，开发出家用和信息高速公路多媒体产品并打入市场；它还涉及到交互电视系统和微软网络等许多领域；它也生产未来产品。这个部门与其他产品单位十分相似，都有程序管理、开发、测试与产品策划等职能机构。不过，在促进发明与探索新思路方面，各职能小组之间的职责分工不很明确。
瑞克·罗歇德，一位前卡耐基——梅隆大学计算机科学系的教授，掌管着微软的研究部门，其工作也包括交互电视系统的研究。这个部门大约由250位科学家组成，每年的预算支出超过1.5亿美元。它的主要工作目标是使新技术在5-10年之内实现产业化，同时也包括一些能迅速带来效益的短期项目。研究人员们正在研究：能提高编程效率的工具；操作系统和用户界面的人工智能应用系统；计算机决策系统；语言处理和识别系统；超级计算机的设计；快速响应的视频服务器技术；运用录像、声像、文本等媒体信息创造交互电视和多媒体产品以及袖珍信息系统（例如袖珍PC）。罗歇德解释说盖茨认为微软的规模已经足以维持一支需投入大量资金的研究队伍了，盖茨本人以及其他一些微软领导也认为必须拥有更多的微软独创技术：
从本质上来说，比尔希望微软的研究部门能推进特定领域的研究工作我们希望自己的研究部门是世界一流的，与研究领域内任何一位竞争对手相比都毫不逊色甚至更胜一筹。比尔把这当作一项长期的奋斗目标，微软应该有能力达到这一目标，因为它已具备了一定的条件，达到了一定的规模。这一目标的完成已变得越来越重要，因为公司要想立于不败之地，必须开发具有自己特色的技术和思想。
研究部门为许多产品的开发作出了卓越的贡献，比如新的联机服务，新的操作系统（Windows95，Windows NT）以及提供“智能”帮助并使用户能又快又准地掌握Windows操作的新用户界面等等。梅尔沃德和罗歇德都对微软能最终生产出新一代的技术与产品充满信心，他们希望自己的研究部门能超越许多领先公司的中心实验室。比如，施乐公司（Xerox）的帕罗阿图研究中心（PARC）一直在个人计算机和图形用户界面的研究方面处于先锋地位，但是始终未能将之商业化。IBM在将它的研究人员发明的计算机技术成果产业化方面也存在着重重障碍（如RISC）。
罗歇德向我们解释了他们如此自信的原因：“施乐公司的PARC的问题并不是它自身的问题。它没有做错任何事；它的研究人员都干得很出色，其工作无可指责。只可惜明珠暗投，施乐公司墨守陈规，鲜有创新我认为这是一个教训，公司的经营运作必须与研究人员的工作紧密配合，这样才能使研究成果迅速转化为生产力。”梅尔沃德接着说：“微软与其他公司的不同之处在于它的研究机构直接与公司的最高决策层——总裁相联系，而其他公司的老式实验室则由于它们一贯的‘象牙塔综合征’，极易与其他部门隔离起来。我可以直接向盖茨汇报工作，盖茨也经常参与我们部门的决策，同时我们也对公司内其他部门的决策发表意见。”15（据报道，盖茨花费其1/3的时间与梅尔沃德一起构想未来的产品。16）原则三：尽可能任用最具头脑的经理人员——既懂技术又善经营我们前面谈论到的微软高级经理们（比尔·盖茨、麦克·梅普尔斯、史蒂夫·鲍尔莫、内森·梅尔沃德，保罗·马里茨、皮特·赫金斯、克里斯·彼得斯、瑞克·罗歇德等）也许有其弱点，但他们都很有能力，对微软的发展起到了不可替代的作用。事实上，盖茨与其他经理经常鼓吹他们只聘请聪明人充当经理、开发员与测试员等等。但是到底“聪明”是什么意思呢？比尔·盖茨认为，“聪明”就是能够迅速地有创见地理解并深入研究复杂的问题，如他在1994年接受采访时所解释的那样：“聪明人一定反应敏捷，善于接受新事物。他能迅速进入一个新领域，给你做出头头是道的解释。他提出的问题往往一针见血，正中要害。他能及时掌握所学知识，并且博闻强记。他能把原来认为互不相干的领域联系在一起使问题得到解决。他富有创新精神和合作精神。”17盖茨自身便显示出这些可贵的素质，并积极在微软的经理、职员和应聘者当中挖掘此类人才。
随着微软的发展壮大，盖茨已经私下访查了上百名程序员、经理以及技术专家，他们丰富了盖茨对技术知识的了解。他从中挑选了一小群更为出色的员工组成了一个非正式的智囊团，帮助他进行决策并监督关键项目和首创性举措的实施。盖茨习惯于提拔年轻的程序设计专家进入高级管理层。但随着公司的快速发展，盖茨的这种习惯使得微软内部既懂技术与业务又擅长经营管理的中层经理十分短缺。
智囊团微软智囊团的核心大约由10来个人组成，他们管理关键产品领域和公司新的举措，组织非正式的监督组来评估每个人的工作。也有许多在各项目工作的高级技术人员，组成了智囊团的外围；一些人还是公司的元老，从微软建立之初便一直在这儿工作，然而越来越多的成员来自对手公司或者是个人计算机领域之外新技术方面的专家。戴夫·穆尔从不认为自己是智囊团核心圈子的成员（“我比那些人要平凡一些”）。他说，智囊团的成员不属于任何部门，但是他们以其非凡的知识与经验而得到广泛的承认。他对智囊团作了进一步的解释：“它很不正式。你成为其中一员的一个主要原因便是你的事业阶梯。每个开发员都有一个事业阶梯评级每一个职能领域——开发、测试、程序管理、用户培训，都有其自己的事业阶梯。”
微软智囊团成员包括公司的最高层领导、高级开发员和程序经理。18下面对其所包括的公司领导人员作一大致的描绘。执行副总裁史蒂夫·鲍尔莫（39岁）在公司内德高望重，深受爱戴。他是盖茨在哈佛的同班同学，在1980年加入微软，以前曾在斯坦福学习一年的管理。人们可能会觉得他不是管理系统软件部门的最佳人选，但他不惧困难，勇于接受挑战——在20世纪80年代中期Windows项目迟迟无法完成，成为一堆无法收拾的烂摊子时，他挺身而出，承担了开发责任并成功地将其推向市场。他现在主管销售和支持集团，因为产品销售与用户支持领域变得越来越重要。集团副总裁内森·梅尔沃德（36岁）是普林斯顿大学的物理学博士，师从于诺贝尔奖获得者斯蒂芬·霍金。在1986年盖茨兼并梅尔沃德创立的软件公司后加入微软。他负责公司网络、多媒体技术、无线电通讯及联机服务等。
集团副总裁皮特·赫金斯（37岁），在取得斯坦福大学的工商管理硕士（MBA）学位后，于1986年加入微软。他以前主管桌面应用部门，现在与梅尔沃德一起负责新成立的应用和内容集团。集团副总裁保罗·马里茨（40岁），是微软的元老重臣，1986年就在微软服务了，其主要工作是制定公司长期产品战略并监督微软的操作系统软件和其他关键的用户技术等的开发。在这里，我们有必要介绍一下新加入微软的罗伯特·赫伯德（53岁），他在凯斯西部保留地大学获得了计算机科学的博士学位，然后在宝洁公司干了26年，最后升为宝洁公司的高级副总裁，主管管理系统部门、市场调研与广告策划部门以及技术获得部门。他于1994年加入微软后，因其在市场营销方面具有十分丰富的经验而深得盖茨敬重，因为用户产品日新月异，已成为微软发展最快的领域。
高级副总裁布兰德·斯尔文伯格（41岁）是个人操作系统部门的经理，1990年从Borland公司来到微软就职负责Windows3.1与Windows95项目的开发。罗格·海纳（43岁）是负责开发员与数据库系统部门的高级副总载，曾在DEC工作，之后，跳槽到苹果公司，负责Macintosh软件的开发工作。1993年加入微软。詹姆斯·艾尔金（43岁），是领导业务系统部门的公司副总裁。他于1991年从Banyan Systems公司来到微软。现在他主管Cairo（Windows NT4.0）项目。高级副总裁克雷格·蒙代（46岁），负责高级用户系统部门。他以前经营过一家超级计算机公司：Alliant Computer Systems，于1992年加入微软。副总裁乔纳森·莱泽洛斯（44岁），是公司战略关系部门的负责人。他于1986年加入微软，是一位市场营销专家。副总裁克里斯·彼得斯（36岁），主管Office产品单位，该产品单位每年创造的销售额和利润大约占整个公司的一半。
副总裁瑞克·罗歇德（43岁），研究部门负责人。在1991年加入微软以前，他是卡耐基-梅隆大学的计算机科学教授，颇有名望。罗歇德是Mach的主要设计师（Mach是一种用UNIX语言开发的操作系统，用作Windows NT的一个组成模块）。戴瑞尔·鲁宾（41岁）是软件战略部门的副总裁，网络技术的专家。他在1986年就已经是微软的一员了。因为优秀人才的不断加入，他的影响力在慢慢减弱。查尔斯·西蒙尼是这精心挑选出来的智囊团成员中一位大师级的程序设计师。他是斯坦福的计算机科学博士，曾经为施乐公司的PARC设计图形应用程序，包括著名的“华丽”（Bravo）文字处理软件。他在1981年离开施乐公司，在接下来的10年中一直致力于微软的应用软件开发，Multiplan、Word、Excel等都是在他的指导下开发成功的。
智囊团中的有些人物尤其出类拔萃，显得比别人要技高一筹，斯尔文伯格曾经对其年轻的同事克里斯·彼得斯作过这样的评价：“克里斯·彼得斯无疑是深知开发过程要说的人物。他可以说是最为成功的。他的开发过程正被公司其他员工竭力仿效，堪称完美的榜样。我们大家都认为可以从他身上学到很多很多的东西。”与微软其他高级经理人员一样，彼得斯具有很过硬的技术背景，而且他比许多人都要见多识广，经验丰富，因为他在系统软件、应用软件与一般管理部门都干过一段时间，是位难得的通才。他在华盛顿大学取得电子工程的学士与硕士学位，对软件工程颇有心得。1981年加入微软以后，他先后为MS-DOS2.0、Microsoft Mousel。0、PCWordl。0和Windowsl。0进行程序设计。之后大约有5年时间，他担任Excel的开发经理。由于运用了新的开发过程技术，他成功地把Exce13.0推向市场，仅仅比预定时间晚11天。之后他成为Word产品单位的总经理，为微软创造了好几亿美元的收入。1993年，彼得斯荣获副总裁的头衔，主管新成立的Office产品单位，是微软制定开发桌面个人机战略的中心人物。
智囊团另一位重要人物是麦克·梅普尔斯（53岁），在1988-1995年间担任公司的执行副总裁。现在他已激流勇退，成为公司顾问，专门对有关兼并与招聘新人等事项提出建议。梅普尔斯不是开发员，但他却是俄克拉荷马大学的电子工程学士与工商管理硕士。他看起来知道如何来管理手下这一批桀骜不驯的技术员。梅普尔斯徐徐地却又坚定有力地推动了公司沿着产品开发不断规范化的大道前进。他当初毅然离开IBM，是因为他看到了微软的巨大发展潜力的同时，对IBM十分地失望。进入微软后，为帮助盖茨摆脱繁重的官僚式的组织管理包袱，他把IBM的四项基本准则引入微软。第一条准则便是包括雇用、培训、工资报酬及晋升道路在内的一整套人事管理方面的作法：
在人事管理方面，IBM干得很出色。他们有一整套的评估、监督和奖励员工的方法并能保持其连续性。微软在这方面将采用IBM的经验并加以改进。长期以来，微软没有人喜欢被检查系统、管理系统或工资提升系统给“固定公式化”由此造成的结果便是人们做自己喜欢做的事，并把所有的东西都只记在脑子里面而不愿提笔写下来。不过由于公司小，没有造成什么更大的恶果。但现在公司规模扩大了，由于没有一套连贯的人事管理制度，内部开始分化，而且这种分化比我们现在所认识到的要严重得多。所以，我们开始让员工在各组间自由流动并树立员工工资提升和职位晋升的一套制度。戴夫·穆尔便花了很多时间来定义一个D10开发员与D11开发员之间的区别以及他们如何提升等等我们企图使每个人的头脑里都存在一种根深蒂固的观念，即在项目组之间调动人员时，在工资待遇、职业升迁等方面不会有多大的差异。
第二个准则，就是培养中层经理。微软向来缺乏这方面的管理人才。梅普尔斯说道：“我们经常采取休假会、经理会议等方式进行管理开发。这可能比较浪费时间，但是大家聚在一起聊天可以集思广益，互相切磋管理经验。”第三个准则，则是继续设立专项职能，如开发、测试，但是必须保证让员工自由流动以获得更丰富的工作经验。梅普尔斯希望公司内能避免思想褊狭、部门敌对以及争权夺利，这些陋习已经使IBM与其他一些大公司深受其害：
员工们现在思想开放多了。开发员不再对测试员横眉冷对。一般来说，各职能组之间总是会有隔阂与敌意。事实上有时怨结深了无法解开，一些人不得不另换一个工作或干脆离开微软，不过我认为现在已经很少听到这样的一些话了，比如：“测试员水平太低了，开发员才是真有水平。”或者说：“开发员不行，营销人员的素质要高得多。”每个小组也越来越具有凝聚力了。不过，公司对开发员还是另眼相看，无论工资、声名还是职位晋升都向他们倾斜。在微软你若是个开发员，你会觉得趾高气扬，比别人高出一头。这显然是历史与文化的原因造成的。我们公司是技术推进型的，高级员工当然大多数都是技术人员出身。
如今的IBM公司内部冲突不断，各小组都隐恶扬善，尽量隐藏“坏消息”，使公司管理层与质量保证人员难以知晓。梅普尔斯竭尽全力来避免在微软发生类似的情形。比尔·盖茨正属于那种不愿听到坏消息的人，一些微软经理们也极不情愿承认错误或执行时间表上的疏忽。不过，盖茨一旦察觉真相，会因人们不及时告知以致贻误战机而暴跳如雷。梅普尔斯认为员工之间应该进行经常性的坦诚的对话，旨在开展建设性的相互批评使任务完成更为顺利圆满。盖茨持相同的看法，他希望人们能敞开胸怀无所保留，尤其是在产品开发出现严重问题的时候。他希望人们为公司的总体利益着想，而不仅仅基于单个项目或个人职位的考虑。盖茨与梅普尔斯也都不希望看到人们犯同样的错误的情形一而再、再而三地出现。下面梅普尔斯把微软与IBM的气氛作了一下比较：
在IBM]有一些质量保证人员，不过没有微软这儿的多，并且它起着更大的审计监督作用。每每开发部门进行测试之后，质量保证人员总是说他们弄得很糟糕，全无可取之处。微软不像IBM这样互相之间对抗性如此之强。IBM似乎故意采用冲突性管理制度：如果你让员工显露其真实偏好，他们各自所代表的利益便也能一览无余，这样你就可以获得比较全面的信息进行最佳决策。在一定程度上，这可以说是一种很有效的管理方法。我们微软不这么做。我们试图使员工意思一致，达成共识；并做到胸襟宽广，顾全大局。当我在IBM开发部门时，我发现在这儿你别无长进只能学会如何向上级隐瞒坏消息的伎俩实在走投无路、被逼无奈时你才会把坏消息给捅出去最后你将自食恶果，在劫难逃。事情与你所料的正好相反，老是与你作对，你也没有规避风险的经验，这样，在每个人都觉得项目进展顺利时，突然它就整个都崩溃了。微软的风格是把事情全部摊开，员工间开诚布公地进行交流。例如我可以收到一份由Word开发员发来的电子邮件，说事情进展不顺利或者其他什么。总而言之，这种交流是有利于微软发展的。
梅尔普斯的第四个准则便是：一个软件公司必须为产品开发确定一个过程。他说：“如果你在IBM工作，你会觉得过程很有价值但也有不少问题。确定过程很重要，每一个特定的组织或单位都必须有自己的特定过程。”梅普尔斯回忆说，自从1989年的休假会活动以后，他和公司其他领导决定“每个小组只要找到自己的过程并能坚持之，便可以确定他们自己的过程了。”他希望能发现一个可重复出现的开发过程，但从不企图确定一个适合微软所有的小组的标准开发过程。每个业务单位的核心人物都努力把他们开发与测试软件的最优过程记录下来。这样过了大约一年半，在公司内部出现了一致意见，正如梅普尔斯所说的：“虽然人们还是觉得在开发项目时应该保持一定程度的自由。不过我认为有一些基本的做法已经渗透到整个组织。正是这些基本做法推动着整个组织前进与发展。”下面是梅普尔斯列出的一些一般原则；至于盖茨所开列的清单我们以后将会讨论到：
·人们自己制定时间表。
·为常常发生的预料之外的拖延留出一些缓冲时间。
·考虑到有发生变化的可能，不要过早地完成说明书以免浪费时间。
·采用里程碑式管理，从最难的问题入手。
·将用户问题置于技术或过程的考虑之上。
·将能力不同的员工进行合理配置。
技术过硬的经理人员盖茨与公司其他的早期领导很注意提升技术过硬的员工担任经理，这不仅仅局限于开发机构之中。瑞克·罗歇德在卡耐基-梅隆大学任教时，常与出色的计算机科学系的学生打交道。在他作为一个不带任何偏见的旁观者接触微软时，却也禁不住为微软高级员工的高超技术倾倒。他说：“我对第一次访问微软的情形记忆犹新，整个管理层几乎都由技术上十分出众的人员所组成。在整个计算机行业这种情况很少见。”戴夫·汤普森获得康奈尔大学的学士和硕士学位以后，曾在DEC与Concord Communications工作了13年，之后于1990年加入微软并主持Windows NT的网络设计。他说：“微软的一个强项便是它的经理人员都是技术型人才，即使在最高管理层也是如此我认为经理确实应该由技术人员来担任。小组长，即位于第一线的经理，绝对都得会编写代码，能够对小组开发的软件作出适当的修改。”
在微软，各职能部门的经理在升任高级领导之后，并不会放弃其原先的职能性工作。即使像Word与Windows NT这样大组的开发经理也会利用其1/3至1/2的时间编写代码。经理们为了及时解决各自组内发生的问题并作出正确的决策，有必要对技术领域的种种问题有一个清晰的了解。Windows NT3.0项目的软件设计经理娄·帕雷罗里让他手下的经理们像他一样每天花一半的时间编写代码：
我在组内制定了许多规则，其中最重要的一条是每个工作人员都得编程，谁也别想坐在那儿发号施令、管理别人我发现管理者很容易失去目标，他们总是无法认识到问题的本质并且反应迟缓。如果你始终不放弃编写代码的工作，你就能对项目的进展情况了如指掌，及时地发现并解决问题我大概每天花一半的时间编写代码并寻找项目的缺陷。
作为应用软件领域的经理，克里斯·彼得斯也持同样的看法。在他还是Word单位的总经理时就认为：
在微软内部，职能部门的经理还是会花很多时间去干自己的老本行的，这就意味着一个拥有60位开发员的开发小组经理会花费相当多的时间来进行程序设计在一些大公司内部他们把具体操作的层次向下移。你一旦当上开发部门经理，很快就会以自己身居高位、日理万机为由放弃编程；同样地，特性小组组长会以自己重任在肩而不愿编程；至于程序设计员，也会觉得自己十分繁忙、分身无术而不再编程虽然，我是270名员工的领导，似乎不再需要做什么具体的工作了，但是我还是为Word新版本编写了其中一个特性。
中层管理的不足微软提拔技术骨干担任管理人员的初衷之一是鼓励他们继续在技术领域发挥作用，但这样一来他们花在管理方面的时间就大打折扣。事实上，正是对正规培训、晋升机制以及成文规定等管理程序的忽视，才导致了微软在管理上的不尽人意。戴夫·马里茨认为微软的症结在于过分重视管理人员的技术能力而从不过问他们的管理才能。他说：
这家公司在管理上已近枯竭在获得提升时，我竟毫无察觉，直到有一天发现工资涨了才明白是怎么回事。由于经理对我很是敬畏，所以我的工作常常不用接受检查，这就是微软在中层管理上的问题在我看来，微软缺乏行之有效的工资晋升和奖金制度。选拔管理人员的标准就是他们的技术水平，这种政策导致一旦你被雇用为开发员后，就会逐级晋升，最好的开发员将最终成为最高级别的管理人员。
马里茨和公司内其他许多人一样都认为技术管理人员应当具备超群的技术才能，否则在公司内将无法得到其他员工的尊敬。但同时他也同意管理人员不应当仅仅是优秀的程序设计师，他们应当具备领袖的气质和魅力，可惜在微软的中层管理人员中，这样的人实在是凤毛麟角。他进一步阐述说：
要想成为一位经理或者领导——虽然在本质上经理就是领导——你必须具备两种基本的素质，如果你两者兼而有之，那就是天生的领导者：其一，你的技术才能应当超过你的同事或将要成为你手下的那批人。其二便是领袖气质。一般来说微软的经理人员都不具备这种素质。我认为自己属于后一种气质类型而非技术型的管理人员，就这一点来说，我与微软其他人不太一样。你会发现，在第一线管理层的经理人员大多不具备领导才能而在第二线，具备这两种素质的经理人数要多一些职位越高的经理素质越高。在第三、四层，经理们能把管理工作干得很出色，同时他们的技术才能也十分卓越。
梅普尔斯承认他加入微软以后不久就发现公司中层经理人员的缺乏，他与戴夫·穆尔以及其他一些人都在日复一日、孜孜不倦地努力以求改变这种状况。但是微软发展实在太快了，盖茨与梅普尔斯不得不放手让年轻人承担更大的权利和责任，让公司的高层领导们也继续提升那些具有技术背景并且在技术方面取得巨大成就的员工。理查德·巴斯承认说，寻找合适的中层经理是微软现在所面临的“最大挑战”：
毫无疑问我们没有一支优秀的中层管理人员队伍，像克里斯·彼得斯那样出色的经理实在不多，所以现在麦克又多了一项日程安排——培养更多的管理人员我们公司现在面临的最大挑战便是发掘一支中层管理队伍但显然这项任务比较艰巨通过几年来的经验积累我们终于发现应当重视并且培养管理才能微软的文化传统是如果你能大叫大喊并且干劲十足，你就是经理。不过就在去年，情形有所改变在过去，只要你能真正地做出一番事业，你便是经理。但现在这已经远远不够了。
原则四：聘用对专业技术和经营管理都有较深了解的一流职员我们在下一章将会讨论到，微软有一套严格的招聘制度，以寻求具有技术才能并且渴望能利用这种才能来开发与销售软件谋取商业利润的有为之士。那些能融入各专项职能组并与同事愉快合作的候选人倍受考官青睐。经理人员一般都愿意挑选那些能够适应微软工作方式，具有独立思考、学习和活动能力，决策迅速，不需要正规培训和规章制度加以约束的年轻人。但众多人才济济一堂，既给微软带来巨大的好处，也相应地会产生一些不良影响。
一流职员的正面效应在产品和职能经理以下，微软大约有5000名软件开发员和测试工程师。在软件领域，最好的软件编程员在同一时间内能比同一组内效率最低的程序员多编制10倍到20倍的代码，从这一点来看，吸引众多的计算机天才将是微软的一大优势，因为经理们所拥有的人力资源显然不能以员工人数简单相加来衡量，高比例的优秀人才，将使资源内涵大为丰富，其所创造的生产力更是难以估算。（我们可以拿微软与其他的软件公司作一比较。无论在欧洲、美国还是日本，这些公司在选拔软件开发员方面远不及微软苛刻，许多公司甚至雇用那些对计算机一窍不通的人，让他们在屋子里接受编制软件程序的训练。对这些经验不足、缺乏培训的员工来说，很难干出骄人的成绩，在复杂的技术面前也难以保持“清醒的头脑”。19）事实上每一个与我们谈及这个话题的微软经理都大力鼓吹一个经过仔细挑选的精英群体的价值。麦克·梅普尔斯说：“员工素质是无法估量的财富。不是每个公司都像微软这样拥有最好的麻省理工大学或斯坦福大学的毕业生。”瑞克·罗歇德也认为“这里的优秀软件开发员比我所见到的世界上任何地方的都要多”。戴夫·汤普森持同样的观点：“我们公司与其他公司最本质的区别就在于所雇佣的员工素质不同。公司整个系统的基础就是员工们敏锐的思维方式和惊人的工作效率。如果你的员工在几个小时内就完成别人需要花许多天的工作，你就会拥有更大的灵活性，就会觉得有更丰富的资源可以利用。”比尔·盖茨也颇为自得地吹起了法螺：
这些最优秀的员工参与着程序设计、思想创新以及具体的编码过程，他们所熟知的代码范围宽广，这使公司受益匪浅。公司能拥有精通所有程序设计变化的人才真是非常幸运，尤其在工作进程受阻、你不得不小心翼翼的时候。他们能检查出任何编码过程中的缺陷，他们对各种程序设计变化所产生的副作用了如指掌员工们都不情愿与差劲的开发员合作，他们会想方设法使那些人明白，如果你不是真正拔尖的开发员，你呆在这里只会痛苦失意。
优秀员工不仅能够利用其技术才能给公司创造丰厚的利润，还能使一个大公司摈弃其官僚作风，变得相对灵活——更像一个小型公司。克里斯·彼得斯便持这种观点，他十分强调员工独立工作与解决问题的能力。他说：“我们公司有一大群优秀人才，个个雄心勃勃想干一番大事业。而有的公司却雇用一堆没脑子的笨蛋，由经理立下许多规矩来控制他们我见过这种笨蛋公司，他们喜欢雇用平庸之辈并企图通过制定很多规矩来弥补其不足。这显然不太能行得通，因为问题的根本原因不在于缺少规矩，而是由于雇用了一堆需要规矩制约才能干活的员工。”
正因为微软聘请的是一群聪明人，公司从不强求员工墨守规章制度，尊敬正式职衔，员工也不会费尽心机拉帮结派以争权夺利。公司强调的是技术以及产品推出能力。戴夫·穆尔评论说：“在我们公司官衔并不受重视，把产品推向市场才是至关重要的。”布兰德·斯尔文伯格认为，权威和责任都会与那些最有才能的员工相伴：“微软开发部门的一个重要特点便是各个开发组内部的权力分布状况更多的是每个人的力量和能力的反映，这决不是千篇一律的俗套我们公司的管理制度是很有伸缩性的，如果我雇用了一个对特性构造颇为在行的极为出众的开发经理，我估计权力会自然而然地向他转移。我对此并不会介意，而只会调整自己去适应这种情况。”
如果个人或者组之间发生诸如何种构件应当共享之类的冲突，盖茨会作出最终裁决。约翰·法恩以前是程序管理部门主管，现在担任Excel组程序经理，他对微软文化以及比尔·盖茨的作用作了恰如其分的评价：
在这儿成功行事的办法形形色色，从最不正式的耳边轻声嘱咐到最为正式的行政命令下达规则丝毫不起作用行政机制更不占统治地位。所以，当一位软件开发业务单位经理对另一单位经理提议说“也许我们开发的软件应当包含在你们所开发的软件之中”或类似的其他建议时，你不要感到不可思议。这与行政机制毫无关系，只是为使公司利益最大化或者说为了赚取最大利润而采取的一种策略。不过因为这种决策的机会成本很高，一旦失败会造成巨大的潜在的负面影响，所以最后裁决权集中于比尔。在这种意义上，传统的管理方法起了作用。
一流职员的负面效应雇用一些在工作中不愿受纪律约束的员工所带来的后果便是这些人不得不经常经历痛苦的试错过程。我印象很深的一点就是微软的开发员和测试员（也有少数例外）不喜欢翻阅软件工程方面的科学文献，一些其他公司在好几年以前就觉得很重要的软件开发方面的作法（包括进行更为详细的程序设计和代码的检查，对结构设计、构件共享更为关注，在项目管理过程中采用更好的定量度量制与历史数据等），微软却很迟才发现以至于痛失许多良机。
高级经理们——包括比尔·盖茨在内——很难指挥这一群优秀员工。他们不喜欢与人合作也不愿意妥协或与别人共享自己的发明成果。在第6章中我们讨论到微软在这方面做了很多工作并有了一些进步，但是公司做得的确还很不够。麦克·梅普尔斯给我们描述了他刚到微软时所见到的一些问题：
很少有人拥有项目管理的经验，整个公司的管理都很松弛。员工都很优秀，但他们不愿受人支使，不过他们很乐意被引导着去发现该如何去做。于是你可以想出一些主意让员工自己寻找更好的办事方法，而绝不应该命令说“你必须选择这样的过程，你必须这么做”，这肯定行不通。只有推进员工坐下来进行探讨并找出解决问题的方法才是合理的现代化管理模式，你绝对不应该采取独裁式管理我以为我们的管理过程很有特色，只适用于微软而不适用于其他大多数[公司]因为我们公司拥有非常非常出色的员工，他们的主观能动性很高。
随着微软的发展壮大，领导们引进了许多政策来避免各小组的重复作业，但这也仅仅只是工作指南或原则而不是严厉的规定。布兰德·斯尔文伯格对公司的这种转变作了如下评价：“回顾创业之初，我们确实不需要规章制度的约束。现在情形改变了，有必要引进一些新作法来适应新的变化。不过我认为传统文化势力强大，根深蒂固——比如权力分散，管理灵活但又不走极端等。虽然现在有一些硬性规定，但每个组遵守规定的程度大不相同戴夫·穆尔或麦克·梅普尔斯不会给我下达命令说：‘你必须这样去管理你的开发组。’这不起作用。”在下一章，我们将要讨论微软如何定义其工作范畴以及它如何去组织与培养有创见的技术专家等等。
