特殊角色——程序经理

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

    程序经理在规划阶段要贯彻和推进目标描述，书写功能/特性规格说明，创建主要的进度表。规格说明是基于产品规划所产生的目标描述来具体定义特性的实现步骤，目标描述文档是基于大量用户的调查报告和各种研究方法得出的用户的需求，定位产品的目标。但这只是给出了一个大方向，程序经理必须把这个大方向细化成若干个具体的特性，这些特性不仅要满足目标功能的要求，而且又必须是程序开发人员能够理解的语言。比如 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++事业部总监吉姆·麦卡锡所著书《微软团队成功秘诀》。）