在公司组织和管理方面，微软始终遵循着这样一项策略，即坚持发掘既懂专业技术又深谙经营之道的精明人士。我们可以把这项策略归结为4项原则：
  聘请一位深刻了解技术和商业经营的CEO（首席执行官）
  围绕并贯穿产品市场和业务职能，灵活地进行组织与管理
  尽可能雇佣最具头脑的管理者——既懂技术又善经营
  聘用深刻了解专业技术和经营管理的一流员工
从理论上来说，这些原则既不罕见也并非微软所独创；但从实践来看，它们对微软公司和整个计算机行业都有着深远的影响。很少有公司能够拥有像比尔•盖茨（Bill Gates）这样既精通底层技术又知道如何把它们转化为数十亿美元资产的CEO。事实上，许多公司在组织产品市场和业务职能时，采用的管理方法与微软比较类似。但是，他们往往不能同时维持一个强大的产品市场和一系列领先的核心技术。作为一个处于迅速发展、扩张的主导行业中的公司，微软在适应甚至引领市场方面做得颇为出色。它逐步建立起来的技术力量已经能够满足巨大且日益增加的产品系列的需要。
在聘用或提升员工时，许多公司往往只考虑他们的管理能力，而员工的技术知识和企业经营管理、战略方向之间的结合程度，则不是考察的重点。微软在选拔经理人员时，把他们的技术知识和运用技术知识获利的能力放在首位。虽然这种方法可能会导致公司缺乏拥有丰富人事管理经验的中层管理者，但这对微软在竞争激烈的高科技产业中进行软件开发大有裨益。此外，通过新一轮的聘用和汲取，微软可以不断地扩大现有的技术基础，例如，为消费软件、信息高速公路产品与服务增加新的开发小组等。
微软筛选员工，尤其是软件开发人员的条件特别苛刻。在挑选软件开发人员时，往往在所有的应征者中只聘用2%~3%。在聘用经理时则更为严苛，微软重视选拔那些既拥有较高的技术能力又睿智明理，知道如何运用自己的技术来为公司推出新产品的出色员工。
在很多方面，微软的生产单元经理们就像两千年前古罗马军团中的百夫长那样运作。他们都精明能干，不需要过多的指示。对于突如其来的机会和威胁反应迅速。他们在组织机构中拥有足够的资源，独立运作；百夫长们平时各尽其责，只是偶尔进行汇报，但他们的权限只处于一定的限度范围内而不能越雷池一步。自然，首领也深信这些百夫长——还有他们的部属——是在为整个团体的利益而奋斗的。微软的业绩证明：虽然无法做到使每位用户都满意，然而毋庸置疑，微软拥有一位杰出的领导者、一支卓越的高层管理队伍、一群勤奋努力的员工，他们不仅对专业技术和PC软件行业都有很深的了解，也知道如何去赢得成功。

原则一
聘请一位深刻了解技术和商业经营的CEO
首席执行官（Chief Executive Officer）的技术、商业才智以及其领导和管理才能，是许多企业成功的源泉。在今日的美国产业界，微软公司的比尔•盖茨也许是最精明的企业家，同时也是最被低估的经理。无论是对软件和计算机技术的独到见解，还是在创建并维持一个庞大的盈利企业的能力方面，他都表现出了惊人的天赋。在过去，他曾被认为是一个脾气暴躁喜好吵闹的人，经常对员工横加指责（甚至大声咆哮），但随着公司的发展，盖茨终于也逐渐成熟起来。他始终引领着公司对新的产品和业务进行选择，他尤其注重关键产品的功能。不过他现在更多地依靠几十名高级管理人员和技术领导，他所创立的各种正式的和非正式的机制也正在帮助他指挥着微软这架庞大的机器。

盖茨其人
威廉•亨利•盖茨（William Henry Gates）于1955年降生在华盛顿州首府西雅图的一个富有家庭。他的双亲都不是技术人员，父亲是一位律师，而母亲则是一位教师。从各方面来看，少年盖茨和成年盖茨一脉相承。他的传记作者把他描绘成“一个精力充沛的小孩子”，喜欢在椅子上晃来晃去，如同我们采访他时所见。教过他的一位老师形容他是“彻头彻尾是一个淘气包”。他童年时兴趣广泛，喜欢玩各种各样的游戏，其中有一个称为“冒险”，参加者们为控制地球竞相争斗。
盖茨在1968～1969年间首次接触计算机，当时他在私立湖滨中学读二年级。学校有一个简单的电传打字机，可以通过分时连接访问一台计算机。盖茨在学会了BASIC编程语言之后，又与一个十年级的电子专家保罗•艾伦（Paul Allen）一起合作学习更多的编程知识。在他14岁时，就可以和艾伦一起通过编写和测试计算机程序来赚钱了。随后，在1972年两人又创建了他们的第一家公司“Traf-O- Data”，销售一种用以记录和分析机动车辆交通数据的小型计算机。
1973年，盖茨被哈佛大学录取，次年，在华盛顿大学攻读计算机科学的艾伦离开了校园，并在波士顿地区的哈尼韦尔（Honey Well）找到了一份工作。以下的故事是人们所津津乐道的：艾伦如何在1974年注意到了《大众电子学》杂志为MITS计算机公司的新型牛郎星微机所做的广告，以及艾伦和盖茨又是如何利用哈佛大学的计算机设备编写BASIC的一个新版本。
盖茨在1975年离开哈佛大学，全身心地投入到为牛郎星微机（后来为其他的个人机）开发程序语言的工作之中。他和艾伦一起搬到了新墨西哥州的阿尔伯克基市，和MITS计算机公司相邻。同年，以盖茨为首，总共大约40至60名成员一起创办了微软公司，当时他在公司的第一个产品——微软BASIC的开发中占有举足轻重的地位（参考附录1，微软大事年表）。
在上述经历中，青年盖茨表现出了诸多优点。他聪明，极富进取心，他的朋友们也是如此。他能高度集中注意力，把握住自己感兴趣的事物，而且在计算机和为实际应用编写程序方面，这些特点表现得尤为突出。盖茨为人们所展现的计算机世界，不仅仅是追踪记录交通数据，更为重要的是人们可以坐在桌旁运行他的软件。在个人微机时代即将来临之际，这无疑是技能和雄心的伟大结合。
外界和微软的员工们对盖茨的描绘相差无几。他被形容为一个幻想家，不断地蓄积力量，疯狂地追求成功，凭着对技术知识和产业动态的理解大把地赚钱。正是盖茨的独特个性和高超技能造就了微软公司今天的业绩。
盖茨是个幻想家。在个人计算机的历史初期，他就清晰地阐明了这个行业的未来发展方向。尽管经历了许多策略上的失败，但他一直坚定不移地追寻理想中的美好蓝图。
这个家伙聪明得令人畏惧。但从一定意义上来说，他是独一无二的，是我所遇到的唯一一个完全以利润为导向的聪明人。你怎样去赚钱呢？当然不能不择手段，唯利是图。赚钱就像生活中许多美好的事物一样，是吧？如果你能赚钱，显然是一件好事。他就像是一台知道如何去赚钱的巨型计算机。
吉姆•康纳（Jim Conner），Office产品单位的程序经理
他很疯狂，比我们中的任何人都了解产品。每次开会时，你都会大汗淋漓，因为他会马上注意到你的任何纰漏，并穷追不舍，非要打破沙锅问到底。他是那么令人不可思议。
戴夫•马里茨（Dave Marite），前任Windows/MS-DOS的测试经理
IBM曾经天真地认为他们能把盖茨摆布于股掌之间。他们觉得他不过只是一个“黑客”（hacker），不关痛痒，无足轻重。但他们这次却看走了眼。这个怪杰的降生，便是为了在人间攫取巨大的权力和最大利润；而作为一位律师的孩子，他对合同语言知之甚详，驾轻就熟，把IBM那些家伙弄得狼狈不堪，落荒而逃。

盖茨的管理艺术
在一次采访中，我们曾要求盖茨描述一下微软在管理产品开发方面有什么主要秘诀，才能获得如此惊人的成就。他开列的清单虽然包含了一些我们已经注意到的因素，但还是给我们留下了十分深刻的印象。下面是一些从采访录中剪辑出来的简短摘要，阐述了盖茨在管理产品开发方面遵循的主要原则，我们在后面还会进一步涉及到。
1. 精明人士和小型团队
“我们一开始就采用最先进的管理办法，那就是聘请一批了不起的人物并组建小型团队……我们所拥有的最大的优势是：优秀的开发人员总是喜欢与优秀的开发人员在一起工作。”
2. 使大型团队像小型团队一样工作的开发过程
“于是我们不得不拥有规模稍大的团队……我们被迫在许多方面正规化。经过每一个里程碑式的重要阶段时，我们都力争做到没有任何瑕疵，就像做项目评估工作那样。以上所有的这些东西都与项目组的规模大小密切相关。”
3. 采用能够减少团队之间相互依赖性的产品架构
“在微软，其良好的产品架构能使相互依赖性降到最低限度，即使在开发组内部也是如此。”
4. 集中在一起开发几乎所有的新产品
“公司所有的成员都在一块儿工作，只有少数例外。这样，当你急需某人帮助时，你便可以向他当面求教……这也是一个很重要的优势。”
5. 员工在软件产品的目标机器上进行开发
“我们的开发系统和目标系统完全一致。就我所知，许多公司不这么做。”
6. 采用单一的主要开发语言
“员工们可以争论什么是最优的开发语言。但，一经确定，即是唯一。”
7. 大量投资以支持人们的工作
“我们乐意花费巨资为员工购买所需的工具。员工们都有自己的办公室。”
8. 公司内部使用自己设计的软件工具
“我们使用自己的软件工具，所以我们能毫不费力地掌握它们……总的来说，我们从使用自己的软件工具中获得了莫大的好处。”
9. 多人了解有关产品细节
“我们极少出现这样的情况：仅仅一个人熟悉庞杂的代码，而其他人都嚷嚷：‘噢，上帝！咱们头儿是唯一能修改这份代码的人’。”
10. 经理人员既创建产品又作出技术决策
“我们没有不懂技术的管理人员，因此，可以毫不费力地在技术和管理之间寻求平衡。”
11. 迅速在技术和业务之间作出取舍
“【我们有】能力迅速地在技术和业务之间作出取舍。如果其中出现问题，业务【产品】单元的经理会迅速作出反应或通过电子邮件由我来作出选择。这些都是在瞬息之间完成的。”
12. 一个范围广泛的消费者信息反馈圈
“大部分公司没有利用上百万消费者对其软件产品进行信息反馈……而微软仅在美国就拥有2000人的队伍，就我们的产品与消费者进行经常性的电话联系并记载发生的所有事情。可以说，我们拥有包括市场在内的更为优质的信息反馈圈。”
13. 从过去的项目中汲取经验教训
“我们对项目进行了大量的事后分析并查看‘缺陷（bug，即漏洞）’产生的根源，进而考虑如何减少在设计过程中产生的漏洞，以及怎样减少软件工具所导致的漏洞。”
随着微软的发展壮大，盖茨遇到了许多前所未有的问题。他只有不懈地努力，以使自己岿然屹立于这个迅速发展的公司和行业的最前沿；并且时刻掌握微软（及其竞争对手们）不断膨胀的产品组合的详细信息。他十分忙碌，每天都得决定什么该“管”，什么该“放”。可以确信的是，盖茨有一些能干的好帮手，不过他和其他微软经理们都极力反对随意扩充人员。盖茨本人只有一位私人行政助理和一位技术助理，而且都是在最近几年内聘用的。技术助理常由年轻的程序经理或软件开发人员兼任，一般任期一至两年。助理需要复审产品构造思路和说明书，作会议笔录，追踪竞争对手的行动和展览会最新的动态，并帮助盖茨记录项目情况。
微软领导层引入了相当传统的管理系统，不过盖茨仍然事必躬亲。他主持在每年4月和10月召开的程序复查和计划会议，他们在会议上为拓展新产品和预算制定计划。10月份的程序复查重点在于制定3年期的产品计划；每个部门都详细阐明计划上市的产品及其与其他产品之间的相关关系。10月份的复查结束之后，微软的营销人员（称为产品经理）在各部门的产品计划基础之上进行销售预测。具体的预算计划就此展开了。经理们对预测的销售额和费用支出预算进行分析，看其是否能达到公司的利润目标。根据这个分析，盖茨与其他高层人员才能决定在7月份开始的下一个财政年度所要聘用的员工数目。盖茨不仅在所有重要的程序复查与计划会议中起主导作用，而且还要对核心产品单元直接进行指导。
一般来说，盖茨主要通过来自各项目组成员与经理的产品状态报表和电子邮件来定义战略性新产品（或者新的产品版本），并监督开发时间表的执行情况。他每月从各项目组收到许多简短的状态报表——过去每两周一次——并且认真阅读。他参加许多项目的季度程序复查，有时也写写战略备忘录，大约一年四到五次。（有一次我们去采访他时，他正奋笔疾书。他的助手告诉我们，其备忘录内容大致为“我们正面临着几个艰巨的技术挑战，谁能提出解决疑难的方法，什么样的方法从战略角度来看是正确的”。）每年他都要过一、两次“思考周”。在这段时间内，他把自己与世隔绝，思索一个特定的问题，比如：怎样提高用户的支持度？怎样使员工们更为合作团结？五年之后产品世界会发生什么样的变化等等。盖茨试图从他付出的时间中获得最大的收益，赚得最多的美元：“我对构成公司80%收入的产品有着最深刻的了解。”他把大部分时间用在一些关键的应用程序上，如Office及其Word、Excel、Windows等组成部分。他也十分关注快速发展的新领域，如多媒体技术和在线信息服务与产品等。

