当Windows 2000经过胎死腹中的危机，终于如凤凰涅般再生时，微软决定给整个产品组成员拍摄一张合影，以纪念这个历史时刻的诞生。到了拍摄那一天，微软人发现，他们只有把摄像师安排在飞机上才能干好这件事儿——因为Windows 2000产品组整整有5000人！

“团队=软件”，微软软件开发管理理论的基础可以这样一个恒等式来表达，软件可以忠实地展现创造它的团队的一切优点和缺点。软件业中没有两个完全相同的失败，但最常见的莫过于新版本跟不上对手的脚步，微软开发模式的精髓之一，便是通过产品组团队中每个成员对职责的承诺来控制产品的开发过程，保证新产品准时地、经常地被推出。

这正是软件业最大的金科玉律！

开发周期四阶段

微软的产品开发遵循一个完整的开发周期，这个产品开发周期被分为四个阶段：规划阶段、开发阶段、测试阶段（也叫稳定化阶段）和产品发送/出品阶段 。

微软中国研发中心中文技术部经理李东女士告诉记者，在产品的规划阶段要做三件事：拟定基于客户数据的目标描述、基于目标描述的规格/特性说明和基于规格说明和特性优先级制定的进度表。规划阶段中最重要的事情是让整个产品组的成员对共同的目标形成共同的认同。一座伟大建筑的诞生往往只缘于一位伟大建筑师的不朽贡献，但一个伟大软件的设计却需要成百上千人的智力创造。

第二个阶段是开发阶段，这个阶段也叫主要里程碑阶段。微软的任何一个产品组在这个阶段都将根据特性将项目划分成若干个子项目，每一个子项目的完成就对应于一个里程碑。在李东的经验中，一般微软中国研发中心会在这个阶段把产品划分成2～3个里程碑。Milestone1（第一个里程碑，简写为M1）内要完成的是核心的特性和功能，或今后需被共享的部件。那些将对产品稳定性形成很大影响的功能，也应该被放到Milestone1。Milestone2可以放比milestone1次要一些、但也是比较重要的特性和功能。Milestone3放的特性和功能对核心特性和功能的依赖性不大，有的甚至可能根据市场的变化重新评估和取舍。总体来说，应根据特性和功能在结构上的重要性来决定它应当被放在M1、M2或M3来做。

在每一个子项目（里程碑）内，进度表应当具体到每一个开发人员，而且进度表中应当加入缓冲时间。在子项目的执行过程中，程序经理（其角色下面详述）负责协调开发过程并更新规格说明，在开发人员编码、优化和调试的同时，测试人员进行Bug测试及报告，直到特性稳定化之后，里程碑才达到。开发阶段有一个微软所有的产品组都会用到的重要里程碑：代码完成（CC：Code Complete）。达到这个里程碑，意味着所有特性的编码任务全部完成，特性的集成测试通过后，除解决Bug以外，不再有新的代码进来。代码完成是明显的界线，标志着产品可以交付测试。至此开发周期进入第三个阶段。

第三个阶段是稳定化阶段，也叫测试阶段，或叫QA阶段。测试人员对软件做各种各样的测试，其中开发和测试工作是始终并存进行的：测试人员发现Bug，开发人员解Bug，测试人员再检测这个Bug是不是解了。如果你是一个程序经理，这个时候去看记录Bug的数据库，会发现一大堆Bug急剧涌现，随着一个个Bug被解，Bug量逐渐递减。当Bug量控制到某一个特定范围内就可以发Beta版，进行外部测试。这个时期程序经理要跟踪监督用户的反馈，开发人员及时解决用户发现的Bug。Beta测试结束之后，再经过一段时间的测试，就会达到零错误版本（ZBR）里程碑，零错误版本里程碑的达到，并不意味着没有Bug或遗漏的功能，而是标志着团队的成品达到了事先规划的品质水平，可以向发布候选（RC）里程碑进军了。值得注意的是，作为RC的产品，应包含出品之前所必须具备的全部文档资料。发布候选（RC）可能会经历RC0、RC1、RC2 等（最佳情况是RC0测试之后没有一点问题，那是最后要发布的那个产品了），但如RC0以后又发现了Bug，并且大家认为这个Bug必须要解，就又出来RC1，Windows 2000就是经过RC3之后才进入产品发送/出品阶段的。

