管理软件“流水线”
通常，新产品或新版本的诞生，需要走过六道工序，这就是产品规划阶段(Product Planning)、需求形成阶段(Specification)、设计阶段(Design)、实现阶段(Implementation)、测试阶段(Test)和技术支持阶段(Maintenance)。事实上，这六道工序并不像一般硬件产品的流水线那样，这六个阶段或者交叉，或者平行，总之构成了一个复杂的统筹项目。
由于SAP提供的各种解决方案要面对不同用户千差万别的功能需求，在项目开始之前，需要进行非常详尽的规划，以决定功能的取舍和增强，这一阶段决定着产品的发展方向，也是项目成败的关键。同时，这一工作也要求参加项目的SAP和非SAP人员进行充分的交流沟通，从而为将来的开发打下基础。特别是对于那些比较复杂、跨模块的项目，需要在模块间的功能开发和工作进度上作出统一的规划，以避免重复开发和集成问题。
通常，规划阶段的工作可以按三个步骤进行。第一步是收集和评估开发需求，为新产品或升级现有产品而从各种渠道收集用户需求和意见。如果是升级现有产品，则由开发组对开发请求进行评估，并作为新版本开发的基础；如果是新应用模块开发，则由项目的产品管理小组和开发经理对实际应用和流程进行分析，并提供粗略的开发计划，为下一步的决策做必要的准备。第二步则是开发规划的决策阶段，主要是分析整个项目的可行性，以及确定项目开发的优先级，对于比较重要的或者是策略性的项目，通常是由部门主管或执行董事参与决策。第三步，则需要制定详尽的开发计划，包括功能划分、工作分配、进度控制等。
走完规划阶段，项目组以及产品经理则开始对软件产品进行分析，确定各种用户需求的优先级，并决定哪些功能将在系统中实现，以及实现的程度和方式。这一阶段的工作需要与用户及咨询顾问进行大量的面对面交流，在得到用户需求的同时，也需要将项目的进展及时通报，以得到反馈。需求形成阶段作为开发阶段的基础，最终形成的需求文档需要从用户的角度对产品进行描述，对各种功能模块的描述要尽量明了，因为此文档也将是产品实现和测试的基础。同时，文档还要就产品可用性、运行性能等方面进行规定。
当项目组拿到了具体详尽的需求文档后，设计阶段开始启动。在设计阶段，由各功能模块的负责人组织小组成员，一起建立模型（如数据模型、功能模型、过程模型、对象模型等），创建必要的数据结构和函数，同时，对程度元素的命名原则、开发规范及模块间的接口等作出定义。由此形成的设计文档成为项目实现的基础，并且是软件维护的重要参考，所以，此文档应当尽量详细。此阶段的工作以用户需求为基础，为用户提供有效的解决方案，设计的好坏将直接影响到系统的功能和性能。
当某种功能比较复杂时，设计文档通常可以分成两类:
一类是粗略设计，参考系统中现有的过程、工具和函数库，以确定可以复用的对象，使用系统中现有的对象和技术可以提供新功能的可靠性，降低开发成本；第二类是详细设计，包括对数据字典、程序对象、用户界面、处理流程以及各个对象之间的接口定义进行详细的设计。
设计阶段之后，就进入了具体的开发阶段，即实现阶段。实现阶段是以设计文档为基础来创建数据字典和程序对象。SAP对ABAP程序开发有比较完整的指导文档，并要求开发人员按照SAP的开发规范创建用户界面。在R/3项目开发中，规范性与技术同样重要，由于一个项目通常是由很多开发人员协同完成的，程序的可读性和详细文档对于项目来讲是非常重要的。在开发的同时，文档开发人员为相应的功能模块创建在线文档、培训教材等必要的用户文档，这需要开发人员的密切协作。此阶段同时也是开发测试阶段，开发人员需要对新的模块进行测试、代码检查、可用性测试等，并进行开发人员间相互测试，以便在开发阶段保证模块的质量。
实际的测试阶段从具体的开发阶段就开始了，此谓开发测试，而正式的测试则是在质量经理（QM）主持下，由质量管理小组、产品管理小组及用户共同参与进行非常完整、细致的测试。它不只面对单一功能单元，而是根据用户需求文档、设计文档并按用户实际流程设计出测试文档，对系统的可用性、性能、用户界面、表达统一性、文档、翻译等进行全面测试。
同时开发人员需要密切配合，及时修改发现的错误。测试阶段的工作是软件提供给用户前的最后一道工序，它直接关系到软件的质量。所以，此工作需要非常周密的安排，就这个意义而言，QM也担负着保证软件质量的责任。
SAP的技术支持分成三级:
当地支持（Local Support）、地区支持（Regional Support）和开发支持（Development
Support）。当用户遇到的问题无法由前两级完成时，这个问题就会送达开发人员，由开发人员确认错误来源，并提供正确的响应。这一过程可以包括在用户系统中修改程序、文档，如果问题所涉及的功能比较广泛，SAP内部相关的开发人员会协同工作，共同解决问题。随后的分析会对问题或需求有更加深层的总结，一旦需要，新的需求会被包括在新版本的开发中。SAP还会提供Hot
Packages和Hot News，以帮助用户及时处理系统中的错误。
(计算机世界
郑大奇)
管理Bug的“程序”
Bug产生的来源可以分为流程错误和程序错误。
流程错误是非常致命的，它会导致系统无法实现用户的需求，它通常发生于项目规划和设计阶段。对于这方面的错误，SAP有相应的机制加以控制。在用户需求分析过程中，产品管理小组与用户之间进行协同工作，同时经验丰富的项目经理和开发经理也会参与，最后形成的用户需求和项目规划文档还要由专门的小组进行周密的分析和检查。尤其是在模块设计阶段，这种检查更加严格，通常这一阶段的检查是由资深专家组成的小组来完成的，其成员会有来自于其他项目的，从而保证了系统设计的质量。
程序错误是在所难免的，SAP除了利用测试阶段的工作来减少Bug的同时，还用以下手段在开发阶段尽可能地避免Bug:
①自我测试，要求开发人员在完成自已负责的模块后，马上进行测试，消除模块内部的错误；②相互测试，要求开发人员之间测试对方的模块，由于不同开发人员的思维、开发方式的不同，对方会很容易找到一些自已很难发现的问题；③代码检查，通常是由资深开发人员及开发经理来进行，从模块功能、性能、可用性、编码规范、模块集成性等角度进行全面检查。这一工作会在系统实现的各个阶段定期进行。SAP还提供了如CATT等辅助测试工具。
对于系统的后期维护阶段，SAP也有对Bug的完整的管理流程。这可以以开发支持为例来说明。例如，当用户系统发现Bug时，如果当地支持和地区支持都无法处理时，此维护请求会被提交相关负责的开发人员。开发人员负责尽快修改用户系统中的Bug，或为用户提出修改建议和解决方案，同时，也需要在更正（Correction）系统中进行修改，以便以补丁（Patch）的方式提供给所有用户。但对Correction系统中的修改有非常严格的管理，并需要一定的步骤：①与开发经理讨论并征得许可;
②在OSS系统中创建修改申请，并对Bug所在版本、症状、解决方案作出详细的描述和解释，作为用户/顾问将来处理此Bug的参照；③开发人员在Correction系统中修改程序，消除Bug，同时要求进行仔细的测试；④开发人员将修改请求转给另外的开发人员，通常是开发经理或资深的开发人员，由其来进行更严格的测试，此次测试不但要测试Bug是否真正解决，还要确认对程序的修改是否影响了其他程序或模块，以避免带来新的问题。
这些修改会定期以Hot
Package和Hot
News的方式提供给用户，用以修改用户系统中的Bugs，但由于R/3各模块之间的相关性/依赖性很强，Patch的发布需要各模块特别是应用模块与Basis模块之间的协调和同步。
——————————————————————————————————————
大家好，很高兴今天有这样的机会能跟大家交流。
微软公司一直希望帮助中国发展软件产业。
斯蒂夫.鲍默尔、比尔.盖茨都在不同场合提到过这一点。我们微软中国研发中心走得更前一步，在今年5月份的时候，我们和信息产业部签订了为期两年的合同，就是与国内的一些软件企业介绍微软的软件产品研发实践。目前我们已经办了两期，第一期在北京办的，第二期在上海。我不知道在座的有没有参加过的。我自己参与了一些课程的讲解，所以我也很高兴今天有这个机会，和大家交流一下，看看大家关心一些什么问题，以后再办这样的活动更加有的放矢。
今天的题目写的是微软产品的开发过程，这个题目很大，我们跟信息产业部办的“共享新世纪”活动总共是四到五天，我不可能在这么短时间全讲完，我主要从开发实践，从过程方面做一些介绍。
我看到王东临发的电子邮件里面提到了关于软件产业，以及作坊式生产方式的一些讨论。什么叫作坊式生产？或者说到什么时候我们软件产业成熟了？我个人观点是，作为工业化首先要分工细化，就是更专业化，所有事情向专家方式发展。另外生产过程、质量控制要标准化、产业化。这两方面标志着一个产业的形成。另外当然还要看市场，产业的规模，以及行业自己的成熟程度。
刚才周老师说，软件产业某种程度上类似一些产业或者工业生产。
我个人觉得很像电影工业。首先二者都是头脑的产物，然后全是由人完成，都需要复杂的过程。电影分工非常细，有导演，各种制片什么的。
投入产出比都很大，但是高风险，拍一部电影或者开发一个软件，有可能很成功，有可能有人用，但也有可能彻底失败。二者都有盗版。电影有影评人，软件业也有许多专业评论家。所以二者还是很相似的。看一下中国电影，给我们启发是，我们有很好的演员。比方上次我去美国碰到一个德国人，他说最喜欢的演员是章子怡。这说明我们的演员是很好的，但是为什么我们电影没有好莱坞，不能到国际上竞争？我觉得是各种人才的分布不够平衡，在发行，推向市场方面，
可能还是要差一些。软件也是如此，我们有很好的程序员，在其他方面有很优秀的人才，但是整体上各种人员的发展，分配是不平衡的，在产品工业化的管理、推向市场，以及产品质量控制方面还是不够的。此外我觉得生产方式和生产过程不够标准化。
所以这里我主要介绍微软内部产品组各种角色是怎么划分的，他们具体做什么，这些人是怎么组织起来参与产品的开发的。另一部分我想介绍一下微软产品开发过程，也就是有了各种角色，有了团队之后，怎么协同工作，把一个项目从始到终完成，推向市场。
其中有一些谈不上是微软独有的，而是行业流行通用的，但也有一些与微软的具体情况、企业文化会有一些相关。以前我在上海讲课，他们说你这个东西我们拿回去我们也用不着。其实我觉得最基本一点，是要清楚我们这里谈的是微软怎么做面向最终用户的产品。对于做解决方案，微软另有一套东西，叫“Microsoft
Solution Framework”就是解决方案框架。还有一种误解，就是微软那么大，你们可以这样做，我们一共几十个人，我们是不是没法做这个事情？这个其实也不见得，听了微软组织结构你会发现，虽然微软是很大的公司，但是实际上，在某种程度上是以好多小公司方式在运作，具体到一个团队人员规模也并不是很大的。
微软产品组现在基本上有十一类人，各有各的专长，在产品开发过程中有自己各自不同的任务。
第一种是产品规划人员。 产品规划人员主要任务是调查，
包括调查你的竞争对手，客户，以及其他市场需求。产品规划的过程是定义产品的过程。他们通常会做很多研究，通过跟踪市场用户，做市场调查，看行业的报告，从而确定产品三到五年的发展规划。其实作为产品规划人员最重要的一点，就是要有前瞻性。不仅仅是能看到现在市场是什么样的，而更要能看到三到五年以后会是什么样的。我们可以看到微软好多产品，都有一种说法叫”version
3.0”，可能在1.0,
2.0时不是很好，有可能是功能的问题,也有可能是超前于市场的缘故，像
Windows，做出来时候,无论从硬件或者软件应用程序来看,都没有市场，但是通过不断的改进,到3.0
时就取得了很大的成功。从这一点看,产品规划人员是非常重要的。
第二类人是产品管理人员。某种程度上有点类似于做传统的市场人员，但是也不是完全相同。他们主要任务是把产品推向市场。包括决定产品的定位、包装。最重要一点是向用户传达一个什么信息。也就是用户为什么买你的产品，或者升级到你的产品。很多人说微软的产品除了质量好外，市场也做得好。象IE
就是一个很好市场运作的例子。比如，IE 最初的用户定位,不是试图让Netscape
已有的用户转到IE上，从来没有这么做过.而是面向新的Internet用户。这就是用户定位很清楚。此外，对ＩＥ不同版本，开发侧重点不一样，就需要用一条简单的信息告诉用户，这个版本比其他版本有什么好处。这些都是产品管理人员要做的。
下一个角色是程序管理，我们以前叫项目管理，但是上次我在上海讲的时候，
学员说，他们说国内项目经理做的事情很不一样，所以这里我就叫程序管理。有时候我可能会交换着用。
在微软，程序管理主要是做产品，在适当的时候推出适当的产品。他碰到的最主要困难就是如何保持控制。适当时候意味着你必须控制好产品的发布日程，不能有延误。大家知道产品过程中不确定的就是人为因素，这个发布日期控制好，这是很困难的。还有要做出正确的取舍。有些时候你会在发布日期和新的特性之间需要做出取舍，或者是不是采取新的技术，用新的工具、算法什么是不是必要，我们是不是需要去做，做什么和不做什么之间，做出取舍，从而控制产品的特性并使其能满足市场需求。程序管理人员需要衡量做这些事情的危险性，需要衡量得特别清楚。
这三类人员把整个产品的策划，推向市场，以及产品开发过程控制基本上定下来了，可以是说最关键的。
剩下的有产品设计，主要是做产品的用户界面或者可视化方面的设计。这些人一般人都有设计方面的背景。象微软的产品，以前对用户界面设计或者用户交互方面侧重不是很多，因为传统ＰＣ，早期只是专业人员的工具。但现在越来越向消费者、初用者方向发展，那么对于界面设计要求越来越高。公司在这方面投入了很大的人力。我不知道大家都看到新的Windows
XP、或者像“MSN
explorer”没有，这些产品和传统的产品相比，外观，包括用户使用方式。都是完全不一样的，更注重的是一种整体的体验，经历。
产品设计还有一个重要的工作，就是保证产品所有可视部分保持一致。不同的模块或者不同的特性可能由不同的人员开发，如何保证可视部分看起来一样，使用户不至于在一个产品使用时突然觉得不是同一个公司的产品，这就取决于产品设计人员。
第五种人员是产品可用性评估工程师，他们主要做的是保证产品可用，易用，而且能够容易被用户接受。一般在产品开发的过程中或者初期，都有一些不同的原型，就是针对一些特性怎么做，用户怎么交互，设计一些不同的原型，然后交由可用性评估工程师做可用性测试。从而决定最终的方案。这方面微软一直是非常重视的。你可能注意到在ＩＥ早期版本里，地址栏里面并没有
“Go“
按钮，只是有一个地址栏。但是后来通过可用性测试，发现一些用户把地址敲进去后，就在那儿等着，也不知道按回车。确实就有这样的人。所以从5.0
开始在地址兰后加了个按钮。用户敲完地址以后,可以试着按一下按钮, 来连到他所需要的网页。
下一类就是开发人员。开发人员在微软应该是很重要的，但是我感觉相比之下,没有象在我们国内一些企业那么重要。开发人员主要工作,一部分是设计一些算法，对ＰＭ做出的文档或者特性说明要提出自己的反馈。还有更重要的一块，就是帮助ＰＭ推出产品日程，从什么时候可以做到“beta”１、２，
什么时候可以发布。这些跟开发人员密切相关，所以又开发人员决定它的进度。除此之外，就是通常的写代码，编程与调试，以及后期的缺陷修复。
下一部分是测试人员。微软对测试非常重视。测试人员在产品开发过程中要独立完成。就是不受其他人员的影响，独立完成测试。另外某些情况下，要作为用户的代言人，把用户的利益放在首位。如果你认为这个产品这样发出去不行，就一定要坚持。当然这样往往就引起有一些激烈的争论，决定问题到底是要不要解决。但最终的结果是使用户受益。
再下一类就是微软特有的本地化人员。这一点我想对大家目前可能不是很适用。但我们将来怎么把我们的产品推向世界，有一个全球化的过程，也有通过本地化来满足其它中国以外其它市场的要求的过程，所以将来肯定会有这方面的需求。还有一类人员是文档发布，这里面包括网站方面的文档，软件里边的文档，这些文档主要是帮助用户怎么使用产品。还有面向开发人员的，做一些代码示例，这是文档发布主要的工作。我们传统谈到的开发文档在微软是ＰＭ来完成的，就是所有的程序经理在项目开始针对每个特性写非常详尽特性说明。
还有一类人是产品支持人员。这在微软也是非常重要的，一方面微软跟最终用户打交道最常见的一个途径，往往有很多用户打电话提出这个问题，将来在下一个版本会把它解决掉。还有最重要的在微软来说，用户每打进一个电话都是要花钱的，实际上产品支持直接影响到公司的营业额。提供更快速更有效的用户支持，是最重要的一个环节。
最后一个角色是运营管理，实际就是网站运营管理。大家也知道，微软产品目前越来越多和Internet紧密集成，象我们现在做的 “Hotmail”、”MSN
Calendar”等产品，本身就是一个网站。运营管理角色原来是没有的，这只是近两三年来新发展出来的角色，在将来会越来越重要。因为你跟传统的做所谓包装的产品不一样。以前你可以说我把ＣＤ做完了，产品发布了，就没事了。因为用户买了产品，你已经赚钱了。实际在做连机在线服务的时候，你软件发布仅仅是一个开始，用户只要使用一天你都需要花钱，都会影响你整个的赢利。实际上在线管理是非常复杂的，比如“Hotmail”，现在有一亿一千多万用户。在前端大概有五千多个服务器运行着Windows
2000，来满足用户登录。后台还有许多服务器负责邮件的收发，存储，是很复杂的一个系统，因为有底层的网络，有硬件，还有操作系统，还有上面的你的应用程序，再加上Internet本身又是不确定的环境。怎么把这复杂的系统管理好，是很具有挑战性的。因为跟传统的应用程序是不一样，用户随时可以走开。而且还有很多不确定性，象我们传统的产品，用户买得越多，我赚的钱越多。但是在连机的时候，用户多有时候也可能是一个问题，就是你可能支持不了那么多用户。比如一下有很多人来访问，你的网站是不是能满足这么多用户访问的需求。网站运行还往往需要提前对流量，或者对用户数满意做出比较精确的预测。运营管理在微软会越来越重要，而同时产品的很多设计会影响到你到底能不能好好运行。所以这对其他人员也提出了新的要求。
目前基本上来说，运行管理、产品规划、产品管理和程序管理这四类人实际上在主要推动产品的进程。其他人扮演的是一个被动的，或者专注于做具体事情的角色。但是每一个角色，都是不可或缺的。
前面我们讲了微软现在基本上有十一个工种。怎么把这些人组织起来，能够更有效地去投入到开发过程中呢？微软目前基本上是一种所谓的条块结构。在公司内部最基本的组织是一个产品单元，比如像IE就是一个产品单元组。产品单元组的管理者会有预算，有人有钱。在每个产品单元内，在行政上按你的工作类型来划分，像项目经理，他上面会有一个总的项目经理组长，如开发人员有一个开发组长，测试人员也同样。这是在行政上的组织。行政组织结构主要是为了对你的业绩做出一些考核，包括将来会不会给你加工资。在做产品的时候，在每个产品单元组内，又按不同的特性划分为各个不同的项目组，划分的基本原则是希望由一个很精干很小型的团队来进行开发。因为我说了要按产品的不同特性来划分组织，这样就要求你在产品设计时，大的产品能分成小的模块和小的特性，然后相互之间又没有很大的依从关系。因为跨组的交互或者跨组的依从关系是最难管理的。每一个团队内基本上由项目经理，或者程序经理来领导，来负责一个特性，下面会有开发人员，也会有测试人员，基本上开发人员和测试人员的比例一般都是一比一，这样一个组差不多十个人，是最基本的开发单元。一些跟技术有关的决定基本上是项目经理做出来的，不会有上面的人左右你的决定。这种组织结构能够使在一些商务和技术方面很快做一些决定，同时因为每个组人少，就能使大的团队能像小的团队这样很快向前移动，效率不会受到影响。
举一下ＩＥ产品组为例。它在不同时期有不同的人员，人数也是不同的。最早ＩＥ１.０是几个人，ＩＥ２.０可能是三四十个人，到ＩＥ４的时候基本上就到了３００人的项目组。在３００人的项目组里面是这样的组成，一个是产品单元经理，这因为是以产品单元为最基本单位，所以产品单元经理是大老板。下面有五个产品规划人员，产品经理有二十个，项目经理五十个，开发人员一百个，测试人员也有一百个，还有文档发布，因为ＩＥ也有一些ＳDＫ，也有一些联机的网页和帮助文件。文档人员有十个人。这种人员结构也是根据产品的特性，或者你在这个版本中间你的侧重点来决定的。同样在ＩＥ产品组。在IE５.5的时候，也有３００多个人，但这时候项目经理就只有１５个人，比ＩＥ４五十个人要少好多，开发人员也只有４０个人，因为到ＩＥ５.５的时候，基本上大的特性已稳定的，ＩＥ５.５面向最终用户方面做的工作要少一些，主要在稳定性和性能方面做提高，另外对一些公司大企业的用户做一些支持，所以开发人员和项目经理数目减少了，但是测试人员很多，测试人员有２００人，这主要是在ＩＥ４的时候觉得少，所以在ＩＥ５的时候就组织独立的测试队伍进行测试。
ＩＥ产业组分为十个项目组，每个组大概有十到五十个人，基本上负责一个产品模块，像浏览，或者HTML的编辑、打印。但是有一些时间一个项目经理会负责不止一个特性，甚至有一些开发人员可能他在某些方面有专长，他也需要在不同组织之间流动，所以这种组织实际上是一个动态的。
下面我们谈一下微软产品开发过程。开发过程划分的基本原则是，希望把大的项目分为若干个里程碑式的开发周期，并在各个周期都要考虑一些冗余，使你的开发周期变得更实际一些。通过目标描述来保证所有的人是沿着同一个方向发展。利用产品特性描述来指导开发过程。同时利用用户的数据来决定一些特性的取舍，或者优先级的排定。加不加这个特性，不是开发人员觉得好，我就做这个东西，往往还是从用户角度来考虑，用户从中间有多大收益来决定。
还有更重要一点就是统一的术语。在微软内部刚进去时也会做类似这样的培训，会请的各种角色做一个讲座，大概需要六七个小时。其中有对很多术语、缩写，还有对这套开发模式的介绍。从而保证所有人理解的都是统一的。这样你才能保证无论在做事或者讨论的时候，大家的理解是一样的。
还有一点是在开发产品过程中不间断地测试，而不是做完了到某一个阶段才开始测试，因为往往那个那时候往往已经太晚了。
微软产品开发过程分为四个阶段，第一个阶段是规划阶段，这个阶段基本上是由产品规划人员以及项目经理来驱动的，这个阶段主要是要完成这样一些事情：一个是目标描述。基于这个产品目标，我们已经知道了，我们需要做哪些事，做哪些特性来达到这个目标，这样就决定了产品提供哪些的功能。然后PM就要根据这个功能来写出相应的规范说明。一般产品规格说明，就是传统上说得技术文档，基本会写两次，第一次写一个简单的，里面列出了你这个功能或者你的特性希望达到什么要求，跟我们整个产品的目标有哪些相关的，产品之间依从性，为什么要做这个特性。写完这一页的特性描述之后，大家会坐在一起看一看，排定一个优先级别，哪些事我们先做，哪些有可能做，或者哪些是下一版本在做。把这个事情做完了，程序经理会写一个更详尽的特性说明，这是指导开发、测试整个过程的技术文档。基本上一般都有一些模板。
在规划阶段，当所有的特性规格说明完了以后，还要制定日程进度表。这个日程进度表往往需要由开发人员的参与。看到了这些产品规范，根据你的经验估计做这个需要多长时间，还需要打入一些冗余，把这个做完之后，产品规划阶段就已经完成了。
产品阶段完成的标志，就是目标描述，所有特性规格说明，以及日程进度表的完成。这样就进入第二个阶段，即开发阶段。因为我们自己有特性描述，已经知道做什么。所以根据这些特性，会把这一阶段，分为三到四个小的阶段。基本的划分原则是重要的或者相互依从的特性开始做，剩下的一些次重要的。会在第二或三间段做。这一间段是由开发人员去推动。所有的开发人员开始写代码，对于每一个开发人员都有相应的测试人员，会把开发人员写的代码拿去测试。这个阶段完成的标志是所谓的特性完成，或者叫代码完成，也就是所有的这种特性都已经开发完毕。
这时就进入了下一个阶段，测试阶段。测试阶段主要由测试人员推动。在开发阶段也有测试在进行，但在测试阶段进行的主要是集成的测试，象安装，兼容性测试，性能，或者其他方面的测试。此外通常还要发放一些“beta”版本，让用户去实际使用并发回反馈。
这一阶段会有更多的“bug”进来，但是这一阶段基本上不会增加一些新的特性。这一阶段结束的标志是所谓的“零缺陷”。微软有一些来跟踪缺陷或者叫“bug”的工具，如果从这些工具看到针对这个发布周期已经没有任何活动的bug，这就标志着稳定化阶段已经结束。现在有一个趋势，就是稳定化阶段做得越来越长，从而更好的保证产品的质量。
到了零缺陷后，就进入了下一步的发布阶段。在这一阶段大家会继续跟踪bug
的状态，直到确认这可以发布了。一般会做一个ＣＤ，或者把它发到网上。最后发布阶段会由产品经理、项目经理，以及做运营管理的人来共同执行。
总结一下，微软产品组有明确的分工及不同的角色，产品开发由四个阶段组成，即规划阶段，开发阶段，测试和稳定化阶段以及最后的发布阶段。总的原则在微软一个是有详细的分工和职责的划分，通过各个人人的角色控制产品开发过程。我刚才谈的四个过程，十一个角色，但是每个角色实际上并不是同步的。比如像产品规划人员，在第一个阶段和第二个阶段产品规划人员会有一些工作，到第三个阶段因为特性已经完成了，不会有新的特性，产品规划人员已经开始做下个版本。但是产品经理会继续做这个产品保证这个产品继续进行。还有是客户需求决定产品的方向和目标，往往在做一些决定时考虑的是客户和市场，很少纯粹为了技术和其他原因。最重要的是把大的项目分成若干个子项目，是渐进的，不是一次性把很大的问题解决。还有目标描述和产品特性说明，就是我们传统文档，这是为整个项目起到了指导作用，必须定义得很清晰，使所有人都能看到它。最后一点，从项目一开始开始让所有人都去介入。因为好的产品是设计出来的，不是最后开发出来的，因为前期基本上定下来以后，开发的后期是完成的阶段。如果设计有缺陷，比如没有考虑到技术支持方面的问题，后期很难做。假使再加进去对产品质量或者发布日期都有很大的影响。还有就是通过不间断的测试来保证产品的质量。