项目状态报告
微软的每一种软件产品都相应地有一个项目状态报告。项目组每月都会向盖茨以及其他高级管理人员（包括相关项目组的领导）递交此类报告。这些报告是高级管理人员和项目组之间建立交流机制的关键，盖茨常常直接通过电子邮件与相关的经理人员或开发人员进行交流，并在正式的程序复查中使用他收集到的这些信息。除此之外，通过这些报告，项目组的成员也将设定自己的目标计划。盖茨是这样解释的：
我拿到了所有的状态报告。现在恐怕有上百个项目正在铺开……【状态报告】包括时间表、里程碑日期、说明书中的任何变动，还有一些评注，比如“嗨，我们不能再雇人了！”或者“哎呀，如果这个OLE（对象链接与嵌入）2的Mac版还完不成的话，我们都死定了。”……他们知道他们的报告会递交给其他相关项目组的领导，所以如果他们想表达自己的意愿，这是一个很好的办法。如果他们不在状态报告中提出问题，那么两个月后他们会以其他方式来说明，不过，这就会造成信息的中断……内部各小组统统照此进行，从某种程度上来说这是整个小组所达成的共识。
状态报告有一种标准格式，内容简洁明了，盖茨能够快速浏览一遍。他敏锐的目光往往能轻易地找出一些破绽，如项目潜在的迟延或改变等。但他对其中某些项目和事件更为关注，他说：“我把所有的报告全部浏览了一遍……看上百个状态报告对我来说轻而易举……如果报告内容无关紧要，如关于邮件网关产品的，并且报告中没有漏掉成串成串的重要信息，我会点击‘删除’键把它们删去。报表十分简练……大约可以布满两个屏幕……其中有一列记录各个日期，如里程碑的日期、说明书编制日期、代码完成日期……还有一行专门写起始日期、最后日期以及本次报告日期。”盖茨对时间表有无延迟、是否砍去太多的产品功能或有无必要改写说明书等事项十分关心：
每个报告阶段，仅有10～15个报表能够吸引我的眼球……因为有的评注说：“我们砍去了一些产品的功能。”那么，剩下了一些什么东西呢？得给我答案。又有的评注写道：“你正落后于时间表的进度。”这类评注都太过空洞无物。我们真正需要指明的是规模大小及速度要求。或者当一个竞争对手在市场上发行了一个新的版本时，员工们就必须在状态报告中注明：他们是继续保留原说明书呢，还是对其加以修改使它与新的时间表一致。这才是至关重要的……有时候马上就会有一些事情蹦出来，例如，他们这次会修改日期吗？……这些开发评注、程序管理评注、测试评注、营销评注，有的只有三四句话，有时候也会出现长篇大论。当你对这些报告都有了个大致印象后，便会禁不住发出一个邮件，脱口而出：“快点吧，我让你谈一下有关拖放操作的事儿，怎么一句也没看到。”或者“难道我们不需要这玩意儿吗？我们没有答应把这东西给HP吗？还有，RISC版本怎么样了？你怎么什么都没有提！”……值得庆幸的是，不止我一个人在这些问题上明察秋毫，判断无误，另外有一批员工也深谙此道。

程序复查
大约每过三个月，微软就召开各项目的程序复查会议。这些会议一般延续两个小时，盖茨与其他高级管理人员通常都会参加。项目组一般从各职能领域派出一至两个关键人员作为代表出席会议，有程序管理（专门负责编撰产品说明书）、软件开发（编写计算机代码）、软件测试（测试代码）、产品管理（产品策划及营销）、用户培训（准备产品文档）。盖茨告诉我们，他所关注的问题类型与他在项目报告中查找的如出一辙：
你会关心项目进展是否顺利，因为这是一个基本问题。你会想知道员工们的工作是否走在了计划的前面……这也很重要。如果他们添加了一些东西，可能会导致延缓进度，你就得干预，“你们得给我保证速度不会下降10倍”。……如果有些产品完工比他们想象的时间要长，你就得考虑，难道仅仅是因为他们不了解其产品设计吗？……我们真的明白我们在做什么吗？你必须仔细提出足够的问题使自己真正地回答这个疑问。你必须留心倾听项目实行过程中冒出来的好点子，也许值得因此对整个说明书进行一番改造……他们能否抓住突然闪现的灵感并使之升华？他们与其他小组的关系处理得如何？
……我相信小组之间应该共享代码。我常有意向他们灌输这一意识，让他们从其他小组获取他们所需的信息，哪怕毫无关联的其他小组也应当如此。如果他们提出，相互依赖会制造出大量的缺陷或使速度大为降低，或者他们从未能够及时从另一小组拿到代码，那就有必要摆到桌面上进行讨论……
如果市场环境发生了改变，我就会让他们修改说明书，那么他们及时从我这获得相关指示就显得非常重要。此外，一旦拥有了可靠的数据支撑，就可以定下评判的基准，管理人员能直截了当地对员工说，他们干得很出色，或者成绩平平。有时候，在参加会议之前就可以做到了然于心，因为与项目有关的电子邮件实在是非常多。
史蒂文•西诺夫斯基（Steven Sinofsky），是盖茨1993~1994年的技术助理（目前是Office的分组程序经理）。他曾经贬低程序复查的戏剧性效果，声称高级管理人员通常都事先知道存在哪些问题并且会与各个项目组一起先召开预备会议：“程序复查唯一的作用，就是向总裁证明他们能够协同工作。他们以前经常为迈克•梅普尔斯（Mike Maples）或史蒂夫•鲍尔默（Steve Ballmer）或其他高级副总裁做此准备，此后还要为比尔进行准备。”不过盖茨极力使他的问题纠缠在一起。他有时会花费些时间来思考一些极为明显的事情，但想得更为深入一些：“在我所提出的问题中，大约有一半经常使人感到惊奇；另一半往往相当清晰。我会提醒员工哪些标准检查程序是必须的，什么样的系统配置是真正有价值的。”在某些情况下，他也会给予相应的帮助：
在我所处的这个管理层次上，我实际上能够控制什么呢？我有一批资深的开发人员，在我转移到某项目视察时，可以让他们帮助我检查算法【一种数学或程序上的方法，通过计算机代码完成特定任务】，复核代码或提供帮助。因此，一旦一个项目岌岌可危时，就会要求进行独立的代码复查。在公司的初创阶段，我会对他们说：“嗨，给我源代码，我拿回家看去。”现在我不能再这样做了。我会命令手下的D14或D15（公司内的顶级技术职衔）：“回去好好研究一下，再告诉我到底发生了什么。”或者“分配更多的人员来挽救他们。”他们经常会就关于砍掉哪些功能提出建议……因为他们了解所有的相互依赖关系以及各部分是如何协同工作的。
然而盖茨也承认，他发现取消一些陷入困境的项目非常困难：
一般来说，我们不会轻易取消项目。但是，软件市场变幻莫测，我们不得不作出相应的调整并取消一些项目。这属于复合型的技术-业务决策。最著名的例子是我们曾经为之努力的数据库产品。第一个Windows数据库并不完善……你可以说我们是从头开始。有人说我们仅仅重写了其中80%的代码，但这种说法未免太过极端。Word的Windows版本就是一个典型。如果你想找出一个迟迟无法上市的产品，那么这家伙就是微软发展史上最为著名的实例。
在复查说明书时，盖茨关注一些主题。他想知道一个新产品究竟如何引人注目，是否能与其他微软产品系统协调工作，他也关注质量问题（主要以缺陷层次来定义）。盖茨通过分析这三大问题来决定是否能够推出一个新产品。另外一些正越来越引起盖茨关心的问题便是小组之间的相互合作与通用组件共享，协同工作的相关产品或代码共享是否协调一致并遵从时间表的进度安排等。对于微软那些独立性很强的产品组来说，管理这些互相依赖的事宜实非易事，而且它们逐渐成为非常重要的问题，因为微软可能每年都要将许多产品推向市场（例如，Windows 95和Office 95）；任何一个项目的失控延期都可能导致尴尬的结局——产品重新命名。
盖茨更乐于运筹帷幄，确定总体方向，然后让各产品组自己解决这类问题。令人们惊奇的是，他能迅速发现各小组所从事的技术细节问题。虽然在大多数情况下，他都是在他十分了解的产品（如Word、BASIC、Excel）中发现问题，但在超出个人经验之外（如Windows NT）的项目中，他也能指出缺陷。迈克•康特（Mike Konte）目前在Office工作，他曾经是Excel的产品和程序经理，他向我们回忆：大忙人盖茨如何在几分钟内就发现了新功能的一个问题。而之前Excel组虽然知道新功能有缺陷，但没有告诉盖茨，他们已经花费了一个月时间来寻找问题的症结所在：
在Excel 3.0中我们做了这样一项工作，即“次最小重算”。所谓最小重算，是指你只须重算相关的数值；当用户改动某数值时，只对受影响的单元格进行重算，而不必把整个工作表都重新计算一遍。这是重算速度上的一个重大创新。而在Excel 3.0的次最小重算功能中，当中间变量的计算结果未发生变化时，某些情况下甚至允许不重复计算相关的数值……我们与比尔交流这些信息，他说：“这种情况是怎么回事？这个，哦，还有这个呢？”克里斯•彼得斯当时是我们的开发经理，说：“哎呀，真高兴您能提到这些。经过一个月的潜心思考，我们才发现这三种情况。我们也是没有选择啊。”由此可见，盖茨很善于跟踪技术问题。
即使是老练的员工和经理，与盖茨的正面交锋前也会感到忐忑不安。克里斯•彼得斯，现任Office产品单元的副总裁，在他名噪一时的1990年的录像“软件的推出”中给予他的同事们如下建议：
你们必须让比尔明白你们正在做什么，为什么这么做；你不应该向他隐瞒什么，因为他能洞察一切。但是，你必须坚定从容，与他针锋相对。我所能给你们的唯一建议便是在开会时带上你最拔尖的开发人员，他们能不加思索从脑海中源源不断地旁征博引，并把盖茨埋葬在不容争辩的事实海洋之中……永远不要仓促上阵，毫无准备。但是必须要学会说“不”。盖茨尊重反对意见，他很清楚地及时推出产品。我认为我们最后要说的是……对微软来说，了解一个产品如果延迟将会付出什么样的代价十分有用，所以最好不要加上这个功能了。我想最终我们还是会完成那个功能。但这就是他成其为比尔•盖茨的原因。