产品有了稳定的版本就进入最后的阶段——产品发送/出品阶段。对于研发队伍来讲，十月怀胎、孩子终于出世的那一天就是发送投产（RTM——Release To Manufacture）。RTM之后到用户真正拿到这个软件产品之前还要经过我们耳熟能详的产品发布会（Launch Event），当然，这部分工作已经被微软的研发机构移交给市场和销售机构，由产品经理完成相应的产品宣传策划，把产品推向市场。

微软经典团队角色

微软的产品组典型的人员角色有几类（参见图2）。一类是产品规划（Product Planner）和产品管理（Product Management）。产品规划的使命是通过研究，向产品组提供诸如用户需求、市场导向、竞争对手和产品方向的分析，确保产品满足客户的需要；产品管理的使命是确定获利市场，同客户沟通产品的价值。这两个角色相当于对产品的规划以及产品的销售。一类是程序经理（或叫程序管理：Program Management），他负责整个产品开发过程的协调，是微软各产品组中非常重要的一个角色。

开发人员（Development）、测试人员（Testing）、可用性测试员（Usability Testing）之类，在微软也是一些比较特殊的角色。此外还有：Beta测试人员（Betas），如果这个产品需要汉化的话；本地化项目管理（Localization Project Manager）；用户教育（User Education）；最后是售后支持（Product Support）,等等。

尽管微软的产品组角色定位非常清晰，但这些产品组多为横向组织，由多个部门的成员组成。比如产品管理属于微软的销售机构，而售后支持属于售后服务机构等等。微软不同机构和部门之间的协作性极强，这是保证微软按时完成高质量产品的重要原因之一。

在微软的产品开发周期中，每一个角色在不同的阶段有不同的侧重。在规划阶段，作用比较大的是产品规划和程序经理。开发阶段显然是开发人员的作用比较大，测试人员则在第三个阶段“QA阶段”很重要，但是程序经理在这两个阶段的作用都很重要。

产品规划人员对产品影响最大的作用体现在规划阶段。这个阶段的产品规划需做用户问卷调查，用各种各样的研究手段来试图了解用户的需求，并创建目标描述。这个阶段产品管理也收集用户需求，但他主要调查的是市场走向，他关心的是如何与客户沟通产品的价值。产品规划在整个产品开发周期中总是充当一个用户代言人的角色。产品管理在第一阶段和最后阶段发挥作用，产品管理必须设法了解新产品的获利市场所在，并且很好地同客户沟通产品的价值。

相比于产品规划和产品管理，程序经理与程序经理之后的角色与产品具体开发过程更直接相关。

特殊角色——程序经理

在微软的产品组中，程序经理的角色很特殊，他是惟一在产品开发周期的前三个阶段都显得非常重要的角色。

程序经理在规划阶段要贯彻和推进目标描述，书写功能/特性规格说明，创建主要的进度表。规格说明是基于产品规划所产生的目标描述来具体定义特性的实现步骤，目标描述文档是基于大量用户的调查报告和各种研究方法得出的用户的需求，定位产品的目标。但这只是给出了一个大方向，程序经理必须把这个大方向细化成若干个具体的特性，这些特性不仅要满足目标功能的要求，而且又必须是程序开发人员能够理解的语言。比如 Word某一版要支持HTML，产品规划只定目标，但程序经理就要把这个目标细化成几个具体的特性。

