组建职能交叉的专家小组为管理创造型人才和有关技术，微软遵循了一条我们称之为“组建职能交叉的专家小组”的策略。我们将这一策略归纳为如下四条准则：
·以小组形式工作的职能交叉型专业部门。
·让各部门专家自行确定其技术专长并负责人员招聘。
·通过边干边学和言传身教培养新雇员。
·创立晋职途径和“升迁级别”以留住并奖励技术人才。
建立职能型专业部门或者为技术人员创立晋职途径和升迁级别并非什么独到良策，尽管这些措施对于那些技术居于主导地位的公司非常有用。微软的独到之处在于它授权这些专业部门人员自己来定义他们的工作，招收并培训新雇员。我们还感受到对于拥有如此众多员工和产品的微软公司来说，其既定方针和正规教育相对较少。这既是优点（工作种类灵活机动，人们有独立的思想性），也是缺点（人们不得不通过“试错”来学习知识，在许多时候不得不改弦易辙，从头做起）。
这些准则的产生、发展与微软公司特殊的历史、文化有很深的渊源关系。微软早期主要由软件开发员组成，这些人从发明、测试新产品，作出全部关于人员雇佣、市场营销和订立合同的决策，直至回答客户的电话咨询，工作事无巨细。随着微软产品和经营规模在数量以及质量方面不断的扩大和提高，公司增加了成千上万的员工。由产品设计失误或者交货延迟、产品带有严重偏差所带来的风险和成本迫使微软的经理们鉴别出关键的职能并使之制度化。但为避免职能过于分散，技术专家们实行责任交叉并采用多职能小组形式开展工作。
程序管理和软件开发，以及测试，是产品单位里主要的技术工作。微软特别注重寻找初露锋芒并能兼顾PC软件商业价值的“超级程序员”。他们可能并非本行业中最富革新意识的程序员，或者并非对其他公司软件工程方面的实践活动了如指掌，但他们在生产人们竞相购买的新特性、新产品方面具有很高的创造能力，并使之转化为公司巨大的收入和利润。从而，这些微软程序员得以跻身于本行业最具生产力和最有效率人员的行列。
在产品单位里，程序经理、开发员和测试员以“特性小组”形式并肩“作战”。典型的小组由一位程序经理（他通常从事不止一个“特性”的设计开发工作）和3至8位开发员（其中一人为组长）组成，同时还配备平行的测试小组，其成员与开发员组成“搭档”。用户培训专家则作为产品小组的成员进行工作。产品经理负责为产品单位内的营销部门和产品规划组选定人员。客户支持人员虽是另一个独立部门的成员，他们中的产品专家却与单个产品单位密切合作。而某些职能领域（如程序管理）依然难以准确定义，其他一些职能领域（如程序管理与开发、程序管理与产品管理、开发与测试）难以截然分开，微软也从未试图把它们分开。
产品单位由高级经理负责每个职能领域存在困难（比如开发领域和测试领域）。职能经理们在特性小组里工作并向产品单位的微软项目和特性小组组成情况注：粗体字表示项目领导主管汇报情况。这些主管非常类似其他行业（比如汽车行业）的项目经理。譬如在Office产品单位，此人负责协调几个相关项目——主要有Word、Excel和Power Point。2微软经理们将许多决策权授予特性小组。不过，产品单位经理和高级功能经理作出主要技术决策，在单位预算约束下配置资源，并解决不同组别之间的冲突。他们还与高级产品经理和主管组成小组来确定项目时间表，产品阶段性目标和产品上市的决策。
……建立以小组形式工作的职能交叉型专业部门微软为每个基本的职能领域创立了工作思路，它使人们广泛地学习和分担责任，它把人员组合成多职能小组来作为更大的项目小组的一部分进行工作。每个小组的职能如下所述。
程序管理也许微软最难以定义和胜任的职位是程序经理的工作。程序经理必须能管理产品项目的全过程，而且他还是连接软件开发与市场营销（产品管理）的关键纽带。一份由程序经理布鲁斯·雷恩起草的公司定向报告把他本人及其同事们描述为“开快车，坐办公室的技术本科生”。他还告诫说：“程序经理是领导者，是帮手，是协调人，但绝不是老板”。雷恩将程序经理的主要职责范围开列如下：
·产品策划。
·产品规格说明书。
·产品时间表。
·产品开发过程。
·实施折衷方案。
·协调产品开发组。
微软程序经理职能的起源可以追溯到80年代中期。那时，情况很明显，高级经理必须从“超级程序员”手中接管某些产品开发的控制权。同样明显的是，管理设计过程不同于软件开发。杰夫·雷克斯，现任市场营销高级副总裁，1981年由苹果公司转而加盟微软。他回忆起在1990年的一个案例研究中由超级程序员所制造的麻烦时说：“依赖单个超级巨星会产生许多问题：
（l）他们的供给很少；（2）有些人不得不维持或更新他们已编写的软件（这通常提不起他们的兴致），并且他们的代码常令人费解；（3）有时他们不了解市场的需求；最后如果你试图把他们中的几位调配到同一个项目，那么你会在设计决策中遇到真正的麻烦——所谓“厨子太多汤难做”。
吉布·布鲁门萨，1982年加盟微软并在雷克斯手下工作。他曾帮助程序员定义了Multiplan电子表格的规格并将其推向市场。他的所作所为后来演变为程序管理一职，他说：“在1984年初，我们开始开发Mac机的电子表格。我参与其间并为开发组提供了一系列服务：帮助制作规格说明书，做人工检验并且决定哪些错误应马上修正，哪些错误可以留到下一个版本。我并不做设计决定，但我必须确保设计决定已经做好。整个过程进展顺利，于是他们决定给我的工作命名并将其制度化。”
比尔·盖茨支持规范程序管理的决策，尽管这是对他所喜好的工作方式的一次大变动。在公司早期，他经常几乎重写微软所推出产品的每行代码，同时还管理产品的市场营销。但正如在第1章所讨论过的，到80年代中后期，盖茨管理所有事务已经不可能了。他同意建立正规的工作种类，比如产品经理处理市场营销事务，而程序经理的工作介于市场营销和产品开发二者之间。但盖茨并不想让程序经理与开发或营销工作截然分开，他想让程序经理如同吉布·布鲁门萨那样与开发员在小组里并肩工作，使二者相得益彰。盖茨深信，如果没有这种职责交叉与密切合作，各部门职能截然分开会导致失败：
我们过去没有程序管理一职，而开发员不喜欢做繁杂的文牍工作，并且不愿意参加讨论市场营销的冗长会议。于是最终出现了一种新的技术组合，一种非常有影响力的技术组合，它能处理所有繁杂事物其他公司现在也有了程序管理一职，虽与我们的略有不同，但我认为全行业都已认识到这是一个重要的办法。程序经理与开发员每天一起工作这是所有事务中最密切的关系——比开发与测试之间的关系，市场营销与销售对象之间的关系更为密切。你可以将程序管理与开发置于同一经理的管理之下。事实上，只要找对了人选，就能配成小组。并且我们就是这么做的。但如果程序管理与开发在一起合作得不好，别的就甭提了。
现在，在新项目初期，程序经理与产品策划者密切合作以确保每个新产品都有与众不同的“特色”。他们一起撰写产品规划书，这份规划书集中了从开发员、客户支持人员直到包括盖茨等高级经理在内的所有人的智慧。接着，程序经理开始撰写产品规格说明书，它以提纲形式描述了产品的不同特性。这份说明书随着程序经理与开发员讨论产品特性的细节和建立产品原型的过程而不断扩展充实。每位程序经理通常管理几个特性的开发，因此，常在几个特性小组里工作。
在许多公司，通常有软件设计员（有时称为系统分析员或需求工程师）组成的独立部门，他们负责为其他从事产品制作的人员（像程序员、执行员和代码员）做好产品功能设计。通常设计员负责设计一项新产品并把他们的工作局限在项目的这一初始阶段。而微软人则多次向我们声明，在微软，程序经理并不是这种意义上的设计者，相反，微软程序经理的工作从始至终贯穿一个项目的全过程。因为他们设计的规格随着产品制作的过程在扩展在变化。程序经理在项目启动时，可能花费许多时间来定义许多种产品所共有的特性，解决产品结构方面的问题，模拟用户界面（用户在计算机上看到的屏幕或菜单），并且他们经常提出新的特性构思。但程序经理的所有工作是在开发员的帮助之下进行的，而且开发员也提出许多特性构思（特别是在系统软件部门）。
故而程序经理所做的是记录产品的规格，而非设计，他们与特性小组一道工作并帮助管理该项目。克里斯·彼得斯，Office软件的副主管，总结说：“程序经理负责写规格说明书，他不负责所有的构思。重要的是产品规格被记录下来了，并有专人负责。”盖茨同意这种看法，他强调开发员真正控制着最终设计：
我们可以争论是谁提出了好的特性，因为在有的组是开发员，在有的组是程序经理。但是从代码如何运作的意义上讲，程序管理从未作出过任何“设计”。开发员仍然处于强有力的位置，如果他们有一个想法，他们就照此编写代码；他们可能说这个很容易，别的特别难。于是从这个角度上讲，开发员愿意做设计。我们也愿意让他们设计。有一些组，像Windows或NT，或C编译程序——大多数系统软件组基本上是开发员设计，程序经理予以记录当谈到应用软件时，就很难说谁在进行设计。最完善的应用软件是Excel，因为它总为其他许多事情提供范例。这其中也许60%的构思来自程序经理，而40%来自开发员。以乔恩·德·沃恩或一些特性小组的领导为例，这些人真正以他们开发的特性为荣。在任何一个特性中都不好说是由程序经理提供了意见，开发员认可并照此编码，然后把结果给程序经理看。实际情况是高度的相互作用，相互影响。请相信，开发员一想到他们拥有这些特性，就会用难以置信的热情来关心这些特性。
管理设计和开发产品的过程意味着程序经理管理整个项目中的关键活动。但是他们对那些他们赖以完成工作的小组却不享有正式的权威。例如，除了准备产品规划书和规格说明书外，程序经理负责提出折衷方案，比如哪个特性要保留，哪个特性要排除在外等等。他们经常通过一种称为“活动基础计划”（见第4章）的微软技术来了解顾客真正需要的产品用途，进而确定某一产品特性是否有效地满足了这种需求。而且，作为设计和决定待性过程的组成部分，程序经理制作产品原型并且管理特性和界面初始版本的测试。这种测试是通过新用户在微软的的可用性实验室中完成的（见第5章和第6章）。
程序经理在综合开发、测试、产品管理和客户培训等部门意见的基础之上，负责拟定初步的产品开发时间表。他们始终关注着时间表的进度，并确保开发员在可用性实验室里测试了特性；同时为方便内部维修和测试以及方便外部用户，已记录了实验结果。他们与小组中的其他成员商定项目的阶段性目标，并且与测试、开发经理共同确定何时阶段性目标内的特性编码工作算是完成了，以及何时一项产品可以推出了。程序经理还负责通过正式会议，每天的电子信件和非正式会议（走廊会议和午餐会议）与其他组协调工作。这种协调近年来变得非常重要，它包括界面和代码的标准化（这些界面和代码属于不同的产品，但必须一块儿工作）和相关组之间的进度同步（这些组可能共享特性或代码，或者将一起推出它们的产品）。这些情形发生在Excel、Word Power Point、Access和Mail中，也发生在OLE和Visual Basic等应用软件中——在Office的程序系列之内。
作为领导者和帮手（而不是老板），程序经理力图确保在不同功能领域间进行着信息交流并且这种交流贯穿开发周期的始终。开发员、产品经理、测试员、用户支持工程师和高级行政人员——从比尔·盖茨算起——都对有关新产品的决策发表意见：何种特性予以保留，什么时候进行下一步工作或什么时候推出产品。一旦人们在目标上达成一致意见，那么接下来，引用微软文件的话“程序经理的责任就是负责传达”。6约翰·法恩，前程序管理主管，现任Excel组程序经理，谈了程序经理所起的关键作用：
如果微软没有程序经理，情况会不大相同。程序经理的关键作用表现在两方面。首先，程序经理确保产品的特性能吸引顾客，并使顾客愿意为此掏腰包要创造出除了特性不能吸引消费者之外，在各方面都很出色的软件并不难也可以根据“设计”的概念，把这种情况产生的原因称“设计管理”。
其次，他们确保产品在最佳时刻以最优内容冲击、打开市场。通常人们深知产品各部分很容易脱节，而且推出时稳定性不够或稳定性太高产品信息在制作软件、规格记录、测试软件的不同小组成员之间得不到很好的交流。项目越大产品规模越大，成功率越低。如果这个问题不解决，将导致产品各部分脱节，产品说明书与产品实际功能不符，产品功能在两个不同的特性中不能连贯。而解决这些问题的关键在于程序经理，他以某种方式使信息得以交流。
程序经理与开发员、程序经理与市场的密切联系也会产生问题，他们总是把过多的市场准则强加于开发过程，但有时又难以作出取舍。在微软一个很典型的讽刺例子是，如果开发员对实现同一特性的两种不同方法难以取舍时，程序经理会建议他们两种方法都试试。程序经理还倾向于列出长长的特性清单，当产品经理、开发员和行政人员想要缩小选择范围时，这种清单会成为激烈争论的焦点。正如盖茨强调的，开发员在选择过程中仍有特殊的影响力，因为他们必须评估实现这种特性的技术可行性。并非所有的程序经理都有软件设计专长，然而他们影响着微软产品，特别是应用产品高水平层次（或缺乏层次）的决策。而在有的组里，程序经理变得相当技术化，并比一般用户更关注开发员的观点想法，这种情况经常发生在操作系统和语言产品开发中。正如Office软件的高级程序经理麦克·康特所观察到的：“在许多组里人们过多地钻入与市场营销大不相同的、过分技术化的象牙塔之内，这对于程序经理和产品本身都不是一件好事。”
开发麦克·梅普尔斯在第1章中说过，开发员——正式场合称“软件设计工程师”——在微软的地位相对高一点。在调查过程中，我们发现情况正是如此。程序经理通常把注意力集中在整个产品的策划，以及什么类型的特性能达到目的方面。与此相反，开发员确认这种产品策划并创造单个产品特性的细节。Office组的程序经理史蒂文·斯诺夫斯基简要概述了开发员所从事的工作：“他们编写代码，他们完成产品的特性，他们知道编码基数。他们的工作就是通过编写代码来制造产品。”
我们此前已提到微软开发员通常不会从程序经理那里得到产品的详细技术要求，并仅仅照此编码。提供详细的技术要求说明书是一种产品开发类型，在大型软件厂商，如IBM中使用相当普遍。查尔斯·西蒙尼在80年代初也曾试图将这种方法引进微软7，但没有成功。开发员通常和程序经理一道扩展产品说明书，并创造出他们自己的特性细节。然而，在每一个项目中，少数高级开发员和程序经理确实负责产品的结构，并且开发经理（一线经理）为他们的小组提供指导。开发员与测试员共同负责，以确保产品特性能行之有效。微软的条例将开发员广泛和交叉的责任归纳如下：
·确定新特性的轮廓。
·设计特性。
·配置项目资源。
·制作特性。
·测试特性。
·准备出品。
开发员、程序经理和其他人员提供有关产品特性的种种建议。但是，开发员必须很清楚每个特性完成了什么并帮助程序经理决定哪个特性应被包括在新产品之内，哪个特性应予删除。因此，开发员必须评估每个特性并了解人们会怎么使用它。特性设计主要是找出合适的算法（计算机指令）来完成预想的任务。这还涉及一个特性与另一个特性或另外的产品版本之间的兼容性，以及是否可能从其他微软产品中借用代码等问题（这是一件日益重要的事情）。
配置项目资源要求开发员估计他要花多长时间编写每个特性的代码。单个开发员依照过去项目的记录和自己的判断，通过征求组长或开发经理的意见来做计划，另一个步骤是与程序经理一起工作，根据给定的时间、人力资源和市场需求来确定新产品实际的特性系列。随后开发经理与开发员和程序经理协商如何把产品特性分派给开发员或特性小组。
特性制作由编码和检查代码等环节组成。微软文件敬告开发员们当心出现采用了太多的存储器，或者编写的代码依赖于特定的硬件处理器这样的问题。开发员还会从公司收到“无缺陷编程”指令——即依赖于每天的产品构造，阶段性目标的稳定性，每天调试和测试的同步稳定过程（见第4章和第5章）。
检验代码是开发员和测试员的责任，他们配对进行工作。开发员检验自己开发的特性，经常（通常是每天）启动自动装置来检验代码。在他们的工作成为待检与“正式制品”之前，开发员还把所谓特性的“私人版本”提供给他们的测试“伙伴”。“私人版本”使测试员有机会找出错误，开发员有机会修正错误，开发员可以在把代码传递给本项目的其他成员或其他内部使用者之前修正错误。再次，开发员将他们的代码置于可用性实验室中以便从普通用户中得到更多的信息反馈，这样做有利于进一步的开发工作。
开发员最后的任务是准备推出产品。这要求有规则禁止对代码再做任何重大的改变（比如增加特性）。开发员必须将错误的数量降到几近于零，并且维持相当一段时间。
经常与测试员一道或在可用性试验室里测试代码，并站在用户立场上用β版本测试代码，是开发员工作的重要组成部分。这是因为开发员有偏离程序的长度和速度以及用户关心的特性用途的倾向（微软产品在这些方面并不总是做得很好，特别是第一个版本的产品）。高级副总裁布兰德·斯尔文伯格毕业于布朗大学计算机系并在多伦多大学获硕士学位，他在珀兰工作时曾任Windows3.0版本的β测试员。他于1990年加入微软并领导Window/MS-DOS组。斯尔文伯格提到他本人作为微软经理人员的一项重要任务就是在负责Windows95项目中，提醒开发员多为用户着想：
我总是积极致力于建立最终用户与开发员之间的联系，以便让开发员了解用户的需求Windows的下一个版本中主要的阶段性目标是尺寸大小和运行状况。我们将用三个月时间使产品变得更小而速度更快。我认为尺寸大小和运行速度不是你可以仅在最后时刻加上去的东西，并且说：“好了，我们已经加上了所有的功能，让我们来调试它。”我认为在任何时刻都不能离你的最终目标太远，正像你不可能让一头大象节食之后变成一只老鼠一样。
测试源于计算机主机和微机行业的软件公司依靠开发员测试自己的代码，同时还有单独的测试部门，其人员负责进行软件产品的最后测试。但在许多PC软件公司，测试依然是一种特别的活动——主要还是靠开发员来测试他们的产品，有时候会得到外部合同工的帮助。微软过去也是这样对待测试的。但从80年代后期开始，特别是1991年后，戴夫·穆尔和其他经理积极致力于使测试成为公司内部被接受的专职部门，它独立于开发，但又配合开发。
他们尚未完全成功，开发员还是高高在上。但是微软的培训文件指明了为公司上下所接受的，测试独立存在的三条理由：
（1）开发员不可能编写出完美无缺的代码，程序经理不可能制作出完美无缺的说明书；（2）必须让某些人的工作独立于制作说明书和编写代码，以便对它们的质量能有一个公正的评价；（3）在开发过程中，当代码群尚未交织在一起时，及早发现并修正错误对于开发员来说更节约成本和更容易——对提高产品的稳定性和顾客的满意度更有益。
为了更有效率，微软的条例建议测试员从六个方面来检验产品：
（1）用户方面模拟普通客户对某一特性的使用，并判断这个特性是否能让他们理解；（2）国际方面确保对不同的语种、国家或地区，产品的格式及语言使用是正确的；（3）硬件评估产品与不同的硬件平台和设备是否兼容——比如与Compaq、IBM、Gateway、Apple机——或者和特殊的打印机及其他附件是否兼容；（4）软件评估产品是否与其他软件兼容。比如，Word可以被读成或生成Word Perfect文件，同时其特性能向Word Perfect用户提供特别帮助。系统产品像Windows和NT必须能与非微软应用软件一道工作；（5）规格检查检查产品是否依照原先的设想制造，并且规格是否按照程序管理的预想来完成；（6）产品稳定性应在两个层次上检查产品的稳定性。一是定量分析（如错误与错误严重性分析，以及其他我们以后将讨论到的计量手段）；另一方面是定性分析——被定义为判断是否已作好产品上市准备的“主观感受”。
微软在1984年开始聘用测试员——正式场合称“软件测试工程师”。当时公司首次建立独立的测试组。在此之前，为数不多的几位测试员向开发经理汇报工作，并且没有他们自己的职能机构或职务级别。直到1986年，微软才设立了应用软件测试主管一职并聘人担任此职。但是戴夫·穆尔此后在担任开发主管的同时兼此职务。直到1993年，罗格·舍曼出任该职，微软才有了第一位专职测试主管。（正如我们第1章所指出的，部门主管实际上并不监督开发、测试或其他功能经理们的工作。他们主要是为本部门筛选出好的实践方法，并向全公司推广，他们不时地审计产品单位的账目。我们将在第6章中进一步讨论他们的作用。）大多数微软的测试员以及几乎所有的开发员都驻在华盛顿位于内蒙得的公司总部。公司还有两个国外测试基地：爱尔兰分部处理使用欧洲语言的微软产品，而日本分部（微软条例称之为“远东”）处理韩国语、日文和中文版本的软件。总体上，微软近乎是一个测试员对一个开发员，即在公司全体4100名员工中（包括程序经理和产品策划人员），有1850名测试员（相反，日本和美国大型软件厂商一般用于测试的人员不会超过项目人员的10%至15%，甚至更少。11但Lotus与微软人数相仿。12微软或许可以减少测试员数目，但需要程序经理和开发员在开始编写特性代码之前花更多的时间来做结构规划和细节设计，或者使开发员更多地检查自己的设计和代码。然而，这样做会减少微软项目的特性以及构件必须日益增强的灵活性。大量的测试员提供了一种保障：与因错误而使产品被取消或被替代的成本相比，这样做要经济得多。因此，微软分派测试员和开发员并肩工作，并且在项目初始阶段，测试员就组成与开发相平行的小组。同时，测试员向测试组长报告工作。测试组长管理着一组测试产品某个组成部分的测试员，并向产品单位测试经理汇报工作。测试经理向产品商业单位经理而不是向开发经理汇报工作。
准备一项新的测试需要做几项工作。一是查阅以前项目的事后报告以及其他测试组的报告。这些报告提供了需要寻找什么类型的问题以及如何发现这类问题的信息。微软经理还鼓励测试员与产品支持人员及用户进行交流，并浏览媒体的评论以判断工业批评家们的好恶。这些早期工作完成之后，测试员开始设计特殊的工具或代码例行程序来帮助他们进行测试。另一项活动是调研，即研究微软竞争对手的产品和新特性来决定微软应该采取的行动。接着是通过找出可能延误出品的高风险区（包括对其他组的依赖性）来发展一套测试方法。微软的培训材料用Excel作为一个例子来说明怎样进行充分的测试准备。它包括用于特性测试的计划和“脚本”——即用于测试过程的命令或功能清单，其他测试员和经理可以参考它来完善自己的工作。测试员还为自己的程序员开发了自动“测试程序”，这些测试程序比人工测试快捷且更完备，并且它们消除了反复运行同一套命令或功能的单调沉闷。最后，测试员花时间来做微软所谓的“非结构化测试”、“方案测试”、“特别测试”、“大猩猩测试”和“自动式星期五”等种种测试。此时，他们已超越了计划测试书，采取各种不同的方法来使用产品，并尽可能使其暴露问题。
测试员的一个主要责任是测试开发员提供的软件私人版本。他们将开发过程中的错误迅速信息反馈回去。这种信息反馈既反应从用户角度来评估的设计问题，也反应编码出现的疏漏和错误。（按照Word测试经理詹妮·希尔顿的说法，大约80%微软软件开发过程中的错误仅仅是由于“漏掉代码行”造成的）。测试员通过电子邮件向开发员通报在私人版本中找到的错误。只有当私人版本的测试过程结束之后，测试员才向其他人发布一个公共测试版本。测试员还跟踪测试过程中发现的错误，根据他们的特性区域和严重性加以归类。同时，开发员创造了一种测试发布文献（TRD），这种文献不仅说明了哪些特性已经完成，等待测试，而且还指出了应予关注的特殊领域或代码细节问题，以帮助测试员集中注意力。
其他部门微软还有三个定义更明确并与其他部门交叉的职能部门。产品经理是市场营销专家。虽然从1993年后期以来微软将他们中的大部分划归市场营销部，但还有一些人在产品单位中做产品策划工作。用户支持工程师为用户提供技术服务并且分析客户反馈的信息，他们的工作归属产品支持服务部（PSS）。该部向史蒂夫·鲍尔莫报告工作。用户培训人员准备用户手册或帮助文件。他们作为产品小组的成员在产品单位里工作。
生产单位里的产品策划人员与程序经理密切合作，确定产品特性的新构思，并且撰写市场营销说明书（即产品规划书）。除了归纳特性之外，这个说明书涵盖了诸如产品包装、定价、相对于其他产品的市场定位之类的众多问题，并且它要求分析竞争对手的情况和市场趋势（市场营销部的产品经理也做一些类似的分析）。在这些活动之外，产品经理确定新产品领域，提供关于新产品和新特性的建议，并且通过独立的营销部门来准备市场营销和新产品的销售。微软的培训条例，把产品经理描述为“一群工商管理硕士”，“拥有房产的时髦着装者”。条例列举了产品经理的五个关键责任领域：
·管理“商业活动”。
·识别和寻求市场机会。
·在产品开发过程中充分代表客户意愿。
·负责在功能和出品日期二者之间作出权衡。
·负责市场营销和产品销售过程。
客户支持工程师主要通过电话，有时也通过电信方式来回答顾客的问题。他们对有关微软客户和竞争对手的数据进行深入分析。他们还通过指明需要发现的问题和帮助产品组确定优先权等方式为产品开发测试提供有益的意见。通过回答客户的问题，PSS部为客户提供服务和帮助。这种服务被大多数客户视为他们所购买产品的一个重要组成部分。微软每天至少收到来自世界各地的近2000个电话，以及成千上万的电讯查询（比如一种自动的快速查询服务）。为了更好地与客户打交道，微软条例阐明了客户支持工程师的五个关键职责：
·处理客户的电话，及时弄懂客户的问题并找出解决方案。
·研究问题，并向客户提供所有可能的解决方案。
·把电话编码，组成支持数据库。
·对于非客户失误导致的问题提交有关软件错误的报告或文件错误的报告。
·如系客户失误，就把问题整理成一篇可编入知识库工具的文件。
制作了一份名叫“Off-line Plus”阅读者甚广的周报，它把问题报告详细化，能帮助确定测试日程、错误修订以及下一个版本的开发日程。此外，该部门的人员还与程序经理、开发员、测试员以及可用性实验室、用户培训人员密切合作，当新产品、新特性尚在开发之中时，他们从用户支持的角度提出意见和建议（关于PSS作用的详细讨论见第6章。）除了编写用户手册和其他文件外，用户培训部与市场营销部一道提供有关产品的包装、标签以及国际化的建议。他们遵从其他部门的领导，并使其工作过程规范化。他们甚至借用软件开发的术语来表明他们工作过程的特点。在他们发现和修正材料的错误时，他们借用术语表示这是他们的“产品开发周期”和“制造”，以及包括“测试”文件在内的质量保证过程。用户培训部门还雇佣了各类专家，比如职业作家、图像设计师、技术编辑、文字编辑、资料员、索引员和负责打印的生产小组。
准则二：让各部门专家自行定义其技术专长并负责人员招聘在80年代，微软创立了职能型专业部门（比如程序管理和测试），这些部门本身在公司里并没有约定俗成的传统，也无法与大学课程相对应。因此，微软的经理让这些部门和其他部门（比如软件开发、客户支持和用户培训）的创始成员自己定义他们工作的性质，并负责招收成千上万的新雇员。这样做是合乎逻辑的。从此以后，微软一直以这样的方式开展工作。
人员招收和筛选过程微软公司员工的平均年龄约30岁，大多数员工相当年轻，特别是应用程序组里的开发员。全部雇员中有一半直接来自大学，并且许多微软经理更喜欢这条途径，他们愿意招收年轻人，因为年轻人更容易融入“微软模式”之中。
在公司的早期，微软采用亲自面试人员的招聘方法。那时比尔·盖茨、保罗·艾伦、查尔斯·西蒙尼以及其他高级技术人员对每一位候选人进行面试。微软用同样的办法，即按早期雇佣开发员的办法来招收程序经理、软件开发员、测试工程师、产品经理、客户支持工程师和用户培训人员。微软每年派招聘人员去大约50所美国大学。招聘人员既去名牌大学，同时也留心地方院校（特别是为了招收客户支持工程师和测试员）以及国外学校。招聘人员通过人力资源部组织参观，处理日常文书工作，并参与由技术部门和产品部门资深人员进行的面试。有希望的候选人还要再回微软总部进行复试。可见招聘人员并不直接雇佣人员，而是管理招聘的全过程。在80年代末90年代初，这种方法占很大比重。Windows NT组的开发经理戴夫·汤普森曾谈到招聘人员的作用及微软招聘开发员的方法：
在校园里进行一种特别的面试，有人去那儿做预选工作。此后，有经验和没有经验人员的招聘过程基本相同，变化不大。被面试者在一天之内将与4至6位面试者交谈。最后他们将与作决策的人交谈，合适的人将被聘用。面试过程非常灵活机动。招聘人员是这个过程中的关键因素，他们帮助管理此过程。他们使得这个过程对于开发经理来说既不痛苦又不费力。过去在小公司，我们在雇人时花去许多时间。
而现在我仅在只有我才能答复的问题上花时间——比如评估反馈信息，面试候选人，作出决策等等。
当你想发展得快一些，就要有高效的人员面试过程。好的招聘人员对于某些重要的品格具有不可思议的洞察力他们知道什么样的人更可能成为一名优秀的微软雇员。任何只靠人事部门来招收人员的公司其结果是注定要失败的。
微软总部的面试工作全部由产品组职能部门的人们承担，开发员承担招收开发员的全部面试，测试员承担招收测试员的全部面试工作，以此类推。面试交谈的目的在于抽象地判定一个人的智力水平，而不仅仅看候选人知道多少编码或测试的知识，或者有没有市场营销的特殊专长（在判定新雇员四种重要的素质，即雄心、智商、专业技术知识和商业判断能力时，盖茨常被作为典型引用，而这四种素质中智商最重要。17）微软面试中有名的一般性问题包括：估计密西西比河河水的流量或美国加油站的数目。被面试者的答案通常并不重要，而他们分析问题的方法却很被看重。
能通过筛选的人员相对较少。在大学里招收开发员时，微软通常仅挑选其中的10%-15%去总部进行复试，而最后仅雇佣复试人员的10%-15%。总体上说，微软仅雇佣参加面试人员的2%-3%。瑞克·罗歇德，微软研究部副总裁，在称赞筛选过程时说：“这很像是进行口试。面试过程相当严格，我不敢保证筛选出了所有优秀人才，但被筛选出来的肯定都是优秀人才，他们具备一定的才能和天资，以及独立思考问题的能力。”
一旦被雇佣，新雇员将面临一系列的挑战和考验。这些考验可能来自每年一度迎新会上盖茨本人的考查，或者甚至可能来自微软某一条洞穴状的走廊（公司的每一幢大楼都有X型的双翼和各种各样的棱角，使每个办公室的窗户增多，能很好地欣赏附近的山林和如画的风景。只有聪明的人才能在过道里成功地找到自己通过的通道。）而且只有愿意长时间工作的人才能坚持下来。微软员工颇似日本人即使休假也是休金假。戴夫·穆尔描述了微软典型的一天，他说：“在微软情形是这样的，早上醒来，去上班，干活，觉得饿了，下去吃点早餐，接着干，干到觉得饿了，吃点午餐，一直工作，直到累得不行了，然后开车回家睡觉。”
为了更深入地考验雇员的决心，微软付给他们相对较低的工资。盖茨通常不付给雇员高薪，并且在一开始时甚至拒绝向秘书和其他人员支付加班费。他在事实上设立了不给加班费的政策。但在1982年，他开始发放年度奖金，并给雇员配股。在90年代，此类补偿金数目相当可观，因为微软的股票价格持续上涨。给雇员的补偿金现在包括高达15%的一年两度的奖金、股票认购权以及用工资购买股票时享受的折扣。（一个雇员在微软工作18个月后，就可以获得认股权中25%的股票。此后每6个月可以获得其中的12.5%，年内的任何时间兑现全部认购权。每2年还配发新的认购权。雇员还可以用不超过10%的工资以85折优惠价格购买公司股票。18）员工离退和调整诚然，微软人员管理的办法也存在消极的一面。严苛的工作时间表会使员工精疲力竭。人们持续长时间的工作，并且总是在某一特定产品上长时间工作，他们容易变得厌倦，并最终离职而去。理查德·巴斯将其部分归于微软“有意识的只雇佣所需人数一半的政策，这有助于权责分明，减少官僚主义。另一方面，我们倾向选择那些甘愿献身的人们我们喜欢雇佣这类人，因为他们愿意苦干”戴夫·马里茨，前MS-DOS/Windows的测试经理，抱怨经理们缺乏足够的办法来阻止人们过度工作和过早达到高峰期。精疲力竭尤其困扰着开发员，因为他们总是严重低估编码所需时间。精疲力尽也同样影响到测试员，他们与开发员配对工作，经常通宵达旦地测试开发员编写的代码。马里茨自己就是拼命工作的受害者，在1993年完成MS-DOS6.0版本的出品之后不久就退休了：
比如在测试DOS6.0版本的压缩数据时所有工作都是在晚上进行的。我们告诉开发员五点下班，随后我们进入办公室检查他们的磁盘，整理文件，并运行压缩器。当Windows组、Win Word[Wordfor Windows]组和Excel组的开发员早上返回时，他们的磁盘已被压缩，或者已被调试过了，即使是我们不能做的，影像也被转存起来了——全部工作都在晚上进行。这是家常便饭，并且每个周末都如此。如果经常这么做，人们会不愿在这里工作。
我说的是在微软，你永远得不到休息。你总是处在一种紧张状态。我所做的够不够？有没有把所有事情都办好？这是很痛苦的。我知道我不想在微软累死，一两年后，我离开了那里。我这一辈子再也不想看见软件了。在那个地方，我已经看够了。我愿驾一叶扁舟，烟波垂钓，捕鱼为生。
戴夫·穆尔估计每年高达10%的新雇员离职而去，并且在新雇员进入公司的头5年里，这个比例一直保持着。但是有了5年的经验之后，几乎便没有人会永久性离开公司了（有人可能请一两年假去休养或做别的事情，像道格·克隆德就曾去加利福尼亚休假）。穆尔进一步断言，从80年代末起，人员调整比例保持稳定，而且开发部门的人员调整比例每年仅为3%，他还谈到大部分公司范围内的调整来自于产品支持部和制造部，这两个部门的工作都是机械地重复作业，他们雇佣了许多高中生来“每天24小时装箱”。微软鼓励那些工作达不到标准的人员离开。许多资料表明，在1993年和1994年，根据经理们对员工生产能力的评估，公司解雇了5%工作业绩最差的员工（但穆尔坚持说，这种宽泛的人员裁减不适用于开发员。）从严格招收、筛选和离退中脱颖而出的那些人必定才华横溢，雄心勃勃，并且愿为长远的经济利益长时间超负荷劳动。一言以蔽之，他们非常像比尔·盖茨和其他创立微软公司的高级人员。正如Office的程序经理吉姆·康纳尔所说的：
这是我钦佩微软的地方之一。他们在雇佣工作狂方面无与伦比在面试过程中做了大量工作。他们真是非常善于激励人。我自己的感觉，在某种程度上是在说我自己，我认为我们真的善于寻找不达目的绝不罢休的人。在这里，他们给你许多机会和考验。他们非常高兴让你满负荷地工作。人们也接受这种挑战。一个人也许不够，但工作却还是能完成。你会看到许多例子，人们准时地到达他们的办公室。当我还是个测试经理时我常遇到此类问题，我不得不命令大家回家休息，因为他们已精疲力尽了。他们可以接连三四天一直工作他们仅仅是有这样的冲动。并且我认为这正是微软的成功之处。
程序经理程序经理面临最广泛和最难承担的一系列责任。他们必须与其他职能部门，特别是开发和产品管理部门的人员密切合作。没有哪一所大学的学位正好能使人胜任程序经理一职。这样，寻找新雇员总是有点困难。正如比尔·盖茨所说：“程序管理有些不可思议。我们不清楚我们该去哪里招收程序经理，程序经理所需的背景是什么。”
但经验丰富的程序经理知道不招收什么样的雇员。他们不招收能编码或有市场营销背景的专业人员。相反，他们更偏爱那些对公司总体上怎样设计产品，具体地怎样设计软件感兴趣的人员。这与对产品经理的要求有某些相似之处。所以，微软积极鼓励有才华而不当程序经理的人试着干产品管理的工作。但是产品管理专业的人员招收相对容易一些，正如麦克·康特所说：“要找到程序经理的适合人选要难得多可用于设计今天的商务应用软件的正式背景极少，而在学校里学到的关于应用软件市场营销的东西却多得出奇。”约翰·法恩谈及他要寻求的候选人的品质时说：
用人得当极其重要。适合于当程序经理的那些人的魔力体现在两方面。一方面他们完全热衷于制造软件产品。他们必须是那种对所有权极度关心的人。一个每时每刻为产品所有细节操心的人总会比那些不负责任的人制造出更好的产品。另一方面，他们能专心致志地从始至终关注产品制造的全过程。他们总是善于从所想到的每个方面来考虑存在的问题，并且帮助别人从他们没想到的角度来考虑问题，而不是仅集中在其感兴趣的某些方面，不去考虑其他东西。
微软努力寻找程序经理，这种努力主要集中在大学生上，大学提供大约80%的新人选。依照系统产品市场营销的产品经理克里斯蒂的看法，另一个渠道是从微软其他部门转行当程序经理，比如从产品管理、测试和开发等部门寻找程序经理。许多程序经理具有工科本科学历，一些人有硕士学位。一部分人在大学里学文科，偶有一两个MBA，而MBA在产品经理中更为普遍。专门受过与工作有关的正规训练的程序经理都从事各组的用户界面标准化工作。比如Office组，研究组以及消费者小组里的程序经理。他们通常有心理学或工业设计文凭——这是开发新型的，使用更简便的界面所需要的重要的背景。
无论所受正规教育是什么，所有的程序经理候选人都必须表现出理解基本技术问题的能力，尽管他们本身不是熟练的程序员。康特估计在应用领域“大约半数的程序经理可以编写像样的Visual Basic的应用程序技术能力通常不是判断一个人是开发员还是程序经理的标准。许多程序经理具备成为一个开发员的所有能力，但他们喜欢解决什么样的问题却是一种偏好。”在系统软件领域，程序经理显然更技术化一些，因为他们帮助设计某些特性，这些特性由开发员编写代码时使用的应用编程界面构成。
因此，程序经理一般具有设计方面强烈的兴趣以及计算机编程的专业知识或熟悉计算机编程。比如，约翰·法恩，曾就读于俄勒冈州瑞德大学珀特兰分校人类学专业。他在大学里修了许多计算机课程，并且在一个为C语言制作开发工具的小公司谋得一份程序员的工作。他于1986年加入微软并成为编程工具方面的程序经理。后来，他做了Quick Basic的程序经理，并最终成为相当成功的Visual Basic产品的程序经理。他还做过一个时期的程序管理主管。（这项工作涉及筹办会议、培训新的程序经理，帮助需要帮助的部门，并考虑有关人员下一步要加入哪一个部门。）麦克·康特集对技术的理解能力与商业兴趣于一身，他的晋职经历与吉布·布鲁门萨相似。他有纽约大学斯坦商学院信息系统与管理的学士学位，刚开始他在一个小型应用软件公司工作。在1989年加入微软之前还做过自由咨询顾问。在微软，康特开始在Excel市场营销部作公司财会工作。作为这项工作的延伸，他创造了在市场营销部门内规划新产品，为Excel新版本作高级设计的工种。两年之后，他的头衔转为程序经理。他还成为Excel4.0版本的小组领导人，接着成为Excel5.0版本的高级程序经理。1993年加入新Office组。另一位高级程序经理，Office组的吉姆·康纳尔具有更高的学术背景，他在加州大学圣迭戈分校学习，研究行为和神经生物学，并获心理学哲学博士，他作过伯克利和密歇根大学的博士后，后来又辞去华盛顿大学的研究工作并于1983年创立自己的软件咨询和开发公司。康纳尔在1989年加盟微软，开始是做合同测试员，接着成为网络系统产品的测试经理。后来他成为互用性设计组的程序经理，从事有关界面标准化似及Word、Excel、Power Point及其他应用软件的共有特性的定义工作。在1993年，该组成为Office产品单位的一部分（见第3章）。
开发员对微软人来说，他们清楚地知道一个开发员需具备怎样的技能，并且知道如何鉴别这些技能。开发员寻找那些熟练的C语言程序员。C语言是一种高级可移植性语言，可以与低级的汇编程序语言互换，而汇编语言有助于程序更快运行，使用更少的存储器。开发员还希望候选人具有一般逻辑能力并在压力之下仍能精确工作。在微软，开发员们相信，在面试中表现良好的人，在许多人急需产品时的最后期限里，更可能编写出过硬的代码（如果这时犯错误，必然会在计算机出版界曝光，并使公司国内或国际范围内的声誉扫地。）他们所需要的人员不仅局限于为编程而编程，而且还追求个人挑战并乐于将产品投入市场——既为自己又为公司赢利。微软经理还喜欢直接从大学里雇佣计算机专业的毕业生，并使他们尽快投入到微软项目中去。
因为开发员在公司的作用很重要，他们编写的代码就是微软的产品，故而招收开发员的过程尤其严格。这在招收人员的年度里占用了许多时间。根据麦克·梅普尔斯的分析，在80年代末90年代初，微软开发员们花费了他们15%的时间来招收新开发员。管理层现在试图限制单个开发员花在面试上的时间——规定每周不多于两次，每次为一个小时。大体上，一位普通候选人在学校面试时会遇到一个开发员，在微软公司会有三个开发员对他进行面试，接着午餐时会遇到另外一两个开发员，所以至少有四到五个开发员面试了每一位最终候选人。如果某部门还不能作出决定，它可以邀请候选人回来再进行面试，如果不止一个部门对某个候选人感兴趣，该候选人可以返回并在其他部门再进行一整天的面试。
微软还要求每一位面试者准备一份对候选人的书面评估报告。由于许多人（包括高级经理们）会阅读这些报告，所以面试者常感到来自同事间很强的压力。他们必须对每一个候选人做一次彻底的面试，并写出一份详细优质的评估报告。戴夫·汤普森在解释NT组招收开发员的办法时论及此事：
开发员是唯一胜任面试新开发员的人我们组织面试。面试至少有一个主要部分是编码问题面试过程组织得很好。每个人为别人提供信息反馈，所以有大量有效的信息交流。你的信息反馈会被所有人看到，这一事实会提高反馈信息的质量，而这无疑又会提高面试的质量。如果面试结束后你写了一份什么也不是的信息反馈报告，里面没有任何数据，你会很尴尬。尴尬会催人进步，不是吗？于是你下次肯定会认真做好面试工作。
测试员微软在招聘软件测试工程师上遇到了困难。很清楚，应用软件测试员必须懂得普通人怎么使用软件产品，而系统产品测试员则需要懂得开发员如何使用特性，以及应用程序和打印机等附件如何与操作系统配套使用。软件的这两类测试员必须热衷于“破坏事物”。他们必须想办法让产品失败，使之不能正常工作——这恰恰是与程序经理和开发员相对立的工作。这并不需要有共同的技能和偏好。
戴夫·穆尔简要地说道：“寻找愿意成为职业测试员的人很费力。”这种困境起因于微软不愿意招聘其实想当开发员的人来当测试员，因为有些人认为他们可以通过当测试员来达到目的。又由于编程方面的知识对于有些测试，如对操作系统和语言的测试是有用的，甚至相当重要，情况就变得更复杂。
的测试经理马克·奥尔森具有微软经理们在测试员中寻找的那种类型的背景和智力。奥尔森，1965年生于华盛顿塔科马，可算是与计算机一起长大。在大学读物理学时，他修了几门编程课和其他技术课程。毕业后，他在IBM呆了几年，从事半导体材料开发工作。由于他没有研究生学历，他被限制在初级研究职位上，他本人对此感到厌倦，于是回到华盛顿寻找新工作。奥尔森谈到1989年加入微软的经历时说：“我在我的母校进行软件测试职位的面试。他们面试各类事情。我是物理学专业的理科学士，那时这样的学位并非求职时理想的敲门砖于是我抓住这个机会，研究微软公司的所有情况，以及有关测试员的所有情况我知道微软需要有人来分解、破坏软件，理解它们怎样运作并确保它们能正常运作。”
奥尔森迅速成为公司几位顶尖的应用测试员之一。但他还是觉得准确鉴别称职的测试员所必备的素质很难。在面试过程中，他寻找与开发的想法不同的人——这些人从不想当然地认为一个特性会正常运作。他们研究可能导致特性失败的隐性内容，比如“多特性测试”（测试一个特性与另一个特性的关联）。奥尔森说：
在面试过程，很难确定具备什么样的素质会使人成为一位优秀的测试员。要确定这种素质比仅凭借编码知识就能推断工作能力的情况要难得多。要做测试员，不仅需要有能力在没有任何记录的情况下，学习新软件并抓住主旨，而且需要具备检查它的能力，于是我们寻找永恒的怀疑论者，他们从不认为任何事情是想当然的。他们不会因为开发员说软件能正常工作就随声附和，他们调试它，把它推向极限对于特性应怎样工作，测试员必须在另一方面比开发员更精明必须能够懂得电子表格的用途以及客户怎么使用它。然后由一两个人通过在6个月内模拟100万人对电子表格的使用来对产品进行测试。这是真正的挑战——要抓住所有的情形。
像奥尔森那样有一个理科本科学历背景的人，在测试员中相当普遍。同时，他们也普遍缺乏为其他公司测试软件的经验。微软经理们喜欢直接从大学里招收测试员，或至少是招收在测试方面没有任何经验的人员。缺乏经验但聪明的人能够很快掌握微软那套测试方法，同时对微软的低工资和高要求也会感到满意。
不排除有些测试员在加入微软之前已有些经验。比如Word组的测试经理詹妮·希尔顿，她曾在塞乔州立大学主攻历史和自然科学，并在威斯康辛大学获科学史硕士学位。她曾在一家计算机系统公司干销售工作，接着在微软的竞争对手——软件出版有限公司（出品哈佛图像）干了5年的测试和质量保障工作。希尔顿在1990年加入微软，并且职位升迁得很快。
有时，测试员还来自微软公司内部的其他职能部门。奥尔森估计在1993年Excel组里共有50位测试员，其中15%来自客户支持部门。他们对于一般客户面临的问题有深刻的洞察力，莫希·邓尼曾做过Windows NT3.0版本的测试经理和程序主管，早先他曾是一名程序经理。但是，经理们不鼓励开发员们转行干测试工作——特别是在应用软件部门。因为程序员们经常假定他们的代码能很好地进行工作，而好的测试员可能不会接受那些代码。奥尔森强调指出：“我们愿意要那些想当测试员的人，我们不要那些想当开发员的人。开发员用非常结构化的方式编写代码，他们作出假定，并根据这样的假定来编码。我们不想要任何预先作出假定并满足于此的人。我们需要对这些假定提出质疑的人，并且他们能够提供更多的东西。”
与应用软件部门不同，系统软件部门的许多测试员与开发员具有相同的背景。而且，他们偶尔也会由测试转向开发，也有人从开发转向测试（但在真正有才华的开发员中这种情况很少）。这种人员的混合是有意义的，因为用户并不直接地与操作系统打交道。操作系统特性的关键用户是为这些系统编写应用程序的开发员。对于计算机语言和软件开发工具，情况也是一样，比如戴夫·马里茨，有生态学（从南非大学获得）和计算机（从以色列特克里昂大学获得）的学士学位，在1987年加盟微软之前，他还做过以色列武装力量的坦克司令员和空降控制系统的汇编程序员。马里茨在微软先做图像工程小组的领导工作，后来成为MS-DOS/Windows的测试经理。
莫希·邓尼曾有程序开发经验，但不是在微软。他曾在以色列特克里昂大学学习计算机工程并从事过军事应用软件的开发工作。他在1988年加入微软并成为OS/2软件的程序经理，后来又成为OS/2的测试经理。在做Windows NT的测试经理之后，邓尼雇佣过50个测试员，其后，他又雇佣了更多的测试员。他通常试图招收开发员来做测试员。邓尼承认有过很艰难的时刻，他说：“我们不得不推销我们自己，因为在许多人的心目中，软件测试与干练的软件工程师认为的富有挑战性的工作不符（但是）他们要通过同样的面试过程。”这种面试过程的筛选标准是任何被招进OS/2项目的开发员也必须通过的。戴夫·马里茨在雇人当测试员并说服他们乐于从事这项职业时感到非常费劲：
大家变得厌倦测试干测试员这行我们晋职机会不够，并且我认为我们雇人的办法也很成问题。戴夫·穆尔和其他人可能会有不同的看法，但是我们从大学里雇佣所谓的STES（即软件测试工程师），而这些年轻人他们全力以赴学习计算机并决心取得CS（计算机科学）学位，他们向往编写代码。但我们却把他们领到这里，让他们从事测试。这些年轻人会觉得疲乏之极但是这是唯一能够达到招聘标准的候选人。我们的这些标准是你首先要进行面试，必须问被面试者编码方面的问题。如果你偶尔遇到一个非常棒的人——你也许能够让他在实验室里工作三个月，测试应用软件。学习连通性和Novell工作原理——但他却不懂多少编码知识，他不会把一个整数插入到一串C语言整数链表中去，他就永远不会被这里雇佣，因为他无法通过面试。
为弥补测试员人手不足，同时应付产品测试的高峰期（比如当一个产品β版本刚完成时），微软经常雇佣兼职或合同测试员。这些人通常没有编程方面太多的知识，他们一般工作时间长，而工资较低。其中有些人，像吉姆·康纳尔，知道许多编程知识，于是成为了正式雇员和经理。
其他部门微软不要求产品经理有编码的专业知识，尽管他们中多数人有工程学背景，并且一些人还学习过计算机。他们一般能在各种设定值下熟练地使用计算机软件，他们中越来越多的人有商务管理方面的高级学位（如MBA），以及市场营销的正规知识。比如麦克·康特，在加入微软并成为Excel组的产品经理之前有管理与信息系统专业的学位，并有销售和信息咨询方面的经验。理查德·巴斯有美国海军学院电子工程专业的本科学位，在海军部研究与开发程序管理部门工作了10年，接着又在MIT获管理学硕士学位，他于1990年加入NT组，成为产品经理。桑贾伊·帕塔萨拉蒂作为高档消费者技术部商业发展组的产品经理，具有计算机本科学位和MIT管理学硕士学位。而克里斯蒂·威奇斯，曾在布格桑大学攻读政治学和心理学，他从人事部转到Excel组从事产品管理，后来又转而从事系统产品的市场营销工作。
客户支持工程师同样也有广泛多样的背景。在招收该专业人员时，PSS经理寻找具有如下品格的人选，如候选人看上去是否感情投入，是否乐于解决别人的疑难问题并教给他们正确的使用方法，是否具有良好的分析解决问题的能力和交流技巧，而不是仅有技术文凭。19前PSS市场营销主管特瑞希·梅补充说微软还进行一些基本的心理评估和测试，特别是对于那些即将走上管理岗位的新雇员。一些客户支持工程师有编程的背景，但他们主要的工作是帮助客户，其范围从MS-DOS和Windows的初学者直到高科技产品，如语言编译程序或网络交流系统的熟练用户。比如马克·辛登沃格有数字电子专业学位。在1984年加入微软之前，从事计算机硬件修理工作。他领导过一个支持Mac机的Excel软件小组，后来转到Windows支持组。现在他是PSS部Excel组的产品开发顾问。
准则三：通过边干边学和言传身教培训新雇员怎样教育和引导加入微软的新雇员？这个问题随着公司产品的多样性和复杂程序的增加变得越来越棘手。特别是在程序管理之类难以定义的功能领域，这一问题尤为突出。早期，人们通过交谈或边看代码边使用产品来交流产品设计知识。新雇员注意观察有经验人员的工作，每个人通过“试错法”来学习。在许多领域，微软现在还是这样运作的。微软试图雇佣能自学业务的人员，而不愿在培训项目、正规条例和流程，或者详细的产品记录上大量投资。它依靠熟练员工来教育新雇员，这些熟练员工有组长，某些领域的专家以及正式指定的指导教师，他们除了本职工作外还要担负起教导新雇员的责任。
这种办法有它的优点和缺点。优点在于大家觉得有权学习并自己决定学什么和不学什么，他们在公司里的作用灵活机动，只要有能力应付，这种作用可以变得相当广泛。但是这也有消极的一面，新雇员的提问常常会暂停熟悉员工的工作。而且由于微软的快速发展，有经验的中层经理和组长很缺乏，新雇员常常不得不通过试错来学习或者跟着经验不超过两年的指导教师学习。这时的错误成本可能很高——会在世界市场上有损公司的收益和声誉。
程序经理微软发现雇佣，培训程序经理都不容易。麦克·康特谈到他的经验时认为，程序经理的工作是“部分在学习，部分在创造。”在公司早期，这一概括尤为正确。甚至在吉布·布鲁门萨成为第一位程序经理的十年之后，微软还没有为这个职位制定详细的工作指南。康特承认这一点，他说：“总体上说是微软，具体地说是微软的程序管理一职，都没有正式的取向。这里没有正式的培训项目，没有任何事情必须要由手册规定，比如所有程序经理必须这样编写说明书，或者必须这样制作产品模型，甚至这样来安排时间表等等。”
程序经理现在可以受到一些正规的培训，包括一个供选修的为时三周的培训项目。另外，微软不定期举行“蓝碟”午餐会，届时会有程序经理介绍他们自己的经验。比如，约翰·法恩曾经介绍过怎样制作一份好说明书，他的这次发言被制成录像带在公司内部传播。但是，总体上微软经理们深信，边干边学，言传身教以及开始时选择合适人选是培训程序经理的良好途径，这些比试图在教室里教育他们要强得多。法恩在他还是程序管理主管时谈到并强调了这一点，他说：“假如你雇到了合适人选，那么有效的培训带来的好处90%来自于言传身教，即新程序经理与更有经验的成功的程序经理一道工作，并向他学习。这些年来在培训方面通过其他机制的努力达到剩下的10%。与开发员和测试员相似，法恩强调程序经理也通过从相对简单到更复杂的项目来学习经验：
刚开始时，你的任务可能是一句话就能说清楚的单特性领域，对初学者来说或许是一个很难透彻理解的领域：负责一个单独的特性。这意味着你应确保产品推出时特性领域各个方面也完成了——它不会导致产品脱节，它具有一定的稳定性和功能这种工作要干一段时间——6个月，1年，无论多长时间，都会有人对你进行密切的指导随后，当这种工作你已做得相当熟练之后，你会在更大的特性组中从事类似的工作，但指导会少得多。一段时期之后，你会拥有一个小项目或一个大项目的一部分。如果你从事的是一个小项目，你会是它的唯一的程序经理。这是对程序经理的第五档要求。这是一个我称之为“Ninja程序管理”的职位，也就是说，无论一个项目对于你有多么难，从刚开始至任务完成，你要想方设法当然有许多发展方向。像在其他公司一样，你可以从事管理工作。这样，你要想到越来越多的跨产品的战略问题。当你达到这个深度时，就像在其他公司一样，你的功能领域已变得没有意义了，你可以做公司需要你做的事情。
开发员新开发员必备的经验水平以及特殊的培训定位要求，随不同的组，不同的产品和特性而变化。在诸如Excel和Word，甚至Windows和MS-DOS组里，大多数开发员只有两三年的经验。但在Windows NT组里，核心设计者在大型组织，如DEC的操作开发上有12年甚至更多的经验，大多数其他NT开发员有4年的经验。这其中一些人来自公司外部，一些人来自公司内部（如从OS/2或语言软件转来的）。在所有的组里，让新开发员加入进来变得很难，因为软件主要产品构件的数目非常巨大，而潜在的互相作用也越来越复杂。Word的开发经理爱德·弗莱斯曾在新墨西哥州技矿学院主修计算机专业。1992年转到Word前在Excel组里工作，他解释他对待新加入者的办法时说：
新雇员是一种挑战非常难。他们在大型复杂程序开发的中期加入进来。所幸的是，他们不必知道有关程序的所有事情，还能做一些工作。但是，他们会得到一些痛苦的教训。他们学习他们不得不为尚不明了的事情担忧比如，他们认为他们将在某处装入一些特性，但他们必须理解其中的宏语言，并且那种宏语言影响到他们怎样做他们的特性。如果他们做得不对，他们会破坏这种宏语言，或产品中任何其他模式他们的特性可能在一个模式里能工作，但在另一个模式里却不能，或者它可能工作，但不能在打印前预览，或者根本不能打印。有许多互相影响的事情。
或许因为开发员编写的代码不留余地，代码不是工作得很好就是工作得很糟——微软对这个领域人员有更长的正规定向和培训的历史。微软为新开发员提供了几个为时两天的实习班，培训他们处理开发过程、产品、工具和其他专题。微软人仍在继续争论这些课程的用处，经理们也没有使这些课程变成强制性的。戴夫·穆尔特别强调他喜欢让新雇员马上投入工作，甚至不必“看上半个小时录像带以了解微软如何起家。他们或许已经知道了这些事情，这是对士气的抹煞。从校园来到这里的最初时刻是令人兴奋的，这样的兴奋将贯穿他们今后的工作。项目急需这些人员加入，立刻加入，在第一天就加入。”
在头几天里，新雇员与经理们及来自其他专业部门的高级人员见面。他们会听到有关开发周期的一个方向性的简介，详细的开发过程他们将在以后的项目工作中学到。开发经理会立即派给新雇员一个单独的任务或者让他与特性小组一起工作。他们还可能把新雇员介绍给愿意当指导教师的高级开发员。在许多组里当指导教师是一个正式任务，一个人当9个月。“指导教师是真正做培训工作的人”，穆尔说。新雇员开始从事相对容易的特性编码工作，这种工作需要一周左右时间并且与其他特性关联甚少。高级人员（特性组长、领域专家、指导教师）随即非常仔细地检查新雇员编写的代码。
在有些组，新开发员能看到描述产品内部结构的有关文献。比如Word、Excel、Windows NT软件都有入门书，分别为“Word Internals、“Excel Internals”和“Newcomer Doc”。但这些入门书很快就变得过时了，并且不像新雇员所希望的那样详尽。这些入门书也不可能通过书面语言解释清楚在大型系统中计算机代码的复杂性。所以新雇员还必须依靠指导教师，并且通过亲自阅读代码，做实际编码和调试工作来学习知识。乔恩·德·沃恩以前在Excel组工作，现在是Office的开发经理。他曾在俄勒冈州立大学学习数学和计算机，1984年加入微软。他谈到了“Excel Internals”这类文件和微软的“口授传统”：
解释了Excel一些基本事情，像单元表格式，存储器的配置，层次（操作系统的特殊界面，使在Windows和Macintosh平台上使用相同的Excel的核心成为可能。见第5章）的一些知识，介绍非常零散。我们必然依靠这点东西来学习知识。我想说我们有很强的口授传统，这就是指导教师来教导新雇员或新雇员通过读代码自学在一个项目完成过程中，这些文件的真实性在减少，于是我们必须修正它。在我们做项目时我们不修正它，但我们会在项目之间给予足够的关注。
德·沃恩认为这些文件尽管不完美，但仍有用。因为Excel现在由上百万行难度很大的代码组成，这使新雇员学习起来相当吃力。通过自学来掌握有关系统的知识变得特别重要（和困难）。因为大约半数Excel开发员在微软工作的年限不超过二三年，而且整个项目仅有一位技术领导。不断更新这些文献是另一项费时的工作，是德·沃恩和其他微软员工所不喜欢并倾向于放弃的工作。结果，他们使文献尽量短小精悍，并且仅在产品的两个版本之间才更新它：
在组里，我现在正把重点放在这上头。Excel很难学。你初次面对几百万行代码——你从何开始？我们总觉得要使它变得容易的途径是记录更多的东西——但是，现在，你不仅得保留你的源代码，而且保留你已写下的所有东西。我已说过，在过去，指导教师的作用发挥得很好，但Excel5.0版本的开发是个例外。也许我们真需要写下更多的东西。但是，草率的一面是所有新雇员已投入工作，尽管他们的认识还相当模糊。
组在微软公司发挥了特别的作用，它不仅是软件开发过程和特性标准化的技术领导，并在事实上成为培训有才华的开发员和经理的基地。正如程序管理部门的约翰·法恩一样，德·沃恩认为新雇员通过实践会学得更好，他说：“我们所做的仅仅是根据大家的级别层次，把任务分派给他们，或他们接受任务，然后靠他们的聪明劲儿把任务完成许多人为此感到不安，他们说：‘我们不能让他们做这些工作，他们没有任何经验，’但是这里，我想我们应该说：‘是的，他们没有经验，但他们可以边干边学。’”德·沃恩回忆起他在微软干的第一份工作，那是让他为Mac Excel1.0版本写拷贝保护软件。这项工作迫使他去学习，在高深的技术层面上，Macintosh机磁盘驱动器在软件和硬件方面怎样工作。德·沃恩还认识到让人们自己去学习的结果是不时会出现错误，而这是一个好经理应该预见到的：
首先，人们可以犯错误。犯错误之后，然后观察怎样修正它，这样可以学到很多东西。这也是我学习知识的关键途径之一当某人从事一项新工作时，其他人或许是这个领域的专家，当他们的代码写成之后，会有最好的专家来查阅他们的代码并告诉他们，这样编是对的，或这么做会更好这样每个人都边干边学指导教师会解答疑难问题但当他们觉得自己的代码编写完之后，会有人对代码进行检查并找出错误。
当然，并非所有新来者都有乐观的初次经历。在小产品组里的新开发员，受到来自高层管理人员的注意较少，很容易在忙乱的工作中被忽略掉。大卫·惠特尼，MIT1990年计算机系的毕业生，从事微软Mail的工作，他联系自己的经验评论说：“他们分派给我零散的任务。在搞一个新项目时，他们把新雇员使来唤去，一会儿让干这个，一会儿又让干那个。我干的都是一些低层次应用结构方面的杂事，处理存储器管理程序并进行调试，就干这样一些事情。”
微软过去为开发员提供了更多的定向培训。在80年代，微软最富才华的程序员之一道格·克隆德（他最近离开了公司）为新开发员办了一个叫“训练中心”的培训项目。这个培训中心的培训计划根据受训开发员的能力持续几周或几个月。这个培训中心被赞成者称为“克隆德大学”，被反对者称为“克隆德花园”。新来者还通过其他事情学习。比如，查尔斯·西蒙尼发明了一种独特的编码规则，在微软使用时被称为“匈牙利标记法”（见第5章的讨论）。在经理们允许他们加入项目开发时，开发员还必须通过其他的考验。微软人经常争论花很长时间对开发员进行定向培训的用处。事实上，PC机软件公司一般不搞广泛的新雇员培训，它们大多数都雇佣熟练的程序员。（这与主机和微机的软件生产者相反，他们通常有二三个月到一年的培训项目）。几年前，“克隆德大学”结束了，因为克隆德本人对此感到厌倦。此后，微软转而直接把开发员安排进项目，只提供指导教师和几门供选修的短期课程，以提高他们的技能。
指导教师制并非尽善尽美。它依靠熟练员工来指导无经验人员，并主要是通过示范和口头说明。但当微软熟练员工变得相对短缺，而同时产品越来越多样化和复杂化时，情况就不太妙了。这正是Excel5.0版本所遇到的情形。由于种种原因，该产品直到1994年初才面世，比计划时间晚了几个月。（以前，Excel项目最多只延误几天或一两周时间）。德·沃恩谈到这个问题并分析了原因——微软没有及时安排有经验的人做指导教师。他说：“上个夏季，我们没有那么多有足够经验的指导教师来做工作。而且，我们野心勃勃，急于求成，为了该项目的某部分投入了大量人力。但当别的工作开始时，会产生很大的冲突。也许下次我们应该提出建议，每周给出一些时间来安排指导教师。”当微软减少新雇人员并且规定任何一组当中，新雇员不得超过开发员的50%时，这类问题减少了。微软也增加了更多的正规培训。正如盖茨所说，微软人还是喜欢主要靠言传身教来培训新雇员，并且他们认为现行方法不会导致严重问题。
指导教师制？实际上并没有什么不好我们过去有非常正规的培训，但人们对此并不特别热心。不是有些人不学，光浪费时间，就是有一些超级巨星对此根本不屑一顾。存在固定的事情，固定的计算技巧，但是给这些人一本“编程入门书”（怎样编写计算机代码的初级课程）足矣，只要确保他通读了全书并理解了书中的东西，给他看代码，并问他一些问题。现在我们非常正规，我们提供了一系列课程，大家可以以适当比率来选修。但是，进入一个项目，从更高级人员处学习，这对我们来说似乎更为成功。
测试某些定性策略、技术工具（如自动测试程序和错误数据库）可以使测试变得更有效。在加入产品组之前，微软为所有的测试员提供基本的培训。测试员可以在实习室和讨论会上学到上述那些东西。而其他的知识，如有关特殊产品的知识，或者怎样最有效地使用特殊工具和技术，则需要导师的言传身教和在职经验。
尽管在不同产品领域内存在着许多共性，但在接受最初的基本训练之后，各个产品单位都有各自的方法向新测试员传授有关产品和测试支持工具的知识。较大的组里还有文件概括测试概念，样本测试计划和清单，以帮助测试员确定什么时候算是完成了测试任务（见第5章）。Excel组甚至有“电子帮助文件”来收集对Excel测试员有用的信息，但是目前尚没有建立结构化系统方式来进行测试。马克·奥尔森在谈及检查使用软件的所有不同方法的困难时，强调了这一点，他说：“使你的测试覆盖产品的方方面面，并保证不会把事儿弄得一团糟的方法是建立测试结构。你有系统的方法来浏览和修正一个特性，你有需要测试的事项的清单，并且延长这张清单，你必须确保没有遗漏任何一个特性中细微的环节，你必须使你的开发组尽可能明白这些。当他们编写代码时，必须将这些问题考虑在内。而不是当你找到一个错误时才轮到你来修改，以使它正常工作。”
像其他的专业一样，测试员作为特性测试组的成员来学习专业知识。小组由三至八九个熟练测试员和新测试员混合组成。测试员还和单个的开发员配对进行工作。测试员仍向组长（测试小组的“主管”）和部门测试经理汇报工作。测试员也有指导教师，但微软并不像依赖开发员指导教师那样依赖测试导师来进行培训。
不知如何编码的测试员进入微软后通常要学习这个技能。他们学习一门Basic语言或更高级的语言课程。编程对所有组里的测试员都变得日益重要。凡是带有宏语言的产品，包括Excel和Word，需要进行编写代码的测试。事实上，越来越多的应用产品包括了宏语言，以使用户能按规格改装产品，（一个宏指令是指用户可以把一系列命令变成一个简单的命令或一次击键，在一步中完成一系列任务。）在系统领域，许多测试是通过编码运用不同的应用编程界面（APIS）构成的，所以在这里编码很重要。但甚至在应用程序组里，测试员越来越多地使用自动测试生成器和宏语言来编写测试案例。这些需要基本的Basic知识或者Basic语言的图形版本Visual Basic的知识。
其他专业部门产品管理和用户培训专业的人员培训是非正式的，新雇员通过边干边学和从指导教师那里学习知识。新雇员很大程度上还依靠过去项目的范例来学习，这些范例包括以前完成的成功的市场营销报告和计划，或较好的记录文件。大学市场营销课程中的产品管理以及相关科目（比如英文写作和编辑，图像设计和图书出版）对于用户培训人员也是有用的。
微软为客户支持工程师提供了正式的培训。这种培训与公司在过去几年里努力改善公司形象和提高为顾客服务的能力是密不可分的。顾客不仅仅只是购买微软的产品，他们还会享受到许多售后服务。客户支持工程师不必像开发员那样有必备的职业教育，但他们必须有关于微软产品如何工作的广博知识，并且实际上必须在某种产品上具有专业知识。
新的客户支持工程师在分专业之前，接受三至四周培训。这种培训从基本的系统产品MS-DOS和Windows开始。他们还接受交际技巧，包括如何与顾客打交道等方面的一般性训练。为便于边干边学，新PSS雇员通常从Windows支持分部开始，接着进入应用程序支持分部。作为定向培训的一部分，他们还接电话，与导师一道工作（每位技术员有一位导师）。在他们被分配处理客户的电话之前负责答复客户来信。20工作确定之后，每个雇员每年还要接受大约20小时的再培训。
培训电话服务员的高级PSS人员，与开发组织密切合作以理解他们开发的新特性。同样，数据库工具之一的知识库（支持人员用它来帮助回答问题）的管理员也与开发员和用户培训组织密切合作以理解他们开发的新特性。马克·辛登沃格，负责PSS产品开发分部与Excel软件单位的联络，他解释培训和对产品开发的投入在本部门所起的作用时说：
世界范围的培训计划将从事对新雇员的培训工作。在我们组，特别是Excel组，我们的培训是整个开发交流周期的组成部分。他们是负责文件浏览和说明书浏览人员的组成部分，他们从产品设想开始紧紧跟踪它的开发，所以他们后来实际负责进行有关该产品的人员培训。知识库的编写也是同样，他们为工程师提供许多关键信息。所以，他们要经历整个产品开发周期，他们了解产品工作的目的，工作方法以及决策的制定。接着他们就进行培训。
准则四：设立晋职途径和“升迁级别”以留住并奖励人才微软在产品组里创立了技术专业并雇人充实这些专业部门之后，一个新的问题产生了，这是许多公司遇到的典型问题：怎样把人才留在技术岗位上和产品组里，以便利用他们积累的专业知识和公司已付出投资的工具、技术和培训。正如前面提到的，微软倾向于把有技能的开发员推到管理者的岗位（比如产品单位的主管），而且中层经理人员还继续编码或测试程序。但是当开发员，测试员和程序经理只想呆在他们的专业部门里，并且只想升到本专业的最高位置而又不必担负管理责任时，职业管理的问题就产生了。
微软做了一些在鄙视官僚主义的公司里很少见而在高科技公司里相对普遍的事情，他们在技术部门（比如在测试和开发领域）和一般管理部门（比如在产品组和公司一级）建立了正规的升迁途径。
建立技术升迁途径的办法对于留住熟练技术人员，承认他们以及给予他们相当于一般管理者可以得到的报酬是很重要的。梅普尔斯说：“我们非常清楚地意识到双重职业的概念。当一个家伙不想做经理时，他也能像一个愿意做经理当头头的人那样发展并升迁。”
在职能专业部门里典型的晋职途径是从新雇员变成指导教师、组长，再成为整个产品单位里某个功能领域的经理（比如Excel的程序经理、开发经理、或测试经理）。在这些经理之上就是跨产品单位的高级职位。这包括职能领域的主管或者在Office产品单位中的某些职位，他们负责Excel和Word产品组并且构造用于Office应用软件的共同特性。
微软既想让人们在部门内部升迁以产生激励作用，还想在不同的职能部门之间建立起某种可比性。它通过在每个专业里设立“技术级别”来达到这个目的。这种级别用数字表示（按照不同职能部门，起始点是大学毕业生的9或10级，一直到13、14、15级）。这些级别既反映了人们在公司的表现和基本技能，也反映了经验阅历。升迁要经过高级管理层的审批，并与报酬直接挂钩。戴夫·穆尔回忆起1983-1984年微软建立的晋级制度。这种制度能帮助经理们招收开发员并“建立与之相匹配的工资方案。”当微软建立起其他专业部门时，每一个领域都建立了相似的晋级制度。
级别对微软雇员最直接的影响是他们的报酬。通常，盖茨的政策是低工资，包括行政人员在内，但以奖金和股权形式给予较高的激励性收入补偿。行政官员和高级雇员的基本工资比公司的平均工资高不了多少（像许多日本公司一样）。盖茨1994年只拿了27.5万美元的工资和18万美元奖金。但他还拥有公司25%的股票。其他高级行政人员拿的也差不多或更少。像史蒂夫·鲍尔莫（他拥有公司5%的股票，是公司第三大亿万富翁，仅排在盖茨和保罗·艾伦之后——保罗·艾伦作为董事会成员拥有公司10%的股票），1994年他工资收入为24万美元，奖金为19万美元，麦克·梅普尔斯工资额是24万美元，奖金为25万美元。22刚从大学毕业的新雇员（10级）工资为3.5万美元左右，拥有硕士学位的新雇员工资约为4.5万美元。对于资深或非常出众的开发员或研究员，盖茨将给予两倍于这个数目或更多的工资，这还不包括奖金。程序经理和产品经理与开发员的工资几乎一样多。测试员的工资要少一些；刚开始时为3万美元左右，但对于高级人员，其工资亦可达8万美元左右。由于拥有股票，微软的17800雇员中大约有3000人是百万富翁——大概算是相似规模公司中百万富翁比例最高的。
即便是技术级别或管理职务上升得很快，有才华的人还是易对于特定的工作感到厌倦。同时，产品组和专业部门也得益于有不同背景和视野的人员的加入。相应地，微软经理鼓励在产品组之间保持某些人员的流动性，并且他们不阻止合格人员转到不同的专业部门。但是，人们只有在某一特定领域积累了几年经验之后才能换工作。微软的大型产品，像Office、Word、Excel、Windows和NT，需要花几年时间来积累经验，频繁地变换工作是不足取的。对有兴趣更换工作的人，在产品组里为其安排一个顺序。虽然这种顺序随时间而变化，人们通常还是认为某一个组与一些产品比另外的产品更值得去做。在应用软件中，这种看法似乎是根据该组对微软的销售和贡献大小来决定的。而在系统和语言部门，这种标准却围绕着技术挑战性和声誉的高低。比如，Windows NT和OLE是比MS-DOS更吸引人去做的产品，因为，它们一直是巨大的收益发生器。Visual C++和Visual Basic比其他不很普遍的语言更具挑战性。公司的部分其他产品——比如多媒体、交互式电视机或者联机Video和网络服务之所以吸引人是因为它们属于高科技产品，拥有快速发展的新兴市场。在应用软件部门，Excel一直是最著名的，但要求也最高。又由于Office现在是主要的应用型产品，它对于应用程序开发员来说是新的乐土。
程序经理程序经理具有与其他专业人员一样的晋职途径。他们的职务范围从指导教师、组长到部门的程序经理，还有一个负责人员调动的职位：程序管理主管。（这是一个临时的和业余的职位，没有多少人愿意干。程序管理仍是一种复杂的难以定义的职能领域，供主管开发和利用的工具、技术和思想都很少。）这个部门的新雇员一般有大学毕业文凭并从10级开始干起。在1994年，程序经理的最高级别是14级。由于产品的重要程度不同，工作难度的变化也相当大。
程序经理有广泛的职责。程序经理负责与其他组的大部分协调工作，开发员也负责协调特性和共有构件的级别。在微软初期，这种协调主要采用标准化直观界面（比如，菜单和屏幕怎样在用户面前出现）和功能命令（比如，确保Word和Excel中存储文件的方式相同）的形式。直到最近，标准化的努力才有了收获。人们通常共同使用的产品当中的命令、工具条和界面不尽相同。最近，协调的努力主要集中在开发相同的特性和共享构件上。一些有开发经验背景的高级程序经理负责此类型的结构标准化工作。这种工作包括应用型产品（比如Office）和系统产品（Windows95和Windows NT）。
开发员确定开发员的级别（指SDE，即软件开发工程师的级别）是一个比其他专业更正规的过程。这也许是因为确定开发员的级别为其他专业提供了晋级准则和相应的报酬标准。开发经理每年对全体人员进行一次考查并确定其级别。开发主管戴夫·穆尔也进行考查以确保全公司升迁的标准统一。尽管经理们关注平均晋级年限，但微软没有标准的固定晋级时间表。一个从大学里招来的新雇员一般是10级，新开发员通常需要6至18个月才升一级。有硕士学位的员工要升得快一些，或一进公司就是11级。从10级升到11级很容易——用戴夫·穆尔的说法就是“不需动脑子”，“11级的人是那些可以自行工作、自己编写产品代码而不需要太多监督的人。”开发员平均在11级上要呆上两年半时间，但有些人要在这个级别上干许多年，因为升迁考查变得深入了许多。摩尔补充说：“典型情况下，从11级升到12级，我问几个问题；从12级升到13级，我会问许多问题；从13级升到14级，要求经理向我和麦克·梅普尔斯汇报此人对所在部门的贡献；14和15级必须得到比尔的同意”。穆尔，这位14级开发员，详细阐述了升迁标准和要求：
当你显示出你是一位有实力的开发员，编写代码准确无误，而且在某个项目上，你基本可以应付一切事情时，你会升到12级，12级人员通常对项目产生重大影响。当你开始从事的工作有跨商业单位的影响时，你就可以升到13级。当你的影响跨越部门时，你可以升到14级。当你的影响是公司范围的时候，你可以升到15级。通常那些“智囊团”成员一般都是14或15级的软件设计工程师。公司里15级的人员很少。内森·梅尔沃德是15级——他还有副总裁的头衔。查尔斯·西蒙尼是15级。总共只有五六个人是15级。比尔不在这个范围之内，他是总裁。
穆尔估计所有开发员中50%至60%是10级和11级人员，20%属于12级，大约15%属于13级，而剩下的5%至8%属于14级和15级。这些数据显示了微软的快速发展。在过去五、六年里，一半开发员仅有一两年的工作经验。显然，经理们一般不用技术级别来估计一个小组的能力，但他们通常让高级人员来开发特殊的关键特性。经理们会提出他们“需要一个12级”或“需要一个13级”员工来对付项目中某一特别困难的部分。特性小组组长通常是12级，或者非常有经验的11级人员，开发经理一般是13级或14级。14级和15级人员经常从事一个或几个产品中特别困难的体系结构设计。
开发员可以在一到两年内升为指导教师，接着再过几年升为组长。一个特别出众的开发员如有志于管理可以升为部门的开发经理，或者是整个商业单位的首脑，就像克里斯·彼得斯那样。但是，随着开发员人数增长变慢，升到最高开发级别或成为更高级别的管理人员的机会要少得多。马克·沃克，曾在杨伯翰大学受过计算机教育，现在是Word组的开发员，反映了这些变化：
从我开始工作的两三年时间里，公司的变化挺大，机会也变得不同以前。我们仍然干许多有趣的工作，或许比以前还要多。但是现在从人员雇佣的角度来看，我们不再像过去那样增加员工。我所在的组从以前的7人发展到40人，不久又上升到60人。但是这种增长现在结束了。现在整个结构在变。以前，当公司人数增长时，你可以升得很快，并且有许多机会。但现在公司看上去正朝着传统组织的方向发展，当某人离开时，你才能顶上去，并且只能等着被消耗，如此而已。我只好留在组长一职上，我的升迁实际已经停止了。
高级开发员的工作特别富有挑战性，因为微软希望他们既进行人员管理又编写代码。产品组里的开发经理也许是最需要吃苦耐劳精神的职位。此人几乎总是在产品如何工作以及特性如何相互作用方面的专家，同时人们还希望他（她）既尽可能多花时间编码，又能帮助组里的其他成员。由于特性小组组长也是产品特定领域的专家，他们必须全天候地既帮助整个项目又管理他们的小组，以正常开展工作。正如爱德·弗莱斯总结他在Excel和Word的工作经验时所指出的：“我们举荐某人当技术组长。此人一般应对产品通常如何工作有最广泛的理解组长是个要求很高的职位。一方面，他们要用所有时间来编程，另一方面，他们要进行管理和分派任务，回答问题。这也就是说他们必须精通编程，同时还要能处理其他琐事。”组长满负荷的工作是基于这样的假定：因为他们有更多的知识和经验，他们可以用更少的时间来做与其他成员一样多的工作。弗莱斯解释了其中的逻辑：
我们相信，组长能做至少与组员一样多的工作，并且还能办其他事情。换句话说，在我的组里，我已经有一些很好的程序员。如果我真能胜任组长一职，我在一周内应该能够干和他们同样多的编程工作，并且我只要三天时间来做这些工作剩下的两天用来完成我的其他任务有时你在计算机界能听到此类说法，即一个好的程序员比一个差的程序员强上10倍。我不知道差别是否真有这么大，但事实确实如此，他们精通于他们的工作。除此之外，他们还有时间做其他事情。而且一般来说，这就是他们能得到这个职务的原因。他们不仅从事自己的工作，而且还照看其他领域并且学习有关产品的新知识我们总是在寻找发现这类人才。
除了在技术级别和管理职务上可以升迁之外，开发员的另一选择是在微软的其他专业部门寻找新的挑战。这类事情经常发生，特别是在部门内部。正如克里斯·彼得斯所观察到的：“如果你是非常优秀的开发员，你可以在公司的任何一个项目里工作。如果你是一个非常糟的开发员，就很难换组但事实上许多人并不换组，因为他们开始在那些几千行代码组成的程序里学习并提高着专业知识。”在微软公司内部存在着某些分歧，这些分歧所围绕的中心问题是人员在不同产品组之间多大程度的流动于个人和公司均为有益。长时期留在一个组里的好处是开发员能深刻理解复杂产品的大部分。不足之处在于从事同样的工作如果时间过长，人们容易疲倦，甚至精疲力竭，而且人们的工作范围会变得狭窄，不利于部门之间的交流。于是经过梅普尔斯的推动，人员流动在增加，特别是从Excel组流向诸如Word和Project这样的领域。比较统一的意见似乎是开发员在考虑换工作之前应该在一个项目里至少工作两个开发周期或者大约三年。乔恩·德沃恩在谈到人们应有多大程度的流动时说：
我们愿意做的另一件事是在项目的两个版本之间给相当数量的人员一次换工作的机会。这种想法在于人们可以学到有关产品的更多知识，并且我们有一流的程序员，他们掌握着更多的一手资料，即其他人应如何处理问题在公司范围内，我们还有一定比例的人员在项目之间流动我们不鼓励所有人不停地流动，因为这样可能导致某些人在同样的事情上重复工作。我们没必要设计工作指南，因为人们基本上做他们愿意做的工作。我们在过去已作出决策，我们不会让20个人去做同一件事，如果这件事只是一个人的工作。因此，没有必要将其规范化我要说如果有人在同样一件事上工作了三年，这也许足够长了。
区分个人和不同专业的另一途径是报酬。开发员在微软属于报酬最高的一类人。一批有才华并已在其他公司积累了丰富经验的开发员（比如最早加入Windows NT组的开发员）可以不时协商他们的工资额并使工资额超过本级别的平均工资水平。当然这样做的人很少。这种不平等把开发员放在“主角”位置，这有可能加剧员工的紧张关系。但是其他部门的人员似乎意识到在软件公司，开发员必须要有一个特殊地位。理查德·巴斯，Windows NT组内的一位高级产品经理就持这样的看法：
我们中有些人对开发员怀有极度不满的情绪，简直就是忌妒。达瑞尔·希文斯是Windows NT的主要开发员之一。达瑞尔有9辆波尔舍（Porsche——名牌跑车），我希望我也能有9辆波尔舍。但我怨恨达瑞尔吗？当然不。他绝对当之无愧，他棒极了。如果是用我的支票来付给他报酬，我也会乐意的。所幸的是从长期来看很清楚，过一两年，你就会得到你应得的报酬。如果由于某些原因，我们请来了达瑞尔并付给他能买9辆波尔舍的报酬，而他干得并不成功，达瑞尔就不会在这里呆很久但是，这些开发员都是精心挑选出来的人才唯一的影响是，某些人感觉到开发员是“主角”，自己只是“配角”，但这是我们这行的特点。
测试当微软经理们逐渐认识到制造性能可靠、使用方便的产品很重要时，他们更注意在测试领域内留住优秀人才。这有很强的经济含义。因为测试需要在工具、培训上作大量投资，并且个人在特定产品和特性上的经验对于有效的测试是无价值的。马克·奥尔森谈到这一点时说：
我认为，微软的成功，产品的优秀质量，开发活动的卓有成效主要在于测试是有效而独立的领域。它并非不称职的开发员的收容站，也不是想做程序员的人们的出发点。我们真正致力于使它独立所以我们只要那些愿意干测试这一行的人我们希望吸引有兴趣干这种工作的人。我们想要留住他们，并在他们身上投资，培训他们成为适合于各种项目的测试员。我认为这方面我们已经做得很成功，并且还成功地扩大了我们的组织，并沿着这条道路改进了我们的工作程序。
测试员的级别从9级到13级。还没有测试员能得到像许多高级开发员或程序经理一样的地位和报酬。戴夫·穆尔解释了其中的缘由，他说：“如果有测试员向我表明他是14级的材料，我会给他14级如有必要还会有15级。但我还没有见到这类人。”奥尔森虽不是最高级别，但他已经提升得很快了，他说：“实际上我是12级。但当你计算多数级别的年限时，你会发现每个级别要呆上两、三年时间，而我从9级升到12级只花了大约一半时间。尽管晋级途径有限，但我感到高兴的是我有机会学习并且我们将工作干得更好的能力和改进工作程序的理解力都在提高。”
熟悉某些特定的产品很重要。因此，微软经理希望测试员像开发员一样，在同一个产品组干上几年。至少，他们希望测试员留在同一领域内，像在桌面应用软件，系统软件领域或消费者分部内。而且，由于测试员的经验在不断积累，经理们不鼓励他们转到其他部门，比如转到开发或程序管理部门。穆尔强烈反对测试员更换工作，他说：“他们应该一辈子搞测试。如果当初他们是被当作测试员雇进来，就应该作为测试员从事测试工作。”但穆尔承认微软仅到1984年才开始有测试员，到1991年，人数才多起来。公司尚没有为测试员规定清楚的晋升途径和流动范围。像乔恩·德·沃恩他愿意让人在同一个工作至少干上几年。
当然，测试员可以向上升迁。通常升迁的途径是当测试组长，而后是主要产品的测试经理。下一步是测试主管的位置。但大多数测试员更愿意做关键产品单位里的测试经理。一些测试员相信他们至少可以转入其他组和部门，尽管这种流动的可能性相当小。奥尔森描述了这种感觉：
我认为你在这种职业中能干多久并保持头脑清醒有一个极限人们转向程序管理。人们偶尔从测试行当转向编程在你想要的技术级别和管理职务上会有更多的限制。
在我的部门里共有6组人员。每一组有一位测试组长领导，他对本组人员负有管理责任。在我的组织里只做测试的人在增加，有人只做测试并且乐此不疲，他们不愿意管理别人，他们只想搞技术紧接着他们变换产品，因为他们想体验新东西，这当然是一种选择但出现得不多。
对我来说下一步是呆在技术管理岗位上还是转向一般性管理岗位。在我上面的职务不太多。在测试一行，我现在的职务是最高的，我可以在报酬上得到提升，但我的头衔还是一样——Excel的测试经理。
正如在管理和开发部门一样，测试部门的某些工作比其他工作所需的技巧要少一些。从这个意义上讲，测试系统产品可能是测试技术等级中要求最高的，通常它需要大量的编程知识。测试低容量消费者产品的简单特性也许对技术的要求最低。在每一个产品组里，有些特性比另一些特性更富有挑战性，但所有的测试都很重要。因为用户可能会就最简单的问题抱怨公司并打电话质询（一个电话大约要花微软公司12美元）。正如奥尔森所说：
还有一定比例的特性不是那么有吸引力，或者工作起来更枯燥并且不需要技术理解力。比如像测试“帮助文件”你看着文字并按按钮，如果主题出现了，那么一般说来做这种工作不需要多少脑力，但需要有人承担任务，了解帮助文件如何工作以及理解使它正常工作的重要性。我们必须做这种工作。某人可能不适合测试Excel中的程序环境，但他可以弥补我们必须做的工作的缺口。这些人可能没有其他产品测试员那样的技术能力，但很难忽略其工作的重要性，很难通过二者的比较来评估他们的工作是否有同等重要性。你必须检查他们正在做的工作是否与部门职责相吻合，工作是否努力，是否把小事情办好了，所以对工作表现的评估是以个人为单位而不是组范围内的，正像我们已经做的那样。
与每年大约10%的新雇员离开公司相比较，解雇测试员相对要少得多。奥尔森回忆在过去几年里只有4个测试员（他的组里共有约50位测试员）因为工作表现差而离开。因为在这些人身上已经投资，经理们愿意为不放弃努力的测试员提供更多的帮助和培训，而不是解雇他们。然而奥尔森认识到测试员升迁的上限导致了人们的离去，对奥尔森来说一个更棘手的问题是如何激励选择留下来从事测试职业员工的积极性，他说：“对于在组里已干了两三年的人来说，这类问题更大。我怎样继续激励他们？怎样才能使他们不断取得新进展？”
激励测试员的一个日益普遍的方法是送他们参加职业软件工程会议。这种会议集中讨论软件质量或软件测试。微软还发起主办室内研讨会和研习班，并请开发员介绍他们的专业以及代码的功能。这些方法以及1993年罗格·舍曼被任命为专职测试主管，都增强了测试作为一个独立的职业技术部门的形象和地位。他们还让微软人更多了解被该行业其他地方和其他公司运用的测试观念、工具及其实践活动。戴夫·马里茨欢迎这些新进展，他说：“每年预算可供10个人去全国各地参加研讨会。我想这很好，因为我不是测试方面的世界级专家。”
其他专业部门微软的其他主要职能型部门——产品管理、客户支持和用户培训——也有与开发员及其他部门相类似的晋职途径、正规级别和报酬支付体系。正如我们以前提到的，这些部门员工可以更换工作，特别是从产品管理部门转向程序管理部门，从客户支持部门转向测试部门。
总之，微软的人员管理是比较成功的，特别是对于这样一个快速发展的公司，在发展进程中没有“职业化”的管理人员，这种成功经验尤为可贵。1991年在应用部门进行的一次调查（见附录4数据摘要）表明：大多数雇员认为微软是该行业的最佳工作场所之一。当然还有一些问题：比如对新雇员培训不够、部门之间缺乏合作等等。这些问题，盖茨和其他经理们正在想办法解决。员工对于低工资（不包括津贴在内）以及工作中“质量”与“数量”需求存在冲突这两个问题也有反映。但整个调查结果显示，微软提供了一个非常好的，尽管不是尽善尽美的工作氛围，这里有精干和平易近人的经理，而且几乎没有人耍政治手腕，搞官僚主义。微软为员工提供了有趣的和不断变化的工作，并有强烈的团队文化以及大量学习和作决策的机会，同时它允许人犯错误。第3章将讨论微软开发的各种产品以及公司如何在不断扩张的PC机软件市场上开展竞争。