控制新产品的研发
至于应该首先放弃什么事情，什么样的事情应该坚决地牢牢控制，盖茨是这么说的：
嗯，最初，我不让任何人编写代码。那时我会拿走其他所有人写的BASIC语句，自己再重写一遍，只不过是因为我不喜欢他们的编码方式。这个产品有其内在的技术特性，因此我不想让其他任何人参与进来。但是我们马上就有了其他产品，比如FORTRAN和COBOL。在这些产品中，我只是保证我们设计了正确的软件说明书，并且检查基本算法等……我不会委托其他人来把握产品开发的总体思路。我不会说：“我不知道这儿有一个全新的产品组，没有人告诉过我这些。”对于一个软件公司的CEO来说，这是一个很好决策，也是我现在唯一能真正掌控的东西。
盖茨的一个关键作用是他根据对未来发展方向的展望，包括潜在竞争对手的动向，来考虑公司全部产品，然后他还要在技术和业务之间作出艰难的取舍。一个鲜活的例子就是盖茨在5年时间内，推进Excel与其他组将Visual Basic作为通用的“宏语言”（宏是一组特殊的命令，由用户自行处理，使许多复杂的操作仅需一两个快捷键就能激活。使用标准的宏语言，能使用户用同一种方式来定制不同的微软产品）。盖茨也促使各小组采用对象链接与嵌入（OLE）标准使得他们能够更为便利地共享组件。
盖茨也积极参与关键项目的研发。他定义现有的产品，并描绘其未来的发展方向。Word的开发经理埃德•弗里斯（Ed Fries）回忆道：
我们经常与比尔互动，尤其是在产品开发的早期阶段，我们一起仔细审查说明书并决定应该向产品中加入哪些功能……比尔几个星期前就到我们小组来了，我们围着他向他展示即将在Word中加入的各种功能。上周是他的“思考周”，在那一周里他给克里斯•彼得斯发了十来封电子邮件，邮件中说：“噢，我不太欣赏这个Word版本中的某些东西。将来你得给好好考虑一下，怎么样才能使公司所有产品的拼写功能都得到完善。还有，Word和Help等，以及怎么样才能将这些产品整合在一起。”比尔花了很多时间来定义产品的未来方向，他也对我们现在所完成的工作提出直接的批评……他总能勾画出5年后产品的概貌。我们只得在遵循其指示和满足用户需求之间努力寻求平衡。我们试图找到一个能够达到这种微妙境界的折中方案……而这往往是很矛盾的。
尽管微软的经理与开发人员都崇尚一种高度独立的企业文化，但盖茨却习惯于事必躬亲，极少委托他人。据西诺夫斯基所说：“这类事情的数量不多，不过都很出名”。在推进各个研发小组采用Visual Basic与OLE的同时，盖茨还要求在各产品中增加一些关键的功能，其中包括Excel的提纲功能，Word的表格和拖放操作以及Visual Basic中的自定义控件（称为VBX）。盖茨也曾坚持要求程序经理与开发人员采用Visual Basic来编写原型和特殊的软件程序，但当一些小组发现Visual Basic语言由于技术上的原因不太适用时，他们成功地抵制了他的要求。公司副总裁史蒂夫•鲍尔默在得到盖茨的允许后，也曾授权微软的小组们采用Windows NT的测试版而不是Windows或OS/2作为其操作系统。此外，盖茨还通知微软的商业工具小组（一项重要工作就是创建语言编译器），不仅仅要为消费大众服务，还得增加功能以支持公司内部的软件开发人员。盖茨偶尔还会因为延误或错误而中止已经陷于困境的项目，比如Windows的Omega数据库产品（后来演进成为Access）。他还把基于同类功能的多个不同版本的项目整合在一起，如Word、Excel与Mail中的文本处理代码。
员工们试图与盖茨据理力争，而据克里斯•彼得斯的观察，只有这样才能获得盖茨的尊重。但是员工必须以鲜明的技术根据和数据事实为依托。那些由私人的或感情上的原因，或者是内部政治而引发的争论，对盖茨及其他关键人物毫无作用。特别地，对于盖茨来说，需要用新型的智力“模式”——以一种不同的视角来探查世界的广博的观点——来改变他的主意。史蒂文•西诺夫斯基解释说：“如果他能够驳倒你的观点，那么即使你反复地重复你的意见也只是徒劳无功。你必须另辟蹊径来击倒他。”

原则二
围绕并贯穿产品市场和业务职能，灵活地进行组织与管理
比尔•盖茨向我们强凋：“微软以产品为中心来组织公司”。我们发现，在很大程度上这句话是正确的，但微软也非常注重技术或专长（虽然两者有所交叉）。员工们在根据产品而组建的多功能小组内工作，还有一些机制则将这些产品小组融为一体。除了部门和产品组以外，微软还有另外两类组织机构。其中之一较为正式，它组成了微软的管理体系。而另一类属于非正式组织，它由一些被尊称为“智囊”的管理人员和一群执行特殊任务或项目的技术人员与经理松散地组织而成，他们经常为盖茨或其他高级领导提出建议。
组织与过程的演变
微软公司经历了漫长的过程，期间通过不断地摸索与试错，才终于形成了今天的组织结构和产品开发过程。在20世纪80年代早期，微软成立了一个名为“最终用户组”的机构来开发应用程序，这使系统与应用组能够独立发展下去。公司在发展过程中，始终为改善专业技能尤其是在软件测试方面，坚持不懈地努力着。此外，公司还必须克服许多难题，例如产品小组中缺乏重点、质量控制与项目管理方面机制落后等。与其他诸多公司一样，一些具有历史意义的转折点与关键人物构成了公司的发展历史（见表1.1）。
表1.1  微软组织演变进程中的关键事件
1984 在各个部门内部建立独立的测试组。
 Macintosh开发的Multiplan 1.06电子表格软件产品。
 建立除测试组之外的专项技术职能如程序管理和产品管理机构。
1986 开始建立事后分析文档，以鉴别产品质量与项目管理方面的问题，并提出潜在的解决方案。
1987 取消用于Macintosh的Word 3.0文字处理器产品。
1988 IBM的迈克•梅普尔斯就职于微软，并在系统部门和应用部门内为每个产品组建立独立的业务单位。
在Publisher1.0项目中采用里程碑方案。
1989 5月份的“休假会”与11月份的“零缺陷代码”备忘录突出了“每日构建”的重要性。
1990 采用同步-稳定过程中的关键要素（里程碑和每日构建），使得Excel 3.0项目（1989~1990）仅推迟11天就得以顺利完成。
1992 成立总裁的集体办公室。把系统与应用归于全球产品集团之下，由执行副总裁迈克•梅普尔斯统一领导。
1993 除产品策划者外，集中营销团队（产品经理）并成立独立的部门，将业务单元改名为产品单元。
 建立Office产品单元，由副总裁克里斯•彼得斯（Chris Peters）领导。