在第二个阶段，程序经理要管理整个开发工作的进度，检查开发人员的实现是否与规格说明相吻合，而且要使团队目标集中、齐心协力。如果在开发过程中有什么特性的变化，或者某些功能在设计时很好但在实际开发中出现问题，程序经理便要负责其更新规格说明，还要与产品规划、测试人员沟通项目的进展状态，协调开发过程中出现的问题。代码完成里程碑达到之后即开始大规模的测试，程序经理那时的作用就更大了，他要制定和控制每个Bug的优先级，做取舍决定，发送Beta版并收集用户反馈，确保产品按时达到发送候选（RC）。

一句话，程序经理的中心任务是保证软件高质量并按时出品。由于总是要在品质与进度上找到平衡点，程序经理必须精于“引导、驱策、鼓励、要求”团队做出最好的软件和表现出最好的工作效能。

在微软不同的团队里，程序经理所做的事情也有一定的差别。有偏技术性的设计功能的程序经理，他们是团队中的关键人物；有一种程序经理被叫做Release Program Manager，他的主要任务是控制开发流程;还有的程序经理会做一些客户需求调查的工作，定位产品方向。无论如何，程序经理的基本素质首先是要有很好的沟通技巧，具有设身处地为他人着想的本领；其次考虑问题周全，能处理复杂的情况；此外，程序经理要对开发产品所使用的技术很熟悉，对用户需求的理解力也要非常好。比如在具体的开发过程中，测试人员发现Bug越多越好，但开发人员却希望Bug越少越好，程序经理要善于协调二者的矛盾；在产品的开发过程中通常会出现人员突然流动的现象，或者硬件环境出了问题，或者外边竞争对手出现变化，程序经理对这些要反应非常机敏，有能力做出对公司、产品和客户影响最小的果断的取舍和决定。

微软的开发人员无疑是每一个产品组中非常重要的角色。一个头衔是软件设计工程师（SDE——Soft Design Engineer）的开发人员的级别有可能比某一个经理要高很多。在微软，开发人员根据他本身知识和能力的不同分为不同的级别，顶级的开发人员负责整个软件的结构设计，中间有负责某一功能类的结构设计师，最底层的开发人员只完成规定的模块实现。好的结构设计对产品的稳定性、可扩充性非常重要，特别是对一个由多人参与的项目而言更是如此。在产品组中，最厉害的开发人员是整个产品结构的设计师。应该说，微软每一个产品中都有几个核心开发人员来控制整个产品的结构，其他开发人员则在他的领导之下共同完成开发工作。

可用性测试的重要

所有用过微软产品的人会有一种感觉，微软产品非常易用。如何使产品做到易用？微软的办法是通过重视可用性测试（Usability Testing）来实现。可用性测试的使命是通过在产品开发周期的各个阶段加入客户资料和信息来使产品更有用、适用和易用。

在产品开发周期的第一个阶段可用性测试就要展开工作，比如，微软中国研发中心的产品组会把产品的新特性做一个模拟的模型，找用户来试用，产品组的可用性测试人员便会在试用过程中准备录音机、摄像头，把用户的行为摄下来，说的话录下来，按的键记录下来，研究他们对产品的反应，以便把产品设计调整到足够好。

微软中国研发中心中文处理组有一个产品 “微软拼音输入法”，其最早的帮助功能是用鼠标右键击活菜单，这是Windows常用的菜单风格，但是通过前期的可用性测试，李东他们发现中国用户习惯了用鼠标左键，很少用右键，这样用户很难找到微软拼音的帮助功能。后来微软中国研发中心把“帮助”放在显示特别明显的地方——输入法状态条上，这样，按左键就能使用帮助功能。“用户的需求可能跟你想的不一样，这就要真正倾听用户的呼声，让用户来试用，看用户的反应，来决定修改你的产品”，李东告诉记者，微软中国研发中心这样的例子很多。

