第二类人是产品管理人员。某种程度上有点类似于做传统的市场人员，但是也不是完全相同。他们主要任务是把产品推向市场。包括决定产品的定位、包装。最重要一点是向用户传达一个什么信息。也就是用户为什么买你的产品，或者升级到你的产品。很多人说微软的产品除了质量好外，市场也做得好。象IE就是一个很好市场运作的例子。比如，IE最初的用户定位,不是试图让Netscape已有的用户转到IE上，从来没有这么做过.而是面向新的Internet用户。这就是用户定位很清楚。此外，对IE不同版本，开发侧重点不一样，就需要用一条简单的信息告诉用户，这个版本比其他版本有什么好处。这些都是产品管理人员要做的。
下一个角色是程序管理，我们以前叫项目管理，但是上次我在上海讲的时候，学员说，他们说国内项目经理做的事情很不一样，所以这里我就叫程序管理。有时候我可能会交换着用。
在微软，程序管理主要是做产品，在适当的时候推出适当的产品。他碰到的最主要困难就是如何保持控制。适当时候意味着你必须控制好产品的发布日程，不能有延误。大家知道产品过程中不确定的就是人为因素，这个发布日期控制好，这是很困难的。还有要做出正确的取舍。有些时候你会在发布日期和新的特性之间需要做出取舍，或者是不是采取新的技术，用新的工具、算法什么是不是必要，我们是不是需要去做，做什么和不做什么之间，做出取舍，从而控制产品的特性并使其能满足市场需求。程序管理人员需要衡量做这些事情的危险性，需要衡量得特别清楚。
这三类人员把整个产品的策划，推向市场，以及产品开发过程控制基本上定下来了，可以是说最关键的。
剩下的有产品设计，主要是做产品的用户界面或者可视化方面的设计。这些人一般人都有设计方面的背景。象微软的产品，以前对用户界面设计或者用户交互方面侧重不是很多，因为传统PC，早期只是专业人员的工具。但现在越来越向消费者、初用者方向发展，那么对于界面设计要求越来越高。公司在这方面投入了很大的人力。我不知道大家都看到新的Windows XP、或者像“MSN explorer”没有，这些产品和传统的产品相比，外观，包括用户使用方式。都是完全不一样的，更注重的是一种整体的体验，经历。
产品设计还有一个重要的工作，就是保证产品所有可视部分保持一致。不同的模块或者不同的特性可能由不同的人员开发，如何保证可视部分看起来一样，使用户不至于在一个产品使用时突然觉得不是同一个公司的产品，这就取决于产品设计人员。
第五种人员是产品可用性评估工程师，他们主要做的是保证产品可用，易用，而且能够容易被用户接受。一般在产品开发的过程中或者初期，都有一些不同的原型，就是针对一些特性怎么做，用户怎么交互，设计一些不同的原型，然后交由可用性评估工程师做可用性测试。从而决定最终的方案。这方面微软一直是非常重视的。你可能注意到在IE早期版本里，地址栏里面并没有“Go“按钮，只是有一个地址栏。但是后来通过可用性测试，发现一些用户把地址敲进去后，就在那儿等着，也不知道按回车。确实就有这样的人。所以从5.0开始在地址兰后加了个按钮。用户敲完地址以后,可以试着按一下按钮,来连到他所需要的网页。
下一类就是开发人员。开发人员在微软应该是很重要的，但是我感觉相比之下,没有象在我们国内一些企业那么重要。开发人员主要工作,一部分是设计一些算法，对PM做出的文档或者特性说明要提出自己的反馈。还有更重要的一块，就是帮助PM推出产品日程，从什么时候可以做到“beta”1、2，什么时候可以发布。这些跟开发人员密切相关，所以又开发人员决定它的进度。除此之外，就是通常的写代码，编程与调试，以及后期的缺陷修复。
下一部分是测试人员。微软对测试非常重视。测试人员在产品开发过程中要独立完成。就是不受其他人员的影响，独立完成测试。另外某些情况下，要作为用户的代言人，把用户的利益放在首位。如果你认为这个产品这样发出去不行，就一定要坚持。当然这样往往就引起有一些激烈的争论，决定问题到底是要不要解决。但最终的结果是使用户受益。
再下一类就是微软特有的本地化人员。这一点我想对大家目前可能不是很适用。但我们将来怎么把我们的产品推向世界，有一个全球化的过程，也有通过本地化来满足其它中国以外其它市场的要求的过程，所以将来肯定会有这方面的需求。还有一类人员是文档发布，这里面包括网站方面的文档，软件里边的文档，这些文档主要是帮助用户怎么使用产品。还有面向开发人员的，做一些代码示例，这是文档发布主要的工作。我们传统谈到的开发文档在微软是PM来完成的，就是所有的程序经理在项目开始针对每个特性写非常详尽特性说明。
还有一类人是产品支持人员。这在微软也是非常重要的，一方面微软跟最终用户打交道最常见的一个途径，往往有很多用户打电话提出这个问题，将来在下一个版本会把它解决掉。还有最重要的在微软来说，用户每打进一个电话都是要花钱的，实际上产品支持直接影响到公司的营业额。提供更快速更有效的用户支持，是最重要的一个环节。
最后一个角色是运营管理，实际就是网站运营管理。大家也知道，微软产品目前越来越多和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的编辑、打印。但是有一些时间一个项目经理会负责不止一个特性，甚至有一些开发人员可能他在某些方面有专长，他也需要在不同组织之间流动，所以这种组织实际上是一个动态的。
下面我们谈一下微软产品开发过程。开发过程划分的基本原则是，希望把大的项目分为若干个里程碑式的开发周期，并在各个周期都要考虑一些冗余，使你的开发周期变得更实际一些。通过目标描述来保证所有的人是沿着同一个方向发展。利用产品特性描述来指导开发过程。同时利用用户的数据来决定一些特性的取舍，或者优先级的排定。加不加这个特性，不是开发人员觉得好，我就做这个东西，往往还是从用户角度来考虑，用户从中间有多大收益来决定。
还有更重要一点就是统一的术语。在微软内部刚进去时也会做类似这样的培训，会请的各种角色做一个讲座，大概需要六七个小时。其中有对很多术语、缩写，还有对这套开发模式的介绍。从而保证所有人理解的都是统一的。这样你才能保证无论在做事或者讨论的时候，大家的理解是一样的。
还有一点是在开发产品过程中不间断地测试，而不是做完了到某一个阶段才开始测试，因为往往那个那时候往往已经太晚了。
微软产品开发过程分为四个阶段，第一个阶段是规划阶段，这个阶段基本上是由产品规划人员以及项目经理来驱动的，这个阶段主要是要完成这样一些事情：一个是目标描述。基于这个产品目标，我们已经知道了，我们需要做哪些事，做哪些特性来达到这个目标，这样就决定了产品提供哪些的功能。然后PM就要根据这个功能来写出相应的规范说明。一般产品规格说明，就是传统上说得技术文档，基本会写两次，第一次写一个简单的，里面列出了你这个功能或者你的特性希望达到什么要求，跟我们整个产品的目标有哪些相关的，产品之间依从性，为什么要做这个特性。写完这一页的特性描述之后，大家会坐在一起看一看，排定一个优先级别，哪些事我们先做，哪些有可能做，或者哪些是下一版本在做。把这个事情做完了，程序经理会写一个更详尽的特性说明，这是指导开发、测试整个过程的技术文档。基本上一般都有一些模板。
在规划阶段，当所有的特性规格说明完了以后，还要制定日程进度表。这个日程进度表往往需要由开发人员的参与。看到了这些产品规范，根据你的经验估计做这个需要多长时间，还需要打入一些冗余，把这个做完之后，产品规划阶段就已经完成了。
产品阶段完成的标志，就是目标描述，所有特性规格说明，以及日程进度表的完成。这样就进入第二个阶段，即开发阶段。因为我们自己有特性描述，已经知道做什么。所以根据这些特性，会把这一阶段，分为三到四个小的阶段。基本的划分原则是重要的或者相互依从的特性开始做，剩下的一些次重要的。会在第二或三间段做。这一间段是由开发人员去推动。所有的开发人员开始写代码，对于每一个开发人员都有相应的测试人员，会把开发人员写的代码拿去测试。这个阶段完成的标志是所谓的特性完成，或者叫代码完成，也就是所有的这种特性都已经开发完毕。这时就进入了下一个阶段，测试阶段。测试阶段主要由测试人员推动。在开发阶段也有测试在进行，但在测试阶段进行的主要是集成的测试，象安装，兼容性测试，性能，或者其他方面的测试。此外通常还要发放一些“beta”版本，让用户去实际使用并发回反馈。这一阶段会有更多的“bug”进来，但是这一阶段基本上不会增加一些新的特性。这一阶段结束的标志是所谓的“零缺陷”。微软有一些来跟踪缺陷或者叫“bug”的工具，如果从这些工具看到针对这个发布周期已经没有任何活动的bug，这就标志着稳定化阶段已经结束。现在有一个趋势，就是稳定化阶段做得越来越长，从而更好的保证产品的质量。
到了零缺陷后，就进入了下一步的发布阶段。在这一阶段大家会继续跟踪bug的状态，直到确认这可以发布了。一般会做一个CD，或者把它发到网上。最后发布阶段会由产品经理、项目经理，以及做运营管理的人来共同执行。
总结一下，微软产品组有明确的分工及不同的角色，产品开发由四个阶段组成，即规划阶段，开发阶段，测试和稳定化阶段以及最后的发布阶段。总的原则在微软一个是有详细的分工和职责的划分，通过各个人人的角色控制产品开发过程。我刚才谈的四个过程，十一个角色，但是每个角色实际上并不是同步的。比如像产品规划人员，在第一个阶段和第二个阶段产品规划人员会有一些工作，到第三个阶段因为特性已经完成了，不会有新的特性，产品规划人员已经开始做下个版本。但是产品经理会继续做这个产品保证这个产品继续进行。还有是客户需求决定产品的方向和目标，往往在做一些决定时考虑的是客户和市场，很少纯粹为了技术和其他原因。最重要的是把大的项目分成若干个子项目，是渐进的，不是一次性把很大的问题解决。还有目标描述和产品特性说明，就是我们传统文档，这是为整个项目起到了指导作用，必须定义得很清晰，使所有人都能看到它。最后一点，从项目一开始开始让所有人都去介入。因为好的产品是设计出来的，不是最后开发出来的，因为前期基本上定下来以后，开发的后期是完成的阶段。如果设计有缺陷，比如没有考虑到技术支持方面的问题，后期很难做。假使再加进去对产品质量或者发布日期都有很大的影响。还有就是通过不间断的测试来保证产品的质量。
（微软研发中心杨永生谈微软产品开发）
本文地址：http://com.8s8s.com/it/it34176.htm