第一种是产品规划人员。产品规划人员主要任务是调查，包括调查你的竞争对手、客户、以及其他市场需求。产品规划的过程是定义产品的过程。他们通常会做很多研究，通过跟踪市场用户，做市场调查，看行业的报告，从而确定产品三到五年的发展规划。其实作为产品规划人员最重要的一点，就是要有前瞻性。不仅仅是能看到现在市场是什么样的，而更要能看到三到五年以后会是什么样的。我们可以看到微软好多产品，都有一种说法叫”version
第二类人是产品管理人员。某种程度上有点类似于传统的市场人员，但也不完全相同。他们的主要任务是把产品推向市场。包括决定产品的定位、包装。最重要的一点是向用户传达一个什么信息。也就是用户为什么买你的产品，或者升级到你的产品。很多人说微软的产品除了质量好外，市场也做得好。象IE就是一个很好的市场运作的例子。如IE最初的用户定位，不是试图让Netscape已有的用户转到IE上，从来没有这么做过，而是面向新的Internet用户，这就是用户定位很清楚。此外，对IE不同的版本，开发侧重点不一样，就需要用一条简单的信息告诉用户，这个版本比其他版本有什么好处。这些都是产品管理人员要做的。
下一个角色是程序经理，我们以前叫项目经理。但上次我在上海讲的时候，学员说，他和国内的项目经理做的事情很不一样，所以这里我就叫程序经理，有时候我可能会交换着用。
在微软，程序经理主要是做产品，在适当的时候推出适当的产品。他碰到的最主要困难就是如何保持控制。适当时候意味着你必须控制好产品的发布日程，不能有延误。大家知道产品过程中不确定的就是人为因素，把发布日期控制好是很困难的。还有，要做出正确的取舍。有些时候你会在发布日期和新的特性之间需要做出取舍，或者是不是采取新的技术、用新的工具、算法什么是不是必要、我们是不是需要去做，做什么和不做什么之间，做出取舍，从而控制产品的特性并使其能满足市场需求。程序经理需要衡量做这些事情的危险性，需要衡量得特别清楚。
这三类人把整个产品的策划，推向市场，以及产品开发过程控制基本上定下来了，可以是说最关键的。
剩下的有产品设计人员，主要是做产品的用户界面或可视化方面的设计。这些人一般人都有设计方面的背景。像微软的产品，以前对用户界面设计或用户交互方面侧重不是很多，因为传统PC，早期只是专业人员的工具。但现在越来越面向消费者、初学者方向发展，那么对于界面设计要求越来越高。公司在这方面投入了很大的人力。我不知道大家都看到新的Windows
XP、或像“MSN
Explorer”没有，这些产品和传统的产品相比，外观，包括用户使用方式都是完全不一样的，更注重的是一种整体的体验、经历。
产品设计还有一个重要的工作，就是保证产品所有可视部分保持一致。不同的模块或者不同的特性可能由不同的人员开发，如何保证可视部分看起来一样，使用户不至于在使用一个产品时突然觉得不是同一个公司的产品，这就取决于产品设计人员。
第五种人员是产品可用性评估工程师，他们主要做的是保证产品可用、易用，而且能够容易被用户接受。一般在产品开发的初期或过程中，都有一些不同的原型，就是针对一些特性怎么做，用户怎么交互，设计一些不同的原型，然后交由可用性评估工程师做可用性测试，从而决定最终的方案。这方面微软一直是非常重视的。你可能注意到在IE早期版本里，地址栏里面并没有“Go“按钮，只是有一个地址栏。但是后来通过可用性测试，发现一些用户把地址敲进去后，就在那儿等着，也不知道按回车。确实就有这样的人。所以从IE5.0开始在地址栏后加了个按钮，用户敲完地址以后，可以试着按一下按钮，来链接到他所需要的网页。
下一类就是开发人员。开发人员在微软应该是很重要的，但是我感觉相比之下，没有像在我们国内一些企业那么重要。开发人员的主要工作，一部分是设计一些算法，对程序经理做出的文档或者特性说明要提出自己的反馈。还有更重要的一块就是，帮助程序经理推出产品日程，从什么时候可以做到“beta1”、“beta2”，什么时候可以发布。这些跟开发人员密切相关，所以由开发人员决定它的进度。除此之外，就是通常的写代码，编程与调试，以及后期的缺陷修复。
下一部分是测试人员。微软对测试非常重视。测试人员在产品开发过程中要独立完成，就是不受其他人员的影响，独立完成测试。另外某些情况下，要作为用户的代言人，把用户的利益放在首位。如果你认为这个产品这样发布出去不行，就一定要坚持。当然这样往往会引起一些激烈的争论，决定问题到底是要不要解决，但最终的结果是使用户受益。
再下一类就是微软特有的本地化人员。这一点我想对大家目前可能不是很适用。但我们将来怎么把我们的产品推向世界，有一个全球化的过程，也有通过本地化来满足中国以外的其它市场的要求的过程，所以将来肯定会有这方面的需求。
还有一类人员是文档发布，这里面包括网站方面的文档，软件内的文档，这些文档主要是帮助用户怎么使用产品。还有面向开发人员的，做一些代码示例，这是文档发布主要的工作。我们传统谈到的开发文档在微软是程序经理来完成的，就是所有的程序经理在项目开始针对每个特性写非常详尽特性说明。
还有一类人专职于产品支持，这在微软也是非常重要的。一方面微软跟最终用户打交道最常见的一个途径，往往有很多用户打电话提出问题，将来在下一个版本会把它解决掉。还有最重要的在微软来说，用户每打进一个电话都是要花钱的，实际上产品支持直接影响到公司的营业额。提供更快速更有效的用户支持是最重要的一个环节。
最后一个角色是运营管理，实际就是网站运营管理。大家也知道，微软产品目前越来越多和Internet紧密集成，像我们现在做的“Hotmail”、“MSN
Calendar”等产品，本身就是一个网站。
运营管理角色原来是没有的，这只是近两三年来新发展出来的角色，在将来会越来越重要。因为你跟传统的做所谓包装的产品不一样。以前你可以说我把CD做完了，产品发布了，就没事了。因为用户买了产品，你已经赚钱了。而做连机在线服务的时候，软件发布仅仅是一个开始，用户只要使用一天你都需要花钱，都会影响你整个的赢利。
实际上在线管理是非常复杂的，比如“Hotmail”，现在有一亿一千多万用户。在前端大概有五千多个服务器运行着Windows
2000，来满足用户登录。后台还有许多服务器负责邮件的收发，存储，是很复杂的一个系统，因为有底层的网络，有硬件，还有操作系统，还有上面的你的应用程序，再加上Internet本身又是不确定的环境。怎样把这复杂的系统管理好，是很具有挑战性的。
和传统应用程序不同，用户随时可以走开，而且还有很多不确定性。例如我们传统的产品，用户买得越多，我赚的钱越多；但在连机的时候，用户多有时候也可能是个问题，就是你可能支持不了那么多用户。比如同时有很多人来访问，你的网站是不是能满足这么多用户访问的需求，因此网站运行还往往需要提前对流量或用户在线数做出较精确的预测。
运营管理在微软将会越来越重要，而同时产品的很多设计会影响到你到底能不能好好运行。所以这对其他人员也提出了新的要求。
目前基本上来说，运营管理、产品规划、产品管理和程序管理这四类人实际上在主要推动产品的进程。其他人扮演的是一个被动的或专注于做某项具体事情的角色，但是每一个角色都是不可或缺的。
前面我们讲了微软现在基本上有十一个工种。怎么把这些人组织起来，能够更有效地去投入到开发过程中呢？微软目前基本上是一种所谓的条块结构，即在公司内部最基本的组织是一个产品单元，比如像IE就是一个产品单元组，产品单元组的管理者会有预算，有人给钱。在每个产品单元内，在行政上按你的工作类型来划分：像程序经理，他上面会有一个总的程序经理组长；如开发人员有一个开发组长；测试人员也同样，这是在行政上的组织。行政组织结构主要是为了对你的业绩做出一些考核，包括将来会不会给你加工资。在做产品的时候，在每个产品单元组内，又按不同的特性划分为各个不同的项目组，划分的基本原则是希望由一个很精干很小型的团队来进行开发。因为我说了要按产品的不同特性来划分组织，这就要求你在产品设计时，大的产品能分成一个个小模块和小特性，然后相互之间又没有很大的依从关系，因为跨组的交互或者跨组的依从关系是最难管理的。每一个团队内基本上由项目经理，或者程序经理来领导负责一个特性，下面会有开发人员，也会有测试人员，基本上开发人员和测试人员的比例一般都是一比一，这样一个组差不多十个人，是最基本的开发单元。一些跟技术有关的决定基本上是项目经理做出来的，不会有上面的人左右你的决定。这种组织结构使在一些商务和技术方面很快做一些决定，同时因为每个组人少，就能使大的团队能像小的团队这样很快向前移动，而效率不会受到影响。
以IE产品组为例。它在不同时期有不同的人员，人数也是不同的。最早IE1.0是几个人，IE2.0可能是三四十个人，到IE4的时候基本上就到了300人的项目组。在300人的项目组里面是这样的组成：一个是产品单元经理，这因为是以产品单元为最基本单位，所以产品单元经理是大老板，下面有五个产品规划人员，产品经理有二十个，项目经理五十个，开发人员一百个，测试人员也有一百个，因为还有文档发布(因为IE也有一些SDK，也有一些联机的网页和帮助文件)，所以文档人员有十个人。这种人员结构也是根据产品的特性，或者你在这个版本中间你的侧重点来决定的。同样在IE产品组，在IE5.5的时候，也有300多个人，但这时候项目经理就只有15个人，比IE4五十个人要少好多，开发人员也只有40个人，因为到IE5.5的时候，基本上大的特性已稳定的，IE5.5面向最终用户方面做的工作要少一些，主要在稳定性和性能方面做提高，另外对一些公司大企业的用户做一些支持，所以开发人员和项目经理数目减少了，但是测试人员很多，测试人员有200人，这主要是在IE4的时候觉得少，所以在IE5的时候就组织独立的测试队伍进行测试。
IE产品组分为十个项目组，每个组大概有十到五十个人，每个组基本上负责一个产品模块，像浏览，或HTML的编辑、打印。但是有一些时间一个项目经理会负责不止一个特性，甚至有一些开发人员可能在某些方面有专长，也需要在不同组织之间流动，所以这种组织实际上是一个动态的。
下面我们谈一下微软产品开发过程。开发过程划分的基本原则是，希望把大的项目分为若干个里程碑式的开发周期，并在各个周期都要考虑一些冗余，使你的开发周期变得更实际一些。通过目标描述来保证所有的人是沿着同一个方向发展。利用产品特性描述来指导开发过程。同时利用用户的数据来决定一些特性的取舍，或者优先级的排定。加不加这个特性，不是开发人员觉得好，我就做这个东西，往往还是从用户角度来考虑，用户从中间有多大收益来决定。
还有更重要一点就是统一的术语。在微软内部刚进去时也会做类似这样的培训，会请的各种角色做一个讲座，大概需要六七个小时。其中有对很多术语、缩写，还有对这套开发模式的介绍。从而保证所有人理解的都是统一的。这样你才能保证无论在做事或者讨论的时候，大家的理解是一样的。
还有一点是在开发产品过程中不间断地测试，而不是做完了到某一个阶段才开始测试，因为往往那个那时候往往已经太晚了。
微软产品开发过程分为四个阶段，第一个阶段是规划阶段，这个阶段基本上是由产品规划人员以及项目经理来驱动的，这个阶段主要是要完成这样一些事情：一个是目标描述。基于这个产品目标，我们已经知道了，我们需要做哪些事，做哪些特性来达到这个目标，这样就决定了产品提供哪些的功能。然后程序经理就要根据这个功能来写出相应的规范说明。一般产品规格说明，就是传统上说的技术文档，基本会写两次，第一次写一个简单的，里面列出了你这个功能或者你的特性希望达到什么要求，跟我们整个产品的目标有哪些相关的，产品之间依从性，为什么要做这个特性。写完这一页的特性描述之后，大家会坐在一起看一看，排定一个优先级别，哪些事我们先做，哪些有可能做，或哪些是下一版本再做。把这个事情做完了，程序经理会写一个更详尽的特性说明，这是指导开发、测试整个过程的技术文档，基本上一般都会有一些模板。
在规划阶段，当所有的特性规格说明完了以后，还要制定日程进度表。这个日程进度表往往需要由开发人员的参与。看到了这些产品规范，根据你的经验估计做这个需要多长时间，还需要打入一些冗余，把这个做完之后，产品规划阶段就已经完成了。
产品规划阶段完成的标志，就是目标描述，所有特性规格说明以及日程进度表的完成，这样就进入第二个阶段，即开发阶段。
因为我们自己有特性描述，已经知道做什么。所以根据这些特性，会把这一阶段分为三到四个子阶段。基本的划分原则是重要的或相互依从的特性先开始做，剩下一些次重要的会在第二、三间段做。这一阶段是由开发人员去推动。所有的开发人员开始写代码，对于每一个开发人员都有相应的测试人员，会把开发人员写的代码拿去测试。这个阶段完成的标志是所谓的特性完成，或者叫代码完成，也就是所有的这种特性都已经开发完毕。这时就进入了测试阶段。
测试阶段主要由测试人员推动。在开发阶段也有测试在进行，但在测试阶段进行的主要是集成的测试，像安装、兼容、性能或其他方面的测试。此外通常还要发放一些“beta”版本，让用户去实际使用并发回反馈。这一阶段会有更多的bugs，但是这一阶段基本上不会增加新的特性。这一阶段结束的标志是所谓的“零缺陷”。微软有一些来跟踪缺陷或者叫bugs的工具，如果从这些工具看到针对这个发布周期已经没有任何active
bugs，这就标志着稳定化阶段已经结束。现在有一个趋势，就是稳定化阶段做得越来越长，从而更好的保证产品的质量。
接下来是发布阶段。在这一阶段大家会继续跟踪bug的状态，直到确认可以发布。一般会做一个CD，或把它发布到网上。最后发布阶段会由产品经理、项目经理，以及做运营管理的人来共同执行。
总结一下，微软产品组有明确的分工及不同的角色，产品开发由四个阶段组成，即规划阶段、开发阶段、测试和稳定化阶段以及最后的发布阶段。总的原则在微软是有一个详细的分工和职责的划分，通过每个人的角色控制产品开发过程。
我刚才谈到四个过程及十一个角色，实际上每个角色实际上并不是同步的。比如像产品规划人员，在第一个阶段和第二个阶段产品规划人员会有一些工作，到第三个阶段因为特性已经完成了，不会有新的特性，产品规划人员已经开始做下个版本。但是产品经理会继续做这个产品以保证这个产品继续进行。
客户需求决定了产品的方向和目标，往往在做一些决定时考虑的是客户和市场，很少纯粹为了技术和其他原因。
最重要的是把大的项目分成若干个子项目，这是渐进的，而不是一次性把很大的问题解决。
目标描述和产品特性说明，就是我们传统文档，这是为整个项目起到了指导作用，必须定义得很清晰，使所有人都能看到它。
最后一点，从项目一开始开始让所有人都去介入。因为好的产品是设计出来的，不是最后开发出来的。在前期基本上定下来以后，后期的开发是完成的阶段。如果设计有缺陷，如没有考虑到技术支持方面的问题，则后期很难做，假使再加进去对产品质量或发布日期都有很大的影响。还有就是通过不间断的测试来保证产品的质量