通过自我批评、信息反馈和交流而力求进步为了建立学习组织，微软制定了自己的战略，我们称之为“通过不断的自我批评、信息反馈和交流而力求进步”。对此，我们分解为四个原则予以讨论：
·系统地从过去和当前的研究项目与产品中学习。
·鼓励使用数量化的测量标准和衡量基准进行信息反馈和改进。
·视客户的支持为产品的一部分和进步依据。
·促进各产品组之间的联系，实现资源共享。
在近年来的管理文献中，有关组织学习的内容频频出现，已成为一个很普遍的问题。我们对这一概念的阐述则选用很实用的术语。其实无论做什么，组织自我改进的机会很多：他们可以从经营中进行反思，研究产品，倾听顾客意见；也可以鼓励组织的不同部分像分享各自努力的成果一样实现知识的共享，比如在产品和构件的设计上。所有企业都有这些机会，只是很少有公司能充分利用它们的优势罢了。当一个公司中的个人和各组都试图抓住这些机会，取得了可衡量的进步时，我们便认为该公司“创建了学习组织”。
至于学习的原则，微软与其他成功企业并无不同。无论何时，好企业都会对生产过程和产品吹毛求疵，以求从过去的成功中获得经验、从失败中吸取教训。他们会对自身行为制定标准、进行衡量，再广泛地研究客户；并且，他们试图促成不同组织部门间更普遍地相互合作，共享构件，并交流产品与生产过程的知识。然而，就个人计算机软件公司而言，我们感觉微软尤其强调这些原则，与众不同。之所以这么说，是因为我们相信该公司正孜孜不倦地（虽说仍不够）努力着，要建成一个更具凝聚力的组织。
例如，并非有很多软件开发组织制度性地进行项目后期分析与审计，虽然这已得到软件专家们的首肯，被视之为有益措施。而微软的各组却在事后检查与项目审计两方面都做到了制度性管理。和众多软件制造商及服务业企业一样，微软在充分衡量产品开发过程的各要素之后，竭力在进行更有效的管理和避免过度官僚化之间寻求一种平衡。当然，这种衡量与那些中央处理机和微机世界中的一流软件制造商并不完全相同，比如IBM、惠普或日本的计算机制造商。不管怎样，微软正在培养一种习惯，即对其发展过程中的关键因素进行数量化测量。而经理们正是使用这些资料做出关键决策的——例如，何时推进某一个研究项目，或何时发布一个产品。他们还在创造一些用来评判绩效的标准，从而推动进步。
与世界上任何其他软件公司相比，微软可能有更多的客户接受过电话采访或收到电子调查表。究其原因，当然也可归结为它拥有最庞大的用户网——如果没有其他理由的话。不过我们觉得微软公司比任何其他公司更善于通过彻底地分析与客户的联系而获益，并且所得信息能迅速地直接传输到各产品开发组。自1990年以来，产品组还日益重视自己设计的构件能在其他各组间通用。这种共享制在影响着公司文化和发展战略的同时，也使微软的公司组织发生了巨大变化（如办公产品一体化的建立）。
过去，微软的产品组能集中全力关注一个产品，一个竞争对手和一个目标。比如，他们集中力量推出了Windows或Windows NT，或者在电子表格方面赶超Lotus，在文字处理上与Word-Perfect较量。但是，即使像微软这样资金力量雄厚的公司也必须对各种产品进行标准化，使其具有通用性，以便减少开发、测试和获得客户支持的成本。由于产品竞争的客观现实，微软也承受不了因重复设计错误、漠视客户抱怨与建议或纵容项目进程失控所付出的代价。作为一个组织，“学习”如何使公司不再是缺乏控制与合作的各独立项目小组的集合体可能已成为微软必须进行的最困难的转变。
我们认为，微软比起那些全球大企业来，更易于从学习中获益。如其他章节所述，微软几乎把它所有的产品开发组都设在里士满和华盛顿总部。除了通过电子邮件建立的广泛联系和信任外，盖茨和其他经理人员还坚持主张人们保持密切接触，以便面对面地解决问题。就我们的观察，微软公司内进行的大量学习活动都是非正式的——包括在走廊里常见到的谈话以及在个人办公室里、午餐桌上、休假会期间甚至更偶然场合中的各种交流。
原则一：系统地从过去和当前的研究项目与产品中学习如何对单个的软件开发者和项目作绩效评估历来是个令人头痛的问题。这些任务颇像畅销书的写作（生产），极富创造性。人们很难给他们的生产效率或质量制定一套客观的衡量标准。而微软公司聘用的都是些天赋颇高的独立编程人员，想给他们提出建设性的信息反馈和批评意见自然更困难了。正如在公司的一些事后分析报告和内部备忘录中所表现的那样，微软职员是愿意进行自我批评的。但在70至80年代间，各组的保守倾向日益显著。麦克·梅普尔斯认识到了公司需要高瞻远瞩——各组应就其所作所为与微软内的其他组或其他公司进行比较，或许别人在软件开发管理上更有高招呢。1988年，梅普尔斯把在软件开发中鼓励深入学习和资源共享这项工作交给了戴夫·穆尔。
穆尔1954年出生，曾就读华盛顿大学的数学专业。1976年毕业后进了波音公司，最初在CAD/CAM系统工作，还制定过工程技术标准，因此，对于一个管理出色的工程技术公司应该是什么样子他颇有体会。1981年，穆尔作为一个开发员加入了微软，当时公司大约有100名雇员，几乎还未曾建起什么运作规则。他工作勤勉，不光是Multiplan、Word、Chart、Works和其他一些产品开发中的楷模，也因成功地推出了这些产品而享有盛名。1988年，梅普尔斯请穆尔做了应用软件部门的开发主管。1992年，又晋升为全公司的开发经理，并于1992年至1994年间担任测试与质量担保方面的代理经理，同时还身兼数种临时职位。从1994年起，他就向产品开发部主管克里斯·威廉斯汇报，后者再向保罗·马里兹报告。
作为开发部主管，穆尔把注意力集中于几大领域。他一直鼓励各组写事后分析报告，至少能就项目进程开会讨论。他还实施了过程审计以帮助各组分析和解决问题；又组织起正式的休假会活动，届时有关重要人士会就软件开发与质量控制的相关问题相互切磋；再就是在相同职务的人员间极力撮合一些非正式会谈以鼓励知识共享。这些努力弥补了微软公司另一惯例的缺憾，即所谓“自食其果”——内部率先使用微软的产品和工具，以直接体验它们对顾客的好（或糟糕）的程度。穆尔还开始设法制定公司各组的评估标准，这个理想现已为全公司所强调和追求。
事后分析自从80年代后期以来，有一半至2/3的微软项目已写了事后分析报告；其他项目大多也举行过事后分析讨论会。事后分析的文件在自我批评时的坦率令人惊异，原因恰恰在于公司的最高层会传阅它们。甚至比尔·盖茨也饶有兴趣地阅读了有关主要项目（如Word和Excel）及一些新领域（如多媒体）的事后分析报告。盖茨承认：“人们很自然地会对进展得一团糟的事情表示不满我们在编写软件方面很成功，所以对那些没能做好的部分就可能过于苛刻”。克里斯·彼得斯也同意，并认为：“这些文件的目的就是击败自我”。梅普尔斯则视事后分析为微软人喜欢自我分析的一个自然结果：“在某种程度上，那是我们文化的一部分。我们总是拧紧了发条，我们担心竞争失利，我们习惯于思前想后其表现情形之一为我们特别喜欢自我批评，而事后分析以及一系列此类方式都在试图做到这一点，这都是对所作所为不能尽善尽美的永不妥协。我们总是奋斗不息。”
各组一般3到6个月汇总一次事后分析文件。文件从10页以下到100页以上不等，且有篇幅增加的趋势。比如，Word3.0的事后分析报告从1987年8月起只有12页；Excel4.0的事后分析报告从1992年2、3月起，有41页；始于93年6月的Encarta的事后分析报告有84页；而Windows NT的β鉴定竟长达112页！
由于微软的各项目已不仅仅是可简单描述的开发、测试活动，说明文件也随之增加了。其中添加了详细的针对每种功能的章节，一般由各组负责程序管理、开发、测试、产品管理和用户培训的主要人员分别执笔。最常见的格式是对最近项目中哪些做得好，哪些做得不好以及本组在下一个项目中应如何改进展开讨论。事后分析报告还包括了描述性资料，涉及成员（按职能分的小组规模、工作天数），产品（编码规模、与前一版本的比较、所用语言、生产出的平台和语言版本），质量（每1000行编码的错误数、在四个等级中的错误程度、按产品领域分的错误类型、发现和修正错误的记录、由上一项目遗留下来的以及新产生的错误数目），进度表（实际的以及计划的阶段和出品日期）以及过程（比如所用工具、涉及到与其他组及提供产品附件的外部供应商的合作问题）。通常，职能经理们会准备一份草拟文件，经E-mail（电子邮件）在组员间传看，各自添加意见，再由作者综合检查以最后定稿。之后，文件便发送到组员、高级管理员和产品开发部、开发部及测试部的各位主管处。接着，职能组，有时整个项目组会开会讨论事后分析的研究结果。有些组（如Excel和Windows NT）还养成习惯，在每个阶段结束后召开分析会议，做出中期的工作修正，检查特性表并重新调整进度表。
事后分析文件可提供的是一个粗线条的记录，告诉人们在开发Word等产品时微软是如何在对困难的应战中取得进展的。Word组从1987年起在复发性问题文档化上独树一帜，而Excel组则从1989和1990年起，在为相关大项目寻求解决方案方面堪称楷模。自此，微软的经理们开始把Excel等组或某些项目的技巧或经验教训在全公司内广为宣传。他们所依赖的一系列机制有：散布主要备忘录和事后分析报告，创作有关进步安排及项目管理方法的书面文件（这未能受到欢迎），发行克里斯·彼得斯1990年关于Excel组做法的谈话录像（这被证明颇受欢迎），戴夫·穆尔所推广的非正式审计，休假会上讨论质量和进度问题以及按彼得斯的录像所授的经验，人们总结出的软件按时出品的一周程序。下列的这些综述在事后分析报告中均已载明，从中可知微软从各种教训中曾体尝的痛苦滋味。
在80年代中期，微软公司推行过一种Word小组称之为“广度优先”的方法。先由程序管理员写出一个简要的思路陈述和功能具体化提纲，然后开发员在把各种新特性编入新的产品版本时做首次削减——直到各项工作均已告终，人们才会把精力投入测试和各特性的集成上。这一方法显然在很大程度上依赖于项目结束前的大量集成工作。
“广度优先”法对那些各种特性相互独立的小项目很有效。但是，当微软将之“升级”，用于Word、Excel以及Windows和Omega（Access）数据库这些大型的复杂产品时却未见效。到80年代后期，微软产品不仅在各特性间相互影响方面有缺陷，各特性本身也是问题重重。（一个相互影响方面的例子是，当有人使用制表功能时，打印功能却来凑热闹，将它打印出来。）开发员总是不得不返工，又研制大量代码去修改错误，以使各功能运行无误；于是，返工会完全撇开了进度表。在有些情况下，发布可靠产品还会成为难题，或根本就不可能，因为修改程序的使用可能招致更多的错误，直至出现所谓“无穷错误”的状态，结果项目虽已近尾声，有的错误仍得不到修改。
查尔斯·西蒙尼在1987年8月13日的会议基础上写出了一份Macintosh Word3.0的事后分析备忘录。这个项目之所以重要，全因为该组的种种不凡遭遇。Windows版本的产品始于1984年，预计进度为一年。虽然开发组试图重复交叉使用Macintosh和PCWindows平台，并力求适应Windows程序的变化，可还是不可避免地延期了。Windows版最终是1989年11月推出的——迟于原进度4年之久。微软在1987年4月确实推出过一个Macintosh版，却错误百出以致公司不得不回收产品，再向7000用户提供了免费替代品。1尽管组员们经历了这些挫折，人们仍能看到他们在反思整个过程。Word小组在事后分析中建议项目组从“广度优先”法中摆脱出来。看来，更明智的做法是把产品特性分成不同的阶段，从“深度优先”着手，即把一小组人员配置到某一组选定的特性上，进行更加深入完整的构建，并在开始其他特性之前彻底予以检验。西蒙尼对此做了如下解释：
我们在1987年8月13日召开了一个Word3.0的事后分析总结会Word3.0的问题是由各种情况共同引起的，包括缺乏早期的深入测试（这在很大程度上又是由“广度优先”法导致的），不能完全理解产品的复杂性，也未能充分变动1.05数据库以驾驭新的复杂情况。我们打算避免上述问题再度滋生，方法是从更深入细致的开发起步，组织——如果可能的话——“攻坚战”，每2、3或4个人一起在同一特性的不同细节上开展工作。到战役快结束时将详加测试，这次工作由开发员们进行，未加入战役本身的程序员们也参与其中至于如何改变编程组织和编码操作以减少错误数目，我们也有了些主意，多数情况下，这些想法同样适用于其他项目。
组还有过其他一些不妥举措，如在完整提交以前不检查开发员的代码。西蒙尼抱怨道：“先是由于盲目乐观，后是基于进度表的压力，Word3.0的许多新代码没接受检查。”3而几乎所有的公司都发现：代码检查是尽早摒弃错误的有力途径。当然，这份事后分析也揭示出微软的开发员们已在使用先进的抽象方法和基本是目标导向式的设计技术，这使代码有更广的适用性，并能支持大量的新的特性。微软开发过程和编码技术的其他许多优势在Word3.0项目中也崭露头角，包括强调编码中对各种“主张”的插入说明，好让其他开发员、测试员知道原开发员在此做了怎样的假定；使用自动化测试发现错误；引进“工具版”产品记录下用户的每一步操作，以便分析错误。
糟糕的是，Macintosh Word4.0项目并没有更佳业绩；小组成员在1990年推出产品之前又重犯了许多错误。下面这段评论节选自克里斯·梅森所撰的开发事后分析报告，暗示了问题的糟糕程度。麻烦源于小组盲目地想在Macintosh和Windows版之间搞代码共享，没有固定进度表，开发工具毛病多端，缺少特性设计的各方面合作，倾向于一次性修改纠缠不清的错误以及具体化不够充分。
的开发事后分析会议5月10日在美丽的贝尔维尤市中心召开若说这个项目中有失败之举的话，那就是制表以及和Win Word的合并。其中当然也不乏幼稚之举和时间的浪费。我们天真地认为自己能在显示、PLC和日常规则设计上做些基本变动，写出大量复杂的新代码且错误寥寥。Word史上恐怕永远不能实现这一奇妙构想。我相信，和Win Word共享代码是在浪费他们和我们的时间，完完全全就是一个失败最终，Mac Word被树立为经典案例予以研究，告诫人们制定项目进度表时不能怎么做（第1页）。
的进度安排总体看来是不充分的我们的工作其实就没有什么进度表真是太愚蠢了，事后看来，我们从未能按时出品实在不足为怪。我们对自己正在做什么其实并无主见（第5页）。
最大的问题莫过于我们被告之开发系统可以推出了。实际上，所有部分，尤其是汇编程序和解释程序里，错误云集（第8页）。
我们倾向于独立设计特性，从不考虑他们和程序其他部分的相互作用错误，尤其是集中在某一领域的大量错误，能指明特性间的相互作用以及被忽视的设计问题。而我们通常没去领会Word4.0所给的启示。我们始终一次性修改错误我们也不能做到透彻理解表格与Word其他部分的相互作用（第9页）。
我们三次将Win Word代码合并入Mac Word中。第三次之后，两个项目已共享了产品的大部分代码。换个角度来看，Win Word至少做了6次合并每一次都严重破坏了他们的产品当Mac Word正在彻底地重做基础设计，而Win Word却欲向前推进工作时，这些合并更成为远非一个方案可解决的难题（第12页）。
攻坚战未能解决问题，事实上也未如他们设想的能推动深度优先说明存在缺陷，表格只用3页半就描述完了（第15-16页）。
不管怎样，Macintosh Word4.0项目仍是检查了较多代码，做了较好的测试尝试。测试的事后分析由菲尔·福赛特执笔，反映出该项目已引进了更为系统化的测试程序；并已超出了“专门测试”范围，演变为有着更多的计划和具体化分析的文件。福赛特还申请更多的自动化测试工具，呼吁进行更合理的项目进度安排以确保充足时间被用于测试。
发布之后，有一点已确信无疑，即仅仅使用专门测试，以此作为确保产品质量的手段实在漏洞百出。为了避免盲目的行动，也为了有助于测试员的培训，我们决定将部分测试时间用于创作特性说明和特性测试的案例文件。一旦这些完善了，测试的尝试就可组织为一系列完整的工作循环，并可为充分进行非系统化测试配置时间。特性说明写在项目早期，其基础是出于对某些特性如何运作的初步设计考虑我们发现最能发挥这个文件的效力的是把它作为对某种非系统型方法的补充（第2页）。
在所有影响测试效率的因素中，缺乏充足的工具最为突出。由于缺乏足够的自动化工具，我们只得求助于人工测试方法（第6页）。
不正确的项目进度安排和赶进度产生的压力会在整个测试过程中减少连贯性。不太可行的进度表迫使测试在11月（1988）就开始进入出品状态，并一直延续到4月中旬。这意味着测试中40%的努力都花在了出品状态上了（6个月）。在这令人精疲力竭的过程中，我们注意到了生产效率的损失惊人而一个现实的进度表必是基于对代码变化、每KLOC错误数及代码的复杂性衡量的较准确的估计的，并且其他一些通用标准应在开始进入出品状态前多给出3个月时间，用于更系统、更彻底的测试（第7页）。
和4.0项目完成于1990年至1992年间，利用了本书第4、5章所述的过程。Excel3.0被证明是高质量的，且只延期了11天。虽然克里斯·彼得斯在他1990年录像的谈话中详细阐述了所用过程，这个项目还是一直未写出事后分析文件。Excel4.0的开发周期仅为9个月，比3.0版迟一个月便出品了；它的事后分析很具体地将两个项目组的经历作了比较。由于4.0项目略去了大量重要的具体化阶段，直接进入了3.0版中未涉及的添加特性，因此它不很典型。不管怎样，开发事后分析报告（由乔恩·德·沃恩执笔）还是可以反映出微软公司内部的奋斗历程。关键在于能维持这么一种平衡，既不在那些会变动或终被放弃的特性的具体化上浪费时间，又能写成充分详细的文件以便了解什么特性应优先考虑，并估计出给它们编码时的难度如何，进而合理安排进度。该项目小组还从其他组及销售商处引进了一些构件，故而导致了一场关于“相互依赖”问题的讨论，这一问题在以后的项目中还会越来越严重。很显然，微软已开始接受更高的项目管理与质量标准：虽说与老项目相比，新项目的实际进度与进度表的吻合好多了，为什么还是延期？虽说顾客的抱怨已减少到了最低限度，为什么还是有这么多错误？
的开发始于1991年7月8日，第一版（Windows，US）于1992年3月27日推出Excel4.0的开发过程总体上堪称成功。产品广为接受，来自PSS的报告也暗示我们没有质量问题。不过，项目的急促迫使我们砍掉了开发过程中的一些细节，其后果在我们看来是会引起一些进度上的损耗，某些内部和外部的设计决策不当以及较晚终会显形的错误（第1页）。
在进度安排上我们遇到的主要困难是估计失误。由于重要设计的不足导致了估计不够准确虽然Excel4.0和Excel3.0的零缺陷规定几乎一模一样，可在每个开发员的优先表上却未给予同等重视。人们总的感觉是Excel4.0错误太多。按照记录，零缺陷对Excel意味着：
·所有变化必须予以收集，建立联系；·所有变化必须同时在Macintosh和Windows平台上通过“快速检验”；·任何开发员，一旦错误记录超过10个就必须在修·改之后才能转向新的特性（第4-5页）。
程序管理的事后分析报告由迈克·马蒂厄执笔，描述了开发开始之前计划不足，对具体化重视不够等问题。马蒂厄写到想象性描述“是个很好的参考，凭此可把注意力集中在产品上”，但“它比我们真能做到的有更好的蕴意”。他把活动基础上的计划描写为“一种通过将特性合理化并给出重点从而能更好关注于设计目标的好方法”，但他声明“我们并不事先删减说明，所以在那些终被砍掉的特性上白花了很多时间活动小组未能组织有序，成员变动频繁工作中与开发员紧密配合以解决设计问题比说明不离手要更有成效。这会节约周转时间，减少繁文缛节”。另外，马蒂厄还指出需要较早地、更为方便地使用实验室测试，并用更好的方法控制说明的改变。7测试部分事后分析的作者马克·奥尔森则抱怨了具体化过程（说明过时、没有说明和说明不完善是三大难题）及一大堆其他问题，诸如在测试员中平衡工作量，加快改错的周转率。
多数项目都描述过相似问题。例如，新近的Encarta多媒体百科全书出品于1993年3月，项目为期22月，成员10来人。该项目的重要性在于它混合了正文、视、听形象的运用。其事后分析文件表明了该组在采用Excel开发方法方面很下了功夫，然而，项目并未做到善始善终地学习Excel的成功经验。它居然遇到了微软一些项目组在80年代曾有记载的同类困难。思考和计划不足导致了该组在特性的优先安排上不很得力。结果，项目直到最后阶段时还有一些特性未攻克下来，又不能删除，终于延误了进度。半途停止的特性（和早期的广度优先法一样）将被带到下一阶段，给实际进展抹上不大现实的色彩。过于乐观的进度安排迫使每个人都得拼命赶，从而将项目本应配置在代码检查、测试和改错上的时间压缩再压缩。不过，微软还是通过了它第一个主要的多媒体项目，并为将来的同类产品开发打下了经验基础。
虽然在Encarta组的努力下，该产品很有竞争力，令人引以自豪，但小组仍觉得我们能够并力争在下一次做得更好。工作的关键部分将是产品效果、进度安排和协调工作量。从管理的角度来看，因为存在着相当的进度拖沓，Encarta项目算不上典范。事实上，要研究在多媒体项目的软件开发进度安排上什么不可做时，它倒是个例证Encarta的多数问题可归因于一点：在开发这类规模和复杂程度的产品时，我们还缺少对多媒体出版产品（MM-PVB）的经验。现在有了Encarta的经历，以后在项目中面对这些困难时，我们再不会不知所措了。
过程审计梅普尔斯交给开发主任穆尔的任务之一就是实施不定期的过程审计，尤其在项目进展遇到困难时。例如，1993年，穆尔实施了5次审计，每次都集中力量花一周时间。他经常查看那些能弄到手的项目和质量方面的资料，尽可能多地和项目成员谈话，并试图鉴定他们什么地方表现不错及哪里可能做得更好。总而言之，穆尔是想找出一个过程典范以促使小组的工作更为成功；并且，对于核心的项目人员他还会写成文稿或口头上予以详细信息反馈。他把自己的任务描述为建设性的：
麦克[梅尔普斯]已让我着手对小组做审计。一旦哪儿出现问题或他们需要帮忙，审计者总能应需而动。我在那里扮演的可是警察或打手。因此人还没到，他们自己就开始整顿起来：工作暂停，做点变动这就是我要去做审计的地方。一般我会这么来个开场白：“我给你们帮忙来了。我会记录下最好的做法，广为传播。我来这儿就是要抓你们的最好典型。”然后，当他们叙述着自己最好的做法如何如何时，我会问有些什么困难。如果有的问题或做法我相信能在小组内改进，我就给出改进建议。我总把审计视为我到那里去帮助他们的建设性步骤我几乎可以说自己现在做的工作是个专职审计员。
尽管审计是有压力的，穆尔更像一个福音传教士般工作着。他通过逻辑的力量和来自其他项目的资料传输，亲切引导小组朝着更好的做法迈进。我们已注意到了，对于来自管理层、官僚性规定或公司质量保障（QC）组的命令，微软内部存在着一种文化对抗，这时的高速人们去做什么很困难。为适应这种微软文化，穆尔让人们把他的审计视为一种“技术交换”：
这大概要算是我的个人奋斗吧。这里没有一个层级间的管理命令，只是一种技术交换。我不会走入什么人的办公室对他说：“麦克已吩咐我了，要高举条理规范之旗，所以你们就遵守这些标准吧。”我会说：“大家工作进展如何？有没有试过这种方法？或许它在解决那个问题上能有效。”那才是讨论方式。这些小组会选择出最适合的解决问题之道。你们大概已注意到了，根本没有什么质量保证组来围着这些工作组转，我们没有那种传统的质量保证。有个组曾在穆尔的帮助下渡过危机，开发出了Visual C++语言产品。麦克·梅普尔斯在一个程序检查例会上遇到了该项目组成员。辨明问题所在之后，他请穆尔去做审计。该组有三四十名开发员，同等数目的测试员，另加10个程序管理员，但采用的做法却是心血来潮式的。程序经理杰夫·贝勒曾这样描述小组在与穆尔打交道后的变化：“戴夫花了约两周时间采访产品组的主要成员带回来了一系列建议关于开发、测试及程序管理问题的大部分建议得到了支持。但有时我们也不得不强制执行：‘你们应该能做到这点。戴夫·穆尔已说过我们组的确不错，我们要在这个项目上当之无愧。’至于其他方面，建议都通情达理，我们只要照着做就行了，当然也有些从未执行。”
最重要的是，小组采用了每日构造法，即按照各个阶段和细分的任务来安排进度，在将代码纳入构造之前先予以检查。克里斯·威廉斯对这种审计结果大加喝彩：“Visual C++组完全乱了套，C7[C++第7版]是为期12个月的项目，可出品却推迟了13个月他们打电话给戴夫说：‘戴夫，快来帮帮忙吧。’戴夫来了，告诉他们：‘好吧，你们要遵循这些方法，你们要做这些事情。’于是这些家伙完全改变了办事的路子，结果准时、无误地推出了产品。”
休假会年代早期起，微软开始对其主要成员每年至少组织一次“休假会”。目的之一是促成不同部门就手头工作交换信息，再就是对付一些难题，诸如怎样才能在特别产品领域更有效地竞争（1983年的一次“休假”活动曾瞄准了Lotus，以对新的Excel产品的明确界定而结束了会议）以及如何提高开发产品和获得客户支持的技巧。在有些会上，组织者会要求与会者读有关软件工程及相关领域的经典文献（比如菲尔·克罗斯比强调质量，而汤姆·德马科关注项目进度），然后讨论这些作者的洞察力何在以及微软意欲着手进行哪些改进。领导人物会首先就所读发言，引导讨论。
最有名的且业已载入克里斯·梅森的“零缺陷”备忘录并将流传百世的“休假会”恐怕要算1989年5月的那次了，会晤集中于那些旨在减少错误，提高质量的技术和工具上。大约30人参加了这次休假活动，由戴夫·穆尔组织并视为其新任开发主管工作的一部分。穆尔把与会者分为四组，要求他们全力关注零缺陷的方法、工具和其他相关问题。他曾回忆起这次会议，谈到了麦克·梅普尔斯所起的作用：
我和杰夫（哈贝尔斯，后来成了穆尔的老板）谈到了我们需要如何做些变动，可我就是毫无进展。我正和组员们努力工作，力求改进。杰夫也在尝试一些事情。但是“我们需要了解全过程，我们需要零缺陷推进这类观念”之类的内聚力还没形成。到1988年9月份麦克·梅普尔斯走马上任之时，终于开始了旨在真正理解全过程的根本性变革。那时，我和麦克一起工作，规定了这次“休假会”的组织中心是着手实行零缺陷。我考虑这个问题已有些时候了；我敢说其他人也都在这个问题上想了许久。可我还是把大家召集到一起来。事实上，查尔斯·西蒙尼是零缺陷小组当中的一员，不过，选他领导这个特殊小组纯属巧合。所幸的是，那种安排，那种组织系统化以及对各种问题的见识使我们能抓住始终需要向应用软件开发小组揭示的各种观念。
微软坚持每年就不同问题召集“休假会”。1993年至1995年，会议集中的焦点是迎接挑战，以更为集成的实体运营；还有对联机网络和多媒体这类新技术备战。举个例子，1993年6月的“休假会”就讨论了不同产品、不同的业务单位之间相互配合的改进问题。而1994年2月的一次则讨论的是“互相依赖”的管理问题：即当项目依赖的关键构件是由其他项目开发的或从公司外部引进的时，如何处理日益严重的进度安排和质量保证问题。克里斯·威廉斯回忆起这次来自公司各部分的开发经理和测试经理参加的历时三天的“休假会”：“麦克[梅普尔斯]和戴夫[穆尔]是实际上的主办人，他们一起在合计这事。我想议题的形成原因在于大家相当广泛地关注着日益突出的合成化、相互依赖问题，并且对相互依赖和进度的有效管理的能力欠缺问题也有所考虑。所以，有的组被派去察看管理依存度，去巡视‘我们是否缺少一些重要工具，怎样着手减少那些测试时暴露无遗的错误’这类事情。”
目前存在几个关键的相互依赖问题。例如，Visual Basicfor Applications（在语言领域中开发）和OLE（在商业系统部门开发）是Excel和其他使用这些技术的应用软件中的关键部分。Offfice（办公室）产品系列必须在开发Excel、Word、Power Point、Mail和Access时相互配合，这就需要将其一起推出。威廉斯解释说Office现在问题少多了，因为它全部由克里斯指导：“为什么Office，比如说，工作效率很高，原因之一就在于它们都在同一个组织之中。只有当牵扯到不同部门时，事情才会变得问题成堆。”1994年2月的“休假会”上提出了一个很特别的建议，就是在两个相互依赖的组间创造出一个合约样本。这也可作为一种最佳方案清单，用于相互依赖的小组间的协调管理，并详细说明在开发和测试阶段的责任划分和截止日期。
小组间的资源分享和许多大公司一样，微软目前也是部门林立，以至于某一领域的人不一定知道另一领域的人正在干什么。“休假会”有助于发布信息，但这种信息交换并不频繁，层次也太高。于是，戴夫·穆尔这些经理人员鼓励中级经理和其他人员在不太正式的场合更经常地交流各自所知。相同职能部门内经理们的午餐会已固化为一个主要的机制。Excel组的测试经理马克就解释了他如何定期与其他各组的同僚们交流，这甚至比Office产品单位的形成还早些：
在测试水平上，我和Word的测试经理经常交谈，我们做了大量努力去创造同时适应于Word和Excel的特性。我们让各组间工作在相近特性上的测试员紧密联系，共享各种主意和信息。我们反复地分享着工具我们每月还有一次两小时的聚餐会——到会的包括Word、Excel和Project的测试经理们。我们谈论“正面临着什么问题”，“如何予以解决”，“我正在考虑这个问题”，“你这家伙在忙什么呢”我们每月还和公司内所有的测试经理会谈，甚至是全世界范围内的产品组我们做个介绍，然后大家分享各组的业绩。
克里斯·威廉斯是另一位力唱和维护这些经常的非正式会谈的健将。负责用户培训和测试的经理们似乎对此最为热衷。然而在穆尔组织的大部分会议上，开发经理们都没露面，这使穆尔和威廉斯受到了挫折：
如何让大家更多地进行交流是我们碰到的有趣问题之一。用户培训主任举行了所谓的“博览会议”，每周聚一次，每次谈上一小时。每组就各自产品及其走势发表意见，使大家都清清楚楚。然后话题转入多种领域，他们谈HR问题，技术问题，有时也引荐一些外部人员做发言测试员们每月开一次会，到时测试经理们济济一堂，提供有长远价值的议题加以讨论。看来他们收获颇丰。戴夫也曾搞过每月一次的开发经理人员会议，可只能请到其中15%的人出席。
程序经理们在所谓的“蓝色托盘”午餐中定期会晤，人们就一些特定项目交流经验，沟通信息。微软公司将其中的一些录了像广为流传。某些小组的开发员也定期聚会。比如Excel开发员每周一次“自带酒食”午餐会，人们借此机会谈论不同领域的代码，既对正在了解产品的新人有所裨益；也会使自己熟悉一些经验丰富的开发员，他们往往可以填补自己在某些变化和领域内的空白。有时，开发员还会就有关代码的细节问题发行备忘录。
即使没有上述这些定期会晤，“点子”在微软内的传播也是很快的。例如，人们可以通过电子邮件“别名”或小组地址去联系相同职能领域的人员。举个例子，戴夫·穆尔可以向所有的开发经理发布信息，而罗格·舍曼可以联络所有测试经理。尤其是穆尔，他常用电子邮件，借此与别人分享一个好主意，综述一下自己在一些新书或文章中的发现，或者就阅读提出些建议等。人们还会带着各自的好主意在公司内转来转去。正如Windows和MS-DOS的前任测试经理戴夫·马里茨所言：“我们可不是循规蹈矩的家伙，我们常在各部门间东走西瞧。”
自食其果微软还有一种学习机制，即所谓的“自食其果”。我们在第5章解释过，这会意味着创建一特定产品的组将尽可能在自己的工作中使用该产品。如果产品性能太差，构造者和其他每个组员不得不“自食其果”。比如，经理人员坚持要求研制Windows NT或Windows95的小组只要有了稳定版本，就得先“款待”自己，在自己的运营系统中使用产品；这样，小组就能自己测试出错误来了。Word和Excel组将在开发阶段使用这些产品的新版本，以写出备忘录或保存项目资料。
这一机制的更广泛应用是微软各组在工作中使用微软自己的工具和商业产品，通过亲身体验，见客户之所见，并向相关小组不断反馈信息。因此，比尔·盖茨命令程序经理使用Visual Basic来做个榜样；而史蒂夫·巴尔梅则指示微软内部信息管理系统（MIS）的职员在早期开发阶段就使用Windows NT。相似地，微软各组一般只用公司自己的商业语言编译程序，而不会制造或购买更多的专用开发工具。NT组的开发经理戴夫·汤姆森评论了盖茨和巴尔梅的工作：
这些人所做的是试图确定让所有的固有力量能适得其所，发挥效力。而告诉MIS组使用这些产品本身就是把各种自身力量安置妥当，从而产品能做得更棒。要知道，你有一长串用户，只有你的产品很出色，他们才会谢绝一长串的其他供应商，随你而来。另一个例子是，当Visual Basic还在开发之中时，比尔就命令我们组进行网络管理工具开发的成员将它用于工作中他们根本不喜欢它不管怎样，他们还是这么做了，结果，推动Visual Basic进行了一系列有益的改进比尔已达到了他的目的，他迫使Visual Basic的成员做了改进；而后者在发布产品时也承认，开发小组在使用这些产品中提供了大量的信息反馈和意见，着实贡献不小。所以这些家伙们以后会欢迎一些压力的合理介入的。
瑞克·罗歇德在Windows NT中扮演了一个相似的角色。作为Mach——一个在Unix基础上的微型内核操作系统，对NT的设计有影响——的主要设计者，他能使用和测试NT，并与自己的系统作比较。比尔·盖茨聘请罗歇德可不是为了检查NT，可他非常倚重罗歇德的评价。换句话说，盖茨让另一种“自然力”适得其所，详审那些关键性新产品，并帮助他引导这个项目：“举NT的例子，我们让创造出了Match的人管理着小组他总在挑NT的毛病，一发现哪儿比不上Mach，他就直言不讳。于是，这个组出现了许多好建议这的确利于NT。我们并没在聘用瑞克时说你是NT监视委员会的我是和Word、Excel一起发展起来的，我知道那里的规则系统，也认识所有那些开发员。NT则相当新，所以我会不时问瑞克‘你认为这事怎么样？’这里有许多人巴不得对周围的其他各组批评一通呢。”
“自食其果”的另一内容就是开发员应使用普通客户所用的计算机——而不是那种带着许多RAM和硬盘存储空间的“高性能”机型。Windows组的负责人，高级副总裁布兰德·斯尔文伯格详细叙述了他对这一规则的感受（微软并未能一贯遵守它）：
对安装的支持系统非常依赖，因此，产品能够在一个通用的4或8兆内存的机型上运行良好就显得特别重要。因为，如果你给你的开发员用16兆内存的486机型，他们所见的结果就会完全不同于你的客户们的使用结果；在16兆时运转自如得到了4兆条件下没准会摇摇晃晃，抖得厉害。你不能说：“没问题，我有测试机器呀。我会不时在我4兆机型上试用一下。”所以我的做法是，确保我的开发员用的机型和我所预期的客户所用有可比性。这样，我的开发员基本上只用4兆或8兆的计算机。有时这又太保守了，因为大多数开发员想用最快的计算机、最新的技术。他们不是总能想得通，但还是得这么做。如果你看我的保存记录，只要在哪一个项目中开发员用的硬件设备比客户的要优越，产品推出后准保会出现问题。
最近的一个例子是对MS-DOS6.0中Double Space特性的内部（和β）测试。11微软主要依靠使用自己的1000名员工进行测试，他们一般用Windows和新应用程序。微软对该产品的5000名β测试员和内部的微软用户有相似的特点——他们倾向于运行Windows和新的Windows应用软件。不过，在一个老式的或有点毛病的硬件上与某些旧版的DOS应用软件一起运行时，Double Space会遇到一些问题。而且，在和DOS（而不是Windows）并用时，它还会与MS-DOS6.0中一个叫Smart Drive的记忆存储功能相抵触。
在微软推出这个产品前已有了上述问题的征兆，可对他们而言，返工太少见且太困难了。不管怎样，由于看中了信息压缩和记忆增进功能，数以百万的还未升级到Windows的MS-DOS用户买了MS-DOS6.0；又因为机型太老、太小，没法升级，他们还继续在用旧版的DOS应用软件。这类用户中很多人都碰到了Double Space的问题，从而迫使微软进行一次MS-DOS6.0的新的发布（这只花客户很少的费用）。13如MS-DOS6.0的开发经理本·斯利卡夫回忆的：
还在出品之前，我就知道有两个问题，一是有一些特定的复制保护应用软件不能用，而我们的感觉是没有几个用户会超出预期范围。[用户]一定是那些用旧版应用软件、还未升级的人，但他会将操作系统升级的。我们很难知道那会是些什么人我们的一个理论是买了Windows3.1的人们更偏爱买MS-DOS6.0，而机器是和一起推出的。将买MS-DOS6.0却没有Windows3.1的人似乎微乎其微从营销人员那儿我了解到有一批人正要升级，可之后的说法又是也有一批人不会升级后来我们就做了随机抽样的电话调查，以便弄清楚谁正在买MS-DOS6.0；结果是，购买MS-DOS6.0升级的人当中80%至90%拥有Windows和一台386机器。这个消息符合我们的预期[而且]我们感觉到Windows3.1是我们的保护伞可是一反思，我们也不能确信自己的考虑已足够谨慎在微软内部我们有超过1000人在运行Double Space，却没有看出任何问题。我们的β测试员和1月份的β论坛一直在叫：“推出去吧，推出去吧！一切都就绪了。”
虽然错误率只是20%，我们还是觉得微软本应发现并解决这些问题的。公司测试员、内部用户和β测试员应该每日都在一个旧款的DOS机器上对Double Space和其他一系列DOS应用软件做试运行。当然，MS-DOS6.0和Double Space还提供了一个吸取教训的机会。正如我们在第5章所讨论的，对于它的下一个主要的操作系统发布对象Windows95，微软延长了内部开发、测试过程。它还把一系列β测试场所增为400000个。虽然产品延期一年半才推出，而且一些特性有严重问题，上述的和其他一些措施还是减少了因急于出品或β测试不充分而发现不了重大错误的可能性。
原则二：鼓励使用数量化的测量标准和衡量基准进行信息反馈和改进许多公司业已发现，在产品开发这些管理和改进活动中一个关键因素是创造出数量化的测量标准和衡量基准。测量标准是一些统计性的量度体系和资料，可以此对质量加以评判，并表明产品或进程中关键因素的特征。微软的项目最终逐步采纳了一小批测量标准并坚持使用下来，这也算是对事后例分析报告中披露的问题的一种对策吧。经理们主要利用这些做项目的重大决策，比如何时结束某一阶段继续推进或推出产品。另外，数量化的测量标准和资料被作为一种信息反馈系统用以帮助项目间共享信息，一起改进。微软的经理们现在还正在试着利用测量标准创造一套全公司范围内的衡量基准，以期摸索出最可行的开发方案。这些衡量基准将会使所有小组更方便地展示各自的技巧并互相学习；而为确定衡量基准进行的资料收集过程也会延长项目事后分析文件的制作。
前面我们提到过有一些公司在利用数量化测量标准和资料进行软件开发方面比微软先进得多。微软人也承认，他们在明确测量标准和积累项目资料上可做的事很多，而这么做就能把握——以一种能相互让渡的方式——干练、成功的经理们做决策的思路。不管怎样，测量标准和资料在微软已有长期的特殊地位。要是缺了它们，人们可能会企图将决策建立在关于感情用事或主观性的争论上，或者会在是否容纳一个特性，是否发布一个产品，是否采纳一个不同的做法或工具问题上争论不休。微软各组现在还存在这些争论，但感情化的方案从来不会在比尔·盖茨或微软其他高级经理那里获准通过。比如，戴夫·穆尔对运用资料支持人们在程序检查中的建议的重要性发表意见到：“如果人们不能利用技术性材料说明那些建议，就有可能受到忽视。这些人都知道这点。只要是以感情化的或政治化的背景引发的方案，就不用理它；就当什么也没发生。但是，如果在一次程序检查中有人向你提出建议，只要它是有技术支持的，而你却置之不理——你没有充分利用所有资料去做决策，那你就会在那项程序检查中被完全撇在一边。那将是你的终生大错。”
数量化材料在微软似乎很受重视。这种公司内的上下一致使我们深信，微软在更好利用测量标准和衡量基准上有着相当潜力。
测量标准的类别在第4、5章以及在事后分析报告的概述中，我们已看到了微软拥有的各类测量标准的例子。在本章以后的部分，我们将讨论一些关于微软利用实验室和客户支持组织的实例。总的来说，这些测量标准分为三大类，它们具有下列可资度量和追述的特征：
·质量——包括错误的发现和每日每周的修改率；错误严重程度；错误的解决；错误群分析；每1000行源代码发现的错误；实验室使用结果；客户使用中满意程度；客户使用中出现问题的频率。
·产品——包括特性类型和数目；按照源代码行数、储存字节和可执行文件字节来考虑的产品规模；上、下两版间产品规模的变化；代码重复使用程度；进度和内存使用情况；代码的测试范围。
·过程——包括特性小组规模；估计的和实际的各特性、各阶段和可推出产品的完成日期；进度拖延程度；各阶段完成情况；发现错误的有效方法。
在一个项目中，经理们会自始至终运用这些质量、产品和过程的测量标准。在一个项目开始前，他们利用测量标准帮助预测人员需要情况（比如开发员和测试员需要多少人）；他们还试图就进度要求进行估计（比如集成和缓冲所需时间）。在项目进行当中，经理们——以及开发员和测试员们——会使用测量标准来获得有关进展情况、稳定性和效果显示上的信息反馈。项目完成之后，他们又用这些测量标准来标明项目的特征，弄清问题所在领域，评估错误发现技术的有效性，探索多元化项目的趋势，并强调可改进的机会何在。然而，对于某些由微软各组和其他公司收集的测量标准的使用价值与普遍性问题，公司内仍有争论。人们在解释一些专门的测量标准数字时的确容易出错。因此，微软职员（及其他人）需要很仔细地描述为什么以及在何种背景下，他们选用了这些测量标准。比如，在微软我们就看到，人们特别努力地区别应用软件的各种特性，而不是系统产品或项目上的。
在微软，无论是应用软件还是系统软件人员都广泛关注着错误的测量标准。不过系统项目人员更重视那些表明一个产品的执行速度和内存利用特性的成果标准。在系统化的产品里，较低层次功能的有效运行极为重要，因为较高级的应用软件产品会重复执行这些功能。用户还要求应用软件解决快速进行人机对话问题。事实上，一个系统产品的内存使用，比如它要求的是4、8或16兆（MB）内存，直接会转变为其潜在的市场销售规模。举个例子，许多老式的或低价的PC只有2兆或4兆内存，因而不能运行诸如Windows NT（它要求16兆内存）这样的系统产品。相反，应用软件产品正倾向于强调产品推出时及中间阶段期限上的测量标准。应用软件项目一般每隔12至24个月发布新产品，为了实现时间目标就会削减特性。而系统项目则多偏向于推迟发布，只要有可能的话；因为他们必须发布单独一套产品特性用以支持许多不同客户的使用方案。
例子——关于错误严重程度的测量标准测量标准最广泛地被用于微软项目中以处理各种各样的错误和缺点。这些错误是软件产品的“常客”，软件行业的多数人称之为“臭虫”。无论在微软还是其他什么公司，对错误的发现和改正活动从来都是软件开发的一部分。由于微软开发员编写了大量代码，创造的产品的每日构造日渐增多，他们也就会产生和修改大量错误。因此，针对错误的测量标准如此之多是不足为怪的。如第5章曾讨论过的，错误情况反映了产品的整体质量和开发测试期间产品质量的改进程度。微软还使用了一些测量标准用以表明那些发生了并可区别出不同的改进领域的各类错误的特性，估计进展程度以及对发布产品的准备情况做出评价。最终看来，一个项目的错误数目是许多因素的一个函数：人员技巧，人员数目（尤其是新雇员），具体化中的变化，新的、有更动的代码量，代码理解难度，测试的彻底程度以及和其他产品的兼容性等。
项目在给错误分类时使用了一系列不同方案来辨明它们的严重性，它们是怎样、何时被发现的，又是何时解决的，以及对产品特性的影响如何。多数组依靠一种四等的严重程度分类方案，这与软件业的其他公司大同小异：
·级严重度：错误导致了产品失败（“崩溃”）或没法操作。
·级严重度：错误导致了一个特性不能运行并且不可能有替代方案。
·级严重度：错误导致了一个特性不能运行，但可有一个替代方案。
·级严重度：错误是表面化的或微小的。
错误按严重等级的分布发布日产品严重等级（%）注：每行加起之和约有100%，代表对一特定产品的所有错误。来源：《Mac Word4.0开发事后分析报告》；《Macword累加错误比率》；《Worksfor Windows2.0开发事后分析报告》；《Win Word2.0测试事后分析报告》；乔恩·德·沃恩：《微软Excel4.0事后分析报告》，6/8/92；《微软项目Windows3.0版的开发事后分析报告》，3/16/92；《Win Proj3.0项目回顾分析报告》，4/2/92；《Money2.0测试总结报告》，所有微软内部文件。
概括了在不同产品的开发期间各种严重等级上发现的错误比重。这些错误都是在一种产品的“正式的”每日构造中以及在β测试这类的测试发布中被抓获的。（微软是在一种产品的最终的公开发行之前发现并更正这些错误的）。
对于一组特性项目，错误率资料表明在逐年的产品发布中，一级错误比重呈现下降趋势。比如，Mac Word4.0在1989年4月出品时一级错误率为。14Worksfor Windows2.0在1991年9月出现，其一级错误率是。15Money2.0是1992年8月发布的，其一级错误率只有10.2%。16软件开发方法的改进为这一趋势提供了一种可能的解释。
经理们也愿意看到较高级别的严重错误率能通过产品的旧版换新而下降。例如，较高级别的错误率——1级、2级或3级——在Mac Word4.0和Mac Word5.0间就略有降低。如果该项特定产品的这一势头持续下去，那就说明开发者们以一种错误倾向较少的方式增加或改变了特性。
现行测量标准的局限微软的现行测量标准只是一个最小的（或可能是超小型的）集合。它们需要包括用于更深层过程与产品的测量标准，那是有助于在发生之前预测和了解多种问题的，从而项目就能有更多的前导时间以预防问题的发生或至少为应付它们做点准备。一些公司，诸如摩托罗拉、惠普（HP）、NEC以及东芝，已成功地把测量标准运用于这些更深层目标的完成上。然而，麦克·梅普尔斯认为，与他们那些正式计数的公司相比，微软发现并修改了更多的错误：“对于KLOC（上千行的代码的测量标准），我唯一的保留意见是我们并不像那些追求它的人那么严谨。在每KLOC的错误上，我们并未记录下开发员在设计检查以及写代码中发现的所有错误。现在，作为一种观念，我们要在项目中推动更多的识错尽早完成。零缺陷以及许多方案在促使项目的错误提前出现，可我们的计数方式又使得发现的错误看起来少了。”
而且，即使微软收集、使用了一系列的测量标准资料，各项目仍依赖于许多公司并未数量化为测量标准，而是在实际经验中形成的主观规则。戴夫·穆尔曾试图使用测量标准和对历史资料的收集来抓住这些主观知识，但他遇到了来自一些开发员和经理人员的阻力，他们以各自产品或项目的独一无二或存在区别而予以辩驳。克里斯如此评论了这一挫折：
我们所遇的问题之一是虽然掌握了大量经验性信息，可那在[个人]相互间的传播却难乎其难。你看看克里斯（彼得斯）和其他一些推出了许多知名软件的人的各种事例，他们只熟悉自己的那一摊要他们把知识变成一种能广为传播的形式真是太难了。所以我们只好以给克里斯的谈话录像而告终，可那毕竟不够完善。克里斯，说吧，到底什么事启发你考虑到这还不能出品？那是测量标准，那是“我看过[错误]表了，在我看来它有问题”。为什么看起来有问题？这就因为有人只给出纯粹的经验性[信息]，却没有作为测量标准加以指明。
以测量标准为基础的过程改进年，麦克·梅普尔斯创造了一种新的组织结构，把大家召集起来集中全力于过程的改进和功能组内部的训练。他推选了克里斯·威廉斯担任产品开发主管和新结构的负责人，后者曾在谈及软体开发需要更加系统化时直言不讳。威廉斯38年前毕业于保龄·格林大学的计算机科学专业，在微软收购FOX软件公司时他是该公司的开发经理。赴新任之前，他在做编译程序的开发工作。
组织重建后，所有的功能主管现在都向威廉斯汇报，其中包括测试、开发、程序管理、用户培训和内部工具的各位主管。培训经理（他负责的组共有14名微软职员，另加一些外部承包商）和使用测试经理（他负责一个30至35人的组），也需向威廉斯汇报。（向威廉斯汇报的总人数大约有100人，包括需要用特殊语言的中东产品开发组）。威廉斯认为此次重组旨在改进知识传播，自我检查和不同组间的互相学习。由于产品组合正试图共用更多的构件，因此这些目标已在微软占据了新的重要地位。项目现在需要预测进度，并生产出高质量产品，这既是为了外部客户，也是出于彼此互利。他们再不能只为各自所需或自己的那部分用户创造尽善尽美的产品了。
我想，戴夫[穆尔]、我和其他一些人均已承认的主要一点是我们的开发过程一直对创造卓越产品的过于关注以至于在某些情况下，我们被驱使着，付出的代价是没能力求采用一个利于控制过程的行动步骤。有些组在这点上显然比其他组要好，可多数却缺乏连贯。我们没能促进组间的相互支持或共同吸取各自教训。所以我的工作焦点已转向试图促使人们所获的知识尽可能多地在小组间流动，并让人们更多地自我检查各自的行为方式，这会使他们干得更好。我们这儿聪明者云集，只要指明最可行的行动步骤，他们就能妥善行事。但在过去，这种优先次序的考虑一直是力争在最合适的时间把最可能好的产品打入市场。鉴于公司日益变得构件多元化、相互依赖紧密化，我们逐渐认识到掌握一些通行的做法和行为步骤是何等重要！
以过程为中心（而非以产品为中心）的事后分析作为过程改进这一创新的部分成员，克里斯·威廉斯、罗格·舍曼、戴夫·穆尔和另一些人正着手改进为技术开发员和项目经理们设定的测量标准。尤其，他们看出需要建立更多的过程测量标准以解释为什么一个项目在进行中出了问题，而不仅限于说出了什么问题。另外，威廉斯和其他经理计划改变的一个情形是：各项目有时不能使用同样的术语或不能在定义上保持前后一致。（比如，微软并不真有一个通用的定义能解释“代码完成”这一关键的阶段性术语。）威廉斯和他的小组还试图调整和扩展项目事后分析过程，以便并入更丰富的测量标准资料，包括对新资料的收集以及相关的现存资料的共享。最后，他们希望能用测量标准资料在全公司范围内定义和交流衡量基准，从而取得最好的开发方法。
威廉斯尤为急切地要把事后分析过程提高到一个新的水平上。各组在把各自问题编入分析报告方面工作出色，可事后分析经常只是很简短地分析一下为什么会出现问题，哪些解决方案是可行的。而且，单个的各组并无一个持续的合适过程能确保在将来项目中不重蹈覆辙，各项目间也不存在一个系统方法可用于互相学习。比如，威廉斯观察到几乎每个组的每份事后分析报告都提到了由于小组成员不断加入新特性致使进度失控的问题。
你去他们中间总会发现一句耐人寻味的“我这里失控是因为我没能关紧特性的闸门”，一贯如此。我们总是一遍遍地吸取同一教训，这很惨痛。我想在某些标准下，事情就是这样的。而用另一种标准衡量时，我们做的估计工作很糟，导致了我们实际行事时要花些时间在额外添加的特性上，这同样是在做糟糕的工作戴夫[穆尔]做得很不错的事情之一是让人们看清自己的事后分析过程以及他们是怎样行事的。人们在对如何做和什么能做得更好进行检查的事后分析阶段一向工作出色。我们唯一的问题是他们没有把再评估、建立新的优先次序和工作推进拢入一个循环他们说我们将来会改变这一切，可没人说从现在起我们就要改变它，也没人停下来思虑一下6个月以后——到那时你改变它了吗？事后分析只是人人脑海中都已有的短语罢了。每个人都知道其含义是什么，每个人又都指望花些时间这么做。我们只想较少关注发生了什么，更多注意怎么发生了。你怎么会失控？并不是“当我需要一份错误表时，该死的家伙从不给我，”而是“为了确保你需要错误表时就能得到，哪个环节出了问题？”事后分析的问题就是在你自始至终地按照自己的方式工作于开发过程中时，事情处理并非有条不紊。而那正是我们希望去控制的现在从一份事后分析中所能获得的大多是无病呻吟。
戴夫·穆尔同意这种对事后分析的意见：“关于事后分析问题的全部就是这个东西是好的，可人们一遍又一遍地抱怨着同一个问题。大多都是这类事情。许多情况下只要做一件事：一吐为快。好了，把心里话说出来了；再去试着做些改进。那就是用在事后分析中的一些做法。无疑，我们也要改进事后分析的其他环节。在向下一次发布的过程中理应做出改进的。”
最佳做法的衡量这一想法与包括过程审计的事后分析的观念是有联系的。比起写一份事后分析报告，它花的时间要少些，但能创造出一系列易于共用的技巧清单。为了做到这点，威廉斯、舍曼和穆尔一直在设计一套有关最佳做法的衡量基准。（例如：“开发中随每次发布会产生一份详细的测试发布文件或相似文件吗？”“你是否在第X阶段估计了将检查出的错误数目？”“你检查了你的特性表了吗？”）这些可用作过程审计的基础，并在某一项目——比如第二阶段后，为进行衡量基准的部分分析提供一个实施框架。这还能较早地提供一些过程中的或“先导”性暗示：这个项目是否遇到了麻烦。完整的衡量基准方案能检查每一功能的内部运作，比较不同组的做法，并把微软的绩效和外部过程的衡量基准绩效标准做对比；这可能包括软件工程协会和国际标准组织，或行业客户的满意度资料。威廉斯这样对目标做了解释：
我们正在努力开发一种过程评价系统，那非常适于我们的开发过程。这是截然不同于你和那些卖主或供应商的普通咨询关系的。我们把它叫做我们的技巧衡量基准程序。我们正在发展一套开发方案，覆盖全过程人们应非常关注我们想把事后分析作为自我测量的一次机会。你怎么能与我们已获得的迄今为止的最高智慧背道而驰呢？我们认定这会演变成一套标准。我们的目标是到那时展示一些相当具体的测量标准我们可能最终会形成250行左右的[指导纲领]。
威廉斯将强令各组进行衡量，但他是从那些表现出一定兴趣的项目开始的。如果衡量基准的努力成功，威廉斯将会有一套他正想用于小组的测量标准，以使项目管理更有效，相互的学习也更系统化。然而和在他之前的戴夫·穆尔一样，威廉斯也料定会遇到阻力，尤其他成立的新组正尝试一种更广的，试图对项目如何组织和管理自身产生影响的创新：
我们最感兴趣的并不是把这变成个急转弯，而是要鼓励自我检查我最后想的事是人们普遍参加进来，就像都要进行一次牙齿检查。所以我们要做的第一步是针对那些对此有兴趣并已明确表示的组。之后，我的计划是向各组兜售。而且我认定到那时一些组已能发现其价值所在，并在和其他组展开讨论，于是其价值将有目共睹，迅速增加我内心的感觉是，75%至80%的组会判断出这是有价值的，并想这么做。在18个月或两年时间中我们将实现目标如果没有能力把该方案和测量标准联系起来，我想它必遭惨败。我绝对相信“你所不能衡量的，你就不能控制”。在我看来，我们并不必急功近利，对所有的事都一追到底，可我想我们在以一种连贯的方式集中追踪一些事情上做得并不好——比如每开发员每周的错误我现在正力争改进的事情之一就是检查工作太低劣，无论是估计的还是实际的，尤其时间耗损不起。所以，举个例子，一个开发员会说：“我想那要花我三周时间。”可4周半搭进去了，我们照说不误：“你做好了吗？”而他也照答不误：“快了。”终于他完成了，我们只会叹一声“唉！”却不会停下来问：“哎呀，那可花了你4周半。为什么？哪儿出了问题？你遇到的是哪方面的困难？”——太糟了。
罗格·舍曼在1993年成为测试主管，他尤其关注写出过程文件，获得好的做法。在1988年至1989年间，只有几个组遵循梅普尔斯初入微软后的要求（见第1章）。舍曼在欧伯林大学学习了计算机科学和音乐之后于1988年加入微软。他先是在波音工作，后才作为一个用户软件测试员进入微软；他的组在1988年曾就他们的开发和测试过程写成文件，但对材料的处理却未跟上事态的发展。舍曼现在也正在留心要明确规定一些通用术语和测量标准，以便微软各组能更持续地从不同项目中学习，并制定一个标准过程好让他们能一起工作，共同改进：
我们正做的是要用最通常的术语写一个文件，包括所有这些产品的最新版本。然后我打算把它带到微软的开发圈中，说：“我希望大家都同意，以此作为将来我们开发产品的标准途径。”现在有两件事相当重要。一是，我最想搞出一整套标准化术语，这样，即使我们在多元化产品上放弃测量标准时，还能做合理比较。我认为这是微软拥有的一个战略优势。我进行的开发项目很多，由于这些项目的案例丰富，我们能更迅速地了解到什么是有效的，什么做起来却不灵。但如果两组在“代码完成”的定义上都完全不同，那么所有你统计的资料都会很糟。第二点是我想有一个标准的现成的过程。我不想这个过程一成不变；而希望人们用它去实验。当他们做不同事情时，我希望他们记录下做的是什么，以便我们能有区别地予以追踪。如果这工作起来更有效，则广为宣传或变为标准供大家遵守。我想能看到这变成技巧文录它不是官僚化的、负担一样的东西，而能紧跟事态发展，把我们所知晓的最好的做法都收录进去。
原则三：视客户的支持为产品的一部分和进步依据除了尽力从内源——公司项目——多加学习外，微软最近还千方百计地从外源学习：即它的数以百万的客户们。客户可能成为信息的无价源泉，所以现在他们有很多机会直接向微软的开发组提供信息反馈。例如，程序经理们所要分析的既有以行为为基础的计划资料，又有来自客户“希望热线”的信息和每月对客户电话分析整理而成的“电话分析报告”。程序经理和开发员在项目期间需要在微软的可用性实验室里测试样品；各项目还提出各自产品发布一个α版，以供内部使用和提供信息反馈。紧接着会对选定客户进行一次对外的β发布以作为实际测试。之后，开发员将在这些反馈信息基础之上，赶在最终产品向制造商或市场发布之前，做进一步的完善。
甚至微软的产品支持服务（PSS）部门也利用可用性实验室来做它所称的“支持能力测试”。这是要检查支持一项新功能的难度有多大，并用诊断问题的不同方法来试验。当一个新产品推出后，微软就把开发员和测试员们安置在PSS的热线电话旁，并与来自公司不同支持中心的PSS人员一起参加“情景屋”电话会议。这些做法都给开发员和测试员提供了机会去亲自听听什么问题让客户抱怨不止。PSS还会就客户对微软产品、客户支持及公司整体的满意状况作实际调查。除此之外，它也和营销组合作研究客户使用微软产品和竞争对手产品的情况。微软甚至发布了其产品的“工具版”，它能跟踪每一次键盘敲入和鼠标的按动，从而作出用户实际使用产品的电子记录，这个循环会不断重复。
这一系列连贯的活动可清楚表明——微软在1990年以前并未系统遵循——客户支持和客户信息反馈已和产品与开发过程的改进紧密结合起来。其好处有两个：减少支持成本，并通过创造出更多的对产品满意的客户而增加销售额。微软1993年提交的一份质量奖励申请书描述了这一客户支持哲学：
微软的支持哲学强调每一次客户支持活动都是改进产品设计的机会——相应地，我们会用更便于使用、更无需产品支持组织关注的产品回报客户。正像微软已在实践着的，这种客户驱动法在产品设计上的应用改变了软件开发循环的目标。以前，开发员们关注的焦点是“计算机设计”目标——如果没有额外编码就能完成很出色的设计，他们会感到心满意足。现在，只有当他们完成的特性制作使客户初次使用就能理解时，他们才会满意在微软，完成可用性改进首先要做的是了解用户面对的工作任务是什么，以及他们是如何使用软件来完成它们的。这些资料能帮助决策在新的或升级的软件上设计哪些特性组。PSS成员组在信息收集过程的每一个阶段都和产品开发员们一起工作，利用那些通过与客户接触得到的资料，并在特殊的测试与分析中提供协助。
产品支持战略和组织微软曾有着一种对客户反应较为冷淡的公众形象。它发布过的一些产品很不好用（比如MS-DOS与苹果的Macintosh操作系统相比），对某些类型的用户来说既慢且制作粗糙（如Macintosh Word6.0）。但它总算已从不太注重客户支持的坏名声下逃出来了（至少敢于和Word Perfect比较了，该产品以免费电话线提供的无限制的且频繁而出色的支持而闻名）。理查德·巴斯——Windows NT的高级产品经理——曾回忆起往日的情形：“如果你是个寻求支持的客户，那么想想3、5年前你所忍受的一切真是可笑。你只能在规定的几小时内给我们打电话；你不大可能或根本不可能找到几个人，谁知道他们究竟在干什么。我们是有些人非常有天赋，可这对本行的任何人来说都算不上是优势。”
产品开发期间的客户投入在微软，这种状况随着1990年里Windows3.0的引入开始改变，而1992年Windows3.1则强化了这一变化。新的Windows操作系统和新的Windows应用软件的出售量数以百万，其中数以千计的客户开始带着各种问题每天给微软打来电话。另外，微软当时正处在从主要对计算机硬件制造商出售软件向通过零售商主要销给单个客户的转变过程中，而个人用户购买软件后更有可能需要软件制造者的支持。市场研究还表明，和以前的大型计算机与小型计算机客户一样，PC（个人计算机）用户越来越多地视来自软件供应商的支持为软件产品的一部分。为了保住这数百万的新客户，微软不得不改变做法。
一种变更方案是循着Word Perfect（它现在为Novell所有）的路子，建立起一个庞大的组织以便更快、更有效地回答电话询问。另一种变更方案是着力于更加系统地从电话交谈中获取信息，并把这些信息和其他客户材料传给开发组织，从而制造出更易于使用的产品——以此减少客户打电话的需要。第三种方案是要提高处理数目日增的电话的效率，比如通过使支持过程尽可能自动化或以收取不同的费用来打消打电话的念头等等；还要制定出更确定的打电话期间，并帮助为支持运作过程提供资金。
事实证明，微软对这三件事都愿意做。比尔·盖茨带了头：他曾在一次“每周反思会”中（后形成了一份备忘录送往微软执行经理部门，并被泄露给了新闻界）总结认为，微软再也经不起因忽视客户而付出的代价了，它必须改进其支持政策和组织。他还向公众许诺他的公司将为新的Windows产品提供更好支持。与此相适应，微软增加了回答电话的员工人数，此举实在意味深长。其增幅是从80年代中期的20几人到目前的仅美国国内就有2000多人（差不多5个微软雇员中就占了1人）；另1000个支持人员分散在海外36个国家工作。微软还通过产品组组织起电话技术员，总的说来，他们要支持大约200种产品。毕业于威斯康辛大学的MBA、产品支持服务部的前任营销主管特瑞希·梅曾回忆过微软经历的这一转变：
我要说的转折大约发生在两年半以前其表现有两点。一点是[当]比尔在一次论坛上公开陈述说支持是我们事业很重要的一部分，我们将保证在你打电话咨询微软Windows产品时——即使此刻是Window3.0的发布时间——你也能确切得到高质量的支持。另一点是比尔关于他的“比尔每周反思”所写的内部备忘录，不过最终还是到了新闻记者手里。其论点之一是他要在产品支持上进行投资，那曾是事业的重要部分，并将继续扮演重要角色我们的研究表明那的确是不可或缺的一部分。所以大约两年半前，我们增加了投资数目，并建起一个管理组织以关注我们如何才能推进这一转变，这些是很有意义之举。
梅承认这一新战略有两大基柱：一是使产品更便于使用，另一个是建立起支持组织。后者包括采取积极行动、尽可能地实行自动化；并通过向客户提供更多信息——比如以CD-ROM盘的方式，使他们能自己解决更多的问题。梅说微软仔细研究过Word Perfect，但并不想模仿它免费奉送式的支持组织：
这一战略有两个部分。一是减少我们最终接收的电话数，方法是设计一个用户界面以及可提前输入问题的产品，并利用支持和文件的提供来减少问题数目。而另一战略是用颇有意义的投资来确保我们所提供服务的高质量。所以我认为对此要同样强调。例如，我们已经看过了Word Perfect管理支持的办法，并正从中学习。但我们还要研究一下你怎样才能最有效率、最有效果地提供高质量支持。促成满意的标志是什么？因此，用一下投入——产出模型，让我们看看影响有哪些方面，你能从何处获得客尸满意度测试最有效的信号，然后对模型加以微调。我们的目标是，对花出去的每一美元，你怎样才能做到最有成效地利用电话？
对比现在的一对多式电子化服务，你来看看两年前被称为一对一的事故处理法吧，我相信我们所遇事故的80%是由员工在电话上处理的。而今天只有50%的事故由员工解决。其他50%是通过专题讲话、我们的Fast Tip（快而通）服务、布告栏及其他电子媒界以电子化形式解决的，这使得我们以较低成本扩展了接触客户的范围。所以我们在投资于解决如何提供服务，什么是接近更多客户的最有效益方法的问题方面是很有意义的。
电话信息及其处理正如比尔·盖茨在他关于产品开发中的公司力量中所说（见第章），微软接到的数不胜数的电话为分析客户需要及困难提供了绝好机会。微软每天大约会收到6000个“事故”询问——4000是通过计算机或按钮式电话发来的电子质疑，另2000个电话是由支持工程技术人员予以答复的。平均来说，每售出3个产品单位或“盒”就有1个电话，这比起几年前微软所经历的每1.5或2个盒就有1个电话可谓是进步显著。打进PSS的电话平均每个历时12分钟：支持技术员花5到7分钟诊断问题所在，2、3分钟讨论一下解决方案，另花1、2分钟结束谈话。回答问题的耽搁时间在1991年是4分钟左右；到了1992年-1993年间，则下降为1-2分钟，虽然当时电话数目翻了一番。而现在微软对80%的电话能在不到一分钟内做出答复。18对电话模式的详细分析为如何改进产品，最终减少电话提供了许多有用信息。这些信息还启示人们如何给服务定价以打消打电话的念头，或至少让电话需求更为确定些。