1995 成立平台集团，由集团副总裁保罗•马里茨（Paul Maritz）领导，成立应用与内容集团，由集团副总裁内森•迈尔沃德（Nathan Myhrrold）和皮特•希金斯（Pete Higgins）领导。
1984年，公司决定在开发之外成立独立的测试组，这是第一个转折点。这使得开发人员的工作要接受独立的检查。第二个转折点大约在同一时间发生，程序管理开始区别于产品管理与软件开发而成为一个独立的职能。第三个转折，则是由80年代中期一系列的产品迟延和漏洞而引发的，这最终导致公司上下意见趋于一致，认为微软应当严格进行质量控制与项目管理。微软的小组现在已经形成在事后分析书面报告中记录项目中的经验体会，这反映了大家的一个共识，即通过“向错误学习”可以把工作干得更为出色。第四个转折点，是1988年IBM的迈克•梅普尔斯来到微软，他提倡创建更小型的业务单元，这使操作组增加了更多的核心领导，并且使他们更易于管理。
第五个关键事件是1989年的“休假会”，高级经理与开发人员想尽办法减少故障，并提出多种方案以帮助微软小组更为系统地进行软件开发与质量控制。一种思路是把一个项目分解为很多个子项目或里程碑，1988年的Publisher 1.0就成功地采用了这种方法。另一种思路便是产品的每日构建，许多组都实行了这种方案但未强制执行“零缺陷”这一目标。这些关键思路都已成为同步一稳定过程中的精华所在。Excel 3.0（1989和1990年开发）是第一个采用这些先进技术并且盈利颇丰的微软大型产品，它的问世距离规划仅仅推迟了11天。
第六个关键事件便是1992年建立的四人总裁办公室。从此之后所有的产品开发都归由迈克•梅普尔斯负责，这使开发日程一直难以预测的操作系统组更有组织性。
第七，则是1993年的重新改组。大多数营销组的产品经理们被集中起来以成立一个独立的部门，而一些产品策划人员则继续留在产品开发组里。微软还把业务单元改名为“产品单元”来反映这种变动。此外，微软成立了Office产品单元。这些变化彻底地将营销同产品策划和开发剥离开来，从而有利于在微软的核心应用软件产品之间实现公用组件共享。
乔恩•雪利（Jon Shirley）在麻省理工学院中途辍学后，曾任Tandy公司（Radio Shack）的行政主管。1983年，盖茨聘任他为微软总裁，并由他将微软划分为操作系统部门和应用软件部门。盖茨曾经规定开发人员必须向高一级的开发人员而不是总经理汇报工作，这导致每一个开发人员都必须向他汇报，因为他是公司的最高的开发人员。盖茨曾经也试图控制其他的重要领域，如营销等。但随着微软的快速扩张，产品种类大幅增加，这种规定也就随之被废止。雪利认为盖茨管得太多，需要对公司重新进行整顿。例如，盖茨总喜欢把开发人员东抽西调，今天让他们去这个小组，明天放到那个小组。不仅如此，他有时还会突然心血来潮，随意改动说明书，之前却无半分预兆，这种神来之笔常常令手下人员无所适从。雪利认为盖茨应在高抽象层面上定义产品，并为开发组织指引战略发展方向，而不应深陷在项目的细节中无法脱身4。盖茨同意了雪利的建议，他对公司进行了整顿，并将自己的职责集中在应用软件的监督上，与此同时，他任命史蒂夫•鲍尔默负责系统部门。盖茨对这一次公司组织的改组作了如下描述：
在迈克•梅普尔斯加入公司之前……所有的开发小组都以我为中心展开工作。当时盛行这样一种理论，即开发人员不应被迫给那些一天写不了上千行代码的人工作，否则对开发人员而言，这就是一种侮辱。所以所有的开发管理人员全部都是软件开发者，而生产链中的几乎每个环节也都安排了能够编写大量代码的开发人员。现在这个传统被打破了。我把软件开发分为系统部门与应用部门，并且让史蒂夫负责系统部门。史蒂夫虽然不是技术人员，但他十分严谨，品格高尚。当进行技术决策时，他总能知人善任，调度有方，即便他选择的不是经理，也是广为人们所爱戴的人士，大家都很相信他的才干。所以我们总能达到目的。
1984年，由于公司的许多软件产品都出现了缺陷，进而激起了许多采用微软操作系统的PC机制造商的极大不满（微软把这些公司称为原始设备制造商，简称为OEM），因此微软决定把测试组从开发部门中独立出来。比如，1981年与IBM PC机一起推出的BASIC版本就存在问题，当用户使用“.1”或者其他数字除以10时，就会出错。这次事故后，IBM坚持要求微软改善其软件开发和质量控制。在20世纪80年代早期微软还存在其他的未向世人公开的问题。例如，FORTRAN（一种技术性的程序设计语言）上存在一个会改变数据的错误”。5个人用户也开始纷纷投诉，抱怨他们从零售商店买回家的微软应用软件有许多质量问题。
在重重危机面前，微软的高级经理人员终于发现，公司有必要引进更好的内部测试与质量控制方法。但是仍然有人反对这个建议，大多数程序设计师甚至一些高级经理（如史蒂夫•鲍尔默）都认为在高校学生、秘书或者外部承包商的协助下，开发人员完全可以测试他们自己开发的产品。在1984年1月推出Macintosh下的Multiplan电子表格软件的最新版本之前，微软就曾特地雇佣Arthur Andersen咨询公司测试了该版本。但外面的公司往往无法精准地测试复杂的软件产品。结果这导致该产品出现了一个相当严重的破坏数据的缺陷。它迫使微软为2万多名购买Multiplan的客户免费提供更新，每个版本10美元，总共花了20万美元，可谓损失惨重6。
痛定思痛，微软的经理们终于得出了结论，如果再不成立独立的测试组，产品就不可能达到更高的质量标准。IBM与其他有着更为长远而成功的软件开发历史的公司便是效法的榜样。戴夫•穆尔（Dave Moore），微软的开发部门主管回忆道：“我们清楚我们不能再让开发部门自己来完成测试了。我们需要有一个单独的小组来设计、运行测试，并将测试结果信息反馈给开发部门。这将会是一个伟大的转折点。”微软未曾照搬IBM的方法，即组织很多组人检查所有的软件项——从说明文档到代码和测试计划——或者要求行政管理人员在不同开发阶段“停止工作”。这种官僚制度在大型电脑和国防应用软件的生产中较为常见，但在PC机世界中却很少采用。微软也不像IBM和其他的一些公司（包括日本软件制造商）那样详细地监控开发人员与测试员如何使用他们的工作时间。相反地，微软选择了一些灵活有效的做法，如独立的测试小组、自动测试以及为新手和关键组件进行代码复查等。他们并未照搬IBM的经验，而是使之成为行之有效的具体做法。（穆尔指出：“照搬IBM的经验并不适用于微软。”）
但是，穆尔接着说：“我们做错了。”自从微软在1984年与1986年之间扩大测试组以后，开发人员“变懒了”，他们认为能够“将代码扔在一边等着测试”。他们忘了唯有开发人员自身才能发现更多的缺陷，也只有他们自己才能将错误扼杀于摇篮中。与此同时，微软公司历史上第二次大灾难降临了。原定于1986年7月面世的Macintosh版Word 3.0，一度推迟到1987年2月才问世，而且竟然有大约700多处缺陷——有的甚至能破坏数据，让程序崩溃。公司为此不得不在发布初始版本后的两个月内免费为消费者提供升级，其费用超过了100万美元。7
到目前为止，一个连公司内的怀疑论者都深信不疑的事实是，微软在产品开发管理方面困难重重，各小组必须更为规范才能重获消费者的信赖。盖茨亲自上阵，主管应用软件部门，但几个主要项目仍然是一团糟。除Excel外，Windows的其他新应用软件开发停滞不前。而一个数据库程序（别称Omega项目，以后演化为Access）和一个Windows的项目管理应用软件则面临重重困难。
Opus项目，后来更名为Word，使得工作人员杜撰出了一个现在相当流行的新名词“无穷错误”。它描绘的是这样一种情形：测试员寻找缺陷的速度远远快于开发人员修正缺陷的速度，而每次缺陷修正以后，又会产生新的缺陷。如此循环，错误层出不穷，导致完全无法预计进度和最终产品的上市日期。如果暑假实习生在返回大学前未对编写完成的代码进行充分测试，或由于开发人员从一个功能或项目调入到另一个，从而导致来不及完成测试工作，都会引发这类问题。在微软曾经经历过的“迟缓而臃肿”的集成阶段和测试阶段里，开发人员必须面对旧代码，但问题在于，他们可能已经完全忘记代码的具体内容，或者其作者已不知去向。在重写代码以修改数不胜数的错误时，开发人员常常又会引入无数新的错误。8微软的测试主管罗杰•舍曼（Roger Sherman），向我们回忆起微软历史上这一段黑暗的日子：
人们得到消息说他们实际上把事情弄得一团糟……他们像驾着一辆飞驰的赛车，不时地撞到墙上，不过现在他们总算知道墙在哪儿了……人们认识到不管程序是多么地充满想象力或创造力，也不能随意地将它们拼接在一起。他们必须从各个角度全面地分析问题、外部因素，他们必须保证编写出可测试的代码，并且在有限的测试资源内完成工作……他们得编写稳定性很强的代码。从Omega和Opus的反面教训中，人们获益匪浅，并逐渐走向里程碑式的研发过程。我认为他们从Access比从Word的教训中学到了更多的东西。缺陷数据库是如此的硕大无比，以至于几乎不可能存放在一个服务器中。而活跃缺陷多如牛毛，竟使得测试小组几乎无事可干：“何苦呢？开发部门处理完积压待办事项得花2年的时间，到那时他们才能赶上咱们现在的进度。”测试员几乎把所有时间都放在自动测试和开发自动化工具上。终于，有人得出结论，所谓的出品时间都是不现实的，项目也混乱不堪，我们永远也不可能按时推出产品。这大概意味着所有产品的定义……也是虚假的。开发人员不得不大步后退，并专注于一小部分产品使之性能稳定……他们削减了许多开发计划，回退到具有稳定的代码基础并且可以继续开发的阶段。
为了使项目不再失控，盖茨决定到公司外招贤纳士，物色更多的管理人才。1988年7月，在IBM服务了23年之久，领导其软件战略和业务评估工作的迈克•梅普尔斯投入微软门下。他还是开发OS/2 和图形显示管理器（Presentation Manager，IBM PC机的早期图形界面产品）的核心人物9。具有讽刺意味的是，微软员工们经常对IBM的一些现象嗤之以鼻，比如，聘用过多的非熟练开发人员充任程序员（微软员工戏称之为“蠢驴编程”），开发过程过于连贯且封闭等现象。10微软经理们十分自信地认为，IBM得汇合成千上万个员工才可能完成的工作微软集中几百个高级开发人员就可以达成。不过梅普尔斯看起来和那些“蠢驴”不同，他很有天分。盖茨希望通过他使得开发过程安排更为合理，以便微软能有效地构建、推出产品并控制其质量。1989年的一份重要备忘录总结了五月份“休假会”以来的讨论（由戴夫•穆尔组织），促使产品小组勇于采取正确的行动。这份由Word组开发经理克里斯•梅森（Chris Mason）撰写的“零缺陷代码”的备忘录，主要反映了公司现状及即将采用的新开发过程。
而在操作系统领域，微软的Windows同样步履艰难。正如盖茨的传记作者在1990年Windows的第三个版本问世以后所观察到的那样，产品依然问题重重：“微软的测试者们又一次未能找出所有问题”。比如说，无法将程序安装于某些类型的机器上，网络老是出错，鼠标无法使用，某种第三方磁盘管理软件的数据被破坏，还有普通的文档错误……软件行业中流传着这么一则笑话，说微软产品直至第三版本才开始进行beta测试。”11
盖茨及其他微软员工还担心另外的问题。股票期权已成为公司资金来源的一个不可或缺的组成部分，但是经常性的产品迟延上市导致微软的股票价格不断下挫。产品的迟延与反复也使广大客户包括OEM与零售商在内，都迷惑不解、大失所望。有一位股东甚至因微软未能及时推出Word（该产品占微软总销售额的20%）而起诉微软。最后1990年，公司在耗费150万美元后才平息此事。（该案件控告微软的管理人员故意隐匿迟延交货的消息。）至于数据库项目，当1988年梅普尔斯到任时，原定3个月即可完成。而在一年半以后，他与盖茨取消了这个项目。12
微软备忘录
送达：应用软件开发人员和测试人员
作者：克里斯•梅森
日期：89/6/20
主题：零缺陷代码
主管：迈克•梅普尔斯，史蒂夫•鲍尔默，应用业务单元经理和部门领导
在5月12日和13日，应用软件开发部的经理们与他们的项目领导、迈克•梅普尔斯以及其他的应用和语言的代表们召开了一次“休假会”活动。我的讨论小组对零缺陷编码这一技术进行了深入调查与研究。这个备忘录就记录了大家所达成的共识……导致我们产品错误越来越多的原因是多方面的。事实上，我们的工作越来越复杂，但我们并未相应地改变我们的工作方式以应对这种改变……列举出一大堆问题只是为了让大家清晰地认识到，导致这一系列问题的根源，是我们现行的管理制度，而不是我们的员工……我们的进度设计方式和企业文化鼓励我们用最少的工作来完成一项功能。只要在演示时它一切正常，那么我们就觉得完成了这项工作，所有的人也都这么认为，于是这项功能就算是按照计划圆满完成。几个月以后缺陷不可避免地出现了，而我们却认定它与原来的工作毫无关联……当不能按时完成进度规定的任务时，我们便想投机取巧……产品的日趋复杂怎么会成为滋生缺陷温床呢？问题就在于我们并不了解各项工作成果如何整合在一起正常工作。无论是新产品的生产，还是旧产品的修改，都存在这个问题……我真正的意思是：你们的目标应该是每天生产可以使用，随时可以推出的产品……但开发人员无法完全排除错误，这就导致缺陷的存在在所难免。当出现缺陷后，你必须仔细分析并立即着手解决……我们每天主要的工作就是编写代码，而出现缺陷就意味我们主要工作的失败。成百上千的公司和个人用户都依赖于我们的产品：产品缺陷将会使他们蒙受时间与金钱上的巨大损失。可以想象，当电子表格、数据库或者文字处理器中出现问题时，就会使一家公司被迫停业。所以，我们必须开始更加慎重地处理这个问题。
应用和系统部门不断出现的问题，为梅普尔斯改革方案的推出和贯彻创造了一个极为有利的环境。他特别要求项目中的分组跟踪领先市场的竞争对手及产品，如WordPerfect、Lotus1-2-3和Harvard  Graphics。他还要求每个小组对软件开发、测试和项目管理的过程进行定义并不断加以完善。在与盖茨深入讨论后，梅普尔斯把应用部门分成五个业务单元：  办公、分析（Excel），图形（PowerPoint），数据访问（Data Access）和入门级软件（Works）。这些业务单元现在已成为了彼此独立的利润中心——能独立支配各种资源来进行程序管理、开发、测试、营销（产品管理和产品策划）和用户培训——这与IBM在1981年推出最初PC机时采用的业务单元形式十分相似。IBM的这种独立业务单元的实行，在当时获得了巨大的成功。梅普尔斯在为IBM业务单元服务时，便获得了盖茨与微软公司的青睐，他后来回忆起他对微软重组的所施加的影响时说：
这实在很有趣。当我一来到公司，我就参加了所谓的资源计划会议。开发、营销、程序管理还有测试部门的头头们都来了，他们将对一个项目进行详细的审查。每个星期每个项目都会有所变动；有的项目已经迟延了18个月，但还想将继续往后推迟三天，这时他们会求说：“嗯，这个项目需要更多的测试人员。”于是我们让测试员停下手头的工作，将他们派驻到另一个项目。第二周，我又召开资源计划会议。上周被抽调走人员的小组也陷入了困境，不得不要求增援，我们只好再次进行调配。公司内部员工经常被东抽西调，人们根本无法专注于一个固定的项目。于是，我们提出了构建业务单元的想法。从表面上看，它丧失了让人员自由流动所产生的高效率。比如，Word的测试小组就只为Word工作，即使他们无事可做也不外调。事实上，业务单元的建立证明了一旦掌握了资源库的连续性，就可以从容地进行计划与决策。与此同时，它赋予了员工更加广泛的权利与责任，促使一大批管理人才脱颖而出。它使我们更加注重用户并跟紧其竞争对手。总之，微软现在的组织机构就是以小型业务单元为基础而构建起来的。
微软一直沿用这种基本的组织结构，但有所改进。1992年，盖茨将史蒂夫•鲍尔默调离操作系统部门，转而让他领导销售和支持集团。盖茨还创建了一个不断扩大的全球产品集团，由迈克•梅普尔斯来监督应用和系统这两大领域的产品开发。这个任命使梅普尔斯有机会管理操作系统组，直至三年后年他辞职为止。而在那一年，微软公司再次将应用和操作系统这两个部门的职能分离。1993年，微软还集中了营销工作，并建立了Office产品单元。此外，微软又任命了关键职能领域的负责人，如开发、测试，程序管理以及用户培训；自1994年以来，这些职能组都必须向产品开发的总负责人汇报工作。而这些总负责人并不直接监督项目的实施，也没有明确的责任分工，他们的主要工作则是帮助各小组总结并分享最佳经验。盖茨对公司新的组织的增减变动作了如下回顾：
这是一种权衡与取舍，所有与组织建设相关的事情都属于权衡与取舍。它优化了产品制造的团体精神：如何处理我们的产品？在这个产品中我们要做哪些取舍？我们推出产品了吗？产品顺利通过复查了吗？就这样，渐渐地，专业化的观念被破除了。
在产品组织上存在着两大缺陷：首先，虽然公司在面试、新工具开发、新方法运用等许多方面都有着很好的经验，但显然各技能领域没有很好地共享这些经验。如果你所在的小组情况比较极端，比如仅拥有一位测试员，那么怎么能求全责备，你不能在考察过后指责他：“喂，你怎么能连最新的有关测试的书籍都没有看过呢？”所以我们培养了一组人数不多，但熟知测试技术最新动向的员工。其二，代码共享极为不易。虽然存在不足，但也远比以前要好得多。如果在过去的8年中，我们不使用业务单元来规划公司资源，微软早就分崩离析了。
微软公司组织体系所带来的一个益处是它给各小组提供了充分的自由，每个小组就是一个相对独立的开发中心，致力于把各类产品推向特定的市场。正如克里斯•彼得斯所解释的：
虽然我们将业务单元假想为一个个的微型公司，不过实际上它们是不折不扣的产品开发中心……那里没有负责销售和财务的部门——这类职员早已被调离。在业务单元内工作的每一个人的职责都是完全相同的，就是不断地为公司推出新的产品。他们不需要编制代码，也不必进行测试或撰写说明书，他们唯一的工作就是为公司推出产品……在这里，你最好不要编码，如果我们不通过编码就能够赚足美元，那么何乐而不为呢？
受1989年公司“休假会”活动的刺激，微软的经理们现在也特别强调开发人员与测试员在自己所属的小组内至少要工作一个产品周期。他们要求开发人员努力工作，争取产品“一次到位”，并且“以质量为本”。为了达到上述标准，微软采用了“每日构建”与多里程碑技术——这就是同步-稳定过程的精华所在，我们将在第4、5章内介绍这些内容。

