电话分析向PSS打电话的是客户中的少数。微软的信息资料表明，70%的软件用户从来不打电话来，而另15%的客户却打进了电话总数的70%。大多数打过电话的只就每种产品打过一两次，并且一般仅限于购入之后的前90天里，因为在此期间电话可免费打入。历史资料还显示，在前90天里打入的电话中40%到60%是有关设备安置或软件安装的；其他常见问题涉及打印、新的或有变化的特性的使用、操作环境及与其他产品的共同操作性。19很多客户在遇到问题时会首先求助于邻居。然后他们会利用产品的帮助文件、说明或去找卖给他们计算机或软件的零售商。由于向微软的客户支持热线打电话是大多数用户的最后求援之道，理解客户这种选择组合的需要对减少电话数目就显得至关重要了。对这些用户的研究结果激发微软要使某些特性更易于使用，并提供出更好的帮助文件和产品说明。微软还决定对计算机零售商、软件咨询商及乐于帮助周围人的熟练用户提供更多的信息和培训。
微软也知道哪类产品、在什么时间段产生的电话最多。例如1993年间，70%的电话是来自于高居销售额榜首的5种产品，其中：Windows占31%，Word占15%，Excel占12%，Fox Pro占8%，MS-DOS占4%。微软甚至仔细跟踪了解每种产品的平均电话持续时间及与此直接相关联的每种产品的平均电话费用数。从微软总体上看，平均每个电话耗费约12美元（低于15美元以上的同行业平均费用）。20但是，产品不同时，费用、电话模式和长度也大相径庭。比如，1993年中，花在Wordfor Macintosh上的平均电话费只有7美元，而Wordfor Windows则要花12美元。这种差异似乎可以说明Macintosh产品还是要稍微好用些。或许是从DOS程序上转移出来的人数过多之故，Windows用户呈现出电话咨询更频繁的趋势来。
过去，微软是要每个部门等额交纳产品支持组织费。但自从1991年7月以来，微软已改为向单个产品单位收取支持费用。这意味着如果一个组的产品用起来很费劲，设计的特性有许多都是“电话发生源”，那这个产品单位就必须承担所有这些支持费用。“基于活动的成本核算”是微软征集的一个术语，凭借这些征集活动微软才能核定每个电话的准确费用，从而决定如何向单个产品单位收费。麦克·梅普尔斯曾解释过他怎么又被牵扯到对PSS的管理上来，这不仅是出于盖茨新近关注起PSS的驱使，而且出于他在消减成本方面的一贯努力：
两年半以前我开始看人员统计。那时我们一直忽略了它们，突然之间我认识到比起开发员来，那里的人员数目更多，于是我说：“这是个不妙的势头”。所以我们做的第一件事就是开始把所有的产品支持费用直接记到产品头上。现在，每种产品会得到一份月报，告诉他们有多少电话、占收益的比重、存在哪些问题，这一做法已扩及全球。我开始这么干的原因是我刚来时，没有人注意产品成本问题：你们想，500美元收益中20美元可以扣除出去，谁还在乎产品成本。所以我们召集了个工作组，提出了一些简单的准则。我们能从产品成本中削减8%至10%——即20个百分点中的8或10个百分点。这是很大很大的变化。从利润计算来看，这简直是直逼成本底线。
很显然，当你有了问题时，要做的就是让人人都引以为忧，这也正是我们处理PSS问题时首先做的；我们开始向所有的人报告发生的问题。然后，我们有了一些实际的简单准则，就像说，在你成为我们的工作对象之前，为什么不对每次产品发布都设法减少一半原有每单位产品的电话数或一半的电话时间呢？于是你会想，好吧，怎么解决这一问题？
其实很明显。你必须处理最集中的难题。所以，如果打印信封是处理电话的用费中最突出的问题，就派些人去动脑子把它做好些。
梅普尔斯把产品收益的8%设为总支持费用的上限（相比而言，微软估计Word Perfect的此项费用为16%）。同样，各种产品间有了很大差异：Excel和Word的收益中7%花在产品支持上，6%则花在用户产品中。相比来看，Windows的这类支出占收益的20%，而Windows NT则占到25%。微软很快发现，公司诸如Windows NT和LANManager这类客户服务器产品支持起来开支更大，因为它们引起的电话比大多普通PC软件要多而且长些，需要更老练的支持技术人员。因此，向这些新产品领域的成功推进要求在支持组织上进行有意义的同步投资。
定价机制以及对产品类型和所收到电话类型之间的关联分析对于控制和预测在新的、现存产品上的电话支持需求是至关重要的。有的产品会在前几周或数月内便有大部分电话打进来，可其他产品可能要很长时间后才有电话。微软和其他PC软件公司一般在客户购入产品后至少前3个月内免费给予支持，但电话费自付（除了Word Perfect）。这个行业的趋势，包括Novell的Word Perfect部门的新产品，也已从无限的免费支持转向有偿支持。为了处理好那些预计在好多个月——如果不是几年的话——都有电话来的产品，微软也和其他行业的一些公司一样，制定了价格政策。对Word和Excel这些基础产品，客户可在工作时间里通过单独收费电话接受免费支持。90天之后，对这些及大部分的微软产品，客户可通过支付每分钟2美元的电话费拨打“900”这个号码接受24小时服务。希望每天24小时接受支持——比如针对公司产品——的客户还可以从支持方式中进行选择：每分钟2美元，一个电话25美元，一年195美元，或者每年20000美元以享受高质量的支持服务。随着这个定价表的实施，平均看来，一个新产品在其使用期内（包括所有版本）50%的电话会在前6个月内打进来。
支持技术微软利用计算机和通讯技术使得对客户支持的成本大大降低，并且能更有效地分析流入的信息。它主要采用了三种形式：支持技术人员使用的计算机系统或“工作台”，电话系统和客户能利用的自动化信息服务。
“PSS工作台”包括一组一体化工具，由微软的内部信息组创造，在高能PC机上运行。这些工具能跟踪客户提出的问题（电话数目、长度、等待时间、每个产品的电话数、每类客户的电话数及每类问题的电话数），然后他们把客户特定信息储存在系统配置和发行之中。他们还制定了特定做法以供技术人员据此采取行动；记录个人工作量；在工作台信息的基础上生成报告；方便客户对免费条目的查询（比如磁盘替换）以及提供一些微软知识库的使用方法，这是一个电子化信息库或技术支持数据库。21支持技术人员能使用固定查询词语检查整个数据库；他们也能以写入文件回答以往未有答案的问题而补充数据库。微软在CD-ROMs上或通过联机网络向客户散布这个知识库的部分内容，包括Compu Serve和Genie。
电话系统拥有一种所谓的存储功能。微软通过某种技术把电话内容数字化并存储下来，从而对接收的每个电话都能记录少量信息。PSS产品开发顾问、在微软干了9年的老兵马克·辛登沃格曾表扬这一技术是电话系统的“卡迪拉克”，它包括了一个通往PSS工作站的软件“桥”。工作站和电话系统的目标是要尽快分析客户电话，并制定出按重要程度排序的问题表递交产品开发组织。辛登沃格曾对从一个客户电话中采集信息的过程与好处作了如下描述：
每一次和客户的接触都是改进产品的好机会我们手头掌握着每个电话的一定量信息。现在每种产品都有个标准模型附有该产品着手进行所依据的一些标准类别。我们想看出一点主要领域的总体特性，比如多少电话是针对安装的，多少针对打印，多少关于普通用法，多少是有关操作环境的，多少又是涉及共同可操作性的然后，再深入下去，我们跟踪了解了一些特性或问题，最基本的，就是电话都涉及了什么。今天这一任务是通过电话上的“卷藏”机理完成的。你有一张一览表，于是你可以把一些能代表问题出在哪方面的信息和电话联系起来。这些当然是概要性信息。你可以获得一个3位数的产品代码，再加上UCC代码——就是我刚才告诉你的那个水平，也是一个数字。之后我们就有了问题代码数字。所以，如果它是有关安装的特定问题，我们就能知道有多少电话与此相关。
这与以往的支持截然不同：你和手下的支持人员要去告诉某个人物某个问题，他们要问：“你在这方面接到多少电话了？”你只能说：“哎呀，我们不知道。”于是他们又问，“好吧，如果我只能解决10个问题，那么我应从哪10个最重要的问题着手呢？”。你又得说：“哎呀，我不知道。”而现在我们能给各个问题排出先后次序了。
在自动化支持领域——这省去了要人回答电话的麻烦，最重要的是Fast Tips（快而通）技术。这种通过按钮或电话可以实现的全天服务能就微软产品的关键领域提供信息，并回答一些普通问题。另一种自动化支持系统MSDown-Load是一个电子布告牌，在上面微软会展示新的驱动器（运行打印机、图像屏幕和点设备等外部设备的软件）、产品修改（权宜修补）及产品解释；客户利用调制解调器以进入该系统。PSS还管理着微软信息网络。它包括微软开发网络，该网络在CD-ROM磁盘上向开发员提供技术信息，每年更新四次。它也包括微软技术网络，这是每月更新的又一个CD-ROM信息库，能提供详细的产品信息、培训信息，以及PSS知识库——PSS支持人员使用的技术支持信息库——中的一部分工具。
产品改进的信息反馈对微软而言，一个主要的挑战是要去组织和分析每天从不同渠道收到的、来自客户的大量信息。然后再把这些信息以一种有用而精简的形式传输到各开发组。经过正确的处理，这些信息将有助于开发组在修改错误时确定先后次序，使产品更易于使用，并提供出客户真正想要的新特性。另一难题是统计概要只能传输有限数量的信息。
为了尽量利用好客户信息反馈，微软最近建立起一个产品改进组，并引进了其他一些机制来分析客户信息并传输到产品组。由于出自客户的特性想法和改进实在太多，这里不可能一一列出；主要例证包括产品安装，Windows里对打印和图像显示的驱动背后的设计原理，以及贯穿于各种产品的工具条和特性的标准化。经理们还要求开发员们投入更多时间将产品制作得易于使用些；而且，一旦微软推出一个新产品，便要他们去回答客户电话。这些措施是对其他类型的客户研究和产品适用性测试的有力补充。
产品改进的积极创新1991年，微软组织起一个囊括了6名PSS高级技术人员的产品改进组。每名技术员都是某一产品上的专家、担任着该产品开发组织顾问的角色。Excel专家马克·辛登沃格和皮特·希金斯、杰夫·雷格斯及麦克·梅普尔斯一起讨论了成立这一小组的想法，并付诸实施，称之为“微软的秘密武器”。“我们被称为产品改进组，我们是产品开发顾问我们的使命是帮助微软更好地满足客户需要，通过客户的信息反馈和建议而改进产品。为此，我们的战略是去发展一些方法、系统和过程以便获取信息、加以量化，再以一种易于检测的形式传送出去，这颇具意义。它其实意味着开发真正的有效途径，能把五花八门的信息加工整理为统计性的确凿无误的资料。”
产品改进组建立了两种分析客户信息的宝贵机制：所谓“电话分析”的月报，及一个独立的客户建议数据库。报告主要是按产品里界定的功能组织起来，它按产品细分，分析上月从客户打到微软的电话里收集到的各种主要信息。尤其重要的是关于“客户就每种产品与全球各地的PSS联系的‘十大’原因”。23微软把电话分析写在纸上并通过电子邮件传送各产品组的个人和经理处。建议信息库的重要输入源是微软的希望热线，这是一个电话号码系统，客户能打进来对特性的新功能提些建议（客户也可以写信陈述）。PSS工作人员负责把建议抄录下来输入数据库，以供全公司使用。电话分析报告里会包括每种产品的主要15种建议。
在电话分析报告中得以鉴定的问题和建议广为传看；盖茨和其他高级主管们也都是热心的读者。因此，产品组对于报告中反映的问题一般会在3、4小时内就能做出反应，并让PSS知道他们打算怎么处理。正如辛登沃格观察到的：“交流圈发挥了效力，所以每个产品组都有人对我们的刊物逐期予以信息反馈，一般是说：‘问题的确是这样的。’然后他们会说出对此他们打算怎么办或何时着手解决。有时他们已开始处理这些问题了。”通常，测试组会有一名人员负责把PSS鉴定的问题录入产品组的数据库，并确保开发员对仍存在的问题加以解决。程序经理既要关心本产品的新版中哪些特性有待修改，又要注意到客户就新特性或特性变化所做的建议。任何月份中单个产品都可能从客户那里收到几百条建议，因而辛登沃格组的整理排序工作是重要的：
现在，所有这些建议也——对Excel而言它每月的数目在200到600条间——进入了数据库。我们不仅每月检查一下它们，而且把它们积累在数据库中了。然后在计划过程期间，所有建议再次整理分流到各程序经理处，他们仍要再仔细检查一遍。我们不能把这些资料给丢了。我们确实感觉到这是种有竞争力的优势你的程序经理们各有一套特性，他们就会问你收到过些什么电话是与此有关的于是我们的工作就是以一种确实高质量的数量化的方式告诉他们什么有待修改；如果互相需要协调的话，什么是达成平衡的最好办法，因为一切都不是很清楚的。
产品改进组还组织过研讨会，与会的有来自各产品组的营销、程序管理、开发、测试和用户培训人员。这些会议更深入地分析了对某一新产品来说，为什么会有人打电话找到PSS以及在特性或提供上哪些变化可能有助于减少电话。辛登沃格把这叫做一种新产品的“事前分析”：
我们在两天中花了8小时和来自Excel业务单位的80人一起检查了客户在各种常规原则上打来电话涉及的所有问题。每年我们都要做几次这类调查。这么做可以是对一种产品的“事前分析”，也可是“事后分析”在我们仔细检查事情过程时，可以收集到许多信息，包括人们如何使用我们的产品，他们有哪些问题，他们希望看到哪些情况发生，并且我们会提交一份长达五六十页的文件和一个数据库然后我们开始想象性描述和看说明。在仔细查看说明期间，当我们检查到特定性质说明时，他们会说出这么做是否由于PSS的职员的帮助。之后他们还会问我们，这能解决你告诉我们的问题吗，客户会理解这一方案吗，如何把它制成文件——这一类的问题。所以我们就完成了特定性质说明方面的检查以及代码检查再接下去是进入文件提供的仔细检查阶段，到时将有一名工程技术人员，他是我们组员之一，将代表客户参加每一条文件编写——他们需要知道什么，什么是他们亟须理解的关键概念。
开发员时间的再分配来自PSS的数据已帮助微软改变了开发员的时间利用方式。麦克·梅普尔斯曾回忆起他加入微软时，开发员大部分时间都是用在新特性上了。他们很少注意去使现有特性更好用或在一些其他方面做改进：“我们想做的就是让开发员把1/3时间用于改进现已存在的，l/3用于新特性，另1/3则用于兼容性或和世界的其他产品保持一致性。那只能意味着运行Lotus的空白表格程序或与某人的网络相配合，诸如此类吧；并且（或）只是和你以前的特性保持连贯或兼容。在那之前，我们可能还想过要花80%或90%的时间在新特性上，而不是去使已有的特性更简易、更好用PSS真是帮了我们大忙，让我们搞清楚了那些领域都是些什么。”
梅普尔斯和其他经理们还主张开发员在每推出一种新产品后能花些时间在PSS帮助其员工处理电话。各小组的管理助理承担起了安排进度的工作。有些开发员在进度紧时会设法躲避这一职责；但一般来说，开发员似乎也觉得花时间在PSS工作是他们时间安排中的重要部分。对于开发员而言，这既能培训和帮助PSS人员，也能使自身接触到那些颇为受挫而直接就给微软打电话的客户，从而获取第一手资料。布兰德·希尔文伯格回忆起1990年他所在小组推出Windows3.0后他开始在系统组中进行的这一实践：
无论何时我们推出了一种新产品，在随后的一周、两周或三周中，无论需要与否，开发小组都要被派去做技术支持他们有这么多障碍，并且不能处理各种询问，所以要[开发员]去那儿培训他们自我到微软后那可能就是我干的第一件事吧。Windows3.0刚刚开始推出，非常成功，于是他们简直要给工作压垮了。所以我把整个开发小组派到产品支持部那儿做两周的协助支持工作。这真是让大家对客户有了丰富的认识。那也是我的另一种哲学，就是真正让开发员、让每个人都以最终用户为着眼点，记住他们是我们的老板，我们成功的唯一原因是他们喜欢我们的产品。
梅普尔斯是对软件组实行这一政策的强烈支持者，那里诸如“邮件合并”（Word上的一个特性，允许用户把一系列地址和一个普通资料来源合并起来，比如制式信函）这样的问题已是声名狼藉了。把开发员送到PSS就有助于使他们对客户更敏感些，也是给PSS一个信号——你们的工作也很重要。梅普尔斯这样来描述他的一次访问：
我们尽量让每个开发员每季都在PSS呆一天，专接电话；为了鼓励这种做法，我也去这么做。有一次我在Word组中转了转，发现在这帮家伙后有张沙发我说：“嗯，那是干什么的？”他们说：“那是邮件合并沙发。只要我们接到一个有关邮件合并的电话，我们就知道要打上半小时，所以有人会接过电话走过去躺在沙发上，再和客户谈。”一个需要改掉的有趣的问题！但把开发员放在那会使PSS的员工感觉好一些。这就是古老的霍桑效应吧同样重要的是，他们会听、会看什么事情是导火索，还有哪些领域需要改进。
另外，PSS建立起在每种主要新产品发出后每周举行两次的“情景屋电话会议”。这些会议召集起整个开发组，并把他们和微软不同支持地区的支持人员联系起来，就客户所遇到的问题有哪些类型做另一种审视。微软还会发行会议记录，以便让其他组也知道这些会上都谈了些什么。和其他过程创新一样，又是Excel组首先采纳了这一做法。
客户研究和可用性测试除了电话和其他的PSS联系方法外，微软还针对不同场合利用了一系列研究用户的机制。这些研究包括对用户行为和该领域内产品的分析，以及开发期间的产品特性测试——换句话说，即可用性实验室分析。
的研究微软每年支出50万美元就产品支持服务和客户满意度做市场研究。一个主要项目是每年一次的最终用户满意度测量调查，由一家外部调研公司为微软做的，旨在通过鉴别为了获得并保住一个客户什么是必要条件从而衡量客户的满意度。这项调查覆盖面超过1000用户，按微软的和非微软用户粗略分成两组。对微软客户的问题是要分析他们对微软产品、微软公司及微软产品支持的满意程度。在上述三方面都满意并且一定购买和推荐微软产品的用户被定为“可靠”客户（他们不会转向其他公司的）。调查还就微软与其竞争对手及各自产品和支持服务做了满意度水平的比较。数据表明产品设计与客户对支持和公司总体满意度之间高度相关。正由于此，为Macintosh设计的产品——它有个更为简易的界面可用——在客户满意程度上就比Windows产品更高，虽然产品用起来并无差异。特瑞希·梅描写了这一发现：
在[客户满意度]与什么产品及该产品是怎么设计的之间有相关关系。比如，我们做了些交叉型表格，结果显示如果某人对产品满意，那他们将会对服务也非常满意。如果你有一个交互作用的用户界面，那你一般会对服务更满意了。这里有着一点光环影响效应。一般来说，我们让同一个技术人员回答一个关于Mac Excel和Windows Excel的问题。所以你要把人员固定下来。Macintosh的界面有一点容易，或说在过去是这样的，于是我们在一些Mac Excel的支持问题上就比在Windows开发早期阶段里对Windows Excel的问题上得到了更高的满意度级别。
的另一主要调查项目是向微软打来电话者的客户满意程度。PSS人员需要请一小部分打进电话的人参加一个20分钟的调查，然后他们每月分析一下这些资料，观察趋势。这些调查数据表明微软的努力是有效的：过去的满意评价相对较低，而最近的一个表格分析结果是78%的客户对PSS非常满意，64%的人愿意再次购买，61%的人一定推荐该产品，另有54%对产品非常满意，结果是41%的“微软产品可靠”评价率。
非常基本总体满意满意满意总计（加权的）资料来源：微软公司，产品支持服务部门：《ITAA奖励申请》，1993年6月，第13页。
产品使用研究在对通用产品进行研究以了解用户习惯和需要方面，微软依靠着几种途径。例如，在90年代早期对Word加以改进时，微软就挑出了200名Word Perfect用户，通过每月采访对他们进行了一年的研究。微软还在美国不经常地做过些“分割式研究”，即从全国不同地区随相选择电话号码，挑出800名左右愿意回答20分钟调查问卷的用户（约50个问题）。这可以就某种特定产品提供有关典型用户情况的信息。微软也研究过各产品的用户登记库，但认识到这些人未必是有代表性的。另外，产品经理克里斯蒂·维特莱斯特别提到了营销组还对特殊客户（尤其是大公司客户）做过详细的个案研究，从而收集到了客户需求方面的信息，并为营销宣传提供了数据资料。
克里斯·彼得斯回忆起从产品使用研究中获得的一些重要启示：空白表格程序虽然神通广大，可20%的使用只是记录一列单子；所有文件的40%只是普通信件；所有文件的30%是备忘录，只有5%是业务通讯。彼得斯得出的结论是：“基本上，我们所发现的事实是，现实生活中这些产品的使用比任何人能想象到的要简单得多——这很有意义，因为现在我们正把这些产品向Safeway商店里数以百万的人出售这项研究是少数几项极受信任的事情之一我们视之为富有意义的有竞争力的一大优势，因为只有我们真正了解到了公司正向哪一类人销售产品，没有别人做到了这点。”
信息的另一来源是微软的产品工具版。产品的这些复制品都有一个独立文件，可以记录下用户每一次按动鼠标或敲下键盘，以及每个动作所花时间。这对研究人们实际上如何使用一种产品及他们在要完成特定任务时做出什么选择是极重要的。微软将这些特殊版本交给那些愿意作为试验点的公司，然后研究收回的数据。自从80年代末以来，微软对Excel和Word的历次新版本都做这样的研究，一般在首次推出后几个月内发布出去；各组利用这些数据对产品加以改进或对下一版重新设计。（Word的工具版对鉴定邮件——合并特性以及寻找文件格式化的不同捷径起过重要作用）。
客户信息反馈的另外渠道是β测试员，他们通过联机Compu Serve网络向微软汇报情况。β测试员主要提供有关哪些错误要在产品最终发布前修改，还对产品下一版出谋划策。正如第5章所讨论的，被选为β测试员的用户要签一份私下协议，然后就可得到软件及需填写错误数据的表格，并从电子渠道交还。
可用性实验室测试我们在第5章描述过微软的可用性实验室如何就新产品的信息反馈提供了另一种宝贵渠道。其他的软件制造商，从IBM到Intuit，许多年来都在利用可用性实验室研究用户怎样对潜在的新产品、新特性做出反应。然而，我们相信微软与众不同，它已到了把这种测试形式集成到固定的软件开发过程中的程度。其重要性在于，不像其他的信息反馈渠道（如PSS数和β测试报告），产品组能在开发过程中——而非之前、之后——就收到这些关键信息。
建立起固定的可用性实验室测试的主意源于1989年和1990年间微软正在开发Excel3.0的时候。一些开发员已在用典型用户测试典型产品。但是做的并无规律，微软也没有实验室设备来分析和收集数据。麦克·梅普尔斯回忆实验室的起源说：
可用性实验室的小组是从很少几个人起步的他们是个服务性组织，试图对每种产品都帮上忙。在某种程度上，那里是真正的突破口。如果你回到5年前，当我们开始搞可用性组时，该组总是对开发组说：“10个人中有6个不会这么做。”而开发组则反驳：“你们从哪儿找了那6个傻瓜？”所以我们就逐步让开发员们也去可用性实验室观察并参与进去。然后我们做出了工具版。再后来我们有了这么个主意，就是在他们开发特性时，找来6个、8个或10个可用性实验人员，让开发员就在中间巡走，和用户谈谈什么是能用的，什么不行。结果这成了开发员们严谨对待的一件事——“你已经对那个特性进行可用性测试了吗？有什么发现？”我想他们认识到了自己和用户想的就是不太一样。
克里斯——1989至1990年间Excel的开发经理——对实验室的产生和普及也有类似追忆。他强调，即使微软最好的开发员，要使特性易于使用，光有自己的那些常识还远远不够。而且，微软的“机智的”开发员们在去可用性实验室看到用户与特性“奋力斗争”的事实之前是不会认识到自己的局限性的。从那以后，使用实验室成了家常便饭：
我不记得确切是在哪天了，但开始是发生在Excel3.0那段日子。碰巧有些开发员在看可用性测验。要不是亲眼所见，你肯定不以为然，并且会立即有无数想法涌入脑海。首先，你会马上想到人的因素，常常有毫无益处的看法——“嗯，如果他们不知道怎么用，可以查用户手册嘛”或“我的点子很棒；只是你找了10个笨蛋才导致可用性实验室里的运行失灵”——一旦你亲眼见到了，这类观念便都不会复生它是让你的产品更好些的有效途径。显然你能使产品更棒人们经常认为凭借常识或聪明就能搞设计了。但是人们对软件做反应的方法复杂之极。我们最好的设计员，我想对任何人也都一样，只能做到60%是正确的。然后还需要第二次通过，在首次通过实验室测试后，正确率可达80%，到第三次通过时，已能达到90%了。
要达到“60%正确”指的是微软采用的衡量实验室结果的简单测量标准：没有参阅用户手册第一次就正确完成了工作的人数；或者人们在首次试用就能正确无误的任务比重（比如占总步骤的比率）。举个例子，一个开发员可能让一些测试员输入一段课文，然后随便查找一个词（如Programme）并用另一个单词（如Program）予以自动替换。这个工作会涉及到“查找并替换”特性的好几个步骤。
彼得斯观察到，开发员们为了改进特性的可用性，往往把大部分的特性不止一次地通过实验室检验。不过，有一些在待检验目录单上排在后面的特性根本就不经过实验室。一个例子是对Excel中的宏进行排错这个特性。几乎没几个人会实际用到它，并且微软预测那些用到此特性的人必是非常有经验的；因此，开发员们倾向于做实验室检测时略过这类特性。相反，像Word中的查找并替换这类特性非常受重视，因为几乎人人要用它。在有些重点考虑的特性测试中，由于总是只有50%左右的分数，开发员们可能会五六次地把这个特性送往实验室。在这种情况下，除非他们对如何修改问题另有高见，否则就要对特性或它的用户界面重新设计，或干脆删掉。
虽然应用软件组是可用性实验室的最大受益者，其他所有的组其实都能用它。彼得斯解释了其中的原因：“相信这种做法的组会比不相信的要用得更频繁Word和Excel，再就是大多数（其他的）应用软件组，都有这种信任系统组和语言组可能远远靠后，因为他们一般有更为熟练的用户，因此本来麻烦就要少些。系统开发员倾向于只对那引起普通用户会接触的界面特性或功能做可用性测试，而不考虑那些幕后操作的功能或只由其他软件开发员可能接触的功能。”
甚至PSS也参加进来了。它利用可用性实验室测试用于支持新产品和特性的不同方法的有效性。马克·辛登沃格描述到：“我们实际上在用可用性测试可支持性。我们走进实验室说：‘在给定某客户遭遇这一问题的情况下，我们会给这个客户用户手册和一个电话’。我们还会给他设计一个问题，然后他们就会给实验室另一边的技术人员打来电话。于是我们把两边拍摄下来，看他们试图解决这个问题的过程。”
微软请到可用性实验室测试产品的可以是任何人，比如用户组人员或“从街上拉过来的”人员。如果开发员想检查一下与竞争产品的兼容性情况，如Word Perfect，他们就去找个该产品用户。（“他们进来会得到免费提供的一大杯咖啡，”彼得斯如是说。）彼得斯解释道：“我们开始扩大范围做这类非常规用户的测试，是基于这么一种观念，即一个人从未见到某特性，一旦给了他一个工作，他一定会找点事干。所以现在一个开发员去找隔壁的另一个开发员说：‘坐在这儿，试一试这个。’”微软人还发现，测试一个特性并不需要一大批用户。彼得斯评论了这一发现：“这是基于一种少数几人仍能做到同样事情的有趣假设，但它看来完全正确。你可能想到10个人中只用一个人不会得到很多信息，然而事实证明，如果真是有问题的话，就是让10个人来做还是零分。对它加以修改之后，你会得到70%的正确率人们倾向于犯同样的错误。”
彼得斯把他从可用性实验室中观察用户得到的“教训”列了出来。其一是开发员在一方面的常识并不总能导致易于理解和使用的产品的出现。他举了在Macintosh中被称为“工具偏好”的工具选择的例子。微软决定采用Macintosh用的这个术语，把它放到Word2.0for Windows中去。可用性实验室测试的目的是要看，如果人们从未见过‘多层对话’菜单，他们能否理解：“因为他们不理解‘偏好’这个词，故只有1/10的人激活了对话框。多数人一扫而过。这项工作最后致使关闭水平方向滚卷条。”在小组把“偏好”换成了“选择”之后，十分之五六都做对了。小组还发现只要在对话框中加一些解释性文字——比如直截了当地说：“要看更多选项，请在目录左边按动鼠标”——这非常有助于人们通过菜单去找到操作办法，文字说明的添加也并不会放慢操作速度。现在，彼得斯表明：“在更现代的对话中，至少是微软的产品里，它们一般包含了更多的文字信息。而那是基于——如果你为提高可用性已是用尽了办法，在对话上加些文字说明一般会行之有效。”再加上说明后，彼得斯组的适用性分数提高到了十分之六七。后来他们又把彩色头像放在了左边以引起对该功能的更多注意，结果成绩提高到了十分之八九。“所以这个例证表明，哪里的正确率从1/10直达到4/5的话，只是需要做一点变动而已。我坚持认为那都不是常识性变化。”
彼得斯吸取的第二个教训是，他认为用户手册基本上不太必要，因为人们多数用不上它：“一个更重要的观念，就是用户手册可有可无。因为那是过去我们总可利用的一种逃避方式。”当用户不能理解一种特性时，只有30%的人会首先阅读用户手册。大多数用户有问题时会首先想到向邻居请教；要是不起作用，他们一般就向产品支持部门打电话。多数客户只是最后才向用户手册求援。
彼得斯承认，其他公司的人以及某种程度上的微软，都在抱怨在开发期间对每个特性进行可用性测试可能太慢，且耗资巨大。如果对这种测试不加适度控制的话，那些过于热情的开发员可能花上数年时间改进他们的产品特性而再也推不出产品了。他解释了成本目标：
我已告诉了大量各式各样的公司，他们说那似乎太昂贵了，我们支付不起。我说你至少能承受得起的是首先承认没人愿意去翻用户手册，或人们至少应努力创造一个不需要用户手册的特性来。你应该关注用户怎么操作不灵了，应该让一个对设计不熟的人看到它，哪怕他就是隔壁的程序员。所以我想，即使一个10人或5人的小组在麻省理工学院（MIT）干些什么工作，如果他们能有“人们能没有用户手册就做完这项工作”的较好观念，那必将受益，随后再观察他们的进展，多加关注。
为了减少成本，微软各项目一般会集中那些能一起运行的特性，同时进行测试，并且他们力图避免在实验室对特性的运行超过两次。像Excel和Word这些组还尽量把实验室工作限制到每周两个半日集中处理，每次测试大约3个特性。然后实验室人员组会把报告送往开发员和程序经理处。被分配到某个特性组工作的程序经理要和实验室工作组一起负责安排测试进度。梅普尔斯尽量也将实验室成本包括进来，把工作组限制在35人左右，实验大约有五六间。（每个房间一次只能有一两个可用性测试员。）虽然梅普尔斯承认存在着创造多元化设施以供不同设计组利用的这种压力，可微软还是坚持只有一个中心实验室。他对为管理好一个经济合算的可用性实验室而做的努力评论道：
实际上没有任何指导方针，可用性实验室是200%或300%的超过预定工作，因为它成了产品如此重要的一部分，以至于人人都想用它来干一切事。可用性实验室希望有100人，有50间实验室。可任何事儿一旦放开，就很难说会变成什么样子了我们在做的过程中是把设计组化整为零，对于可用性问题我们可能也将这么做。一旦它大到一定程度了，我们就把它分成多个组，和客户更加接近，以使他们更明智些，我们会这么做的。集中的另一个原因是它是从两个人开始做起来的，确实存在着设备的问题。
的数据表明，实验室在使产品易于使用和易于支持方面收效显著。事实上，彼得斯把卖出的每“盒”产品的客户电话数减半之功归于了可用性实验室，他说：“没有人会很高兴打电话以获得产品支持。所以这是个两边受益结局的例证。你能做得这么好以使他们用不着打电话，你成功了。而他们首先想到的也不是打电话，他们也赢了。”彼得斯还宣称实验室有助于防止程序经理和开发员添加太多不必要的和复杂的特性。在许多因PC软件产品及其要求储存空间的增加而受到过挫折的客户中，“特性的衍生”是令人忧虑的焦点：“我们想的是，利用可用性测试我们能确实增加更多的特性，并制造出越来越易于使用的产品。所以如果你做得对，我们并不认为特性的衍生会真的有用。这暗示着在能力和易于使用之间存在着一个平衡。只不过在这个行业中一直在灌输的是人们正像行政命令的加工人员一样开始做事儿——即，我们不能使产品造得更便于使用，所以我们就要删除一些特性。但我认为正确的方法是利用可用性测试。所以你能同时有能力和便于使用。我并不认为它们对立。”
原则四：促进各产品组之间的联系，实现资源共享建立学习组织的最后一个问题是：不同的产品组要学会如何作为一个完整的公司成员共享构件和一起工作。微软对集成的、特性丰富的产品日益强调，比如Office和Windows95，这就要求它要有一种系统化方法以设计界面、分享构件，并在项目进度安排和产品质量方面提高一致性。微软和其他软件制造商都再也经受不起那种维持几大相互独立的产品组，并让他们随心所欲，“重新去发明轮子”的做法了，因为其代价必定是利润的降低以及客户对同一公司产品组合里的不一致和不兼容的抱怨。例如，微软经理们断定他们在各自产品中共有14种各不相同的文本处理代码；他们还有几种版本的代码，分别用于数学计算、绘制图表、帮助功能和其他一些任务。
微软目前在各产品组间已有了一系列联系、交流网，便利了各产品之间的构件共享和特性的标准化。除了对设计和代码明确进行重复利用外，项目组正在界定以构件为基础的整齐化设计。他们还正在制造些单个构件，不同产品能通过诸如动态链接库（DLL）或对象链接和嵌入（OLE）的机制予以利用。这种“以构件为基础的整齐化设计”方法和微软早期的主要制造各成一体式应用软件的方法是相对立的。应用软件产品，尤其是Office，需要重复使用共享型构件（如一个工具条，绘图工具或窗口框架）以便向用户提供一个稳定的用户界面。这种重复使用还减少了向单个应用软件添加新的兼容性所需的努力。同时，标准化和构件共享会减少由于不同产品中相似功能的操作略有不同而需要向客户提供支持服务的诸多麻烦。
共同操作性小组学习如何共享并不容易。微软实际上花了几年时间才在它的不同产品单位间实现了构件的系统化共享，要做的还很多。比尔·盖茨当然是其中的主角，他下令新的产品版本一律并入OLE技术体系，还要尝试其他办法力求共享。几年前，微软在这条路上的首批措施之一就是创立共同操作性委员会，然后是一个共同操作组。后者包括OLE，共同操作设计组，初期的Office组（该组集成了Office并作为一个产品推出），适用性测试组，以及想象界面设计组。1993年，共同操作组发展为了现在的Office产品单位。
共同操作组的工作是劝说独立应用软件组采用普通用户界面（如标准化菜单和工具），然后在主要产品上使普通功能同一化。按戴夫·穆尔的说法，共同操作组——1993年共有26人——是被指定的“第三派”而和Excel组、Word组一起工作的。如果两组就如何设计一个普通特性而意见冲突或陷入僵局，共同操作组就要做决策：“这是凳子的第三条腿。你要做出决策。所以如果Excel组和Word组不能拿出主意，你就作为第三方，对两种产品间的任何常用特性——文件打开，文件关闭，复制，粘贴，只要是你在两个产品上都见得到的同样功能——他们的工作是确定这个特性是否以完全相同的面目出现。如果有一个打开的对话框，那么对话框要完全相同，对话操作的控制也要一模一样。
共同操作人员强调一致性是从最终用户的角度，并非指代码重复使用意义上的一致。共同操作组并不检查人们的代码去确保共同特性，而是关注于具体化，确定开发员把共同特性已设计在其中了。当然，开发员可以不同的方式给特性编码，但它在两种程序中必须以相同面目出现在消费者面前。如果不存在这么一个视促成特性的外形和使用的相同为中心工作的组，那么主要产品组生产出的用户界面将会千差万别，因为它们各自的工作重点只是制造最佳的产品。正如前任应用软件共同操作性主管克里斯·格雷姆在总结中说的，共同操作组使得各产品之间常用（或“核心”）的特性如出一辙：
我们创造出了应用软件的共同操作性，因为我们觉得相配套的应用软件在市场上越来越重要。而要使我们的产品工作起来能配合良好的唯一办法是把一些出色的人员放进去，并让他们尽心尽力。相互独立，只关心本产品在同类中能出类拔萃的产品组间的信息流只会导致互相背道而驰。如果你只想成为最好的空白表格程序员或最好的文字处理员，做起决策来相对容易多了，但要想和其他组配合在某件事上达成一致意见却难上加难。所以我们创立了共同操作协调小组，把OLE用到应用软件里；开发出所谓的核心特性，我们不仅会把它们用于Excel和Word，还会有其他应用软件。我们所谓的核心特性只是一个过分简化了的观点；它们是空白表格程序特性、文字处理、数据库，等等。它们这些特性对所有的应用软件都能通用，用户在所有应用软件中都会碰到它们，并频繁使用，因此希望它们用起来并无二致。
在共同操作协调与分享上的努力之所以能成功，一个重要原因是克里斯·格雷姆这些主要经理人员孜孜不倦的长期努力。格雷姆1949年生于爱尔兰，成长于加拿大的温哥华；他在英国哥伦比亚大学学习了应用科学和工程技术，然后在好几个公司做过软件开发员、顾问和经理，1989年加入微软。最初他在一个四人小组工作，旨在找到能把微软主要的应用软件产品的设计标准化的方法。但这个组进展不大，因此不到4个月后格雷姆便转调到Excel组任程序管理员。在那里他领导一个特性小组试图重新界定Excel的构造，并希望和Lotus1-2-3兼容。3个月不到他便接任了Excel组的程序经理。然后又担任应用软件共同操作协调组主管，监管OLE开发、共同操作设计、想象性界面设计和Office产品的合作。1993年重组之后，格雷姆曾在新的Office产品单位中短期担任共同操作设计组的负责人之职，向克里斯·彼得斯汇报。后来他获准转到另一工作岗位。当然，其他人员还在继续努力以推动常用特性的设计和使用。
常用特性的核心系列年，共同操作协调组鉴定出在所有产品中，大约35种主要特性是常用的，却还没能实现共享。于是微软新创了一种办法，该法依靠那些专门知识（比如有文本处理代码的Word业务单位，或有数学计算代码的Excel业务单位）齐全的特定的产品组担负重任，用OLE建构某个特性并加以简化。其他组采纳了这些OLE界面，因此能把那些特性作为一个“标的”并入自己的程序。正如现在可以在Office成套应用软件中所看到的，这成了重新设计和共享所继续使用的方法。微软想让用户能看出来它的产品无论看上去还是用起来都差不多。克里斯·格雷姆详细做了说明：“我们想让微软的产品看起来像个家族，所以我们要让用户在使用一组产品时10分钟之内就能看出来这点。我们希望人们觉得它们都一样，所以，所有特性需要和人们首次见到的或最常用的保持一致。产品的表现应像是一个家族成员一样，它们应能配合默契。
常用特性的核心系列包括工具条，复制——剪裁——粘贴特性，字模，打印对话框和各种菜单。微软的研究表明大约85%的用户操作需要用35%的产品特性；常用特性组界定了这些特性，详细说明了它们的用户界面特性以及按钮、菜单、对话框和其他项目的操作表现。正如格雷姆回忆的，使数百个其余的特性一致化的边际收益是迅速下降的：“从这个角度出发，我们很幸运，因为在几百种特性中，客户所用的85%只是集中在大约35种特性上。其他特性所有的客户都不常用，所以你对它们搞一致化收益不大。这样，通过集中处理35个特性——虽然那只占总特性的10%——就抓住了85%或90%的用户实践。这样花出去的钱收益很大。你若去盯着那些使用频率不高的特性，收益就会急速下降。”
在35种特性的组合中，大多数用户会说在现在的产品——如Word，Excel和Power Point中，约有25%至50%的常用特性看上去、用起来都已经相当一致了。然而，共同操作协调组的成员却认为产品中至少50%的常用特性有着显著差异。应用软件共同操作级程序经理吉姆·科勒评论道：“在至少25%最多可能50%的情形中，一致性程度非常高。我想大多数天真的用户看过这些不同的操作工具会说：‘哎呀，几乎一模一样。’但在至少50%的情形中，是存在显著差异的。其中有一些差异是必要的，这可由不同产品间的功能差异予以证实——它们的确需要有另外的按钮，因为它们做的事不一样。但我要说那些特性中至少25%的视觉成分或功能成分存在差异是出于偶然的。”
常用特性数据的收集微软收集了大量资料以了解哪些特性应包括在常用组里。首先他们判断并估计出主要产品——如Excel，Word，Power Point，Publisher，Project和Windows——中超过300个特性是常用的。因为Excel，Word，Power Point和Project一共就有了600多个特性，所以微软最初想的只是所有现在特性的可能有的一个子集合。第二步，他们利用Excel和Word的工具版收集了特性详细的使用和频次数据。格雷姆特别提到了他们在与用户谈论及工具版数据基础上，针对命令使用频次制成了分析表：“我们本来认为可能有300种特性我们做了大量研究，去决定最有杠杆效用的特性集合是什么。我认识到要在大量的组间取得设计的一致意见是很难的，所以我们需要开拓一种方法，借此找出最重要的东西并能确保自己做得是对的，所以我们和许多用户谈话。我们使用产品的工具版从而我们知道了用户做不同动作的频率。
最后，小组通过对基于活动的计划的进一步洞察、补充了一些信息（参见第4章对这一技术的详细讨论）。研究表明，用户在产品间转移数据相当频繁，并将常用的剪裁——复制——粘贴操作、字模的保存以及产品之间的其他格式化的重要性放在显著位置。用户还想建立混合式文件，包括文本、数据和图表。格雷姆解释道：
事实表明——这并不出人意料——最重要的集成操作是应用软件之间的复制和粘贴（或剪裁和粘贴）。另一个是建立混合文件我们把基于活动的计划用作一种决定所选特性的方法。当客户和一个“产品家族”一起工作时，什么是他们最常用的操作呢？产品间的数据转移是常用的操作。然后你必须把它分成细目来看看哪一种转移是常见的，数据转移到哪个方向，客户遇到的问题是什么，他们真正的意图而非他们今天所做的是什么？一定要先仔细分析用户的行为，再把它分解成你能处理的形式，加以区别对待。所以对每一种特性，我们都把客户普遍经历过的操作详细描写下来，而不仅仅只关注于“让这个特性一致起来”。
一体化成套产品微软推出的Office成套产品其实是主要应用软件的集成品，包括Excel，Word，Power Point，Access和Mail。正如我们第3章里讨论的，微软对Office的定价很有竞争性，销售业绩空前好，现在大约有1500万套付诸使用了。（25）克里斯·格雷姆解释道：“他们都买Office。我们现在售出的Word和Excel中50%是Office的一部分。我们希望销售量越来越高。”最初，整装在Office中的应用软件产品并没有额外加以集成，相互之间也没有合作，每种产品保持本色、各自为战。Office的唯一附加价值是一次性全部购买所带来的方便，当然，折价也很可观。
共同操作协调人员想大幅提高Office组合中共享和集成的程度。他们的常用特性研究使他们能够对Office的构建设计施加影响，于是用户界面现在就有了一致性，并形成了一种以构件为基础的构造方法。Office4.0在1993年10月推出，提供给用户的产品中，不同应用软件之间有关一致性外观。正如比尔·盖茨观察到的，在Word、Excel和Power Point间大多数高层次菜单条目是一致的：
我们在向各产品组推行标准时一直非常强硬。所以在所有产品的高层次设计上我们能看到，9个高层次菜单条目中有8个是完全相同的。唯一不同的一个是在文本处理器中你有表格命令，在Power Point中你有绘图，在Excel中你有数据，因而那第9个菜单条目对不同软件各不相同。如果你从这个层次再往下看，就会发现在File、Edit和Window中——在这些应用软件里任何共享的东西，甚至包括了对话框——所有的命令执行起方式都一样。那是为进一步发展提供可能的一步。那会使人们很舒服地把它们作为单一的应用软件，而不是不同的几种软件。
产品单位现在已有24名专职开发员。虽然微软也和一些外部公司签约构造一些专门构件，但这些开发员自己构造了共享型构件中的绝大部分。Office项目还为所有应用软件（Excel，Word，Power Point，等等）和共享构件的构建单独制作了一份合作进度表。矩阵式的特性小组结构保证了共享构件能满足各应用软件的需要。特定一组特性的矩阵式特性小组包括了Office开发员以及相关软件的代表，格雷姆对此阐述道：“这是我们用来管理共同操作协调过程的另一种工具我们创建了像矩阵式特性小组这类特性组织，那里有来自每个特性领域里每种产品的代表。于是我们就有了Excel，Word，Power Point，Mail，Project等等软件，这都是特性小组中的代表。”
的经理人员和开发员们不得不花上额外的时间、精力对这些特性与单个的应用软件加以协调。但是Office组的目的就是为它们提供基础结构，对此乔恩·德·沃恩也承认：“我们的境况是正在自力更生构建一套人人都用的共享代码。那真是苦不堪言。尤为令人头疼的问题之一是Office组的人员必须竭尽全力地工作，搞清楚客户的应用软件当前的各方面运作状况。我们不能不经过用客户证实自己的设计有效这么一个过程。与以前我们作为单独产品开发员时的情形相比，那可是要花一连串的管理费Office开发组的工作就是要为那些[应用软件]提供更多的基础结构。”（Office以外的项目，如Publisher和Works等，也都在增加对Office组构件的使用。）和Word小组起初对Office的观念是加以抵制的，因为它并不一定有助于Excel成为一种更好的空白表格程序软件，或使Word成为更出色的文本处理软件。但微软利用Office方式为用户提供了更为一体化的应用软件组合。客户通过购买Office，而不是独立软件，用美元投了赞许票，于是Excel和Word小组妥协了。Excel和Word开发员们还认识到Office方式的一个主要的技术优势在于比单个软件减少了内存的使用；这既能空出更多内存用于其他更多的特定目的，也节省了用户做出操作反应的时间。按照格雷姆的说法，减少使用内存显示出了另一竞争优势：“你要是能拿走一半的Word，一半的Excel，一半的Power Point，那可是大大减少了Office用户的工作集合[内存规模]。所以比起那些来自Borland、Word Perfect和Lotus的独立软件——他们没能进行代码共享——人们更有积极性去买Office。”
产品和构件中的相互依存以构件为基础的方式导致了产品之间相互依存度的大大提高，而这种情况下的工作是会和创造出一流的独立产品这类目标的实现、按时发布的不断完善或每月构造原则的保持相抵触的。各项目组以前开发的是单个产品，他们要自己完成和控制代码编制。而现在，各项目都依赖本小组以外的各组提供自己亟须的关键构件。项目组会尽力紧密跟踪所需构件的生产过程，其方法就是尽可能多地监控构件供应者的内部生产阶段。Excel组的程序经理约翰·法恩告诉我们：“工作要想干好的窍门就是确实做到跟踪并记录大量的阶段——那些必定发生的事件。如果我是一个构件使用者，我就要在短时间内跟踪我的构件供应者的许多个生产阶段。那是我检查构件供应者进展状况的一个方法。”构件供应者和使用者还需要频繁交流，以确保双方对构件的特性、界面和进度都有一个清楚的、现时的了解。法恩继续说：
基本问题是缺少交流。在项目进展的几天、几周时间中，构件供应者会做出一些构件使用者根本不知道的假设，或者反过来。后来他们才发现这一点，于是双方的工作都不得不以放弃以前的努力而告终，要不就是没有效率。在此，任何一种最短路径的进度安排都于事无补。真正有帮助的是双方不厌其烦地、频繁地去问问对方组——亲自验证一下，对方组是否真的在做他们该做的事情；而且确保他们不要做不该做的事情。
只对一两个使用者提供一种构件的项目组和后者一般会保持一种紧密有效的工作联系。构件供应者若仅有一两个使用者，就能和他们经常交流；而且也能依靠规格说明更准确地估计出构件出品日。比如，Visual Basicfor Applications（VBA）首先向Excel提供了构件，然后又考虑了其他一些使用者。戴夫·穆尔强调说：“工作最有效的是只有两个客户。那样你就能按其所需提供服务，你能确切知道他们到底想要什么，你总能提供他们想要的——非常好的关系。过去，典型状况下应用软件组只有一个客户，因而很容易就能修改出品日，修改资源的数量，修改特性组，修正行为方式在有些情况下有两个[客户]。可能你正在寻找严格意义上最终用户——家庭使用者——以及这里的公司用户，要把他们想要的具体说明出来是非常容易的事。”
系统项目总是在另一种意义上提供构件，即一个操作系统要包括大量的客户需要用以运行应用软件的构件。这样一种构件的“提供——使用”观念导致了应用软件和系统产品的主要差异。系统产品比应用软件有更多的构件使用者，而正如穆尔描述的，拥有大量构件使用者的构件提供者在预测出品日方面困难会更多：
系统组正在提供一个构件。他们提供所有这些服务。一个构件提供者可能有10来个客户，那你会从他那里发现，他需要那10来个客户的要求，并且不得不做周到。他们不可能必然地服务于某一个单个客户他们必须非常努力地工作以满足那些客户的需要，那太难了。他们在构建那类产品时与只为3到9个客户工作的构件供应者有很大的差异系统组总会有10个或更多的客户。空白表格程序开发员的需要是什么？文本处理开发员的需要是什么？桌面出版系统开发员需要什么？在这一环境下工作的各式各样的应用软件组的需要又是什么？还有些要求是来自于也在空白表格程序上工作的多种类型的出售商们在微软的一个Excel空白表格程序开发员会比Lotus的同类职员有着更为不同的要求。因此那些形形色色的要求最终会驱使他们的产品界定与应用软件领域做出来的大为不同。
分享和共同操作协调机制微软开发员在把Office构件（或任何其他的共享构件）和应用软件紧密联系的过程中，使用一系列不同的共同操作协调机制，比如对象链接和嵌入（OLE）与动态链接库。因为它们通过构件和数据共享以及同步操作，使得两种或更多的应用软件能合作运行，所以开发员们称之为“共同操作”协调机制。
我们在第3章提到过，OLE是一种特殊的微软产品，它使对象共享和共同操作成为可能。（这个产品单位有15名开发员，15名测试员，3名程序管理员和3名用户培训人员；开发员使用的是C++。）OLE使得一种应用软件能从另一软件上获得一项服务（比如“绘出这个图表”或“把这个文本格式化”），然后它能把所得服务的结果嵌入原应用软件显示器中输出。用户还能利用OLE建立混合型文件，包括文本、数据和表格。克里斯·格雷姆回忆起了一段有趣的小插曲，当时有人正演示用OLE从Word向Excel提供一段文本编辑服务，结果把比尔·盖茨也弄糊涂了（但仅仅一分钟而已）：
是我们在集成技术上进行的大投资。一次比尔·盖茨正在Exce1的门厅走过。为了激发开发小组的士气，他有时会在开发部里转转，和每个特性开发组的负责人谈上一会。负责人就会展示一番他们设计的一些特性，然后比尔再作评价。当他看到OLE时，他们转到了利用OLE打开Word进行就地编辑。在起初一两分钟里，比尔没看出来。他发现Excel有些不正常。突然间他意识到了是在利用Word做就地编辑。所以在混合文件里利用构件工作会使集成度大大提高，我们想那对用户来说将会是件美妙的事情。
影响到的不仅包括应用软件产品，而且包括系统产品和特定的应用软件。比如，两位OLE2.0的设计者花了50%的时间和系统产品开发员进行交谈。ISV想把Office用作他们产品的基础构件，所以OLE小组成员也咨询了他们；OLE还向他们提供了一种很灵活的机制，以把那些能压缩他们的产品并和Office应用软件紧密集成的特殊构件或“服务项目”记录下来。
动态链接库（DLL）提供了另一种通用的共享技术，但它们不是一种专门的产品。一个DLL就是软件的一个“添加”条目，当软件运行时，操作系统能自动将之装入内存。然后，不同的应用软件程序就能把它作为一种“服务”进行分享。不同的应用软件能分享的DLL服务有拼写检错，特殊设备驱动器、外国语言界面以及许多其他的载入内存或持续进入的各种构件。DLL的主要优势在于，在任何既定时间里他们都能最大限度地减少一个应用软件所需占用的内存量。
重复利用微软在某一特定产品的一系列版本中——如从1.0版到2.0版，或在PC和Macintosh平台之间——重复利用了大量的代码（超过50%）。由于一个开发员一次就能完成一个特性的编码，而非每一版或每个平台都要重新来一次，因而重复利用代码节约了成本、减少了精力消耗。例如，Excel4.0在Windows和Macintosh平台间共享了69.4%的代码，另有15.4%用的是Macintosh的专有代码，15.1%用了Windows的专有代码。
微软还运用了许多方法以进行独立产品间的代码利用，比如共享构件（以VBA为例）、共享一个常用的API，或干脆采取“拿来主义”的办法。采用了构件重复利用的方法后，开发员们所提供的诸如绘画和图表功能等独立性操作就能通过OLE或DLLs供各种产品共享。微软基础类（MFC）可以提供一整套能重复使用的C++，是采用API方法的一个实例。戴夫·穆尔对此解释道：
Excel4.0的产品代码重复利用矩阵源码类型在Macinto Windows按照源共享占总代的专用专有码类型比例码的比和有代码代码的合计例数间的共享代码代码汇编代码，等文件按平台类型的合计数占总代码的百分比来源：乔恩·德·沃思：《微软Excel4.0的事后分析报告》，6/8/92.
“人们使用这些基础类别作为他们编码的基础。其原因是既然他们的内存使用和功能管理都来自于标准库，有着通用结构，那就可以形成一套惯例程序，使每个应用软件有更多的机会被共享。但是我们并没有命令人们使用这些面向对象的程序编写技术基础类是一个构件库，随我们的Visual C++工具组一起出品。”克里斯·格雷姆认为，像MFC这样的通用API可能会以5：1的比例大幅度地减少系统和用户界面服务。
项目组还寻找机会从其他产品中复制代码，根据需要加以利用。例如在Windows NT的约400万行源码中，开发员对以前的系统，如Windows3.1、DOS4.0和OS/2以及语言组的重复利用率达到了35%。佩拉佐利详细解释了Windows NT中采用的“拿来主义式”重复利用方法：
有相同的排错功能。事实上，我们偷了他们大量的代码。我们认为并非一切都要从零开始。那不是NT——只要合适，我们就从Windows组中拿来代码Windows被分解出了一种所谓的User和GDI[图形设备接口]的功能，其中User管理直线形的窗口，而GDI负责绘图功能。我们把他们所有的User码都拿来用上了，因为它用的也是C语言所有的应用软件，如文件管理器和外壳程序也都用过来了。命令解释器本来是为DOS4.0产品编写的，后来该产品发展成为OS/2.我们把它也拿了过来，装在了NT上语言组的成员给了我们C语言的运行库。我们可不在乎它们是从哪儿来的。
总的来说，微软有大量机会重复使用现存代码，因为开发员们已经为大批产品编写了数量惊人的代码。为什么微软没能很经常地重复使用代码呢？一种可能的解释是微软实行自给自足的小组文化，消费者软件业的飞速变化则是另一种解释，虽然这也可能是不努力实现共享的一个借口。微软各组现在正在学习更多地分享他们的一切成果。即使如此，盖茨也承认项目小组仍未能尽可能多地利用代码：
我们用的是小型的开发小组——他们非常偏爱自给自足，所以他们不会过多地与其他小组共享代码。目前我们却拥有比其他公司更多的代码，因而我们能比其他公司共享更多代码。然而我们在这点上仍做得不够。当然我也能给出一些很成功的案例全公司只有一套图示代码，可为什么要那么多文本处理代码。我可以作出解释何以至此以及为什么它并不像看上去那么糟糕。但如果我们在规格、结构设计上能够做到聪明行事的话，我们本可以避免大量的重复性工作。
