怎样看微软的Program Manager 这个角色

记得自己在顾问的经历中，曾和许多开发团队交流过微软的 MSF，许多人都曾经疑问过 MSF 组队模型中的Program Manager，因为从他们的公司，他们的团队无法找到这样的角色来对应，至于开发 Team、测试团队、设计团队、文档团队、配置团队、用户教育团队、本地化团队还能想象，但唯独 Program Manager 找不到对应的。因为一个 Program Manager 需要项目管理的技巧，Program Manager 也需要负责功能需求、Program Manager 还要写功能规范说明书、Program Manager 还要负责设计原型。Program Manager 要有三大硬功夫：Technical Proficiency，Project Management  和 Design Sensibility，而且还要有内功，拥有非凡的 Communication 能力和 Leadership。

然后问题就来了，很快就人问，什么是 Leadership？ 这个问题够开一门二周的课了。然后第二著名的问题来了，Project Manager  和 Program Manager 有什么不同？ 开发组的 Team Leader 和 Program Manager 有什么不同?

真的这样类似的问题非常的多，找到对应关系也许是你此时认为在团队或公司实施 MSF 的一个重要前提。但我相信你需要一些场景和 Context 来看这个问题。

Project Manager ——这是一个项目的最高决定人，在许多公司一个项目经理是一个项目的资源所有人。他需要完成这个项目，并进行项目管理活动。但需要项目经理（甚至大部分项目经理）不要求他会程序设计和精通技术，甚至进行编程。他的目标是完成项目，让用户验收，拿到验收单。可能他需要组织需求分析、设计、开发、测试、安装、部署、维护等等等，也可以产品以及开发出来他只需要完成客户验收的部分。总之，这是一个普通和广泛意义上的项目管理领域和范畴。

Program Manager ——这是一个产品开发过程中的角色，而不全是项目范畴的概念，它可以只存在产生开发的生命周期中。微软的所有产品是设计、开发、测试然后发布、再设计、开发、测试然后下一个发布。你会发现似乎没有用户验收的问题。

这里有两个 联想，第一种人很快发现，微软 MSF 走的产品研发的路线，和我们公司或团队的项目运作方式并不同。所以我们需要重新考察 Program Manager 这个角色，但是我们如何发挥 MSF 中 Program Manager 这个角色呢？ --舍弃不要？还是继续生搬硬套

第二种人，会联想到这样的问题，既然没有用户验收环节，那么微软的产品如何保证用户都接受，都会去购买，其实这也是一个验收的过程，暂且称为虚拟验收。一个项目的目的是为了让用户最后验收。那么微软在产品设计、开发、测试的环节如何保证它能够被"虚拟的验收"？靠好的设计、编码规范、风险评估、足够的测试？因为你总需要有足够的措施保障你的产品能成功，能被虚拟验收。

先看看，JOEL 说软件一书的55页怎么说的：

长期担任微软总设计师的Charles Simonyi 提出主程序员（Master Programmers） 的概念。其主要思想是，虽然由一个主要的程序员负责所有的代码编写，但是他或者她要紧紧的依靠高级程序员而且将他们视为“代码仆从”。与考虑调试每个函数的作法不同，主程序员应主要关注每个函数的原型而创建出可见的轮廓，然后将它扔给一位高级的程序员去实现。（当然，Simonyi是主程序中的主程序员。）由于主程序员这个术语显得太老气横秋了一点，因为微软用Program Manager 一词来描述此类概念……一个名叫Jabe Blumenthal的聪明人从根本上重新确立了程序经理的地位，这样一来，Program Manager就掌管着产品设计与规格说明书。从那以后，微软的Program Manager就负责收集需求，弄清代码的意图在于做什么，以及编写规格说明书。在通常的情况下，每个Program Manager配备大约5名的程序员，这些程序员负责用代码去实现程序经理已经以规格说明书形式确定的功能。Program Manager还要去协调marketing,文档创建、测试、其他内部的杂务以及所有那些不应该让程序员花时间的琐碎事务。最后，微软的Program Manager需要让人觉得他心里装有整个“公司的宏图”，而程序员则可以无所顾忌地一门心思让自己的那块代码确实显得合理而高效。

JOEL 娓娓道来了 Program Manager 的来历，这不是全部，至少不是我看待的全部。但 JOEL 说出一个很重要的特性 —— Master Programmers

Program Manager != Technical Proficiency + Project Management + Design Sensibility + Communication + Leadership。

这些都是一个Program Manager 要做的工作或素质。Program Manager 应该等于一个词 Program Manager = Ownership