现行的管理结构和组织体系
自1992年首次创立“公社制”领导制度——总裁办公室，此后，它逐步演化成了微软当前位于董事会之下的管理体制。1995年7月迈克•梅普尔斯退休后，公司又进行了一次改组。通过这次改组，现在比尔•盖茨身兼主席和总裁两个职位，此外还有五位主管负责微软的四大业务集团：集团副总裁内森•迈尔沃德（前任高级技术部门领导）和皮特•希金斯（前任桌面应用部门领导），二人共同负责新成立的应用和内容集团；集团副总裁保罗•马里茨（以前负责产品和技术战略）领导新成立的平台集团。这两个集团构成了微软的产品、研究以及开发的基本框架。执行副总裁史蒂夫•鲍尔默掌管销售和支持集团，而罗伯特•赫博尔德（Robert Herbold）则负责运营集团并同时担任首席运营官。部门副总裁与总经理们对这些集团领导们负责，并管理产品单元经理，而产品单元经理则直接领导职能小组经理，再下面便是产品小组组长。
如图1.1所示，应用和内容集团下设四个部门：桌面应用部门、用户服务部门、联机系统部门以及研究部门。平台集团也分为四个部门，分别负责个人操作系统、商用系统、开发人员与数据库系统、高级用户系统。大多数部门自身就拥有市场营销机构，其职员由产品策划人员担任。它们还共用着一个可用性中心实验室（由30～35个职员组成），以测试产品功能与原型。销售和支持集团下设有许多独立的部门，它们分别为其他的公司和部门提供服务，如全球的OEM销售商（主要包括AST、DEC、Dell、康柏、富士、Gateway、IBM、NEC、好利获得、Packard Bell、东芝、优利、Zenith等）、产品支持服务（简称PSS）、国际化经营部门（主要面向亚洲）、高级技术销售部门、战略企划部门（向大公司销售特殊产品并提供咨询服务）、北美及欧洲销售部门等。运营集团则负责财务、磁盘生产、说明手册及相关书籍的出版（微软出版社）、信息系统和人力资源管理。

图1-1  微软公司组织体系（1995）
在平台集团内部，由个人操作系统部门生产Windows和MS-DOS这两个系统。商用系统部门则负责Windows NT与OLE（对象链接和嵌入）技术的开发，它还包含一个独立的产品单位以开发工作组应用软件（负责电子邮件及PC机服务器系统）。开发人员及数据库系统部门开发编程语言（如Visual Basic）、编程支持工具以及数据库产品（如Access和FoxPro）。高级用户系统部门下辖互动电视系统、宽带通信及多媒体应用技术等几个子部门。在应用和内容集团，桌面应用程序部门下设有Office产品单位。它负责监督Word与Excel产品单位并与图形产品单位（PowerPoint）紧密合作，以使这三个产品能够在Office应用软件套装中更好地协调工作。这个部门同时也生产Project这种流行的项目管理工具。用户服务部门包括“微软家用软件”产品组，负责生产家庭理财软件（Money）以及为家庭娱乐和教育设计的多媒体应用软件；同时也生产一款名为Works的套装软件，它集文本处理、电子表格以及数据库功能于一身，主要提供给初学电脑的人使用。联机系统部门开发和管理新的微软网络产品。研究部主要负责探索新的产品和程序设计技术，并与其他各产品组紧密地协同工作（参照附录2、3中关于微软主要应用产品与操作系统的描述）。
图1.2清晰地展示了微软是如何组织产品单位与专项功能的。该部门包括多个产品
 
图1-2  桌面应用部门（1995）
 
单位，每个产品单位一般都设有五个职能小组，每个小组都由独立的经理管理，他们分别负责程序管理、开发、测试、产品策划（由委派到产品组的产品经理负责）及用户培训。微软会将这些小组按照其生产的产品划分为几个区域。例如，在Office产品单元成立之前，Excel单位的开发人员被划分到五个小组中：重算/功能、图表、打印/格式化，加载项（一种特殊的软件程序，可用于统计分析或拼写检查等）和宏/转换。进行用户培训时某些产品单位会将他们的小组集合，以准备培训手册和联机文档（例如Help菜单的撰写）。在桌面应用部门，由Office产品单位的用户培训小组来为Word、Excel和PowerPoint准备培训手册。与此同时，在开发组内还包含另外一些小组，他们与微软的海外分支机构一起准备产品的非英语版本，而产品管理组一般都有国际化经理来主管国外的市场销售。例如，微软在日本有一个分部（K.K.），主要负责制作日文、中文及朝鲜文版本的桌面应用软件，该分部直接向部门经理负责。
表1.2按职位将微软的17000位员工进行了分类。大约有30%的员工（5100人）在36个海外分支机构从事销售、产品支持以及产品本地化的工作（海外销售额占微软零售销售额的70%左右，请参见前言中的表2）。在美国本土工作的13300名员工中，大约有1850位程序开发人员，1850位软件测试工程师，400位程序经理与产品策划人员。大约有2100位员工从事用户支持；4000人从事市场、营销和咨询工作；600人从事用户培训工作；2200人从事运营与行政管理工作；300人参与研究工作。
表1-2  微软员工的大致分类（1995）
数 量 职能与领域
400 程序经理和产品策划人员
1850 软件设计工程师
1850 软件测试工程师
2100 客户支持工程师
4000 市场、营销与咨询服务
600 用户培训
2200 运营与行政管理
300 研究
4500 海外人员（各个职能部门，其中包括400名开发人员）
17800 总计
资料来源：开发部门主管戴夫•穆尔于1995年7月18日所发的电子邮件。
规模稍大的产品单位，如Office、Windows NT和Windows，每个单位都有三百至四百名员工，其他的一些产品单位也都拥有两百名以上的员工。一般来说，操作系统开发组拥有的开发人员与测试人员比应用软件开发组更多；而应用软件的各个功能很直观，其市场定位也多瞄准非技术型顾客，因此它在产品策划与程序管理方面需要更多的人才。总而言之，表1.2的这些数字反映了微软在过去十年来的巨大变化。想当年，在20世纪80年代早期，Excel、Word、MS－DOS/Windows等部门只有十来位或更少的开发人员，整个公司也就几十人而已！产品支持服务部的员工数也从在20世纪80年代早期的十来个，发展到现在的两千多个，为产品开发组提供了宝贵的信息反馈（请参见第6章）。微软素以高效率著称的市场营销队伍，也由十年前的寥寥数人发展到如今的三千员工，而且其中还包括数百名帮助公司安装数据库和网络系统的顾问。
市场营销开支（包括广告费用）是微软最大的一项支出，大约相当于1994年营业收入的30%。运营成本（包括产品支持）大约相当于1994年营业收入的15%，而研究与开发成本（看作日常费用）为13%，还有3%的一般管理费用。扣除以上各项成本支出，微软的税前净利润为其营业额的37%（见第三页中的表1）。研究与开发、市场营销以及产品支持等各项开支的急剧增加，使得盖茨、梅普尔斯与公司其他高级经理寝食难安，千方百计想办法来削减这些费用——比如，实施更为系统的工程制度，促进产品组之间的合作，提高产品质量与易用性（用以削减用户支持的开销）。随着产品组之间的依赖程度的加深，产品的规模和复杂性不断增加，以及保持产品新旧版本之间兼容性的强烈需要，这一切都给公司管理留下了诸多难题。有时，它们甚至使微软为在预定日期内推出产品而付出的种种努力付之东流。Office 4.0与Windows 95就是因为上述原因而迟迟未能问世，微软公司也一度陷入困境，对此后面我们还会详细讨论。