在第二个开发阶段，当开发人员达到M1，能看到产品的最重要的特性时，可用性测试人员要随时反馈设计好不好，如果要有个别的改动，则在M2中将M1的某些功能改动加进来。可用性测试人员要理解用户的工作领域、行为和心理，微软公司总部有很多做可用性测试的人员是心理学方面的专家。用户的感受只有通过可用性测试人员分析、理解成对功能的描述，或者对功能的反馈，才能使产品开发人员能够理解并改进。

里程碑式的开发模式的好处

综观微软对软件开发周期过程的管理，其精髓的做法一是将大项目划分成若干个子项目的里程碑式的开发模式；其次，通过对产品组各人员角色对职责的承诺来控制产品的开发过程，以保证产品的进度和质量。

不管是小软件还是大软件，里程碑的概念在微软所有的软件开发中都会被用到。这也是微软在软件开发上摸索多年凝聚所得。国内软件企业的开发大多是从有一个想法就开始做，不分什么阶段，但往往因为软件功能太多，不同的人负责不同模块，到产品的最后阶段再去集成和测试，大量原来没有预计到的问题都“冒”了出来，这时再去“动”各个部分，时间肯定要推迟。这种模式将导致两个问题:一是质量无法控制，二是时间无法控制。

李东认为，在微软里程碑式的开发模式下，做同样大的产品，因为按子项目来划分里程碑，每一个子项目都经过一定的稳定化阶段，再进入到第二个子项目的时候，就是基于一个相对稳定的一部分子项目基础之上的行为，这样就将风险或错误的累加分散和降低。以局部的质量控制来保证整体产品的进一步稳定，能使得质量和进度得以很好的控制。而且，把一个大的项目分散到不同的阶段来完成，可以灵活地去增加或减少一些功能，否则，把增加或减少功能集中到最后集成阶段，而且是在不稳定的环境下来做，困难可想而知。这就是里程碑式的开发模式优秀之处所在。虽然里程碑的做法在成本上比较高——为了协调出大家对里程碑一致的价值观，为了协调出里程碑的衡量准则，如此等等，团队必须付出大量时间和精力，承受比较大的痛苦，但这是惟一能够确保开发成功的方式。

国内软件企业的开发模式多为“大拿领衔制”，通常公司十多个技术人员中间有一个技术“大拿”，剩下人辅助他，把这个产品的所有代码写完，则软件就算完成了。“大拿领衔制”脱不去小作坊的味道，虽然保证了“技术大拿”的创造性，却失去了软件研发过程应有的规范。

软件企业的创造性和制度要相辅相成。在微软的所有里程碑中，“代码完成”里程碑（code complete milestone），是一个重要的分界线。在代码完成之前，产品组自由发挥创造力，最需要大量的交互和碰撞。代码完成之后，则需严格按照里程碑完成进度。进入测试阶段，微软通常把里程碑分得更细致，比如Beta、零错误版本、发布候选、RTM等等。每个里程碑都不是简单的摆设，而是有严格的规定，快到里程碑的时候开发人员不能做没到里程碑时的修改，“原来一个Bug怎么改都可以，但到里程碑附近的时候，就要求只能改动最重要的Bug”，微软中国研发中心副总经理徐汕开发Windows 2000时曾与副总裁吵过架，“我们觉得中文版需要这项功能，但当时已经太晚了，大家争吵了很长时间，最后还是不能改。”为保证软件按进度完成，靠近里程碑时需要“收敛”，而收敛惟一的方法就是少做事情。过了一个里程碑，产品比以前的质量就要好许多。通过一个一个里程碑来收敛，这个项目不会偏离目标很远。从代码完成到RTM是微软软件开发周期中非常重要的过程，这个时候已经完成充分发挥智力的时期，而规范成为更重要的要素。（注：本文只给出了微软团队工作方式的常规模式，具体的实践模式可参考微软Visual C++事业部总监吉姆·麦卡锡所著书《微软团队成功秘诀》。）