依靠改进特性与固定资源激发创造力在产品定义与开发过程中。微软遵循着一种战略，我们称之为靠改进特性与固定资源来激发创造力。我们把该战略分成五个原则来讨论：
·将大项目分成若干里程碑式的重要阶段，各阶段之间有缓冲时间，但不进行单独的产品维护。
·运用想象性描述和对特性的概要说明指导项目。
·根据用户行为和有关用户的资料确定产品特性及其优先顺序。
·建立模块化的和水平式的设计结构，并使项目结构反映产品结构的特点。
·靠个人负责和固定项目资源实施控制。
微软定义产品与产品开发过程的方法并非特别新颖。有一系列公司都使用相似的渐进开发法，如计算机硬件销售商（惠普与DEC），计算机系统集成商（EDS与SAIC），航空航天与国防承包商（TRW与Hughes）以及电子设备制造商（Motorola与Xerox）。然而，微软在制定产品与产品开发过程战略以支持其竞争战略方面显得尤其成功。
微软力求开发面向广大市场的产品，并设立了实事求是的标准。它的产品开发期与生命周期相对较短，这些因素都产生了非常巨大的影响。产品开发计划既要紧凑，又必须灵活而有弹性，开发过程还必须尽快往前进行。最新的工程方法或工具只是第二位的。在变化较慢的市场上，公司可以在开始写程序代码之前，先构想出一份详尽的产品说明，然后“锁定”该说明及相应的工作进度安排。微软的软件开发组更多的是平行展开工作，正如克里斯·彼得斯所解释的那样：“我想，在变化较快的商用软件市场上，开发过程是各不相同的。在整个开发过程中，所有的事情都在平行地进行。每当你有了一个‘产品说明’或开始按工作进度表办事，随着测试项目被重新定义，产品说明马上会被更新，工作进度也会相应更新。所有这一切都以尽可能快的速度往前赶，你永不停息。”
首先，微软的开发小组努力了解用户的需要，再把这些需要分成一个个单独的特性，然后他们给予这些特性不同的优先级，把它们再分配给子项目，这些子项目则将整个开发项目划分成了3-4个里程碑式的重要阶段。为了在产品开发过程中激发和凝聚创造力，微软的经理努力“固化”项目的可用资源——限制任何一个项目中的工作人数与可用时间。这样，固化的项目资源就成了项目开发计划中最关键的规定因素，尤其是其中的预期出品时间使得整个开发小组充分凝聚其创造力与努力工作。开发小组必须按照反推法自己规定由出品日回溯的中间步骤和中间阶段，同时与其他微软项目、产品批发商以及第三方系统集成商协调产品的交付。这样，即使预定的出品日期时常改变，项目也能实现这些目标。
然而，对应用软件产品和与之不同的系统软件产品，微软在使用这些定义产品和产品开发过程的原则时有一些不同。应用软件产品，如Word与Excel，或是消费型软件产品，如Works与Complete Baseball，比起系统软件来（如操作系统软件），往往开发期较短，开发组较小，对出品日的估计也比较精确。而新的系统软件可能有许多新的功能，需要数年和数百人来规定、开发与测试。例如，为了开发Windows NT的第一版，微软用了4年多时间，最多时开发组里有400多人。而Excel5.0只用了18个月，开发组也只有100到125人。许多应用软件产品，像Excel与Word，往往已经是第“N”版了（而非第一版），这使得这些产品的开发周期更有规律，也使估算今后的工作进度更为方便。
在功能方面，系统软件往往更多地有一组不可分的“核心”功能，在产品包装出品之前，这组功能必须被完成并表现得可靠（即“稳定”）。为了加速产品的出品而从操作系统中删去一些未完成的功能会非常困难。开发和完善一组能正确和有效执行的核心职能，是发行像Windows NT与Windows95这样的系统软件的最强动力；出品日期这个目标被排在第二位。应用软件和消费型软件往往有更多的独立的特性，在项目进行时可以加减这类软件以适应竞争的压力、资源的限制以及出品日的安排。因此，在生命周期的早期阶段，系统软件产品的想象性描述与说明文件要比应用软件完整和详细得多，目的是为了规定好核心职能组以及特性之间的相关性。
系统软件产品往往测试期也较长，包括广泛的β测试。这是因为它们需要更强的稳定性以及与众多的应用软件、网络系统、计算机销售商平台，诸如打印机这样的外设的兼容性。应用软件往往有较多的独立功能，产品间的相关性较少。现在由于强调软件之间的共享性（如Office套装软件），这一点已有所变化。
微软越来越多地运用共享或通用构件来构造软件，这已经开始改变微软应用软件的结构。应用软件曾是互不相关的产品，但它们正变得越来越组合化与可以共享。举例来说，项目现在可以灵活地往不同的操作或单独的“线程执行过程”加入内含OLE的构件。这些构件可以向用户提供特定的功能包，如绘图、打印或数学计算。用户也可以综合来自不同产品的功能和信息对象——比如，写一封含有图形和电子表格数据的书信。
决定应用软件产品需要哪些功能的往往是市场营销人员和程序经理，而不是具体的程序开发员。他们使用根据用户情况建立模型的技术制订计划。具体开发员在系统软件的功能上则更有发言权。部门内部的各开发组也有差别。虽然微软对小的消费型软件的管理不像对那些作为收入主要来源的大型软件那么管理紧凑，但他们彼此之间却非常相似，如Excel与Word。在系统软件和计算机语言领域，一般说来，Windows NT就比Visual Basic或Windows95被更精心地组织和管理过。不过，应用产品与系统产品在微软还是有许多相似之处，部门内的产品开发单位也是如此。我们在以下各节中所写的大部分对这两类软件都适用，对微软制造的所有重要产品也都适用。
原则一：将大项目分成若干里程碑式的重要阶段，各阶段之间有缓冲时间，但不进行单独的产品维护在今天的微软中——尤其是与80年代相比，人们虽然力求更现实些，然而在进度安排上他们仍旧雄心勃勃。一个项目的进度安排具有灵活性，但同时也提供了项目内外互相依赖性以及一种高度组织化的预期交流机制。典型的桌面应用软件项目，如Office、Word或Excel，新旧版本大约只间隔12到24个月。微软正逐步对应用软件产品轮流使用12和24个月的进度计划，其中，12个月的周期只增加小特性，24个月的项目进行重要的特性与结构的变化。对同一种产品的两种进度安排可以同时开始，在最初12个月齐头并进，这样微软就可以每12个月提供一种新版本。
然而，重要的新操作系统产品，如Windows NT或Windows95，可能需要3到4年的进度安排。微软的管理人员并不是一味地在一个12到24个月的典型项目中投入得越多越好。他们要努力弄清在一个新的开发项目上，到底有多少时间和人员可用。他们也考虑了未知的变化与困难，确定项目的规模使之与时间和可用人员相符。这样，微软的项目进度表由计划阶段与若干循环过程组成，每一循环包括产品的开发与发布，测试与稳定化以及为意外事故准备的或在重要阶段连接处安插的“缓冲”时间。每个项目都有自己单独的进度表，但微软已经越来越强调产品之间发送安排的协调性。例如，Office有一个集成的进度表，内容涵盖了Excel、Word以及其他作为套装应用软件一部分的产品。
程序经理、开发员与测试员，他们是规定、实现和测试一件新产品的人，同时也是对产品前一版本修改错误、变更并增强其功能的人（这被称为产品“维护”）。并没有一个单独的组从事产品维护。在许多其他公司中，这样的维护工作花去了开发员本可能用于新产品开发的大量时间。与之不同，微软的产品单位创造了产品新版本连续的“发布周期”。MS-DOS出到了第6版，Windows出到了第4版，Excel出到了第5版，Word出到了第6版，如此等等。微软的产品组根据市场营销情况与顾客信息反馈决定什么是产品中应该保持的特性，什么是应该添加的和改变的特性，然后他们把这当作是下一个产品版本的一部分工作来做。下一个版本也可能包含原来项目中由于时间紧迫而不得不砍掉的特性，开发应用软件产品时这种情况尤其普遍。
项目进度安排与里程碑微软的同步一稳定产品开发法（第5章会更详细地描述）始于80年代晚期。这种方法集中了里程碑和每日构造这些关键的概念（为做到“零缺陷”）。从前的项目事业单位于1988年出品的Publisher1.0，是第一个在进度表中使用了里程碑的微软项目；1989年和1990年的Excel3.0是第一个采用此概念的大型项目。其他一些小项目，如Works，大约在1988年到1990年，也采用了里程碑概念。有的开发组在此时期使用了“每日构造”策略，但他们对使用“每日构造”以不断发现和修正缺陷却只有肤浅的认识。1989年在采用“休假会”之后，里程碑与“每日构造”以及更严格的质量控制方法，在微软中逐渐变得普遍了。今天，微软中典型项目的生命周期包括三个阶段。计划阶段完成功能的说明和进度表的最后制定，开发阶段写出完整的源代码，稳定化阶段完成产品，使之能够批量生产。1微软把这三个阶段称为“进度表完成及项目计划被批准”、“代码完成”以及“发布供生产”（用到软件产品上“生产”概念是指磁盘和文档的复制）。这三个大阶段以及阶段间内在的循环方法与循序的“瀑布”式生命周期很不相同，后者是由需求、详尽设计、模块化的代码设计与测试、集成测试以及系统测试组成。2微软的三个阶段更像风险驱动的、渐进的“螺旋”生命周期模型，该模型已日益为软件开发机构所采用。
在微软，计划阶段的产品是想象性描述与说明文件，用来解释项目将做什么和怎么做。在管理人员拟定进度表、开发员写出源代码之前，这些东西都促进了人们对设计问题的思考与讨论。开发阶段围绕三次主要的内部产品发布来进行；稳定化阶段集中于广泛的内部与外部（β）测试。在整个产品生产周期中，微软都使用了缓冲时间的概念。缓冲时间使开发组能够对付意外的困难和影响到时间进度的变故，它也提供了一种手段，可以缓和及时出品与试图精确估计出品日之间的矛盾。若是对现存产品的更新，计划阶段也许只用3个月的时间，但对新产品，计划阶段就可能长达1年以上。在以往典型的项目中，开发阶段与稳定化阶段大约需用18个月，这18个月可以如下划分：
·6一个月的开发时间，一般包含3到4个重要的里程碑式产品版本。
·2一个月的开发缓冲时间，分配到每个里程碑式产品版本中去。
·3到8个月的稳定化期，包括测试与缓冲时间以及用6个星期为最后的版本和顾客支持作准备（完成最后的测试与联机文件编写的目标日期是最终版本投产前约6周；完成印刷好文档的目标日期是最终版本投产前约4周）。
在开发和稳定化阶段的所有时间中，一个项目通常会将2/3的时间用于开发，1/3的时间用于稳定化。克里斯·彼得斯，Office部门的副总裁，曾这样概述通常的进度：“一般说来，在总的进度表中，用一半的时间写出产品，留下另一半时间调试或应付意外事故。这样，如果我有一个两年的项目，我会用一年来完成事先想好的东西如果事情有点麻烦，我便去掉我认为不太重要的特性。”这种里程碑式的工作过程使微软的经理们可以清楚地了解产品开发过程进行到了哪一步，也使他们在开发阶段的晚期有能力灵活地删去一些产品特性以满足出品日的要求。
概括了微软的（a）产品阶段周期，（b）文件或中间产品，复查以及（d）中间的里程碑或某阶段的完成等情况。这些图和以下各节将集中讨论程序管理、开发及测试在产品周期中的角色。提供了一个典型产品周期的综合情况，其中包括另外一些公司职能如产品管理（市场营销），用户教育（创造供顾客使用的文档或手册）等内容。同步——稳定开发法计划阶段：定义产品的想象性描述、说明与进度。
·想象性描述产品和程序管理部门运用广泛的顾客意见来确定和优化产品的特性。·说明文件基于想象性描述，程序管理部门与开发组定义特性的功能实现，结构问题，以及各部分间的相关性。·制订进度表与构造特性小组基于说明文件，程序管理部门协调进度表，安排出特性小组，每个小组包括大约1名程序经理，3-8个开发员，3-8个测试员（以1：1的比例与开发员平行工作。）开发阶段：用3-4个顺序的子项目，每个产生一个里程碑式的产品发送，来完成特性的开发。
程序经理协调开发过程。开发员设计、编码、调试。测试员与开发员配对，不断地进行测试。·子项目Ⅰ前1/3的特性：最重要的特性与共享的构件。·子项目Ⅱ中间1/3的特性。·子项目Ⅲ最后1/3的特性：最不重要的特性。
稳定化阶段：全面的内外部测试，最后的产品稳定化以及出品。
程序经理协调OEM（原始设备制造商）与ISV（独立软件开发员），监督从顾客得到的信息反馈。开发员进行最后的调试与代码稳定化。测试员发现并清除错误。·内部测试公司内部对整个产品做详尽的测试。·外部测试公司外在的“β”测试点，像OEM，ISV以及最终用户处对整个产品做详尽测试。·发送准备为批量生产准备发布最后的“金主盘”磁盘与文档。
资料来源：1993年3月17日对开发主任戴夫·穆尔的采访，以及《进度安排方法学与里程碑之定义》，微软公司Office事业单位内部流通，1989年1月9日与产品管理和用户教育有关的产品生命周期模型产品周期阶段计划最后的里程碑：项目计划批准（包括：进度表完成）开发（3-4个里程碑）最后的里程碑：代码完成稳定化最后的里程碑：发送投产组织的角色产品管理（市场营销）·市场研究·营销计划·想象性描述·定价、升级、包装·β测试点·发行程序管理·想象性描述·设计＆原型特性·写说明·基于行为制订计划·相关调查·创造主进度表·管理项目的执行状况与联系·为找出错误而提供输入·完成后产品之出品可用性试验室测试员·建立可用性目标·考察性测试·循环测试（原型早期代码）·完整产品的测试·基于行为制订计划的方案测试·领域测试·为下一版本进行的测试视觉界面设计组·开始用户界面设计·对用户界面说明进行讨论·确定用户界面设计·建立图与位图·视觉界面设计复查开发组·特性的初步设想与可行性·特性设计·写出并优化代码·产品每日构造·测试与改错·发布产品·测试与改错内部可操作性设计组·通用特性集设计·支持代码共享·商量测试计划·对下一次发布之通用特性作计划本地化组（为美国外版本服务）·本地化计划·建立与批准词库·视觉与功能检验·翻译文件·复查检查运行时之用户界面·小组内测试与调试·印出生产周期·最后的测试软件测试·测试策略·创立测试·运行测试项目组·内部测试·β测试·最后的版本测试产品周期阶段计划最后的里程碑：项目计划批准（包括：进度表完成）开发（3-4个里程碑）最后的里程碑：代码完成稳定化最后的里程碑：发送投产组织的角色用户教育（印刷的文档）·概念上的设计与策略文件·定义专有名词·写出、编辑与创造联机链接·技术复查·确定内容与图形·最后的版面定型·准备与发布给销售商·印刷文档·文档发布投产用户教育（联机文档）·与上同·与上同·确定运行时用户界面的帮助·小组内测试与调试·最后的测试、调试产品支持·收集顾客资料·预测支持成本·找出支持问题·决定支持策略·训练·产品支持服务（PSS）β与估值·对顾客支持资料库的扫描·打电话资料来源：1993年3月17日，对微软开发主任戴夫·穆尔的采访以及微软内部的无标题文件。
计划阶段计划阶段是在一个项目的生命周期中，所有于开发前进行的计划所占用的时间。计划阶段产生出想象性描述、市场营销计划、设计目标、一份最初的产品说明、为集成其他组开发的构件而规定的接口标准、最初的测试计划、一个文档策略（印刷的与联机的）以及一份可用性问题清单。计划阶段从想象性描述开始。想象性描述来自产品经理以及各产品单位的程序经理；它是对产品作出的市场营销设想，包括了对竞争对手产品的分析以及对未来版本的规划。想象性描述也可能讨论在前一次版本中发现而必须解决的问题以及应添加的重要功能。所有这些都基于对顾客和市场的分析以及从产品支持服务组（PSS）处得到的资料。经理们把长期产品计划问题当作三年计划周期的一部分来考虑，这在第1章讨论过。
说明文件从一个大纲开始，然后定义出新的或增加的产品特性，并对其赋以不同的优先级。就像第2章所说的那样，程序经理负责产品说明的写作，而其他一些人，尤其是开发员与测试员，具体撰写该文件。说明文件只是产品特性的一个预备性概览；从开始开发到项目完成它要增加或变化20%-30%。虽然在生命周期的晚期文件说明变化一般较小，但越是到晚期，开发员就越是必须具备充分的理由来作改变。
程序经理用Visual Basic工具创造出大量的原型。他们也开展设计可行性研究以了解设计中的取舍情况，尽快做出涉及产品说明的决定。前程序管理主任约翰·法恩，现任Excel组程序经理，认为说明文件必须把产品特性概括得使普通用户也能用一句简单的话来描述产品：“你发明产品的特性，一个接一个所有都是从用户的观点出发的，那是你应做的一切——抛掉任何其他想法，只思考‘用户看到的是什么？’当你用一件产品时，产品所做的应该能被用户充分理解，他应该能用一句话讲出产品在做什么。从我的观点来看，有一些产品不够好，因为虽然它们有一些相当棒的特性，但是没人讲得出产品做了些什么。”
正如第1章所述，比尔·盖茨和其他高级董事要对重要产品的说明进行复查。至于不太重要的产品，则将该工作交给部门经理去做。概要的说明文件，开发员的时间估计，为测试及文档制定的策略以及顾客支持，这一切构成了项目进度表的基础。盖茨也对重要产品作项目复查以批准项目计划与进度表。在计划阶段结束时，项目所处的状态是项目计划被批准且“进度表完成”。
开发阶段开发阶段的计划对三四个主要里程碑版本都个别分配一组特性，规定出特性的细节和技术上的相关性，记录下单个开发员的任务以及对进度的估计。在开发阶段中，开发员在功能性说明的指导下写源代码，测试员写出测试项目组以检查产品的特性与工作范围是否正常，用户教育人员则编写出文档草案。
当测试员发现错误时，开发员并不是留待以后处理，而是马上改错，并在整个开发阶段内使测试不断地、自动地进行。这就改善了产品的稳定性并且使版本发布日期更易估计。当到达项目中的一定点后（例如，执行了进度表的40%时），开发员就试图“锁定”产品的主要功能要求或特性，从此只允许小的改动。如果在此点之后开发员想做大的改动，他们必须与程序经理以及领头的开发经理商量，也许还要征求产品部门经理的意见。
主要的里程碑版本一个项目是围绕着3或4个主要的内部版本，或“里程碑子项目”来组织开发阶段的。微软希望这些版本能非常稳定。从理论上讲，项目应能做到以之向顾客出品。正如克里斯·彼得斯所评论的：“我们第一次（在大项目上）运用里程碑方法是在开发Excel时。我认为现在所有其他组也在使用了你所做的是把一个项目基本上分成三个部分然后你假装在每一部分完成后都要推出产品。”5开发员也许需要在每个重要版本发布前做一些预备性发布以达到测试组的验收标准，这样才能完成重要的里程碑版本。前任Excel的程序经理，现任Office高级程序经理之一的麦克·康特，描述了一个项目是如何基于重要的里程碑版本工作的：“我们实际上将开发分成三个分离的里程碑。它们也许是6周的，或者是10周的里程碑在里程碑快结束时，我们的目标是获得所有已经在创造的特性，并且对该里程碑而言是无错误的这样，当我们达到了‘出品质量’时，我们就能向下一个里程碑前进。关键在于这样一来，我们就永远不会让事态完全失控，不会在项目快完成时由于有成千的错误以致完全说不准何时能真正完成项目。”
项目大约用2至4个月来开发每一个重要的里程碑版本。每一个版本都包括其自身的编码、优化、测试以及调试活动。项目为意外事故保留总开发期1/3的时间，这就是保留给每个里程碑的“缓冲时间”。举例来说，Excel5.0的开发阶段中有三个主要的内部版本，每一个都是为时13周的里程碑。起初的进度表规定在每个里程碑内，用8周开发，2周集成（确保不同的特性能在一起正常工作）；Excel组还为每个里程碑分配了3周的缓冲时间。该组在第一个里程碑处没有用完所有的缓冲时间，于是项目就为第二和第三开发期各加了1周，使之有9周开发时间。然而，第二个里程碑后，Excel用尽了缓冲时间，主要是因为在转换Macintosh机器上使用的编译时出了问题。在第三个里程碑处，缓冲时间不够了，开发员需要额外的6周，这主要是因为Excel依赖OLE与用于应用程序的Visual Basic（VBA）。OLE晚了6个月，VBA晚了8个月，这都使Excel5.0以及Word6.0增加了复杂性Excel5.0主要内部里程碑预计的和实际的进度表主要内部里程碑预计进度实际进度里程碑Ⅰ8周开发2周集成3周缓冲8周开发2周集成1周缓冲里程碑Ⅱ8周开发2周集成3周缓冲9周开发2周集成3周缓冲里程碑Ⅲ8周开发2周集成3周缓冲9周开发2周集成3周缓冲总计39周6周延迟45周资料来源：与Office开发经理乔恩·德·沃恩的会谈，1993年4月15日与1994年9月29日。并延迟了出品。正如麦克·康特所评论的：“是啊，我们本打算在9月27日出品，但事实上却拖到了12月22日，晚了3个月。VB与OLE对我们而言是个大问题。”
再举一个例子。Office的开发阶段有4个主要内部版本，开发阶段与稳定化阶段共占21个月。第一个里程碑版本是结构定义子项目，经理们都把这看作一个特例。其他三个里程碑子项目每个长16至18个周；每个子项目在开发和缓冲上都用相同的时间，然而对每一次集成都逐次增加一周时间。系统软件产品、消费型软件产品以及在研究部门中创造出的新型软件（如Tiger视频服务器），都遵循着相似的过程。然而，它们在产品的性质以及面向的顾客上是有一些区别的。布兰德·斯尔文伯格，个人操作系统（Windows/MS-DOS）的高级副总裁，概述了系统产品需要的四类里程碑的完成，并将微软的渐进开发法与他在苹果和Borland公司所获得的经验作了比较：
当我们到达里程碑时，我们不光是开发了功能，而且要符合产品规格、性能以及质量方面的要求这就是说，当我们成功地加上了那些功能后，我们并未到达里程碑，我们是在实现产品性能目标，达到某种水平的质量后才能到达里程碑。如果我们在前一个里程碑处放松了一些产品性能目标，只注重把那些功能开发出来，那么在下一个里程碑处，产品的规格与性能问题就将优先于功能问题。然后在随后的里程碑处，产品规格与性能问题又只是增加功能时附带考虑的问题如果说我们在苹果公司中的做法是保守的话，那么这儿的做法与之不同。[苹果的]小组是割裂的，独立的，各自开发各自的东西。在还有3个月就要出品的时候，你才会说：“好了，让我们把一切集成起来。”Borland公司是把工作分成许多小的部分，并且总是让开发的东西能够运转，这是种渐进式的哲学看起来似乎这种渐进的方法费时较长，但实际上几乎没有用过很长时间，因为这使你总是能掌握住事情真实的情况。
外观固定，特性完成以及代码完成当对最后一个主要的里程碑版本做了测试与稳定化之后，产品就要进行“外观固定”。该短语系指产品的主要用户界面构件——诸如菜单、对话框以及文件窗口将不再有任何进一步的大变动，虽然小的改动在所难免。项目采用外观固定是为了方便用户教育组编写产品文档。当产品功能齐全且测试员能在上面运行测试方案的时候，产品就“特性完成”了。在此时，一件产品还不能说是基本上稳定了，它可能还有许多错误，还需要在速度和内存的使用上大幅改善其性能（称为优化）。当产品“代码完成”时，开发阶段才最后结束，这意味着所有的特性都能按说明中和用户文档中规定的那样工作，除了调试与随机性的优化之外，没有什么工作剩下来了。例如，当Excel5.0代码完成后，乔恩·德·沃恩，以前是Excel的开发经理，现为Office开发经理，又用了两个月的时间重写完成得不好的代码。克里斯·彼得斯有一个决定项目何时能到达“代码完成”的粗略的经验估计法：
对一个30-40人的项目来说，代码完成不容易定义。例如，如果有人用了三天来修改一个错误，他们实际上是在写代码，他们就没有“代码完成”这样，实际上发生的情况便是，当你赶着完成项目时，错误的数量也增多了。然后，当人们真正注意修改错误时，你会到达某一点，从此点以后到出品日，错误的数量每天都在减少。在那点以后的道路对你而言绝对是越来越轻松的。当这种情况发生时，你就知道你已代码完成了这是不容置疑的。
稳定化阶段稳定化阶段着重于对产品的测试与调试，向产品发布不断推进。项目在稳定化阶段尽量不增加新的特性，但如果出现了竞争产品，或其他市场因素改变了的话，也有可能增加一些产品特性。微软的测试过程被组织成一系列的阶段，每个阶段比如说是4个星期。测试员与开发员不断地寻找并修改错误以尽可能早地为产品的发送做好准备；稳定化阶段也包括缓冲时间以应付不可预见的问题或延迟。一个项目将其产品最后一个主要的里程碑版本分发给各种各样的测试组，有微软内部的，也有微软外部的。外部测试组（称为β测试点）包括个人用户，大的公司顾客，独立的软件销售商以及批发商。当进行了广泛的测试后，没有发现严重的错误，并且项目经理决定在下一开发周期再修复所有剩下的已知错误时，“零错误版本”就产生了。开发员于是生产出一份“金主盘”，将之发送投产。微软就从这份拷贝上生产所有其他拷贝。产品发送投产后不久，项目小组一般再写一个事后文件——一份广泛的关于项目中什么工作做得较好而什么做得不好的总结。（在所有的项目中，一半到2/3的项目实际上写了该报告，长度从15页到上百页不等，第6章对此有详细论述。）项目进度表中的缓冲时间微软使用缓冲计划，以在最高的效率与较好地对未来作预计之间求得平衡。这种应付突发事件的时间在开发和稳定化过程中是每一个主要里程碑的一部分。缓冲时间主要用于弥补由于对特性的不完全理解，或是技术困难或是由于疏忽而忘记把任务写入进度，或是未料到的难题而形成的漏洞。问题常常出在关联项目的拖延上，或是需要时间协调事先未计划而又在不止一个产品间共享的特性改变等方面。缓冲时间有助于一个项目适应意料之外的事件。就像克里斯·彼得斯回忆的那样：“当我们最终开始按时出品时，我们做事的一个秘诀就是终于将缓冲时间纳入了进度表。缓冲并非‘懒惰和愚蠢’，而是为了应付意外事故的发生准备充足的时间。你并不知道未来的一切，只要你承认你有不能完全预测未来的麻烦，你就应该在进度表中加上缓冲时间，这样按时出品就很容易了——如果你有魄力砍去特性或缩小特性规模的话。”
项目必须把缓冲时间完全用到不确定事件上去，而不是在日常的或可预见的任务，像特性开发，测试，或文件复查上运用它。项目小组也使用内部的产品里程碑作为他们的目标，而且不将此算入缓冲时间。这样，由项目领头人与开发小组商定的内部里程碑，像“里程碑Ⅰ版本”，就反映了主要里程碑减去缓冲时间的日期。内部里程碑名副其实，只供职能组内部使用，并不出现在印刷的小组进度表上；项目小组外的其他单位使用印刷的进度表作出他们的进度安排。在应用软件产品中，典型的缓冲时间占进度的20%-30%。彼得斯证实了这一点，“在Excel[3.0]的开发中，我们把进度的20%安排成缓冲时间，我认为这也是现在处理该问题的做法。”6因为系统软件产品进度相对较长且特性集相对不可分，这些项目一般需要更多的缓冲时间。说服传统的项目经理，使之明白大量缓冲时间的必要性是困难的，因为他面临着缩短产品开发时间的压力。然而，微软却经常在其项目中运用缓冲时间的概念。布兰德·斯尔文伯格描述了他本人对系统软件产品“50%缓冲规则”不可动摇的信念及来自高级经理的阻力：
许多时候开发员天真地说：“那东西用一星期就可以完成，”于是你就相信他，只安排一星期时间。我们已经学到了怎样更好地问开发员问题来控制任务的执行，以及怎样把缓冲时间注入进度之中。在过去，许多人不在进度中包括缓冲时间。我在职业生涯的早期曾遇到过这样的情况。当你将包含一些缓冲时间的进度表呈送给总裁时，他说：“什么，你们这些家伙要出去钓鱼还是怎么的？你们在那缓冲时间里要做什么？”“这个，根据经验，我们需要缓冲时间来修改错误。”“是吗？
确切地讲讲你们要做什么？”“好吧，如果我能确切地告诉你我将要干什么，我很愿意告诉你，但是请相信我——那些缓冲将是需要的。”就许多传统的经理而言，容忍进度表中有缓冲时间，不啻为信念上的一次飞跃。大多数情况下，缓冲时间被开发经理一棍子打死：“不，让我们抓紧些，我们需要出品，我们可以挤掉一些缓冲时间。”于是你的进度表就脱离了实际。我并不知道缓冲时间将被用来做什么，但一次又一次，我知道那是需要的。不管它是用来修改错误，或是你边干边有了一些想法并决定：“我们实在应该有这个特性。”这样，如果你有两个月，你会将一个月分配作为缓冲。[一个]50%缓冲规则事实上是准确的，虽然我对此讲不出什么道理。
除了有助于使产品进度安排更符合实际，缓冲时间还给了项目一个机会，使之可以对竞争对手的产品公布或不可预知的大事作出反应：
现在我不知道有完美的说明和丝毫不差的估计，说到底，将来我们也无法完全了解竞争情况。我们无法了解这个非常非常激动人心的工业将走向何方。传统的进度安排方法只是把你知道的所有东西一股脑儿算进去，说这就是期限——那是我们了解的所有东西。考虑到我们对未来所知如此之少，难道我们就不曾对如此短的期限感到过惊讶吗？确定正确出品日期的方法是加上缓冲时间，承认未来不确定的时间。未来的不确定性是显而易见的。这并不是魄力不够或胆小懦弱，这只是承认未来就是未来，这是自信。
复查与检验点为了创造出一些来自管理层顶端的压力使项目处于控制之中，微软也在关键的时候进行每周一次的、每两周一次的或每月一次的项目复查，尤其是在决定实施计划之前。正如第1章所述，比尔·盖茨会参加到这个过程，与关键项目频繁接触，有时甚至每周一次。例如，Excel5.0有四次复查，这些复查通常由两个小时的会议组成。盖茨，麦克·梅普尔斯，皮特·赫金斯及其他关键的开发员和程序经理，测试经理与马克·奥尔森都参加会议。对其他一般的项目，盖茨可能只通过E-mail来批准进度表和产品说明。
产品维护与“里程碑0”
在大多数软件开发机构中，独立的小组——通常对产品开发经验极少——从事产品维护工作。我们在前面提到过，微软的情况与此不同。在这里，对产品下一版本的开发包括了创造重要的新功能与修改上一版本的错误。不光如此，微软还设立了单独的产品支持组以回答用户的电话，该组的大小基于对电话量的估计。对于紧急情况，一些产品组还设有快速修补维修小组，他们对一件产品进行中间的“点版本发布”以满足顾客需要（例如，MS-DOS6.2就代替了MS-DOS6.0）。
微软最近开始采用的另一概念是“里程碑0”。乔恩·德·沃恩将此描述为在一个产品版本完成后，另一开发周期正式开始前出现的工作：“经验的做法是，每人负责自己编的代码能工作听起来开始一定很乱，但实际上在最后，人们确实学到了做事的正确方法，我们甚至还腾出了一些时间。我们现在开始委婉地称之为‘里程碑0’。这是处于一个版本结束与下一版本正式开始之间的时间，人们在此仔细检查并清除他们所知道的不当之处如果有的地方我们确实很不喜欢，它就将成为下一进度的一部分，我们将更正规化地修改它。”例如，在Excel4.0与5.0之间，开发员用了一两个月时间做这种修修补补的工作。
在里程碑0阶段，开发员与程序经理一起完善下一版本的说明，完成对进度的估计。这样，项目就有机会往进度中安排时间以在下一版本中改正重大错误。现在，新项目大约用对间的10%重做已有的特性，包括一些用户界面的变化，而不是一开始就开发下一版本的新特性。也有这样的情况，微软会推出一个填补漏洞的中间版本，如Windows3.1与Windows NT3.5.然而，对于关键产品，微软越来越普遍的做法是，对小改动（如12个月修订）与大改动（如24个月修订）平行地进行开发。
原则二：运用想象性描述和对特性的概要说明指导项目就单独的一个项目而言，微软和其他PC软件开发者的主要任务是，既要给出足够的开发框架以使工作能持续进行，又要能容纳开发过程中出现的变化并保持足够的灵活性。为了做到这一点，微软采用高水平的想象性描述和概要的说明来指导项目运转，而不是在一开始就努力写出一份完整和详细的说明。想象性描述是由程序经理和来自市场营销组的产品计划人员共同编写的，它是一份非常短的文件，定义了一组驱动产品开发过程的目标，但不涉及产品要求的细节。例如，Word6.0的想象性描述只有一页，Windows3.1的描述只有一句话。对一件全新的产品，想象性描述通常会详细得多，实际上，它还包含了一份粗略的说明文件。总的说来，微软的目标是想象性描述越短越好，而且力图讲清楚“产品不做什么”而非“产品做什么”，这是因为决定产品不要哪些功能比决定要哪些功能困难得多。
运用想象性描述，程序经理开始编写功能说明文件，该文件解释产品的特性是什么以及这些特性如何与其他特性及产品发生关系。程序经理开始只写一个概要说明文件，随着项目的进行添加更多的细节。因为他们明白，过早固定产品特性及其细节是不现实的。在一个项目的生命周期中，竞争者的产品，顾客的需求以及市场机会可能不断变化；因此，说明文件必须非常机动灵活，以适应变化和利用新机会。同时，说明文件也应非常具体，以估算项目进度表，并使开发员能顺利工作下去，不必不断地重做特性。此外，开发员需要有这样的自由，即能决定如何用实际代码完成特性目标。
在项目进行过程中，程序经理负责开发、更新和改进说明。完整的说明文件像用户手册一样，是项目的产品之一，而不仅仅是开发中的投入。相应地，完整的说明不只起着产品功能最新描述的作用，它还是在产品投产与出品前进行测试与评估的主要基础。在说明过程的早期，程序经理会建立一个说明文件的正式网络地址，并运用版本控制工具来记录连续的再修订；直到项目结束后说明文件才付印。另外，程序经理们应该与开发员和内部操作组一起对说明提出建议，并用文件和进度表来保存测试软件的运行结果（主要是可用性试验室），以及建立一个跟踪系统来记录信息供写事后报告使用。
想象性描述有助于决定删除哪些特性的想象性描述大约有5页长。它所关注的是市场营销组希望产品具备的优先次序：特殊的功能，产品运行所需的软硬件，特殊的依赖性（如OLE），对事业单位计划的总的看法，以及进度表的各个方面。Excel5.0的想象性描述还规定了“领域”（用来对特性分组的宽泛的类别），并把这些领域分配给了一个个程序经理。因为Excel5.0相对来说是一个复杂的应用软件，有大量的功能，所以想象性描述不仅规定了最近版本的目标，还规定了未来5年的产品目标。它还包含了单独地为一些单个“领域”服务的小型想象性描述。
相反，Office的想象性描述则强调依靠大量应用软件在一起和谐工作来完成单独一件任务。例如，创建一份复合文件，其中包含文本，数字数据，图形以及自动插入的排版信息。Office的想象性描述认为PC“只有一个主要的应用软件”，而不是认为PC有许多独立、各异的应用软件，用户不得不使之互相配合。
在具体说明一件产品时，一个主要问题是，市场营销人员往往希望产品有许多特性，而在一个紧张的进度表内这是完不成的。为了对付这种情况，微软的各个组都用想象性描述帮助细化产品版本的规定主题，然后他们就用这些主题来决定接纳或排斥那些候选的特性。克里斯·彼得斯描述了一个项目若不具备对产品作出的清晰的想象性描述将会发生何种后果，他也讲了好的和差的想象性描述之间的区别。
通常的做法是，程序经理会写出一个概要说明，其中包含了许多无法完成的特性。开发员会粗略地估计出在每个特性上要花的时间。当知道了希望的出品日期时，就会召开一个喧闹不堪的会议，人们在此讨价还价，大声咆哮，尖声叫嚷，为的是要努力提前出品。好在有一些关于想要产品做什么的单一的想法，这在永无休止的争论中对大家都大有裨益想象性描述有好有差。好的描述告诉你产品不包含什么；差的则向你暗示产品中包含了一切。为了对产品包含什么与排除什么做到心中有数，你必须做出某种关于这件东西不是什么的解释。市场营销部门经常认为所有的东西都包含进去最妙困难的部分是需搞清楚不要做什么。在每次发布时，我们总是把清单上2/3的特性砍掉。如果我们把想要做的所有事都写下来，那将会是一份长达1500页的文件。现在很清楚了，想象性描述可帮你建立选择机制，而非创造机制。
例如，Excel3.0的想象性描述对产品目标的陈述是：使Excel3.0成为“迄今为止创造的最有分析力的电子表格。”在说明过程中进行关于加减何种特性的讨论时，由这项描述引出了一个决定，不包括三维图形（3-D）和其他一些对象。当项目成员必须决定哪些特性要去掉时，他们更偏爱数学的或数据的分析特性，而宁可放弃那些支持图形功能的特性，虽然Excel3.0加上了一项绘图功能。
然而，产品的想象性描述也可能改变。当Excel3.0最终出品时，市场营销部门已把主导思想改成了“可以更轻易地拥有强大的能力”。这个市场营销主题集中在产品的强大能力与易使用方面。实际上产品对这一新的市场营销主题支持得很好，但主题的改变确实也造成了程序经理和开发员的一些混乱。
编写说明文件根据约翰·法恩的观点，说明文件应该与做菜的配方非常相似。他给出了苹果饼的配方例子——或者说是最初的说明：“饼的做法因人而异。这里介绍的苹果饼具有当今世界所有饼的优点。它的关键配料是掼奶油、苹果、面粉、糖以及其他一些东西。它应该大得让人人都能满意。比起版本1，我们会大大改善其规格。制作饼的方法是：混合苹果、糖、柠檬汁，把它们放于面包片中，烤得足够热以确保饼能烤熟。”
对开发员、测试员、用户教育人员以及市场营销人员来说，概要说明文件的作用就像烹调书一样。说明文件在产品小组的所有组员之间，产品小组之间以及产品小组与管理部门之间起着传递产品的设想与要求的作用。这些机构是说明文件的“读者”。因为项目对开发、测试、用户教育以及非英语版本的所有进度安排都基于最初说明中的信息，所以说明文件必须足够清楚地描述特性并赋予其优先级。这样项目才能建立起有意义的进度表。我们也应该注意到，一些程序经理感到越来越大的压力必须在开始前使这些“配方”说明尽可能完备。产生这种压力的一个关键原因是产品构件之间越来越强的互相关联性，比如Office的情况（见第6章）。结果是对复杂产品，程序经理建立的说明文件可能非常详细与冗长（1000多页）。
因为说明建立在想象性描述的基础上，它就比想象性描述文件包含了更多的信息。概要说明文件应由一个总经理作出小结，以清楚地概括产品的设想。说明文件也应包含下列各项：能用一句话表示的项目目标，关于产品是什么与不是什么的清单，对顾客的定义，对竞争产品的定义。9它应描述出产品对系统的要求，包括操作系统的版本，最小内存要求，硬盘空间，处理器速度以及图形。另外，说明应列出产品对第三方（如打印机驱动程序）、其他组和构件（如视觉界面设计组或OLE）的任何依赖性。然而，文件主要的内容还是对功能的描述，讲出产品特性是想做什么，而非怎么去做。它也将特性划分，归属于普通的功能领域与子领域，范例可见描述的Excel的情况。
特性描述通常都遵循一个标准格式。在概要说明中，每个特性有一到数页，描述它将如何工作，外观怎样以及从用户的角度出发如何与用户交互。如果特性有一个用户界面（如面板、菜单或按钮），那么说明就应该包含一张示意图，显示出界面该是什么样子。设计一些方案演示出用户将如何使用特性，对弄清如何才能有效构造特性尤其有用。概要说明也涉及特性努力去解决的那些难题。（特性与特定用户难题及用户行为之间的联系将在下一原则——特性选择与分级处深入讨论。）例如，Word的Windows版有一个特性，即可以很快地存储一个文件，即使该文件包含有其他应用程序所建立的文件；这种存档行为在桌面印刷与书籍印刷中是很普遍的。概要说明是如何描述这一特性的呢？我们举例如下：
Excel说明中的特性领域加载宏Macro宏水准基点Mail邮递计算Name名字分级显示图表Print打印配置Projects项目数据Q+（Righttoleft）右到左显示Search搜索编辑Setup设定格式Startup启动公式Toolbarandobjects工具条与对象函数Userinterface用户界面帮助Utilities实用程序链接What-if假设分析装载/保存Window窗口与Lotus的兼容性资料来源：1993年4月13日，与测试经理马克·奥尔森的谈话以及不知日期的微软文件《Excel测试领域》。
Excel5.0的特性子领域范例领域子领域领域子领域图表普通图表编辑系列箭头（继续）术语坐标轴文本复杂参考优选可拖曳图标点图表编辑主格式与格式雷达图，系列线图形重叠不限量股价组合图格式式样曲面图图表库三维图表数据点标签三维柱状图图例链接苹果的事件数据系列标识图表建立重叠的坐标轴标题印刷签名图片普通绘制区资料来源：1993年4月13日，与测试经理马克·奥尔森的谈话以及不知日期的微软文件《Excel测试领域》。特性所解决的难题书籍出版的难题以专业方式出版的较长的文件一般由一组人共同创造。组员们同时在文件的各部分展开工作，而出版是一次完成的。因为“书”只出版一次，所以在出版之前，“书”要被印刷许多次以供不断进行复查。这样，对各部分进行合并与印刷以造就一个主文件的工作重复了多次。
开发产品的难题通过“包含域”的合并形成主文件是不可靠的。合并要求在每一个层次上重新存储数据。这样，主文件就会含有复制的支持文件的所有数据。因为主文件最后会是一个数以兆计的庞然大物，存一次要花很多时间，所以你一定想尽可能少地去存它。但如果不是每次都达到完全再同步，你又冒着使主文件与支持文件失去同步的危险。
概要说明文件中的特性描述对用户教育人员编写文档以及地方化人员撰写非英语版本都是至关重要的。程序经理应尽量避免改变反映特性的用户界面中的术语（如对话框或菜单），因为要在非英语版本中做相应的改变非常困难。当为用户界面写说明时，为了方便非英语版本的编写，程序经理要密切注意单词长度、缩写、数据格式、货币格式、文化差异、排序顺序、纸张大小、左右顺序，以及其他可能在不同语言和国家间有差异的因素。
程序经理负责协调并“写下”说明很明显，在产品生命周期中，程序经理处在不断转动的信息之轮的轴心上。他们写下说明，帮助定义用户界面以及负责协调内部运作等问题。根据约翰·法恩的说法，他们会考虑以下问题：11·这项特性的要点是什么？
·用户如何使用该特性？
·这项特性有意义吗？
·该产品中或微软的其他产品中有类似的特性吗？·开发完成的特性确实是我们所计划的吗？
·有哪些问题被遗漏了？
·组内的交流令人满意吗？
正如第2章所述，一位程序经理对开发员而言，是个领导者、协调者、使事情易办的人，而不是他们的老板。因为开发员通常很深地介入到说明的创造之中，所以说程序经理写下了说明而非单独创造了说明是非常准确的。麦克·康特曾这样讨论了程序经理的角色：
当我说程序经理写下说明文件时，我给了你一个错误的印象。也许更准确地说，程序经理只是记录了说明的文字；说明其实是整个组用一定方法写成的。事实上，程序经理的一个困难任务便是力图使每个人都认为设计说明他也有份儿开发员对设计介入非常非常之深。程序经理凭空造出说明，打好它并交给开发员，而说明居然能付诸实现的情况是极罕见的。更经常的情况是，不断地重复[以及]争论不休，这可能正是由于开发员对特性应如何实现有自己的看法。一部分是因为他们会给出成本信息：“好吧，如果你要一个单独的窗口类，那要花64周。而如果我们不要，如果我们用对话框，那就只用16周。也许我们应该用对话框。”同样，如果你与一位开发员交谈，他说：“喔，那会花1000周。”也许他真正的意思是，“我认为它是个笨主意。”当对未来进行预测时，开发员对特性的偏好通常会产生惊人的影响。
对重要产品如Office（包括Excel与Word）或Windows的说明，通常都需要10至20个程序经理，在一名“组”程序经理的协调下完成。一些程序经理工作于产品的某些部分，如购买的拼写检查器或外语版本。克里斯·彼得斯这样描绘程序经理和开发员之间的交往：“[程序经理]力图使开发员克尽职守。要知道开发员并不是为[程序经理]工作，而且程序经理也不在任何确定的方面对开发员有任何控制，明白这一点很重要。换句话说，如果程序经理在说明中写了什么，开发员可以按也可以不按他写的那样去实现程序员读[说明文件中的特性描述]，理解代码，然后做出与之非常相近的东西。经常地，在过道中前前后后都有许多人在谈话，许多人在尖叫与咆哮。”
管理说明的工具支持为了在说明演进期间（对特性的功能添加细节以及特性集的改变）进行联络和对其管理，小组成员们大量使用电子邮件。他们以前使用Word来建立和更新一个大的说明文件，但现在通常使用Excel的电子表格来管理说明的内容。说明文件体积也不断膨胀，现在即使是每个说明领域或子领域都有一份单独的大文件。电子表格列出下列各项：
·特性数目。
·特性标题。
·与主要程序经理之联系。
·开发联系，用户教育联系，市场营销联系，国际联系等等。
·对每个特性的进度预计和真正使用的时间。
·测试发送文件信息。
·说明的更改（修订）日志。
当然，说明的用户可以把信息从电子邮件中移至Excel电子表格中，再移至用Word写的真正文件中。电子表格的一个替代物是微软内部开发的说明工具，专门处理一定结构的Word文件。程序经理主要使用这些文件说明及电子表格说明。
在一些较早的项目上，微软开发组利用一种工具来处理对说明文件的“一直控制”。这种工具在一定时间只允许一位用户更改文件，虽然许多用户可以读它。然而，该工具由于要求每一位程序经理的机器上都有大量硬盘空间从而被证明为不必要。现在，微软处理这种进入权控制的方法是简单地让人们通过电子邮件向“拥有”特定特性的程序经理表达意见。只有拥有该说明的程序经理才能实际上对文件作出更改。
构造原型当程序经理具体说明一件新产品或一个新版本时，构造原型便成为他们的基本行为。这从许多方面来说都使开发前测试成为可能，尤其是在可用性方面，并且有助于对与用户交互情况作出更好的理解，它也能使产品说明更紧凑。布兰德·斯尔文伯格注意到程序经理即使对系统软件也建原型：“他们绝对会建原型，或者他们会与开发员一起建原型。实际的编写说明，决定这个或那个特性是否包括进来，正由开发负责转变为程序管理负责。”
是选择用户界面时的建原型工具。程序经理在说明过程中，普遍地对大量产品运用该工具。另一个流行的建原型工具，画笔（Paintbursh），使程序经理能创造产品的计算机屏幕模型。这些静态的屏幕图形用于对现存产品作微小改动尤其适宜，比如改变一个对话框的外观。如果程序经理需要从零开始创建原型或有一个实际在工作的原型，那么Visual Basic更有用一些。（一个与Visual Basic相类似的工具是苹果的Hyper Card，Excel的程序管理组在过去曾用之于建原型。）然而，Visual Basic不能在Macintosh机器上运行（虽然一个Mac版就要出台了），并且如果改变是渐进式的话，有时会费时费力太多，程序经理因而不愿进行。Visual Basic用于对话框原型是出色的，但在其他方面则不是太好，像设计新的象征型图表。
死板的说明变成有生命的文件说明不应过于详细以至限制了发明创造。微软创造的产品要求有所发明和有创造适应力。正如克里斯·彼得斯所评论的，说明文件必须足够灵活以适应这种演进：
说明绝对是随开发过程而变的，说明是有生命的文件。它是对发展中的特性作出的最好的描述。它给出了让开发员作出发明的大量空间。人们希望它是关于重大问题的思考，如这个特性如何与其他特性相互影响。但和大的国防项目比起来，我们在这儿做有些事的方法不大一样，那就是由于该工业变动如此巨大，以至说明必须随着产品开发而变。你在产品开发时得到了如此多的信息：你从你的顾客那儿得到信息，你从你的竞争对手那儿得到信息。你得知有的东西很容易就可实现，或者你实际上已实现了一个特性，并且突然意识到，只需少许扩展，它就可用于产品的全部其他领域。在开初，这是你未料想到的，现在，你清楚地意识到了，你发现了这一点。如果你不知为何仍然说：“好吧，我们有说明摆着呢，我们要把‘写代码的人’——这对开发员来说是个带有侮辱性的词——限制在这个范围内，他们应该按说明来做。”这样一来就会使士气严重不振，开发出的东西会一塌糊涂，并且不会按时完成。
在项目进程中，说明文件的早期版本会有相当大的增加与改变。例如，Excel5.0的最早的说明在开始编码前是1500页，然而当产品推出时完整的说明长达1850页。（微软的一些人员认为这太长了。）Word6.0最初的说明长约350页，完成时的说明大约有400页。最新Office的说明文件的较早版本长达1200页；微软最近没有印刷其说明文件，但可以肯定的是，该说明文件已经大到不能用一个单独的文件容纳了。
不光是规模上变大了，在第一个主要里程碑阶段开始后，30%的说明文件改变了（或“剧烈重组”了）。麦克·康特论述如下：
如果你在我们开始开发前读了说明然后在项目结束时又回过头去读了以前的说明，我敢说你会发现至少30%的说明是不准确的一个特性的精神也许还在，但也有可能改变了当我们开始时，我们认为这个对话框会需要五个选择项。在我们开发了一段不短的时间之后，我们意识到其中三个造价高昂，但我们需要另外两个选项这样，当你真正完成了工作时，那已经是不一样的特性了。
康特还提到一个项目会削减掉最初的产品说明中20%-30%的特性。
现在，在第一个主要里程碑阶段开始前，许多项目就力图对说明早期草稿中所有的特性作详细描述。然而，在实践中，微软的各个组看起来只对大约70%的特性做此工作。在开发的过程中，特性的准确细节以及为实现特性需作出的取舍往往并不清楚，于是程序经理有意让一部分说明不完整。当项目继续下去时，开发员提供关于特性的表现，实施的可选方案，以及表现上作取舍的进一步信息。克里斯·彼得斯强调，非看第一手的源代码不可，这样才能作出正确的特性抉择：
说明总是不完整的，作为一名开发员，你也总希望它不完整。程序经理永远不看产品的代码，他们也不想看，那不是他们的工作。但是要想正确做出特性却要求你去看代码，并对代码作出那些工程意义上的取舍。另外，我们工作于其上的特性是极其复杂的，这样，再次地，如果没有实际看见事物是如何运作的，就不可能准确知道特性将会是什么样，我们已经在IBM中看到了说明的一次性完成所带来的恐惧，因为没有人聪明到那个份上。应该做的是看看说明是什么样的，修改它，使之更加完美——使之成为人们想要的东西。
项目有时加上在说明早期版本中完全没有的重要新特性。娄·帕雷罗里，Windows NT的软件工程经理，对NT3.0项目过程中作出的变化评论如下：
我们要出品的东西必须有以下功能：以窗口方式运行，可兼容，是32位平台，是功能强劲的技术，支持网络互联性以及高质量。真正拖长了时间[产品最后版本]的是加入的额外功能。NT产品现在将能对Macintosh机器提供服务，这样你就能把你的Mac客户机联到一个NT服务器上。你能把Mac文件放到其上，把文件夹放到其上，点一点Mac机上的图标，就可以看到NT机器上的文件夹。这在两年前的产品中是见不到的然而在此处的产品中却有了。所有通过电话线连接的远端存取服务器都包含在此产品中；我们将ISDN驱动程序纳入产品，这样你就可把到达你房屋的256k线插入你的PC，然后通过ISDN与你的服务器交谈。我们以前从未动过把此项功能加进去的念头，然而许多压力共同使这项功能得以加入。这样，就有许多“让我们加上这些好东西吧，”的要求，例如Mail，两年前的产品中没有Mail，但现在我们正把它推向市场。
然而，开发员需要尽可能早地知道说明中的哪部分是在变化的，哪部分是稳定的。他们不愿投资时间于开发、改进或使用那些在项目发展中会被删掉或改变的特性。但很遗憾，一个大项目的开发员从来无法完全掌握特性所处的地位。微软对此的办法是交错工作，首先集中于那些没有什么用户界面的特性。这些特性不大可能改变，因为在完成开发前不必去了解用户对它们有何反应。
例如，开发员可能首先工作于这样的特性，该特性增加一个字处理程序支持的字体的数目，或“优化”磁盘上储存文件的内部数据格式。这以后，他们可能再工作于常用的特性，如绘图用的工具条。然而，很晚才决定用户界面的外观可能会对文档的及时生产产生不利影响，并且会缩短可以用来做可用性测试的时间。乔恩·德·沃恩回忆说Excel4.0开发中出现了一些问题就是因为他们将说明稳定得太晚。Excel4.0开发阶段始于1991年7月8日，第一次发布——在美国的Windows版——是1992年3月27日：
短期项目的决定做出的非常晚——如此的晚以致我们不得不马上开始编码。这是一个错误，因为它给整个事业单位带来了许多过度的紧张从严格的开发角度来说，在进度表完成很久以后，我们才停止作出关于实现的许多决策。这就意味着进度表不像它应该做到的那么准确了。因为我们有些决定做出得非常晚，程序的一些部分就不能与其他新特性同步。例如，因为工作簿被设计和实现得如此之晚，就不可能照最后设计的那样实现Lotus式的3-D电子表格装载。这就造成了大量与[工作簿]装载有关的较晚发作的错误，而这本来是可以避免的，通常说来，这些错误倾向于这些概念性错误，而非简单的错误。
编程组在项目刚好结束处做了大量小心翼翼的改动，他们的活儿干得不错。因为设计决定作得晚，几乎不可能让测试组有时间搞出像样的测试方案缺乏一开始的设计期在事业单位中的功能组之间造成了紧张。程序管理和开发之间的关系受影响最大。因为要在短期内作出如此多决定，一些程序经理就只能采取专断的态度，这使开发员感到程序经理不是“我们这边的人”。
文档的外观固定如果项目的大多数用户界面细节完成得过晚，那么用户文档就可能不完全或不准确，因为为改变文档而留下的进度时间不够了。为了防止这个问题出现，微软设立了“外观固定”目标，允许用户教育人员与最终调试和测试员平行地编写文档。但如果开发员老是改个没完，或者直到项目结束也未决定用户界面特性，这个目标也就变得几乎毫无意义。
除了付出最大努力在相对较早时就固定产品外观外，开发员还常在较晚时改动那些影响产品外观的特性；用户教育人员别无选择，只能在项目快结束时重做文档以适应变动。这反映出在微软中，开发员比起测试和文档编写人员来，处于支配的地位。克里斯·彼得斯承认了这个问题：“保持外观固定是世界上最难做的事所有的人员通常在最后都没什么事了，而用户教育人员却经常还在叫苦连天。这是典型的战斗你在编写文档时经常跟不上形势我的意思是，文档[基本上]还正确，而这些人却在项目快完成时，不得不一天工作12个小时，再搭上许多周末[他们]必须重做一大堆事情。”
灵活的说明文件在微软（以及其他地方），产品拖延的一个基本原因是在开发过程中不断地对说明文件或产品的特性集进行改动。经常发生的是，一旦一个组同意改动说明文件中的一些东西，那么所有的事情都变得从属于改动了，以前的说明和进度表变得无人理睬。麦克·康特详述了说明的改动会怎样导致进度的拖延：
当你回顾为什么[进度拖延]会发生时，你会发现有一大堆原因，但其中有一些是基本的。一个原因是不断地改变产品定义——如果每次出现了什么新东西你就说：“好吧，我们要改一下计划；我们要加上这个新特性”——这就对产品产生了巨大的影响。每一个改变都要花时间去实现，[于是]你忽略了对整个产品的考虑。它以这种方式影响人们的决定：“好的，如果那是可以讨论的，那就让我们把所有其他一切也加以讨论吧。”另外一个原因是你有一个产品开发进度表，告诉你从何时开始开发，但你对应在何时结束只有模糊的概念，到该结束时你却不得不调试产品了。实际上到现在，这还是大多数应用软件的编写方法。
微软的说明文件相对较灵活。然而，一些项目，当项目进行到了一定点，例如，40%以后，建立了对说明中重大改动的控制。他们允许此后的那些小改动主要是为了让特性正确工作，而不是为了增加新特性。这类控制在诸如Word或Excel这样的产品上较易实现，因为它们都处于多年的版本更新周期中，每12至24个月就会出现新版本。如果发现这些项目在开发中应做一个大的改动，他们会把改动延迟到下一版本，而不是去破坏现在的进度表。康特对Excel组在一定点后，如何避免了对说明做出大改动颇为自得：
它也意味着我们力图做到非常有纪律性，不到说明固定和有了一个包含我们要做的所有特性的平衡的开发进度表后，我们实际上不开始开发。想要在开发过程的中间加上特性，那对我们而言将非常非常困难。这样如果我们在产品开发的中间知道了新东西——太晚了，等下一次吧。现实情况是，总是有许多小玩意使你滑入机会主义的想法中，想把它们加进去，但那是困难的，因为它们必须经历整个过程，而有许多组要被牵涉。
特性添加太晚不光造成开发延迟，它还压缩了测试可用的时间。然而，愿意让说明演进却有助于产品在市场中获胜。这对有较长开发期的产品尤其有用，因为市场需求与公司需求随时间而变化。要想对说明演进很大的项目保持控制，需要格外强的技术领先性。在一定点，经理必须对任何改变说不，或变得对同意往产品中增加的东西分外挑剔。Windows NT为我们提供了一个这种灵活性与强有力控制的范例。
我们在第3章提到过，NT是在80年代末开始开发的，用以替代OS/2，后者是微软与IBM协同开发（至1989年）用于替代MS-DOS的。微软从DEC雇了戴夫·卡特勒来管理该项目；他对新的Windows类型的界面并不熟悉，但他写了一份说明，然后写了一份为公司市场生产可靠操作系统的详细设计。与IBM的分离和Windows3.1面市的爆炸性效果说服了比尔·盖茨、保罗·马里茨、史蒂夫·鲍尔莫以及其他微软的高级人士，要把NT带入大众市场的Windows家族中。特别地，微软的最高管理层希望NT吸收Windows3.1的图形用户界面并与Windows3.1的应用程序完全兼容。这些和其他的要求需要产品作出极大的改变。1993年NT出品前，在原始的详细设计后，NT经历了三次重大设计改变。卡特勒和他的组目睹了所有这些工作并把项目相对保持在控制之中。14在此期间，他们还在抵制对产品作更多改变上展示了相当的纪律性。例如，娄·帕雷罗里回忆起决定不支持Double Space数据压缩，因为加上这条特性会使他们没有足够的时间来彻底测试产品：
当考虑像DOS6.0那样做Double Space时，我们只是会说不。在一个仅测试就要花3个月的文件系统中，我们没功夫做那个。想一想，如果花6个月开发，加3个月测试，然后——你会相信只用过3个月的文件系统中的数据吗？我不会。在文件系统中，我们现在用的是像NTFS这样的东西，这是我们最近的文件系统，我从7月开始就在我的机器上亲自使用它，从没有丢过一份文件。我觉得自己有充分的信心来告诉大家，可以在它上面运行。我永远也不会告诉人们，可以在一个连我自己都不曾用够3个月的文件系统上运行。
理解与安排特性优先级的困难当微软的产品规模变大并且功能日趋复杂时，特性的数量也显著增加了。如此一来，项目就需要用一种方法来对特性赋予优先级。一个办法是集中于下一个产品版本中会使顾客抱怨电话最少的特性，这些电话平均每个要花微软大约12美元。程序经理也读市场研究资料。麦克·康特描述了Excel组如何对付该难题，即决定什么是用户最想要的特性：
特性的阵列让人晕头转向在产品增加和该工业成熟的同时，出现了几股潮流。首先，这场无意义的，非常像军备竞赛的特性战结束了。在以前，你不停地多加入“2%”的特性，尽管几乎没人用到它们。我们原来就很清楚，人们将不会按特性的多少来挑选和使用产品。然而，软件工业在以前一直着力增加新特性，因为这曾是顾客想要什么的一个重要尺度。但那种潮流在变。我们从五年前起有了市场研究；如果你在那时问人们，他们在电子表格中想要什么，他们会说是功能强大。但如果你今天再问，功能强大就只是第四或第五重要的了；最重要的是易于使用。当钟形曲线延伸出去时，人们对特性的兴趣就减少了，用在电子表格上的时间少了，对其在情感上的喜爱程度降低了。对他们来说，那就像传真：只想让它工作而不想学它。产品已经变得功能很强了，我们必须做的是使它们更好地工作。
程序经理以前常按独立的特性思考产品和组织说明文件，这与他们如何对开发员分组相一致。当说明在长度和复杂性上都大大增加了时，这种特性分割法就成了思考产品的一种坏方法。程序经理和市场营销部门对产品描述作评价也变得越来越困难。康特回忆起从市场营销组得到关于详细说明文件的信息反馈时遇到的问题：
我们以前通常按产品的功能领域在说明文件内分类与打印，这样我们就会得到数据库特性、兼容性特性以及分析特性。我们会大致地按开发员如何分组把它们分开。但要评价说明则非常困难我会将说明交给市场营销部门并说：“请给我信息反馈，告诉我这特性集是我们想要做的吗？”市场营销部门可能读也可能不读说明，因为那实在是太长了。即使他们确实读了，他们也会迷失在其中，因为读那玩意儿可是件需要超级技术的事情。如果他们对说明确有评论，他们也是说：“啊，我们认为这个对话框排列得不对。你真该把检查框放在左边，”或是诸如此类的东西。这不是作为程序经理希望得到的信息反馈。你希望市场营销部门的伙计们回来告诉你：“等一下，这产品对律师没用，而他们是我们市场营销策略的关键，”或是“它不会对小企业有用的。”你真正希望从市场营销部得到的高水平信息反馈应是像这样的：“这与我们的策略不对路。”但读一份像说明那样庞杂琐碎的文件，他们很难达到这样的要求。这就有点像读一份汽车的零件清单，然后试图弄明白这是辆赛车或是其他什么车一样。
程序经理也尝试着召开大型会议，开发员、测试员、用户教育人员、产品支持人员、市场营销人员以及程序经理统统出席，讨论说明与评价特性的取舍。康特回忆了在大会试图弄清问题与作出决定时碰到的困难：
现在你有一个大组，你不能围绕着由300个杂乱特性组成的团体来集合。必须有一个总的想法一个有力的主题每个人都能明白它组越大，我们就会在更多的特性上争吵，整个过程就越失去理智。于是我们走进一间大屋子，大喊大叫地讨论事不管是谁，叫得最响通常就可以把他们负责的特性加进产品。如果特性是一些新的三维图表或一些很“新潮”的东西，那它就会被加进产品，如果特性无疑是很重要的但不是那么“新潮”，就没有人理睬它。打印是非常重要的，但它并不是那么光彩夺目，于是人们就不愿做它。房间里也很容易有放冷枪的。一个聪明的家伙会说：“那是个蠢主意，”于是所有的人都会对那主意失去兴趣。如此一来，对我们设计未来的版本而言，这样的会议过程就不是让我们可以宽心的了。所以我们决定：“好吧，让我们稍稍反转一下这个过程，让我们想都不要想特性。”
最后，当程序经理把新产品的精髓展示给比尔·盖茨时，他们面临着一个挑战。康特提到，依靠一份数百页长的初步说明是不行的：“实际上，Billg[指比尔·盖茨，这是他的E-mail地址]的程序复查对说明表示出一些不满。问题在于，‘我们的小伙子老板非常聪明和忙碌，我们应怎样与他联系，告诉他在产品下一版本中我们要干什么以及如何干——让他评价我们做的是不是件聪明事？’我们能给他说明，为特性辩论，像我们通常做的那样，但那是没有什么价值的。我们很清楚，我们做这类评价工作的体系糟糕透顶。”所有这些因素——众多的特性，需要来自其他组（尤其是市场营销组）的关于特性评价与优先级安排的信息反馈，以及需要在产品精髓问题上与组和高级管理层进行交流——都有助于制定基于行为的计划，以及其他将在下一原则中讨论的技术。
原则三：根据用户行为和有关用户的资料确定产品特性及其优先顺序在微软的早期，像麦克·康特所说，产品包含什么特性通常依赖于谁在设计会上叫得最响。产生潜在特性的主意很多，但在为下一次版本进行开发的时间中，项目完成不了那么多；这样，最困难的问题就成了什么特性应被排除在外。意志坚定的开发员或程序经理往往使那些顾客实际上并不需要或没法学会怎么正确使用的特性包括进了产品。为了解决这个难题，微软采用了一个原则，在开发进度表中将特性选择与优先级安排建立在公司的被称为“基于行为制订计划”的技术之上。
基于行为制订计划在概念上与会计中的“按活动核算成本法”很相似。后者跟踪公司做了什么（例如在设计新产品时一个多功能组发生的费用）而不是跟踪正式的部门或传统职能来弄清楚费用支出。虽然许多其他公司也以相似的方式深入研究用户，但看起来微软是独立地对自己的计划技术命的名，与成本会计知识没有关系。说起微软中基于行为制订计划法的推行，麦克·康特是三个最早的倡导者之一，另两位是山姆·霍布森与克里斯·格雷姆。（当提出此概念时，山姆·霍布森是Excel的一位产品计划经理，克里斯·格雷姆是Excel组的程序经理。）基于行为制定计划法从对用户行为，诸如写信或做预算，做系统研究开始。然后，根据特性在支持重要的或经常的用户行为上的重要性来对其进行评价。这样做的优点是对特性取舍的更理性的讨论，对顾客想要做什么的更好的排序，对某个给定特性是否方便了特定任务的更集中的辩论，可读性更强的说明，以及在市场营销、用户教育和产品开发中更好地同步。
特性选择和优先级安排中的基于行为制定计划基于行为制定计划法中的关键点在于按用户行为、产品特性以及行为和特性之间的内部联系来分析产品。程序经理和产品计划者把产品试图支持的用户任务或方案分成大约20个“行为”，然后他们努力把行为（以及任何子行为）映射入微软的现行特性和竞争对手产品的特性中去。他们也把行为映射到不同的顾客形象——如是新手还是高级用户，或不同的市场部分中去。
当说明产品的新版本时，基于行为制定计划法帮助程序经理和开发员集中他们的精力与创造力。在实践中，像Excel那样的项目争取在每个新版本中加入的主要行为不超过四个。绝大多数特性直接映射入这些行为之中。Excel组甚至列出每个特性支持多少行为，以之作为说明文件的一部分。该做法使项目可以按特性对用户的价值来对特性分级。麦克·康特概述了Excel组如何评价行为，使下一个产品版本只集中在少数几个特性上：
所有这些要点在于，对什么是在下一次发布时我们要集中于其上的重要行为，一个事业单位基本上要形成统一意见。让我们挑四个行为——我认为四是个好数字，没别的意思——然后让我们安排它们的优先级。它们就是Excel下一次发布时我们的工作焦点。我们仍然有哪些大会，我们聚在一起，互相叫喊。但现在，不是争吵我们要做什么特性，我们争论的是做什么行为。我们会说：“我确实认为重要的行为是从1-2-3中切换，这儿是我的资料，这儿是我为什么认为该行为在战略上重要的理由。”另有人会说：“不，我认为基本的用途更重要，因为更多的人使用它，并且我们应该集中在新用户身上。”
当我们有了一份分好级的清单，内容是四个我们想在Excel下一版本中集中于其上的行为时，这个过程方告结束现在我们回到我们有的那份长长的特性清单处，并说：“好了。我们有特性1，它对我们的行为支持得如何？啊，让我们看看，它有助于建立模板，它有助于方案——这家伙得了2分。让我们看看特性2，它有助于建立模板与方案，它还有助于打印——这东西得3分。”当然，我们从未这样简单地处理过，但我们确实讨论过为每个特性依次打分。
这样“打分”的一个作用是，它促使程序经理和开发员都起来竞争，使他们的特性支持尽可能多的行为。这是良性竞争——对用户有益，而且对说明的生产率及开发努力也有益。打分也使选择特性成为可能，如哪个特性纳入产品，哪个特性被排斥，或哪个特性留到未来也许专门针对某些特定行为的版本去做。康特描述了基于行为制定计划法如何鼓励了项目创造更多的通用特性：
它有一些令人感兴趣的效果。首先，人们仍然必须考虑他们想纳入产品的特性，所以他们会想：“好吧，实际上我要骗骗大家。如果我哪怕只把特性改动10%，它就会支持更多的行为，那么它就可以被纳入产品了。”而那正是你希望人们做出的一种欺骗，因为我们确实希望特性更通用一些。我们希望它支持的行为越多越好。这也给了我们一个对一大堆好主意说不的办法，当然，这实际上是作为一名程序经理最难办到的事之一。
为顾客行为而非产品特性收集资料基于行为制定计划时，项目在计划阶段首先集中于行为，其次才是特性。程序经理和市场营销人员并不去思考和排除他们喜爱的特性，再围绕它们搞出想象性描述的草案。他们真正做的是列出一份顾客都做些什么的清单，然后把想象性描述集中于支持那些行为的特性。
例如，微软的产品经理与程序经理从人们到底如何使用电子表格开始研究，并且研究人们用电子表格做了什么特定的行为以完成特定的任务。他们注意到很多人用Excel来做预算。这些用户也遵循特定的行为：他们也许先做一个模板，发布它，再要求人们填它。然后他们也许会在模板上运行方案，再把结果送往老板处以供审计与评论。也许他们稍后会做一些敏感性分析，最后再合并信息并打印之。人们通常一年做两次预算。另外，还发现大公司和小公司都经历了大致相似的预算过程。然而，在小公司中，通常是一个人做预算；在大一点的公司中，人们在预算过程的各部分有所分工。
当微软的人员仅仅考察这一项任务——预算时，他们就发现了大约20种基本的顾客行为。不仅如此，他们还注意到说明的现在版本不够充分，没有包括行为中的几项。他们还发现预算中用到的许多行为与其他行为，与写费用报告或预测销售很相似，结果是，他们创造了一个更基本的叫做“数字累积”的行为。人们做预算时的另一个行为是从Lotus1-2-3中切换至Excel，包括从Lotus转移文件和简单地切换程序。虽然经证明有65%的Excel用户以前有使用Lotus1-2-3的经验，但Excel还是没有因考虑到了这一点就偷懒，仍然使从前的Lotus用户可以方便地做转换。
克里斯·彼得斯给出了基于行为制定计划法如何帮助小组集中其创造力的事例：
我们有这个叫做基于行为制定计划的技术，它基本上是指到人们和顾客中去，对他们到底在做什么进行研究。如果你问人们他们想要什么特性和改进，当用户考虑了各种可能后，你得到的回答往往就不能反映其真实心声。反过来，如果一家公司试图基于顾客发明特性，他们的想法往往又拘泥于顾客的需要。我认为我们去试图弄清顾客做事的步骤比让顾客弄明白我们能编写或发明什么容易。于是我们走出去看人们如何做事观察字处理器的使用，观察打印错误是如何产生的，或人们是如何做邮寄名单的看起来大多数公司做邮寄名单的方法是：把所有顾客的姓名与地址列到清单上，把名单复印出来，做成标签，最后按正确的顺序一个个地来。如果你只去问人们在一个字处理器中想要什么特性，你得不到这个答案。
你常听人说：“我想要一个绘图包”“那么，你要用绘图包来做什么？”“我要画一幅机构图。”这样，只有当你在详细到一定程度上明白他们想要做什么类型的东西，只有当你把这些东西分成可以构造出不同任务的行为，只有当你照这种方法来创造特性时，你才能知道你[是否]拥有了完成实际行为必需的所有子行为。并且你也能集中于创造具有最大效用的东西；换一句话说：“这个特性为七个不同的行为所用。”它使你能像以前一样有创造性，因为你不曾放弃过创造性，但现在你用一种相当集中的方式。你不曾说：“告诉我你想要什么特性。”你做的所有事情是对到底发生了什么做基础研究。
以行为为中心对产品进行全面考虑年初，Excel4.0的计划阶段开始使用基于行为制定计划法。微软也在Excel5.0中运用该法，并且在其他组中推广，尤其是在一些行为影响了或对特性有所要求的产品中推广。Word与Mail组，以及一些系统软件组和语言组，都采用了该方法论下的一些形式。然而，为了让这项技术能更容易地演进，微软没有写下这套方法或试图把它变成一门科学。就像康特评论的：“它当然是完全突然地出现的我们有意不把它写下来和使之非常科学化，这样它就可以在公司内传开的过程中有所演进我们认为，如果行为[基本行为]稍微超过20个，你就无法保持与行为的联系了，它就会变成一个大杂烩。它不是个非常科学的东西。”
基于行为制定计划法看起来已经在组之间传开了，因为它有助于项目人员以更全面的方式来考虑产品。这种着眼于整个产品的观点有助于在不同职能上工作的项目成员理解产品做什么，以及其他产品的相应特性如何可能支持那些需要或不需其他应用软件产品的行为。康特对这些技术的好处评论如下：
我们努力做的一件事便是对其他组大讲该方法论带来的福音。这样做有一些出于自私的理由。该方法本是设计成基本上只在“说明执行文件”——说明实际代码自身——上帮助我们的东西。但结果是，许多时候你看到了这些行为之一，如从1-2-3中切换，然后说“嗯，你知道吗？我们需要一个市场营销方案来支持它。”于是它就变成了这样的东西，我们现在突然可以由此出发，用一种更全面的方式来构造产品。我们也发现有一些跨应用软件的行为，如创造一个复合文件，那儿需要一个特性——不是我们的产品需要，而是我们要求开发Word的伙计们在他们的产品中加进去的特性传统上，这类跨应用软件的特性会被归入到某些附录中，以方便砍去。
做市场营销研究以支持基于行为制定计划法为支持基于行为制定计划法，从市场营销组来的产品经理与程序经理、开发员一起开展一些联合的研究，如指导对用户的研究工作。然而，一般说来是产品经理做大多数的研究。正如康特所述，这种研究现在一年到头都在进行：
传统上，产品计划研究是一件很专门的事，只在我们固定说明前五周内发生当我们完成了，比如说是Excel4.0后，程序经理想马上做Excel5.0.他们会说：“好，我们需要你们所有的产品计划研究，我们将在八周内固定说明，你们要做好研究给我们。”但是搞市场营销的伙计们正为发布新版本忙得不可开交呢，他们没有时间，当他们有时间来考虑时，太晚了，因为我们已经固定说明了。由于基于行为制定计划法的研究是更通用的，所以我们事实上一年到头都做此研究。
基于行为制定计划法也导致微软拓宽了用以支持产品开发的市场营销研究类型。开始时，程序经理对大家应做何种研究来收集关于行为的信息不加限制，虽然他们确有建议。康特就偏爱定量研究，不太喜欢定性研究或很小的样本研究，因为从定性研究中做推断最困难。关于大型研究项目有个好例子。研究中有一项市场各部分调查，做法是向美国家庭随机拨号，电话询问。市场营销组用这种调查方式问人们使用产品时有些什么行为，并且由此得知Excel需要一项新的列表管理行为。（第6章对顾客信息反馈与产品改良有深入讨论。）微软的组从那时起开展了花样百出的研究；现在，他们的研究从直接访问顾客到请求顾客使用能记录下他们所有击键的“工具版”产品，无所不包。康特说到：
研究从访问顾客到专门的研究项目，变化多端。我们确实对用户做些纵向的研究。我们会每三到四周访问他们一次，看看他们使用文档与产品顺手与否我们有一种行为叫基本用法，它是一种假行为。它是翻滚查找、选择和进入公式，以及那些人们在做一个预算或其他什么事时老在做，实际上并非必要的行为。为此，我们有一个Excel的专门版本叫工具版，它可以记录下用户的每个动作，这样我们就能回溯过去，分析这些动作。
一般说来，基于行为制定计划法给了市场营销组一种机制，使其可以更明确地影响微软的产品演进。正像康特总结的：“我们[程序经理]发现能从他们[市场营销]那儿得到比过去好得多的信息了。我们现在得到了真正的信息，‘喔，这个行为不是那么重要，不要集中在它上面。这个行为对我们很重要，集中在它上面。’而不是仅仅得到一张表，上面列出了他们希望在发行展示会上看到的为其所喜爱的特性。该方法也使我们得以从一些不具备资源进行美国市场营销的合作者[微软的组中]，像[微软的]国际部那儿得到更好的信息。”
做相关调查以研究群体行为虽然基于行为制定计划法可以抓住不管是个人还是群体的行为，微软的项目还用一种叫“相关调查”的技术来帮助理解在组或小组中工作的用户的行为。相关调查是在20世纪80年代晚期，在DEC中逐渐发展起来的，而最早则是人类学研究者用以研究群体和社会动力的技术。Office，Money，以及Cario这些产品，都用了相关调查来帮助完善现存的说明与特性，同时也用它来探索自己应支持的新的行为类型。
相关查询包含一系列的纪律、训练及态度，比基于行为制定计划法复杂得多。基本的模式是个浸入的过程。首先，项目小组选择一个焦点，比如用Office产品创造一个复合（文本与图形）文件。其次，小组成员访问顾客点；这不是真的采访，而是更偏向于仅仅观察顾客及其行为。第三步发生在顾客点采访中或其后，观察者做大量的笔记，绘制图表或模型，从物理环境、工作过程以及行为流程、依赖等方面记录下行为。
最后，小组成员回到微软开一个数据提炼会，一打左右的成员一起讨论这次顾客点采访。在数据提炼会上，人们用成千上万标了号的不干胶便笺做成一幅“姻亲图”，试图抓住他们观察到的行为及行为间的联系。顾客点采访通常持续2到3小时，其后的数据提炼会开2到3小时。项目在3到4周内指挥进行一系列的顾客点采访与数据提炼会。麦克·康特总结了该过程：“这简直就像‘不去不明白’的事：他们达成了一致，但他们自己也不完全清楚是怎么达成一致的没有去做[相关调查]的人就达不成[一致]。”
康特还提到该技术的其他一些限制：“问题在于相关调查没有真正的产出没有快速得能用一页纸写出所得结果的产出其他人想吸收它很困难。所以想要把它推广是费力不讨好的。”另一个问题是相关调查非常费时间，还可能要求项目代表在3到4周内参加一系列的访问。一些结果也是模棱两可的；例如，对Office组的相关调查研究导致在关于“找到东西的地方，打开东西的方法，做新东西的地方”的用户界面中出现了概念分离。然而康特指出，在可用性试验室中，用户在区分打开与找到对象时有困难。
原则四：建立模块化的和水平式的设计结构，并使项目结构反映产品结构的特点。
微软产品设计中的一个关键概念是产品的基础结构——尤其是生命周期短的应用软件——应随项目的进展变得更加单一（而不是错综复杂）。当开发组构造产品的第一版时，他们更多地使用分级式结构，好为产品设计规定出一个最初的架构。然而，随着时间推移，他们向单一的结构迈进，以使项目能集中于特性开发。项目需要逐渐地增加和删除特性，随着时间改变和发展特性（比如从基于字符的界面向图形用户界面过渡），以及增加产品间特性表现和运作的一致性。就像第6章将要详述的那样，微软越来越强调不同产品间的特性共享。共享有助于使不同产品的“性能与感觉”都统一协调起来；它也方便了需要不只一个应用软件的用户，减少了代码的重复书写，缩小了单独一个应用软件的规模。
正如第2章所述，微软力图使项目结构反映产品结构的特色——它用特性组织产品，用特性小组组织项目。这种方法使得每个人都容易明白小组是如何与整个产品相关联的。项目从规定概要说明开始。概要说明的形式是一份已确定了优先级安排的内容清单，涉及产品下一版本将要开发的相对独立的特性；例如，Office有一些诸如编辑文件、操作表格、格式化数据的特性。这些特性并非完全独立，因为编辑文本特性依靠打印特性来打印，依靠文件管理特性来存储文本。不过，相关的特性组应是足够独特的，这样项目才能由分开的特性小组加以开发。
程序经理和开发员把项目分成特性子集，再将之分配给每个特性小组，让他们在3到4个主要的内部项目里程碑中进行生产。对于Office软件，微软还把项目分成Excel特性，Word特性，Power Point特性以及对所有这些产品通用的特性（通常由Office开发组来构造）。第5章分析了开发员从整体上协调与演进产品的技术，如每日构造与同步。这种产品组织与开发法使微软能靠简单地增加开发员和创建一个大的小组来渐进地增加产品的功能。正如克里斯·彼得斯所说的那样：“我们[在Excel3.0上]有一个非常大的开发小组可能会让一些人感到惊奇的是它确实有用。你实际上可以写许多特性。让我们设想有大约30个人。我们做的特性是10个人做的三倍吗？不，我们大约只能做10个人做的两倍。比起Excel产生的收益，Excel的开发成本是微不足道的。事实是我们用30个人做20个人的工作，实际上得到二倍于以前所能得到的特性。这使我们相对于Lotus有了巨大的比较优势。”
把特性（与函数）当作建筑材料微软产品的特性是用户最终可见的相对独立的功能单位。它们就像建筑材料，对应用软件产品更是如此，例如打印，自动选择一行数进行加总计算，或为一个特定销售商的硬件装置提供接口。系统软件产品，如Windows NT或Windows95的特性，对最终用户通常并不直接可见；微软和其他公司有时简单地称这些不直接可见的特性为“函数”。
程序经理承担开发一组特性（或函数），努力使其实现从说明经测试、文档化直到最后完成的过程。他们必须与开发员合作，后者负责估计进度表与完善每个特性。开发员还要在一台联网开发计算机上存储一到几个文件，用以保存特性的程序源代码。
大多数特性的开发与改进只需要一名开发员，而有的大型特性则要一个小的小组。造成这种差别的原因是一个特性的复杂程度是主观的，取决于开发员对它的认识。一个特性只需要一个人工作的例子是为Word增加字体。在最近的产品中，一些特性是如此之大以致个人要工作整整一年。大多数特性需要用时约三人周——即一个人工作三周。最小的特性也许只花三天左右。一个非常受欢迎的特性，Excel的“自动汇总”特性，只用了一个人一周的时间。
产品结构——为特性服务的产品内部的灵活构架产品结构是产品内部的基干，它规定了重要的结构构件以及这些构件如何组装到一起。产品结构及用于组装结构的构件，提供了实现产品特性（即做详细设计与编码）的支柱。产品的结构对最终用户而言通常并非直接可见；只有结构要实现的特性是可见的。产品结构也是决定产品长期结构完整性的基石。产品功能的任何改变都不应造成潜在的产品结构散架。
微软倾向于使它的产品结构非常灵活，以利于渐进性的添加、删除、完善或集成产品特性。好的产品结构减少组与组之间，包括微软内外开发员之间的内部依赖性。比尔·盖茨在我们的采访中强调了这一点：
如果有100人卷入了[Windows]NT的开发，那么实际上是有10000人卷入了，因为所有在公司外写NT软件的人，以及那些写实用程序和用户界面程序的人，都在工作。于是有一系列关于内部互相依赖的工作怎样进行的问题。好的结构甚至能减少开发组内部的依赖性。
产品结构层我们也能从“层”以及层之间接口的角度来描述一个结构。低层为结构中的下一更高的水平层提供一系列的功能与能力。软件公司通常把最低层叫做系统“内核”；最高层提供功能与能力——即最终用户看到并使用的特性。有时最高层下面的功能和能力也能被最终用户看到。做一个粗略的类比，层化结构就像一个洋葱。一个洋葱有一个内核（或核心），它有许多环绕核心的相连的层，但顾客只能看到最外层。创造和规定功能层之间的完全抽象的接口有助于把产品的功能与下面的细节隔离开。这些细节包括对特定硬件平台，如Macintosh或运行MS-DOS和Windows的PC的依赖性。
在软件结构中，主要的规定性概念是对每层间接口的定义。第3章把这称作应用程序编程接口（API）。API规定了结构中一层的公开进入点，这使得处于高层的产品部分对其调用成为可能。产品层由上千的“子程序”或计算机代码指令集组成；开发员通常只让其中的少数能为程序的其他部分运用或调用。典型地，当一个项目把产品分成许多部分让不同的小组去开发时，他们同意每个小组去定义应给其他组提供什么类型的功能与能力。这些定义通常以API的形式给出，它可能是关于过程名、每个过程应接受哪些参数以及对每个过程应干什么做简要描述的清单。定义良好的结构层与API，有助于对产品特性进行灵活的增加、删除与改进。
的结构通过使用通用层获得可移植性结构中的每一层都有一个应用程序编程接口，它定义了本层的功能与能力。对不同操作系统平台上使用的不同版本的Excel，前四层API是一样的。Excel最底层的API随基本平台（如Macintosh，Windows，OS/2或Windows NT）的不同而不同，但由于微软对通用可移植层使用了与平台无关的API，Excel代码的外壳便与这些差异隔离开了。
产品结构展现了水平产品结构层的概念。在这儿，我们从高到低列出Excel的五个结构层：
·公式与公式操作。
·格式表（创建格式或展示数据的方法均经过良好定义）。
·单元格（数据放入单元格，单元格计数等方法均经过良好定义）。
·通用的可移植层（专用于Excel的小型“操作系统”或核心）。
·操作系统（诸如，Windows95，Macintosh或OS/2）。
的通用可移植层是产品结构的一个重要技术策略。这大大方便了在不同硬件和操作系统平台上重复使用应用程序代码的重要部分。在一定意义上通用的可移植层像一个小型的“操作系统”，可在Excel应用软件的特性与基本操作系统软件，如Windows或OS/2之间专门作为接口服务。正如乔恩·德·沃恩所详述的那样：“我们按〔通用〕层写Excel，它是我们的操作系统版本。我们在Macintosh，Windows，OS/2上实现了它，现在又在Windows NT上实现了它，最后这个工作做起来非常轻松。通用层几乎是Windows版的，刚刚又在Win32上通过了编译。它是一个相当棒的对图形环境概念的实现。我们利用这个层，在Mac和OS/2上做了Excel2.2.”
并非每个微软的应用软件产品都有一个像Excel那样的通用可移植层。例如，Word就没有。Word6.0用Windows API来近似地作为一个通用层，尽管初次尝试的结果就像最初的Macintosh版那样表现不佳（见第3章）。Excel组在产品开发中较早地编写了他们的通用层，以便于在Macintosh和PC机器上使用相同的代码。德·沃恩总结了Word的通用可移植层的开发情况：
例如，Word努力使自己有一个通用层，它们将用Windows API作为它们的通用层。我们〔Excel〕早就做出了通用层。以前这纯粹是一种试验，因为当我们考虑该问题时，我们内部都对此存在明显的怀疑：你能不能用这种办法写出勉强能够满足要求的程序呢？于是我们必须在Excel上做实验。在那时，我们认为无法用Windows API作为通用层写出一个好的Macintosh程序部分原因是由于我们了解两种API，我们在Mac API上做了Mac Excel1.0，在Windows API上做了Excel2.0.这两者很相似，同时又很不相同。我认为在很多时候我们对差异估计过大：“哇，这些差异是没法直接克服的，我们认为自己做不了。”但当你对事情更熟悉之后，你会对此有不同的认识。
的产品结构作为产品结构的另一个范例，Windows95用专门的层来支持大范围的应用软件，包括32位，16位以及DOS应用软件。这些被称为“虚拟机器”的层提供独立的处理线程和被保护的区域；每个“虚拟机器”看起来都像是一台让程序运行于其上的单独的计算机。所有的Windows应用程序，包括16位的Windows3.1应用程序与32位的Windows95或Windows NT应用程序，都在系统虚拟机器层上得到执行。在系统虚拟机器内部，每个32位应用程序都有其私有的“地址空间”。私有的地址空间可以防止应用程序的数据干扰其他应用程序的数据或使其他应用程序异常中止（或叫“崩溃”）。所有16位应用程序在系统虚拟机器中共享一个单一通用的地址空间，这样它们就仍然可能互相干扰（就像它们在Windows3.1中那样）。Windows子系统支持系统虚拟机器，而Windows API则规定了Windows子系统的能力。每个DOS应用程序在其各自的DOS虚拟机器中执行，使用各自私有的地址空间。
的基础系统提供了产品结构中的最底层，它支持系统虚拟机器，Windows子系统以及DOS虚拟机器。基础系统包括一个文件管理子系统（磁盘文件，CD-ROM文件等等）、网络子系统（包括远程计算机存取与数据共享协议）、操作系统服务（即插即用结构能力、日期/时间功能等等）、虚拟机器管理器子系统，以及设备驱动程序（键盘、显示器、鼠标等等）。基础系统中的虚拟机器管理器子系统构成了Windows95操作系统的心脏。虚拟机器管理器子系统实现基本的系统功能，如处理调度、内存操作以及程序的开始与终止。
产品子系统产品结构的水平层中含有一些各不相同的子系统或是功能与能力的子集。每个子系统有一个API，该API是子系统所属结构层的API的直接子集。例如，Windows3.1开发出了“通用打印子系统”概念。这里的API很简单，它使第三方销售商能用更简单的方法来编写打印驱动程序（打印机驱动程序是一个随销售商不同而不同的小程序，它对销售商销售的特定的打印机进行控制）。布兰德·斯尔文伯格描述了通用打印子系统的好处，以及微软如何在通用视频子系统与其他地方应用同一概念的：
对Windows3.1，我们使用了新的打印机驱动程序结构，我们称之为通用驱动程序。它是一个功能强劲的通用打印机驱动程序，起着引擎的作用，使我们运用微型驱动程序Windows95产品结构资料来源：艾德里安·金：《深入Windows95》（Redmnond，WA，微软出版社，1994），第64，105页。
的可拆卸的模块成为可能。在简单的情况下，他们〔指编写打印机微型驱动程序的人〕基本上只需写出与打印机通话用的转义序列表，所有的光栅操作〔如计算机对线的定位〕以及所有的设备管理就都由我们提供的部分〔子系统〕完成如此一来，编写打印机驱动程序就从原来要花一个非常有经验的人6个月时间才能写出一个难懂难改的庞然大物，变成了一件只要读懂打印机手册，查查转义序列表，花上两到三周时间就能完成的事情了。结果自然是对于Windows3.1，我们有很棒的打印机驱动程序，并且可以驱动更多的打印机。打印机驱动程序过时问题也不再困扰大家了，我们从PSS处得到了许多这样的信息我们现在正在对大多数其他驱动程序运用相同的基本原理。由于我们还没有对Windows3.1的视频使用通用驱动程序，于是视频驱动程序就成了一个难题，视频驱动程序常有错误，从而导致系统崩溃。于是，对芝加哥版[Windows95]，我们使用了通用视频驱动程序结构，为各个显示卡附上小的可拆卸的微型驱动程序。我们对通用调制解调器驱动程序也在做同样的事，安上小的可拆卸的调制解调驱动程序。我们对硬盘和其他东西也在这样做。
特性优先的产品结构与表现优先的产品结构许多现存的微软产品，如Office与Excel，均为“特性驱动”的产品结构。然而，对一些刚出现的产品，如用于“快速响应视频”的Tiger项目或其他的多媒体项目，要求有“表现优先”的产品结构。结构不同是有原因的。例如，传送视频和音频信号，要求即使在负荷很重的条件下也要有可靠的实时系统表现。（“实时”指产品必须在一定期限前瞬时地进行某种操作，如传送视频音频信号，否则信息就没有用了。）根据研究部副总裁瑞克·罗歇德的说法，这些不可调整的表现优先的要求与微软传统的产品特性概念不符：
在像Word和Excel这样的产品中，对在某个时间内完成某个操作可能也有目标规定，但是它们不是硬性规定，不须严格照办；它们只是讲应该做到差不多这样。但是当你考虑视频信号传送时，例如通过有线电视网或是电话线或甚至是标准计算机网络传送，你就必须给出一个非常非常严格的保证，讲明信息何时到达，必须以多快的速度处理才能使之正确发挥功能。系统在重负下的表现必须被完全地规定下来。绝不能让系统在重负荷与轻负荷的情况下表现得很不一致。要确保系统在重负荷下能够按规定表现，并且负荷超过一定点系统就拒绝接受进一步的负荷增加，这样才能维持住前面的保证。
微软开发这些表现优先型系统的过程包括，在所有可能的负荷情况下，对经保证的表现进行数学与算法设计。这个开发过程强调“错误容忍”功能，这指的是在操作中，系统能从失败中自动恢复。例如，第3章讨论的Tiger视频服务器项目开始时只是一个研究活动，经历了广泛的最初分析与模拟阶段。现在它转入了高级消费型系统部，由罗歇德充任交互式电视及视频系统开发主任。项目花了6个月时间来定义基本的系统思想以及生产最初的工作版本。在开始编码前，研究组必须指明系统的重要表现元素。研究组也使用了诸如经常构造、里程碑等老过程，并且允许说明不断改进。首先强调表现，而非强调特性或功能，同时需要预先分析与模拟，这或许就是这些新系统类型与微软通常构造的其他产品类型相比，所具有的主要特点。罗歇德继续讲道：
我认为那就是重大差异可能存在的地方，更传统的方法会是，比方说，首先搞出功能，然后再解决表现问题而强调表现则是当有重要的强制因素时，你必须首先通过分析和建模型来从算法上解决那些强制问题，然后考虑还想在它上面增加其他什么特性或想做其他什么事我认为差异可能是，一个做法在过程的早期就提出了行为中的表现与质量分级问题，而不是像任何计算机项目中可能更传统的做法那样，把这些问题留到过程的后期。
小的结构文档：源代码是唯一文件与“黑客”传统相符，除了API文档，微软不对其产品结构生产什么文档。有时高级开发员写下高层结构，但这最终还要取决于开发经理。对复杂特性，许多开发员在某些点记录并复查特定于他们所负责特性的结构细节，但做不做由他们自己决定。除了源代码文件与特性，为数不多的组为新程序员准备了描绘某层结构的文档。例如，一份8页纸的文件就把Word的内部结构解决了（主要的数据结构，它们如何工作，等等）。然而，人们不常更新这些文件，经理们也不要求项目生产这样的内部文件。
相反，说明不涉及实现问题；开发员应该知道如何去实现，或者能够去学会。克里斯·彼得斯解释道，记录的关于结构的文档如此之少是因为“一个开发员的工作是编写我们要卖的代码，而不是花时间写高水平的设计文件。”比尔·盖茨支持这个观点，强调设计文件不应该与源代码分开：“〔有〕一些方法使你拥有独立于源代码的文件。〔如果你认为〕靠走弯路和在那些〔其他文件〕上花大量时间，你会获得更高的效率的话——那简直荒谬可笑。自然界中很多相当刻板的法则都是非常可笑的。这样，许多讲实效的人就边构建很棒的设计边创造很棒的软件一个文件。那就是源代码。那是你去的唯一地方。你在那儿学到所有的东西，你也知道那儿的所有东西。”
分割代码与“保持事情的简单”
微软不是依赖有关产品结构的文档，而是靠开发员来分割代码。这通常有效，但并非百试百灵。乔恩·德·沃恩描述了对开发员的依赖：“我们不做——我们经常陷入这该由谁负责的争论中——许多的全面设计工作，像‘那个特性应放在这个模块中，这个特性应该是那个的接口’这样的事我们不做。我们依赖人们的判断力，他们正确地分割事情。有时人们做不到，那就有麻烦了。”德·沃恩强调，微软也力图使设计和代码尽量简单：“我们的另一类指导原则是‘保持事情的简单’，除非万不得已，事情就没必要搞复杂。我不确定是计算机科学那么教的还是别的什么原因，令人吃惊的是，人们喜欢把事情搞复杂，即使那样做是不必要的。”
分割与简化的一个例子是德·沃恩在Excel5.0上参与过的一个“回到存盘”过程。原先的过程很复杂，影响到程序中至少20处不同的部分。因为人们不大用到该特性，开发员经常会忘记了它的存在，在做一个与此特性无关的改变时，就“破坏”了该特性。结果便是该特性一直有很多错误。德·沃恩用简单得多的设计替代了先前的特性，把功能集中在代码中的一个地方，于是在系统其他部分工作的开发员就不用担心弄坏它了。本·斯利夫卡，MS-DOS6.0的开发经理，给出了另一个例子，描述了糟糕的分割以及他的一个产品部分中过度复杂的设计：
之所以把Double Space管理器的用户界面与压缩工具库（CEL）分开设计，是为了能在不需要修改CEL的情况下写出基于Windows的UI[用户界面]。CEL能理解所有的CVF〔压缩后的卷文件〕细节，如格式、重启性等等。不幸的是，这个概念未被执行，于是重启性，牢固性，以及CVF的限制与性质的重要方面都被分散于〔Double Space〕管理器与CEL之中在将来，我们应确保所有小组成员都用面向对象的设计方法，集中于数据隐藏和接口最小化，以保证代码是模块化、分离化和可维护的。搞一个两到四周的教学期，讲清在何处设计与实现项目将会是一件非常非常有益的事。
产品规模增长微软和其他公司运用产品规模度量制使开发员明白他们的产品从一个版本到下一个版本有多大改变。不断增加新特性和图形能力会造成源代码行数和可执行文件长度的极大增长。例如，Mac Word从3.0版到4.0版，源代码行数增加了68%，从152525行变到了256378行。规模出现极大增长的其他产品还有Wordfor Windows（从1.0到2.0版本增加了31%），Excel（从到4.0版增加了31%），Projectfor Windows（从1.0到3.0版增加了85%）以及Windows NT（从最初的开发员工具包2.0到β1增加了109%）。
增加的特性会证明规模变大是值得的。然而，开发员和测试员却不得不受折磨，去理解、修改、测试与调试不断变多的代码。当代码增加时，开发员通常力图分割代码并确定各部分之间的依赖性。这些方法有助于使修改、调试以及测试特性的时间长度保持在可管理的范围之内。在有些情况下，项目组不得不改变他们的开发风格。例如，Office就曾采用过两步制构造过程，以适应巨大的代码量和减少产品构造所用的时间（见第5章）。
开发员还应尽量减少产品需要占用的磁盘空间量。该空间量是产品的“可执行文件”的大小。它会影响到产品在软盘上的存储以及内存的占用情况。然而，产品可执行文件的大小不容易管理或预测。它依赖于特定于产品的代码和数据的数量，以及一个产品中或从其他产品“链接”到一个产品上的可复用或可共享代码的数量。例如，Word、Excel和Power Point作为Office套装软件的一部分共享某些特性；Office还直接与Windows操作系统的某些文件链接。若比较单个应用软件的可执行文件的大小，单独安装就比把三个软件都作为运行于Windows上的Office套装软件的一部分一起装上时大。因为这个原因和其他原因，在代码行与可执行文件大小之间没有直接的对应关系。另一个实例是Wordfor Windows1.0与Projectfor Windows3.0，两者的源代码行数相近，但可执行文件的大小则差距悬殊。
微软的项目同时使用实际数字与图表来记录可执行文件的大小，然后开发员花一些时间使代码简洁紧凑和有效率，以力图缩小可执行文件的规模。例如，显示了Wordfor Windows2.0可执行文件规模的增长情况。1991年5月到6月的跃升和同年8月到9月的缩减反映了特性的增减、使用和去掉调试代码、代码优化，以及其他一些因素。
特性小组和作为“内容专家”的小组领导在第2章中，我们把特性小组描写成这样一个小团体：它由一个领导和3到8个开发员组成，工作于相关的特性领域。小组的规模常常视小组领导的经验和能力而定（更有经验的领导带更大的小组）。特性小组领导向项目开发领导汇报，并负责项目的全部开发工作；而项目开发领导则拥有对产品的更为全局性的观点，从而最有可能发现内部互相关联的问题。乔恩·德·沃恩认为特性小组领导是微软开发过程和吸纳新人能力的关键：“特性小组领导非常重要，我认为他们是使整个过程有效运作的最重要的因素。因为当工作要求很急而人员又需要指导时，他们就是那些居于此位而有责任提供指导的人。他们还负责编写大量的代码。”
在20世纪80年代晚期，几个组都差不多在相同时间开始使用特性小组。Excel是带头人之一，在1989年和1990年间制造3.0版时率先采用了特性小组概念。该组当时只有几个小组，然而从那时起，这个数目就大大增加了。例如，Excel5.0（1993年晚期出品）有10个特性小组：8个工作于基本的Excel产品，一个工作于单独的Graph产品，另一个工作于Query Tool产品。Word6.0Wordfor Windows2.0可执行文件规模增长度量制范例（1994年早期出品）有六个特性小组。
项目也以特性小组为中心。考虑到它的规模（超过了100个开发员），经理们一开始就把特性小组又组合成了三个大的独立的组：一个组负责Windows95基础，一个负责网络，最后一个负责可移动的构件（项目后来合并为网络组与可移动构件组）。正如布兰德·斯尔文伯格所解释的：“可移动构件组下有两个特性小组，网络组下有半打，基础组下约10个，基础组最大，人也最多，完成的产品的部分确实也最多。他们构造文件系统，外壳，底层的内核，设备驱动程序，所以有10到12个不同的小组。每个小组有一名特性小组领导和一名程序经理来负责该领域。对每一个领域如果特性小组领导能力很强，他带动全小组前进。如果程序经理能力很强，则由他带动小组前进。如果他们能力都很强，他们就共同带动。”斯尔文伯格把Windows95中负责主要的独立组的人看成是“内容专家”：
在我的组中，我把他们分成三个主要组。这三个组在我的组中是相当独立的，他们内部各自有程序管理，开发和测试——所有有关开发问题的部分。一个组负责基础部分，一个组负责网络部分，一个组负责可移动构件部分，因为这样可以使这些组仍然相对较小并保持等级制度的平缓。负责这些部分的人将是内容专家如果你去看成功的软件产品，那些我在Borland与在这儿，微软都与之打交道的产品，你会发现处于做决定位置的人——程序经理，测试员，开发员，市场营销伙计们——都是内容专家。他们了解那些产品，他们了解如何使用产品，他们了解竞争对手的产品，他们了解未来将向何处去，他们也了解技术。他们是产品人；他们不只是管理人员他们是内容专家。当你了解产品时，你就能作出正确的决定。当你不了解产品，当你仅仅是力图照着说明，依葫芦画瓢地构造产品时，你就抓不住什么是重要的。你没有关于优先级的感觉，也感受不到什么确实是重要的和激动人心的，什么是确实重要的马上就应开始做的。
斯尔文伯格也强调要保持特性小组的小规模，使工作联系紧密，因为产品有与创造它们的组织相似的倾向：
软件倾向于映射出构造它的组织的结构。如果你的组织庞大而迟缓，你就很可能造出庞大而迟缓的软件。如果你的组小而灵活，交流充分那么它写出的东西也会是互相配合得非常好的。如果你有两个组，它们最后应交付密切配合的软件，然而两个组之间相处得不好的话，你最后得到的通常会是两个组或两个构件之间非常正式的接口正因如此，我经常只要看看一个软件就能告诉你造它的公司的情况，准确性还颇高。你让15个人去写编译器的话，往往会得出须经历15次通过的编译器。经历15次通过的编译器一般是慢不堪言的。
每个人都是某个功能领域的专家许多微软的产品现在是如此之大，以致经理们鼓励开发员成为部分代码的专家。结果，开发员常与其他开发员——“当地专家”商讨——以进行可能影响到其他特性的编码与结构决策。例如，Windows NT有成百上千的功能领域。一些个人在各自的地盘内成为专家。像Excel和Word这样的产品小一些，但它们也有成打的功能领域，每一领域亦有专家。娄·帕雷罗里对此评论道：“我们做的一件事是确保每人都有其专门领域我认为这有两个作用。一，当你有难题时有地方可去，你可以找该领域的专家。二，它让人们自我感觉良好，因为他们是这个领域的专家。我们并不鼓励人们只成为一个领域的专家。”
像在所有的软件公司中一样，一些开发员比其余的有经验得多，技巧高得多。微软的项目利用这种差异带来的好处，把最困难的任务和领域分配给最能干的人，通常，只有更有经验和天赋的开发员才能作同时影响到产品许多部分的改变，如更改NT内核的代码或Excel的重复计算工具箱。克里斯·彼得斯评论道：“不管你处在开发的哪个层次上，老的模式——一些开发员比其余的好10倍——总是正确的。总有一个家伙比你强10倍。如果你是这个牛气十足的家伙，你就会担负巨大的责任了——责任总是按一个实际的特性涉及面的大小来分配的。如果只是个相当小的独立的特性，我们会倾向于把它交给一个经验有限的人。但如果特性有各种副作用和衍生分枝，它就会被交给一个更老练的人。”
下一个原则描述基于特性的产品组织与基于特性小组的项目结构如何也形成了项目进度安排的基础。
原则五：靠个人负责和固定项目资源实施控制估计产品的开发与交付进度是一项富有挑战性的任务，尤其是在软件项目中。有许多因素会影响到进度，并且测量开发过程也很困难。微软解决这些困难的方法是把进度安排和工作管理的责任推到最底层，即单个的开发员和测试员那儿去。这保证了每个人除了作为小组的一部分来表现外，还负有个人的责任。单独的开发员设立他们自己的进度表，程序经理把单独的进度表加总起来，再加上缓冲时间，以制定出一个全面的项目进度表。顶层的总经理也固定基本的资源——人员与时间——以确保项目集中并限制其努力与创造程度。
关键的目标，尤其对应用软件，是指明产品的目标出品日并争取尽可能长久地坚持它。程序经理和开发员然后从出品日回溯，规定中间的项目里程碑的日期。这个“固定的出品日”法的中心在开发员身上；动机是减少这样的情况：项目没有定义结束点，因此在最终是无用的设计、再设计和测试的循环中消耗一年或更多的时间。这些看起来无休无止的循环及相当不准确的进度表在微软中曾是普遍现象。当经理们对项目控制不严时，这些情况还不时发生。这种失控的项目使员工、经理和顾客都感到灰心丧气。用布鲁斯·雷恩的话来说，一名程序经理“捏造进度，无论是有意还是无意，对谁都没好处。”
开发员做出他们自己的进度估计在过去的10年左右，微软靠让那些将为特性编码的开发员估计他们需要的时间来为项目做进度安排。高级经理一般不交给人们进度表，然后告诉他们要在特定的日期前完成工作。许多美国、日本、欧洲的公司都用这种专断的态度做进度安排，虽然它们通常也要与开发员商量并浏览其他项目的历史资料。比尔·盖茨强调，微软让开发员和小组设定他们自己的目标：“所有这些日期都是小组定的日期。没有其他人来试图设定这个日期。我们在大约10年前就抛弃了那种自上而下的日期设定方法。”
基于开发员的估计也随之带来了问题。经理们不得不对开发员过分乐观的程度做出猜测，并相应调整项目进度表。与之类似，经理还必须增加缓冲时间来解决可能因信息不完全而出现的问题。这类进度安排就不如另外的一些那样精确。例如，对每个开发员在特定类型项目上做什么来保持详细的记录，编制不同行为的统计平均值或“标准时间”，然后再用这些资料做项目估计与控制。（这种更工厂化的风格在大的日本软件制造商那儿很普遍。19）然而微软的基于开发员的估计方法有两个主要优点：它从人们那儿得到更多的合作，因为日期是自己定的，不是经理定的；进度总是富有进取性，因为开发员不可避免地会低估他们真正需要的时间。
在过去几年中，微软的项目改善了他们调整估计的能力，并加上了适当数量的缓冲时间。现在，许多开发员对过去的项目保存了他们自己的记录，以观察他们的估计有多准确。项目成员、小组领导以及开发经理经常接触以前项目的资料从而帮助调整他们自己的估计，虽然经理并不要求项目保存和分析这样的历史资料。虽然微软的进度安排方式给了开发员一种更大的“自由幻觉”——这是克里斯·彼得斯的叫法，但如此一来，就要在准确性上作出牺牲：
从心理学上讲，让写特性的开发员估计特性的进度是必要的如果你想要按时推出产品的话，这是你能做到按时的唯一办法。因为如果你把估计写好交给一个人，那么它并不是真正的出品日，它是你所以为的出品日。于是，如果他们做一个特性花的时间比你规定的时间长，你就被证明只是个傻瓜。他们会认为你并不了解事情如何进行。你永远不用担心开发员产生的估计会过于消极被动，因为开发员总是弄出太乐观的进度表。这样，仅仅靠给人们选择权，让他们估计自己的特性的进度，你就能造出自由幻觉，同时仍然有一个非常雄心勃勃的出品日期至少在这个地方[微软]，你永远不用担心进度表是由开发员完成的，并且开发员完全拥有它。
对细致的任务的进度估计微软的第二个进度安排方法是，对要完成之任务做非常详尽的考虑，在此基础上请开发员给出他们对“实现”的估计，以此力图“促使”更加现实主义并避免过度低估（20世纪80年代曾发生在Wordfor Windows和许多其他项目上）。通常把任务细化到4小时（半天）到3天之间。有些组，如Excel，便在这个范围内。正如乔恩·德·沃恩所说：“当我们做进度安排时我们力图把进度细化到任务不超过两天。对不同特性而言，有的可能只有一个任务，有的则可能有20个任务。”这股朝向更细致的进度安排的力量很重要，因为开发员不善于具体地考虑特定的任务要花多长时间。克里斯·彼得斯曾在Excel和Word中推广更准确的进度安排，现在则在Office组中推广。他解释道：
任何任务只要超过一星期，那人们就一定没有充分地全盘考虑它。任何任务某人估计只用少于半天就可完成他对它则考虑得太多了；他应该用更多的时间去编程，更少的时间来考虑。经典例子是，你问一位开发员要花多长时间来做某事，他回答说一个月。一个月其实就等于无限长的时间。于是你说：“好吧，一个月有22天[工作日]，你在这22天中要做的22件事是什么呢？”他会说：“喔，这个，也许它要花两个月。”即使把任务分成了22个任务他还认为，“喔，它比我认为的要难得多。”于是我们通常力争把任务弄得小于3天。
为系统软件产品做进度安排更困难。砍去特性不再是容易的了；而且，产品的可靠性与功能通常比按时出品重要得多。不过，像Windows NT这样的项目在早期强调了细致的进度安排（几天或半周的工作），以后则把注意力更多地放到了对构件进行集成与全力完成产品上。正如娄·帕雷罗里所回忆的：“当我们做最初的进度表时，我们确实力求把事情的进度安排在几天内或半周内然后我们力争有一个集成期。很明显，估计软件设计简直如同巫术。我们的一个大问题是，你永远达不到人们想要的功能水平。你做出了你许诺要交付的东西，然后人们说：‘哦，看看，你没有处理这个。’或‘在这台机器上他们的接口有点不一样，你必须处理这三种情况。’于是我们在最后就要考虑许多额外的因素，并通过测试把它们集成进产品。”
安排开发员与小组进度时的心理学我们已提到过，当项目变大时，微软把员工分成小组。然后经理把进度的责任和所有权尽可能低地分发下去，直到小组和个人；这使二者都产生了一种拥有工作的感觉。它还在小组中，个人中，尤其是小组领导中造成强烈的跟上预计进度的同事压力，因为经理可能再平衡进度，从落后的小组或个人手中拿走工作。这样，同事压力使经理不太需要努力就可以对个人或单个小组的进程实施严格控制。
例如，Excel3.0（及最新的Word版本）就使用了这种进度安排心理学。几个特性小组做出了自己的进度表，他们相对自治地工作，互相激烈竞争以保持进度。结果是甚至一个大组（整个Excel项目）也像自己设定目标与时间界限的自治小组那样工作。Excel组并没有单一的、协调的进度表，然而项目推出仅仅比预计晚了11天。克里斯·彼得斯回忆了这次经历：
为了把责任分到尽可能低处，我们让每个特性小组制作他们自己的进度表。不光是出品日对每个人来说是重要的，它还意味着每个特性小组领导希望他们能确保按时推出实际上并没有协调的进度表，换句话说，如果你有5个特性小组，当人们犯了错误并且特性尚未完全造出时，你实际上会有五个不同的出品日。于是在每一个里程碑时间，你将再度平衡进度表：你会或者砍掉特性，或者将它们在特性小组之间重分，直到事情重新变得平衡，这时你就能向下一个里程碑迈进。最后的情况是，你得到了各种各样极好的东西。此时，一个特性小组中的伙计甚至会更不愿意犯错误，因为在这个管理者被挑出来做特性小组领导的公司中，在他的直接同事可能做得更好或更差些的情况下，犯错误使自己显得不像个很好的新管理者。比起以前所有这些人只是跑来告诉一声“啊，我有点晚”的情况来，这对出品日所有权的影响甚至更强。基本上，我们以前一直在试图想出一种办法，使我们可以产生出与更小的组相同的行为模式。
“固定的”出品日当然，当经理把如此多的权力委托给了个人与小组时，潜在的危险也增大了。麦克·康特，他曾对Excel5.0的进度情况做过记录，回忆了微软的进度安排有多糟：“软件开发的大问题之一是你的进度表很不确定。那总是个大问题在有的令人尴尬的情况下，微软中曾出现过本应花两年左右时间的项目竟花了8年来开发。”根据康特的说法，微软中项目进度打滑的一个基本原因是，开始一个项目时没有固定的出品日，这样一来，对项目试图做些什么就没有限制，对怎样确保开发中产品的质量也没有认识。我们在第1章提到过，这种情形会导致微软的人们称之为“无穷错误”的状态——即使在开发员认为错误已被消灭了之后，项目还持续地产生数量巨大的错误，因为每一行由开发员写出用以修复错误的代码往往又产生另一个错误。于是开发员面对的是经年累月的调试与返工，无法预测何时结束。
有鉴于此，为了把创造力约束在时间限制之中，微软现在在新产品或产品新版本开始前争取固定出品日——至少是有出品日的内部目标。这给人们施加砍去特性和集中在一个项目上的压力，逼迫他们去苦苦思考那个绝对应该进入一件新产品的关键特性。虽然最终产品的交付目标可能由高级执行人员设定，但开发员与小组仍然设定他们自己的进度表。克里斯·彼得斯详述了固定的出品日的优点：
我们努力做“固定出品日”发送的原因是，这逼迫人们拿出创造性，并做出在浮动出品日下无法完成的困难决定。你也许会想，“我应该做30个还是20个特性呢？”如果出品日不固定，答案常是30个。“我们是做大而复杂的版本，中等版本还是小而简洁的版本呢？”“啊，我认为我们应该做复杂的版本，我们只要移动一下出品日”这样，固定的出品日通常被采用，以强迫人们提供那产生了80%收益的20%必不可少的〔产品〕记住，问题不是缺乏主意，而是主意太多。这样一来，你靠做什么来给自己约束以找到那绝对重要的主意？
彼得斯把1990年Excel3.0的几乎准时推出看作他的“最高成就”。这个项目保持着微软中一个相对较小，但相当复杂的应用软件按时推出的进度安排记录：“一般说来，我们推出产品往往延迟半年到一年，微软的有些部分肯定还在常这么干。但数年前我们努力创造了一个信息反馈环路，了解是什么造成延迟，并力求对其进行改进。我们那时就能做得不错了；现在，甚至是一些灾难性事故〔通常〕也被控制在只比原计划晚60天以内。但还没人打破只晚11天〔的记录〕。”
固定出品日概念用在系统软件产品上的程度要低得多。一个大的负面因素是限定出品日一般会造成在项目末尾处，测试时间和质量保证行为的时间不足。考虑到一个操作系统必须工作于其上的复杂多变的用户情况（设备与应用软件的不同组合），相对于应用软件，测试和质量保证行为对系统软件往往更为必需。本·斯利夫卡总结了对MS-DOS6.0项目而言，固定出品日方法的有利面和不利面（我们将在第6章对此深入讨论）：
产品组确实在整个项目期间都时刻关注着出品日。我们都对我们要去哪儿有明确的认识，并记牢了要到达目的地就必须做出的那些取舍。共同的目标是把小组团结在一起，使之发挥巨大力量不幸的是，在一定程度上我们成了出品日的俘虏。如果在创造性的测试以及查找尚未发作的错误上多花点时间，也许对避免顾客正经受着的一些问题会有所帮助。虽然不清楚我们当时是否会找到并纠正那些发布以来遇到的问题，但结束时更为从容的气氛会给我们更多的机会。
跟踪与宣布出品日与20世纪80年代的做法比，组程序经理，开发经理，产品单位经理以及高级执行人员现在都对主要产品在开发进度表上处于何种状态保持相对较新的记录。即使如果直到里程碑交接处前经理们都不干预或再平衡工作，他们也在做这项工作。许多组现在也有记录估计时间与真正进程数据的相似的度量制，并使用或是微软的Project或是一份Excel电子表格来收集和显示数据。（比起Project来，Office组与其下的产品单位更喜欢Excel，这主是要因为Office的人对Excel更熟悉。克里斯·彼得斯也说，比起管理像软件开发这样的单独任务来，微软的Project更适合管理对飞机和建筑物的设计。）例如，展示了Power Point3.0的项目进度表。原定的交付日期是1992年3月；在同一年5月产品推出前，该组几次修改了这个日期。对目标日期的一次重大修改发生在1992年1月1日左右，项目大约已到了代码完成里程碑时。当一件产品到达此点时，往往四五个月后就可以发行了。
直到产品确实已经准备好了进行商业发布前，微软不太喜欢宣布一个计划的出品日。然而，正如第3章提到的，为了战略上的原因，在有些情况下，微软和其他公司也非常早就宣布其新产品计划。早期宣布（软件行业内称之为“蒸汽品”）可能是发出要进入新市场或有意向一位特定的竞争对手挑战的信号，从而防止顾客去买另一公司的产品。然而，一般说来，过早宣布计划的交付时间减弱了变化开发计划的灵活性，给了对手再反应的机会，并且在出品日错过（经常如此）时引起负面的新闻报道。麦克·梅普尔斯对此评论道：
我们也已走向保守，在产品没准备好推出前就不宣布出品日。除了系统软件，至少其他所有产品都是如此。对为什么早宣布是有益的，市场营销人员总是有很好的理由，但几乎每次的结果都是，从某种市场营销的意义上讲，早宣布确实未带来益处。其次，你常给竞争对手一些信息和更多的时间来做出反应。第三，你完全搞乱了自己的业务模式。第四，如果你偏离了进度表和决定改些东西，你会惹起整个世界的关注和对你的指手划脚。我最不希望《华尔街月刊》来告诉我如何推进一个开发过程。如果在6月推出，我希望他们永远不知道那本是打算在4月推出的。如果由于一系列原因我们决定要改变出品日，我不希望为此必须向500个人作解释。这是一个我们的多数顾客和竞争对手都尚未领会到的因素。
许多公司为其产品宣布出品日，然后又“滑过”了这个日期以纳入额外的开发或测试时间。微软的进度表正变得更为准确，但是，正像看到的Windows95或Microsoft Exchange这样的全新产品的情况一样，很明显，它们继续超过出品日。我们的印象是，微软的经理们现在希望在推出产品前保证其产品的质量或可靠性。交付延迟是要冒着一些使顾客疏远自己的危险，但有错误的产品对此则冒着更大的风险。在第5章我们将深入讨论制定产品出品决策的基础，以及检查微软实际上是如何构造与测试其产品的详细过程。