古老的博弈——系统部门VS应用部门
1992年，在微软高级管理层的变动中，最引人注目的便是公司将系统和应用部门正式地整合在一起。在过去，各项目组都直接向盖茨进行汇报，而现在它们则划归迈克•梅普尔斯统一管理。由于这两个部门之间长期排斥对方，但是它们之间的战略依赖性又变得越来越高，因此将它们整合在一起很有意义。应用部门只有深入了解Windows如何运行才能写出好的应用软件，从而对Windows与一些技术（如OLE）的演进施加关键影响力；另一方面，如果以微软为首的应用软件制造商不再编写应用软件，那么新的操作系统，如Windows NT，就绝不可能在市场上占据一席之地。问题在于，历史上微软的系统与应用部门从未和睦相处过。虽然系统软件往往更难开发与测试，但系统部门的员工（尤其是Windows 3.1和Windows 95的开发者）与在应用软件部门工作的同僚相比，管理却更为松散懈怠。
梅普尔斯曾经成功地使应用部门管理更为规范，做到以质量为本。他对系统部门也进行了相同改革，这一行动一直延续到1995年。虽然他的举措赢得了一部分经理的支持，如戴夫•卡特勒（在加入微软前在DEC工作），但遗憾的是，他最终没有完全获得成功。他总结教训时说，他将重点放在用户问题与产品进程上，但由于受两个基本因素的影响，这种作法更适用于应用软件部门而非系统软件部门。首先，操作系统必须能够在各种不同类型的硬件上正常运行，而对各种不同硬件进行测试需要“冗长及大规模的beta测试”（指从用户的角度对初级产品版本进行测试），以便让用户能够使用机器与应用配置的不同组合来测试系统产品。但这种测试的进程难于预测。其二，梅普尔斯发现操作系统项目一般需要更多的员工，其组件也与许多不同产品相互关联，这使得项目管理非常“笨重”，他说：“应用软件部门效率较高的一个原因是他们能够以小组形式工作，这一优势使得交流更为便利，依赖性也较少。但系统软件部门的队伍庞大，相互依赖性强，因此这两个部门的工作过程截然不同。坦诚地说，应用软件部门的小伙子比系统软件部门的小伙子更易享受到工作过程的驱动，这并不是我的主观臆断，而是事实。”
这便导致了在系统软件部门内部经常会出现一些混乱局面，这种状况甚至波及到了形象极佳的Windows 95项目。不过Windows NT却是一个例外，正如梅普尔斯所说的：“哪怕是在系统软件部门内部，各产品开发过程之间的差异也很大。Windows NT组的主管戴夫•卡特勒管理得就非常严格，他们专门准备了一本工作簿并记载该项目的所有事项……这是一种非常严格的开发程序。而Windows组与DOS组却与之相反，他们更像一帮持枪抢劫的乌合之众，毫无章法可言。他们常满不在乎地说：‘让我们开始编程吧，看看会出什么结果’。”不过梅普尔斯认为所有的系统软件组都必须集中更多的精力以减少产品缺陷，并提高完成日期的预测准确率。
虽然两个部门泾渭分明，两者间的界限也正在逐渐弱化，但两方的经理们都认为系统软件部门比应用软件部门问题更多。克里斯•彼得斯在成为Office副总裁之前，是MS-DOS 2.0和Windows 1.0（还包括不同版本的Excel和Word）的开发人员。他曾强调公司在编写说明书和项目管理方面缺乏有效的控制：“你会发现系统软件部门比应用软件部门更加缺乏组织性……我从不认为他们拥有合适的说明书……他们会说，我们在这项目中采用的是里程碑式的技术，但当你询问他们在项目中总共有多少个里程碑时，他们便会无言以对。”Windows NT的高级产品经理理查德•巴斯同意克里斯的上述看法，他说：“当我在1990年刚加入到微软时，就发现应用软件部门和系统软件部门在管理方法上存在着巨大的鸿沟。事实上，从系统软件部门来看，我们一直都时刻关注着应用软件部门，并认为他们管理有方，在他们那里开发过程能得到更为有效的控制。”
史蒂夫•鲍尔默独特的管理风格，是系统软件部门特殊文化氛围形成的一个重要原因。多年以来，他更偏向于营造相对宽松的环境，不设独立的测试组，给予程序经理和开发人员很多创新的自由空间，甚至还允许在开发末期对产品进行改动。MS-DOS与Windows的前任测试主管戴夫•马里茨（现在已离开微软），曾经这样评价他的老上司史蒂夫•鲍尔默：“他十分精明，不过在他下面做事很困难，因为他总是那么随意……他绝不是那种做事井井有条的人，这也导致了他无法控制系统软件部门。”Office组的高级程序经理迈克•康特，指出了系统软件部门形成独特文化的另一个原由：
我认为他们现在仍在进行着许多观念的转变，其中之一即从面向OEM转变为面向最终用户……从一定程度上来说，这正是微软的历史和文化。史蒂夫•鲍尔默是系统软件部门的最高权威。他不是那种有官僚做派、有板有眼的人，正因为如此，规范化并没有影响到系统软件部门。另一个原因就在于他们倾向由技术来主导一切，开发人员拥有更多的发言权。但缺乏严格组织的开发人员却很不理性，如果依着他们的性子去做，那就可能无法顾及市场需求、用户支持或其他的一应原则。所以系统软件部门一直没有出现好转。尽管应用软件部门曾经一度也如同美国西部大开发一样毫无章法，但迈克•梅普尔斯却将它治理得井井有条，相比之下，系统部门却从没经历过这样的约束。不过以上的观点来自于应用软件部门的一位员工，所以你可以对此持怀疑态度。尽管史蒂夫•鲍尔默已经离开了系统软件部门，但他在公司内具有很高的威望，因此他仍然保持着强大的影响力，除此之外，盖茨更是对他言听计从……但迈克却是一位善打持久战的人物，他不会初来乍到就发号施令：“好吧，让我们打破一切陈规，按我的方式开始干吧。”他的做法与之正好相反，我想他会潜移默化地改变身边的事物。
微软的员工大都赞同康特的这一观点，并将这一观点归结到为何系统和应用两个部门有诸多不同的原因之中。人们甚至还提出了一种地域上的差异解释：应用软件部门坐落在整个微软园区内更具现代风格的北部地区，一条大路把“宏伟豪华的棕色大厦与南部郊区”分隔开来（戴夫•马里茨如是说）。尽管应用软件部门的条件相对更为优越，但盖茨仍然将他的办公室与系统软件部门设在一处。产品的不同技术特性也成为了导致差异性的重要的一环，不过由于操作系统中用户界面和功能变得越来越重要，这种差别已在逐渐缩小。产品开发主管克里斯•威廉姆斯认为系统软件部门的员工在取得更多的实践经验后会逐步改变他们的立场，他说：
系统软件部门的员工始终认为一个产品在成熟之前不应进入市场，因此他们采用了截然不同的软件开发方法……我想你必须切身经历过三、四个项目周期，就能数次体会到糟糕的管理过程所带来的痛苦……而一旦考虑到那些在系统软件部门工作的员工，他们的的开发周期……比应用软件部门的要长两倍。刚从Windows NT组离开的家伙跑到我这儿来抱怨：“我们再也干不了！”至于那些在Chicago（即Windows 95项目）组工作的同仁，我估计等产品推出以后也会有一部分跑到我这抱怨相同的话……这便是这两个部门的本质区别。我认为另一个重大区别就在于，在系统软件部门内负责具体项目的人都是那些曾经获得过成功的人。毫无疑问，Windows 3.1是一个相当成功的项目，人们正是用老式的方法成功地创造了这个软件。既然它并没有遭受失败，你怎么能指望他们尝试着进行改变呢？

新兴市场和技术
虽然操作系统与应用软件给微软带来了丰厚的利润，但微软公司的业务范围并不仅仅局限于这两大领域。新兴的消费者产品和联机系统是增长最为迅猛的两个市场，而这两个部门却有着另一种截然不同的文化，他们更关注于如何将前沿科学技术同消费者的日常生活习惯结合起来。在最近的一次采访中，曾担任微软高级技术主管的集团副总裁内森•麦尔沃德先生向大家描述了他的三项主要工作：（1）帮助盖茨制定公司的技术策略，比如哪些技术应该获得授权、购买或者自己开发等；（2）创造未来的产品；（3）开展研究活动，这主要集中在计算机科学领域，既支持微软的各个产品组，也使盖茨对未来个人电脑的构想成为现实。
从更广泛角度来看，麦尔沃德所扮演的角色就是时刻准备着为微软进行“思维转换”，正如在数字信息领域发生的一些事情：
许多公司都有自己的拳头产品，但却难以再进一步地发展，这正是困扰着大多数公司的一个传统问题。微软的特别之处就在于它从来都不惧怕改变自己的拳头产品，其中主要的原因就是我们的高级经理都是技术型人才。我们精通技术，归根到底，正是技术在推动着整个产业不断向前发展。也许你精于营销，但是无论你有多么精明，如果不懂技术就无法保证你在技术革命的浪潮中安然无恙，它会在倾刻之间就将你席卷而去。13
高级用户系统部门目前是平台集团的一部分，它极为重要。通过同研发、宽带通信和联机系统等部门的紧密配合，它开发了在家用和信息高速公路中使用的多媒体产品并打入市场，这些产品包括交互电视和微软网络等，此外，它还致力于研发未来的产品。这个部门的功能架构与其他产品单元十分相似，都设有程序管理、开发、测试与产品策划等机构。不过，在促进创新与探索新思路方面，它的各职能部门间的职责分工并不是非常明确。14
里克•拉希德（Rick Rashid）是卡耐基-梅隆大学计算机科学系的前任教授，他掌管着微软的研究部门，其中也包括调研交互式电视系统。这个部门大约由250位科学家组成，每年的预算支出至少有1.5亿美元。这个部门的主要工作目标是研究那些在5~10年之内就能商业化的新兴技术，同时也包括一些有潜力的短期项目。研究人员们正在研究能提高编程效率的工具、面向操作系统和用户界面的人工智能应用程序，计算机决策系统，语音处理和识别技术，超级计算机的设计，视频点播服务器技术，运用视频、音频、文本等媒体信息创造交互电视、多媒体产品和小型信息系统（例如“钱包PC”）。拉希德解释说，盖茨本人以及其他领导认为公司必须拥有更多的专有技术，而且微软的规模已经足以支撑一支精良的研究队伍。：
从本质上来说，比尔希望看到有一个部门能推进特定领域的研究工作……我们希望自己的研究部门是世界一流的，与任何一位竞争对手在特定的研究领域相比，我们的能力要与他们一样出色甚至更胜一筹。比尔将这视为一项长期的奋斗目标。由于微软已经及时地赶上了同行，并达到了一定的规模，它有能力达成这一目标。如果公司要想立于不败之地，那么就必须开发独有的思想和技术，这使得以上目标的完成变得越来越重要。
研究部门已经为诸多产品作出了卓越的贡献，比如新的联机服务，Windows 95、NT等新的操作系统，以及提供“智能”帮助并使用户快速掌握Windows操作的新用户界面等等。迈尔沃德和拉希德都相信微软能创造出新一代的技术与产品。他们希望自己的研究部门能够超越许多领先公司所拥有的中心实验室。比如施乐公司（Xerox）的帕罗阿图研究中心（PARC）一直在个人计算机和图形用户界面方面处于领先地位，但是它始终未能成功地将其研究商业化；IBM在将它的研究人员发明的计算机技术成果产业化方面也存在着重重障碍（如RISC）。
拉希德解释了他们为何如此自信的原因：“施乐公司的PARC的问题并不是研究中心自身的问题。它没有做错任何事，其研究人员的目标也很正确。关键的原因在于他们就职于一个墨守成规的打印机公司，根本无法在PC领域有所建树……我认为这是一个教训，它告诉我们只有当公司充分运作研究人员的研究成果，才能充分地发挥这些劳动结晶的作用。”迈尔沃德补充道：“微软与其他公司的不同之处在于，它的研究机构与公司的最高决策CEO联系紧密。其他公司的老式实验室则受限于‘象牙塔综合征’，同其他部门完全割裂开来。我能直接向盖茨汇报工作，盖茨也经常参与我们部门的决策，与此同时，我还可以参与公司内其他部门的决策。”15（据报道，盖茨花费三分之一的时间同迈尔沃德一起构想未来的产品。16）

原则三
聘用深刻了解技术的管理者——既懂技术又善经营
前文涉及到的微软高级经理（比尔•盖茨、迈克•梅普尔斯、史蒂夫•鲍尔默、内森•迈尔沃德、保罗•马里茨、皮特•希金斯、克里斯•彼得斯、里克•拉希德等）也许存在弱点，但毫无疑问的是，他们对微软的发展起到了至关重要的作用。事实上，盖茨与其他经理经常鼓吹他们只聘请聪明人来从事经理、开发人员以及测试人员等工作。但“聪明”到底代表什么意思呢？比尔•盖茨认为，所谓“聪明”就是能够迅速而有创见地理解并深入研究复杂问题，正如他在1994年接受采访时所解释的那样：“聪明人一定反应敏捷，善于接受新事物。他能迅速进入一个新领域，给你做出头头是道的解释。他提出的问题往往一针见血，正中要害。他能及时掌握所学知识，并且博闻强记。他能把原来认为互不相干的领域联系在一起使问题得到解决。他富有创新精神和合作精神。”17盖茨自身便显示出这些可贵的素质，并积极在微软的经理、职员和应聘者中挖掘此类人才。
随着微软的不断发展与壮大，盖茨已经以私人身份面见了上百名程序员、经理以及技术专家，这些人进一步完善了盖茨的技术与知识体系。他还从这数百人中挑选了一小群精英组成了一个非正式的智囊团，以辅助他作出决策并监督关键项目和创新的实施。此外，盖茨还习惯于提拔年轻的程序设计专家进入高级管理层。但随着公司的快速发展，这一习惯也导致微软内部十分缺乏既懂技术与业务又擅长人事管理的中层经理。