一个Program Manager 代表着项目/产品中一个特性的 Ownership， 一个工作的 Ownership，一个风险的Ownership，任何需要 Ownership 的地方，这就是 JOEL 下面说的

Program Manager 的价值是无法衡量的。如果你曾经发牢骚说，程序员应该如何关注技术上的质量而不是可销售性，那么就意味着需要一个Program Manager。如果你曾经发牢骚说，能够写出优秀代码的人从来不会关心文档的优秀和语法，那么就意味着需要一个Program Manager。如果你曾经发牢骚说，产品似乎在毫无方向地随机飘荡，那么预示着需要给一个Program Manager。

你可以想象这样的场景，假如你是一个背负价值着10000000000000万合同金额的产品/项目经理，甚至你们公司的老总，他最关心的问题是，我们的产品今天能发布了吗? 客户需要的功能都开发完毕了吗?
假如有100个功能或任务，老板最希望看到的是像点将台一样，下面站立100个人，依次说，报告老板，01功能完毕，报告老板，02功能完毕，报告老板，03功能完毕……报告老板，99功能完毕，报告老板，100功能完毕。

这100个人每个都是一个Program Manager，你说原来 Program Manager 就是干这个事情的

我忘了考证具体的数字，这个你可以推测出来，比如 Office 开发团队有2000人，一个开发人员至少有一个或两个测试人员，就按1：1，那么有1000个开发人员1000个测试人员，那么按1：5（一个 Program Manager 下面有5个随从人员），那么至少就应该有200+200=400个 Program Manager ，然后你可以根据模块（比如 Word、Excel、Outlook 等等）、产品特性的大小，任务的大小，再对这个进行一些调整，比如产品特性大的一个Program Manager 下面还有许多小的 Program Manager，或有的 Program Manager 下面有5个人，有的有10个人。但无论如何应该有超过10%的 Program Manager （我忘了具体的数字，朱敏博士在一次培训中曾经介绍过这个数字）

又比如说典故中的诸葛亮火烧赤壁时说的万事具备，只欠东风。在这里就意味着有10000个 Program Manager，再加上一个负责搞定东风的 Program Manager。不然这事情没法成功。
当你理解了 Ownership 的含义，你就会更容易的看懂 JOEL 后面说的，找什么样的人做 Program Manager，更重要的是如何在你的公司、项目或开发团队应用 MSF 模型。MSF 3.0 4.0 甚至以后不叫 MSF 了，但Ownership 的原则不会变的，也许你们公司或开发团队没有 Program Manager 这个头衔，但应该有肩负Ownership 的人。比如: A 事情 Ownership 是你，那就意味着：A 事情这就是你的工作，你的工作就是把 A 事情做到一种可以刻量的程度；任何时候，A 事情都由你负责和掌握，有什么问题都会来找你；同样为完成 A 事情，只有你能做出决定和选择，而且也只有你为A事情的结果负责。你最大的使命就是确保让A事情成功或完成。如果 A 事情失败了，那么你也就完了。

许多公司不是没有 Program Manager，而是没有 Ownership 的概念。一件事情可以让 A 做，也可以让 B做，A 做是一个结果，B 做是另外一个结果，而且两个结果都接受都可以，甚至3个 N 个结果都行。一件事情A 主管说这么做，B 主管说要那么做，怎么做? 一件事情有许多的声音或 Ownership 不清楚。 这会浪费多少的人力、物力、时间和金钱。

所有对于所有的项目经理、开发团队的主管来说，无论一个开发任务有多大，多么困难。正如刚刚所说的如火烧赤壁一样，那么这意味着你要确保这10001件事情发生，确保每件都有一个人（Master） 来负责，而且结果只有一个。当10001个结果发生，火烧赤壁才能成功。

回去看看三国演义，你看看各位战将都负责了什么，周瑜成功扮演了一个 Program Manager，他必须保证曹操相信他殴打黄盖的苦肉计。而诸葛亮在火烧赤壁的项目中成功扮演了一个 Project Manager ，同时也是担任了一个 Program Manager，因为他必须保证借到东风。

你们公司不必像微软一样一定要有 Program Manager 这个角色，但一定要有明确的 Ownership 意识和机制。诸葛亮这么做了，确保了火烧赤壁，微软这么做了，确保了他的产品能及时发布，你的项目/产品要成功，我想你至少考虑要这么做。

这么说，你或许领会少许微软 Program Manager 这个角色的意义了吧。最后，真的，不要拘泥于 MSF ,不要拘泥于 Project Manager  和 Program Manager  的差别。不要拘泥于 Program Manager 这个头衔或定义。