智囊团
微软智囊团的核心大约由十来名专家组成。除管理关键产品领域和公司的创新之外，他们还组成了一个非正式的监督组以评估其他员工的工作情况。也有许多在各项目工作的高级技术人员组成了范围更广的智囊网络。尽管其中大部分人是微软建立之初便一直在这工作的元老，但来自于竞争对手或个人计算机领域外其他新技术领域的专家也在迅速加入其中。戴夫•穆尔从不认为自己是智囊团的核心成员（“我比那些人要平凡得多”）。他认为尽管智囊团的成员不属于任何部门，但他们以其非凡的知识与经验而获得了广泛的认可。他进一步解释道：“它很不正式。你成为其中一员的主要原因便是你所处的职业地位。每个开发人员都有一个事业阶梯评级……而每一个职能领域——无论是开发、测试、程序管理，还是用户培训，都有其自身的事业阶梯。”
微软智囊团由公司的大多数高层领导、高级开发人员和程序经理组成。18在行政人员中，执行副总裁史蒂夫•鲍尔默（39岁）是盖茨在哈佛的同学，在1980年加入微软之前，他曾在斯坦福学习过一年的管理。虽然在今天看来他可能并不是管理系统软件部门的最佳人选，但当20世纪80年代中期的Windows项目陷入困境，迟迟无法交付时，他不惧困难，挺身而出，承担了领导研发的大任。随着产品销售与用户支持领域变得越来越重要，他现在主管销售和支持集团。另一名集团副总裁——内森•迈尔沃德（36岁）则是普林斯顿大学的物理学博士，他师从于诺贝尔奖获得者斯蒂芬•霍金。当盖茨在1986年兼并他创立的软件公司后，迈尔沃德也随之加入了微软公司。他目前负责公司网络、多媒体、无线电通信及联机服务等。
集团副总裁皮特•希金斯（37岁），在取得斯坦福大学的工商管理硕士（MBA）学位之后，于1986年加入微软。他以前主管桌面应用程序部门，现在与迈尔沃德一同负责新成立的应用和内容集团。集团副总裁保罗•马里茨（40岁），是1986年就加入微软的公司元老之一，其主要工作是制定长期产品战略，并监督微软的操作系统软件和其他关键的用户技术的开发等。罗伯特•赫博尔德（53岁）则是一位刚加入智囊团的后来者，这位凯斯西部保留地大学的计算机科学博士曾在宝洁公司工作26年，主管管理系统部门、市场调研与广告以及技术获得部门。1994年，他戴着宝洁公司高级副总裁的头衔加入微软，由于消费者产品已成为微软发展最快的领域，他在市场营销方面引入的资深经验深得盖茨重视。
还有其他几位高级管理人员也属于智囊团。高级副总裁布拉德•西尔弗伯格（Brad Silverberg，41岁）是个人操作系统部门的经理，他于1990年从Borland公司来到微软，并领导Windows 3.1与Windows 95项目的开发。罗杰•海嫩（Roger Heinen，43岁）是负责开发人员与数据库系统部门的高级副总载。在1993年加入微软之前，他曾先在数字设备公司工作，之后到苹果公司负责Macintosh软件的开发。詹姆斯•奥尔欣（James Allchin，43岁），于1991年从Banyan Systems公司来到微软，他是领导商用系统部门的公司副总裁，目前主管Cairo（Windows NT4.0）项目。高级副总裁克雷格•穆迪（Craig Mundie，46岁）负责高级用户系统部门。在1992年加入微软之前，他经营过一家超级计算机公司——Alliant Computer Systems。乔纳森•拉扎勒斯（Johnathan Lazarus，44岁）于1986年加入微软，他是一位市场营销专家，目前担任公司战略关系副总裁。副总裁克里斯•彼得斯（Chris Peters，36岁）主管Office产品单元，该产品单元每年的销售额和利润大约占整个公司的一半。
副总裁里克•拉希德（Rick Rashid，43岁）是研究部门负责人，也是Mach的主架构师（Mach是一种基于UNIX的操作系统，用作Windows NT的一个组成模块）。在1991年加入微软以前，他是卡耐基—梅隆大学计算机科学专业的一位著名教授。达里尔•鲁宾（Darryl Rubin，41岁）是软件战略部门的副总裁，网络技术专家。他是微软的元老之一，1986年就已经加入。不过随着优秀人才的不断加入，他的影响力也在慢慢减弱。查尔斯•西蒙尼（Charles Simonyi）也是智囊团中的一员。他是斯坦福的计算机科学博士，曾经为施乐公司的PARC设计图形应用程序，其中就包括著名的“华丽”（Bravo）文字处理软件。他在1981年离开施乐加入微软，接下来的10年一直致力于引导微软的应用软件开发，如Multiplan、Word、Excel等。
在智囊团中，有些人物尤其出类拔萃，比其他人进步得更快。西尔弗伯格曾经这样评价一位年轻的同事：“克里斯•彼得斯深谙开发过程之道。他可以说是最为成功的。他的开发过程正被公司其他员工竭力仿效。毫无疑问，他是公司里最好的一个榜样。”与微软其他高级经理一样，彼得斯具有过硬的技术背景，但他曾经在公司的系统软件、应用软件与一般管理部门都干过一段时间，因此比许多人都要见识广博，经验丰富。他在华盛顿大学取得了电子工程的学士与硕士学位，并对软件工程颇有建树。1981年加入微软以后，他先后担任了MS－DOS 2.0、Microsoft Mousel.0、PC Word l.0和Windows l.0的程序员。之后大约有5年时间，他担任Excel的开发经理。由于运用了新的开发过程，他以仅比预定时间晚11天的骄人成绩，成功地将Exce1 3.0推向市场。之后他担任Word产品单元的总经理，为微软创造了好几亿美元的收入。1993年，彼得斯开始主管新成立的Office产品单元，并随之成为公司副总裁，他现在已经是微软制定开发桌面个人机战略的关键人物。
智囊团另一位重要人物是迈克•梅普尔斯（53岁），他在1988至1995年间担任公司的执行副总裁。现在他担任公司顾问，专门对有关兼并与招聘等事宜提出建议。梅普尔斯始终缓慢而又坚定有力地规范着公司的产品开发过程并减少混乱，因此对公司而言，他尤为重要。虽然梅普尔斯并不是一名开发人员，但他是俄克拉荷马大学的电子工程学士与工商管理硕士，有着相关的行业背景，重要的是他知道如何来管理手下这一批颇具创造力的技术员。当初他之所以离开IBM，一方面是因为他看到了微软的巨大潜力，同时也对IBM十分地失望。进入微软后，通过引入IBM的四项基本准则，他力争帮助盖茨摆脱繁重的官僚式的组织管理包袱。迈克•梅普尔斯首先引入的第一条准则便是包括聘用、培训、工资报酬及晋升道路在内的一整套人事管理方面的经验作法，按照他的回忆：
IBM在人事管理方面做得很好，而且一直在不断改进。他们有一整套递进的评估、监督和奖励员工的方法。微软在这方面将采用IBM的经验并加以改进。但没有哪位微软员工喜欢被检查系统、管理系统或工资提升系统给“固定公式化”……由此造成的结果便是人们总是做自己喜欢做的事，并把所有的东西都只记在脑子里而不愿提笔写下来。现在公司的规模不断扩大，公司内部开始出现分化，而且这种分化可能比我们现在所认识到的还要严重得多。所以我们开始在各组间调整员工，并树立员工工资提升和职位晋升的一套原则和制度。戴夫•穆尔便花了很多时间来具体定义一个D10开发员与D11开发员，以及他们如何提升等等……我们企图使每个人的头脑里认识到，当公司在项目组之间调动人员时，对员工的工资待遇、职业升迁等诸多方面不会有太大的差异。
第二个准则，就是培养中层管理人员，以弥补微软一直以来存在的缺陷。梅普尔斯说道：“我们经常不惜耗费时间举办休假会、经理会议等，以便进行管理开发。尽管这可能比较浪费时间，但是大家聚在一起聊天可以集思广益，并有机会谈谈自己在管理中所遇到的困难。”第三个准则，则是继续设立专项职能，例如开发、测试等，但是必须保证让员工能够在部门间正常调动以获得更丰富的工作经验。梅普尔斯希望公司内能避免偏狭的思想、部门敌对以及争权夺利等等陋习，它们已经使IBM等一些大公司深受其害：
员工们的思想现在已经开放多了，开发人员也不再敌视测试人员。一般来说，各职能组之间总会存在一些隔阂，甚至会产生敌意。事实上，这些问题一旦发展到无法解决时，一些人就不得不另换一个工作岗位或干脆离开公司。不过我认为现在已经很少听到这样的一些话了，比如“测试人员一无是处，开发人员才是人才”，或者说“开发人员没什么用，营销人员才厉害”，每个小组的凝聚力也越来越强。不过公司内部体系对开发人员还是另眼相看，无论是职位、工资还是声望都向会略他们倾斜。如果你是微软的一位开发人员，那么你会觉得趾高气扬，比别人高出一头。我想事实就本该如此，这就是微软的文化所在。我们是一家技术驱动型的科技公司，公司里的大多数高级员工也都是技术人员出身。
在梅普尔斯看来，IBM公司内部冲突不断，各小组都报喜不报忧，他们总是尽量向管理层或质量保证人员隐藏“坏消息”，因此他竭力避免在微软也发生类似的问题。比尔•盖茨当然也不愿听到坏消息，而微软的一些经理也极不情愿承认错误或时间进度的延误。不过一旦盖茨发现经理们未告知他真相，他甚至会在会议上恶言相向。梅普尔斯认为员工间应该经常进行坦诚的交流，以便达到相互批评、互相学习的建设性目的。尽管盖茨的行事风格更具有对抗性，但他也赞同以上观点，他希望员工们能够敞开心扉无所保留，当产品开发出现严重问题时更应该如此。他希望大家在考虑问题时能够从公司的角度出发，而不仅仅着眼于单个项目或担忧个人的得失。与此同时，盖茨与梅普尔斯都不希望看到员工一再犯下同样的错误。梅普尔斯将他在微软的所见所闻与IBM的内部氛围作了以下比较：
在IBM内也有一些质量保证人员，不过没有微软多，并且它起着更大的审计监督的作用。每当开发部门进行一些测试工作之后，质量保证人员总会抱怨他们的工作是如此的糟糕。微软的员工角色之间的对抗性远不及IBM。IBM有意地采用这种冲突管理制度：如果能让员工表现出其特定的偏好，那么就能明晰所有的事实并作出最佳的决策。从某种程度来看，这的确是一种有效的管理方法。但微软并不这么做，我们试图让员工达成共识，并让大家从公司的角度考虑问题以顾全大局。当我在IBM开发部门时，我发现在那里只能学到如何向上级隐瞒坏消息的小伎俩……往往只有在走投无路时才会在最后时刻将坏消息汇报上去……这样所造成的结果也很明显，肯定会以悲剧收场。你总会感觉到事与愿违，也没有得到正确规避风险的经验。这样一来，当每个人都觉得项目进展顺利时，它却会突然在一夜之间完全崩溃。微软的风格是把事情都开诚布公，员工间进行畅通的交流。例如我可以收到一份Word开发人员发来的电子邮件，他会向我阐述事情进展不顺利或者其他什么事宜。总之，大家都不会认为这种交流会对微软产生什么不利的影响。
梅尔普斯的第四个准则便是：一个软件公司必须为产品开发定义一个规范流程。他说：“如果你在IBM工作，你会觉得流程很有价值但也有不少问题。但拥有一个流程至关重要，每一个特定的组织或单位都必须有自己的特定流程。”梅普尔斯回忆道，自从1989年的休假会活动以后，他和公司其他高层领导决定“每个小组只要能找到自己的流程并能持之以恒，便可以定义他们自己的流程。”虽然他希望能够发现一个可复用的开发流程，但他并未奢望能够找到一个适用于微软所有小组的标准开发流程。每个业务单元的核心人物都努力记录下他们开发与测试软件的最优过程。大约一年半之后，在公司内部达成了一致意见，正如大家梅尔普斯所说“虽然人们依然觉得在开发项目时应保持一定的自由度。不过我认为我们已经形成了几个基本的处理方式，而且这几个基本原则已经逐渐渗透到整个公司，正是这些基本做法推动着公司向前发展。”下面是梅普尔斯列出的一些通用原则，我们将会在后文中讨论盖茨所列的原则：
 由员工自己制定时间表
 为经常发生的意外延误预留一些缓冲时间
 假设可能发生变化，因此不要过早地完成说明书以免浪费时间
 采用里程碑式的管理方法，从最难的问题入手
 将用户问题置于技术或流程之上
 对员工实现合理配置

技术过硬的经理
盖茨与公司其他的早期领导一直致力于提升技术过硬的员工来担任经理，而且这一举措还不仅仅局限于开发部门之中。里克•拉希德在卡耐基—梅隆大学任教时，常常接触一些出色的计算机科学系的学生，但当他作为一个中立的观察家接触微软时，也不禁为微软高级员工的高超技术所倾倒。他说：“当我第一次访问微软时，就发现几乎整个管理层都由技术出众的人员所组成，这令我记忆犹新。这种情况在整个计算机行业非常少见，很少有公司会让技术人员担当关键的管理职务。”戴夫•汤普森（Dave Thompson）在获得康奈尔大学的学士和硕士学位以后，曾在DEC与Concord Communications工作了13年，1990年他加入微软并主持Windows NT的网络设计。他曾说：“微软的一个长处便是它的经理们都是技术型人才，即便在最高管理层也是如此……我认为经理确实应该由技术人员来担任。小组长，即位于第一线的经理们，绝对应当编写代码，并且能够弥补他的员工在开发中出现的问题。”
职能部门的经理们在升任高级领导之后，并不会放弃其原先的职能工作，这在微软是一个常识。即使像Word、Windows NT这类大型开发组的开发经理也会利用其1/3至1/2的时间来编写代码。经理们为了能够作出正确的决策并及时解决各自组内发生的问题，就必须直接掌握相关的技术。Windows NT 3.0项目的软件设计经理卢•佩拉佐里（Lou Perazzoli）不仅自己每天花费一半的工作时间来编写代码，而且要求他手下的经理们也这样安排工作时间：
我在组内制定了许多规则，即便是我也得遵循它们。其中最重要的一条便是每个人都必须编程，因此谁也别想只是坐在那儿发号施令管理别人……我发现管理者很容易失去目标，并且总是无法认识到问题与本质，而且面对问题也无法做出快速的反应。但如果你始终在编写代码，那么你就能及时地对问题做出反应，并更加关心项目的进展情况……我大概花一半的时间来查找问题并编写代码。
而在应用软件领域也有相同的观点，如克里斯•彼得斯，当他还是Word单元的总经理时就曾说过：
在微软里，职能部门的经理依然会耗费相当多的时间去干自己的老本行，换句话说，一个管理着60位开发人员的小组经理仍然会花大量的时间编程……在一些大公司内部……他们将具体的工作任务向下层转移。一旦当上了开发部门的经理，你很快就会以自己身居高位而放弃编程；同样地，功能小组组长会以自己重任在肩而不愿编程；甚至连程序员也会觉得自己繁忙得分身乏术而不再编程……虽然我的职位处于整个组的第一层，管理着270名员工，似乎不再需要做什么具体的工作，但是我还是为新版本的Word编写一个功能。

中层管理的不足
由于微软偏好提拔优秀的技术骨干担任管理人员，并鼓励他们继续在技术领域中工作，从而导致他们无法经历足够的时间成长为一名优秀的管理人才。事实上，由于微软过于忽视正规培训、晋升机制以及文本规定的作用，缺乏了这些支撑管理过程的措施之后，公司在管理上不尽人意。在戴夫•马里茨看来，微软的症结在于过于重视管理人员的技术能力而忽略了他们的管理才能。他说：
这家公司的管理太糟糕了……当我获得提升时，我竟然对此一无所知，直到有一天发现工资涨了才知道我已经升迁了。由于经理对我很是敬畏，好几次他都未曾检查我的工作。这些充分说明微软在中层管理中存在着问题……在我看来，微软缺乏一一对应的工资晋升和奖励制度。由于员工的技术水平是选拔管理人员的依据，这种政策使得员工一旦成为开发人员就会逐级晋升，最终的结果就是最好的开发人员将成为最高级别的管理人员。
马里茨和公司内其他人都认为技术管理人员应当具备超群的技术才能，否则在公司内将无法得到其他员工的尊重。但他同时也强调管理人员不应当仅仅是出类拔萃的程序设计师，他们还应当具备领袖气质和魅力，不过在微软的中层管理团队中，这样的人才实在是寥若晨星。
要想成为一位经理或团队领导——虽然经理在本质上就等同于领导——你必须具备两种必要的素质之一，如果你同时具备这两者，那么你就是一位天生的领导者。其一，你的技术才能应当超过你的同事或你将要管理的那批人。其二便是具备领袖气质，不过一般来说微软的经理人员都不属于这种类型。我认为自己拥有那种领袖气质而非技术型的管理人员，从这一点来看，我在微软里显得有些与众不同。在微软的第一线管理层中，你会发现大多数经理都不具备领导才能……而在第二线，具备这两种素质的经理人数要多一些……总之，职位越高的人员的素质也越高。在第三、四层，经理们通常既精于管理人事工作，也拥有卓越的技术才能。
梅普尔斯承认，他加入微软之后不久就发现了以上问题，他同戴夫•穆尔和其他一些高层一起力争改变这种状况。但是由于微软发展的速度实在太快，盖茨与梅普尔斯不得不放手让年轻人承担巨大责任，而公司的高层领导们也在继续提升那些具有技术背景并且在技术方面取得成功的员工。理查德•巴斯承认说，寻找合适的中层经理是微软面临的“最大挑战”：
毫无疑问，我们尚未拥有一支优秀的中层管理队伍。只有像克里斯•彼得斯那样的人才是卓越的经理，所以迈克又多了一项工作——培养更多的管理人员……我们公司现在面临的最大挑战便是发掘一支适用的中层管理队伍……但显然这项任务不可能一蹴而就……经过几年来摸索，我们终于开始重视并培养管理才能……如果你能大叫大喊并且冲劲十足，你才能成为经理，这已经形成了微软的一种文化。不过就在去年，我发现这一现象已有所改观……在过去，一旦你能真正地做出一番事业，你就能当上经理。但现在这一条件已经远远不够了。

原则四
聘用深刻了解专业技术和经营管理的一流员工
我们在下一章将会讨论到，微软已制定出了一套严格的招聘制度，以寻求到有为之士——他们应该具有高超的技术才能，渴望利用这些才能来开发并销售软件，最终帮助公司获得商业利润。那些能够融入各个专项职能组并与小组同事合作无间的候选人往往倍受关注，经理们一般都愿意挑选那些能够适应微软工作方式的人才。对于那些具有独立的思考、学习和活动能力，决策果断，不需要很多正规培训和规章制度约束就能开展工作的年轻人，经理们更是尤为青睐。但将这些聪明而又具有独立见解的人才汇聚一堂，既能给微软带来莫大的好处，但也会产生一些不利的影响。

聪明人的正面效益
在产品小组经理和职能经理之下，微软大约拥有5000名软件开发人员和测试工程师。在软件领域，最好的软件程序员在相同时间内能比同一组内效率最低的程序员多编写10到20倍的代码。吸引天才有莫大好处，对于一个掌管高比例的卓越人才的经理而言，不能从他手下的员工数量简单地判断他所掌控的资源，优秀人才使资源内涵大为丰富，其所创造的生产力难以估算。（我们可以将微软与其他的诸多软件公司进行比较。无论是在美国、欧洲还是日本，这些公司在选拔软件开发人员方面的要求都不及微软苛刻。许多公司甚至还会聘用一些其他背景并对计算机一窍不通的人，让他们在教室里接受编程训练。由于他们经验不足、缺乏培训，所以很难表现优异，在复杂的技术面前也难有“灵性”可言。19）
事实上，每一个与我们谈及这个话题的微软经理都会大力鼓吹严格挑选精英员工的价值。迈克•梅普尔斯说：“员工素质的价值根本无法估量。并非每个公司都像微软这样奢侈，能够拥有来自于麻省理工和斯坦福的最优秀的毕业生。”里克•拉希德也认为“这里的优秀软件开发人员比我所见到的世界上任何一个地方都要多，他们好像都汇集于此”。戴夫•汤普森也同意这一点：“我们公司与其他公司最本质的区别就在于雇员的素质大不相同。整个公司系统就是以员工们的聪慧和敏捷为基础而高效运转。这些人能够使你觉得手头掌握了大量的可用资源。如果你的员工在几个小时内就完成别人需要好几天才能结束的工作，你无疑就会拥有更大的灵活性。”比尔•盖茨也引以为荣：
这些最聪明的员工使公司受益匪浅，无论是程序设计、思想创新还是以及具体的编码都无可匹敌。他们是那么地精通编码。尤其在工作进程受阻、不得不小心翼翼前行的时候，能拥有一位精通所有程序设计变化的人才真是非常幸运。他们能检查出所有的缺陷，他们对各种变化所产生的影响了如指掌……由于员工们都不愿意与差劲的开发人员为伍，所以他们会想方设法让那些人明白，如果你不是真正拔尖的开发人员，那么这里并不是你适合的工作场所。
优秀的员工不仅能给公司提供用之不竭的专业技术，甚至还能减少大公司的官僚作风，使之变得相对灵活，从而像一个小型公司那样自由运作。克里斯•彼得斯就认同这种观点，他十分推崇员工独立工作并解决问题的能力：“在我们这可没有一堆到处乱窜的笨蛋，非要等着经理立下规矩来约束他们，微软聚集了大批的优秀人才，他们个个都力争向着正确的方向前进……我曾经见过这种笨蛋公司，他们乐于聘用平庸之辈并试图通过很多规矩来推动他们。我想指定这些规章对问题可能略有改善，但问题的根本原因却不在于缺少规矩，而是在于他们聘用了一批需要制约才能干活的员工。”
正因为微软存在这种聘用标准，而且强调的是技术以及推出产品的能力，因此，公司不再强求员工墨守成规、尊重职衔，员工们也不会费尽心机地争权夺利。戴夫•穆尔评论道：“官衔在我们公司并不受重视，把产品推向市场才是至关重要的，我们只关心到底推出了多少产品。”布拉德•西尔弗伯格对这一评论进行了补充，他认为权威和责任都会跟随着那些最有才能的员工：“微软开发部门的一个重要特点便是各个开发组内部的权力平衡更多的是由个人决定，而每个人的力量和能力绝不可能千篇一律……我们这里的管理充满弹性，如果我聘用了一个对功能构造颇为在行，能力出众的开发经理，我估计权力就会自然而然地向他倾斜。对此我不会介意，而只会努力让自己适应这类杰出的手下。”
如果在个人或者团体之间发生了冲突，诸如应当共享哪些组件等，盖茨会作出最终裁决。约翰•法恩，前任程序管理部门主管，现在担任Excel组程序经理，他对微软文化以及比尔•盖茨所扮演的角色作了如下评价：
在这儿办事的方法形形色色，从最不正式的轻声嘱咐到下达正式的行政命令……规则起不到什么作用……行政机制更无法占据统治地位。所以，当一位软件开发业务单元的经理对另一位单元经理提议说“也许应该将我们开发的软件植入到在你们开发的软件”或类似的建议时，请不要感到不可思议。这绝对不是行政过失，而只是为了使所做的工作取得最大化的利益或者说为了赚取最大利润而采取的另一种策略。但由于这种决策的机会成本很高，而且一旦失败就可能会造成严重的负面影响，所以比尔掌握着最终的决定权。在这种意义上说，此时传统的管理层次发挥了作用。

聪明人的负面效应
对于那些在工作中不愿也不需要受到纪律约束的员工而言，由于这些人时常得通过尝试与犯错来进行学习，从而给雇佣他们带来了一定的负面影响。有一点就令大家印象深刻，微软的开发人员和测试人员（也有少数例外）都不太喜欢翻阅软件工程方面的科学文献，这使得其他公司在好几年以前就发现非常重要的软件开发方法，微软却与它们失之交臂。例如，进行更为仔细的程序设计复审和代码检查，重视架构与设计、组件共享等关键环节，在项目管理过程中采用更好的量化指标与历史数据支撑等。
对于包括比尔•盖茨在内的高层领导而言，指挥这样一群优秀员工也非常困难。他们不喜欢与人合作，也不愿意妥协或与他人分享自己的成果与心得。在第6章中，我们将讨论到微软在这方面所取得的一些进步，但是公司自身做得也不够。迈克•梅普尔斯给我们列举了他初到微软时所见到的一个问题：
很少有人拥有项目管理的经验，公司的管理很松散。员工们都很优秀，但他们不愿受人指挥，他们只愿意通过自己的探索去发现正确的做法。因此，管理者需要想出一些主意让员工自己寻找更好的办事途径，如果直接命令他们说“你必须按照这个流程，你必须这么做”，那么这种强迫他们的做法肯定行不通。只有同员工一起坐下来共同探讨以解决问题……当你的员工卓有才华时，这才是合理而优秀的现代化管理模式。公司不应该采取独裁式的管理方式……我以为我们的管理过程非常独特，只有微软才是适宜它生长的土壤……但这一切都是基于我们公司拥有非常出色而又野心勃勃的众多员工。
随着微软的发展壮大，领导们引入了许多政策来避免各小组在相同的问题上反复纠缠，但这也仅仅只提供了工作指南和原则，而不是严格的规定。布拉德•西尔弗伯格对公司的这种转变作了如下评价：“在公司成立之初，我们的确不需要规章制度的约束。但现实经验告诉我们，现在必须引入制度来适应新的需求。不过我认为公司的传统文化势力非常强大，根深蒂固——比如，权力分散，管理灵活但又不走极端等。尽管现在已颁布了一些硬性规定，但每个组对这些规定的接纳程度并不相同……戴夫•穆尔或迈克•梅普尔斯不会对我耳提面命说：‘你必须这样去管理你的开发组’，这样做根本起不到作用。”在下一章中，我们将要讨论微软公司如何定义其工作范畴，以及如何去组织并培养具有创造性的技术专家。

本文选自电子工业出版社即将于2010年1月出版的《微软的秘密》。