《构建之法》第九章 项目经理

摘至 邹欣《构建之法》一书，以作学习之用

PM 是啥

软件团队里除了能写代码、测试代码和画图做设计的成员，还有一类角色，不做上面这些事情但也很重要，我们叫他们项目经理——PM

PM的M就是Manager，但是P有这几种：Prod-uct Manager、Project Manager、Program Man-ager，在不同的行业和公司，他们的作用各不相同。接下来介绍的是项目经理——ProgramManager

• Product Manager：产品经理——正确地做产品
  目前国内公司大部分PM都是指这个职位。产品经理对一个或多个产品或产品线负责，而互联网产品涉及到这些方方面面：产品定位、市场发展、需求分析、运营、营销、市场推广、商务合作。产品经理横跨这些部门，寻找资源，持续推进产品。随着产品的发展，不同公司，对PM要求会不一样。 核心要求是，根据市场和用户需求，协调各部门资源，正确地把握产品定位和方向，解决用户的痛点，持续优化产品

• Project Manager：项目经理——正确地做流程
  在某些公司，这个职位与产品经理分开单列。他们对项目流程负责，即项目从立项到上线按时完成。正确地协调团队内部外部，调配各部门资源和时间，有效进行风险管理，保证一个项目顺利按计划结项，是一个项目经理的核心价值

• Program Manager：微软的职位名称
  微软产品团队三足鼎立的角色分配就是PM、开发、测试。PM负责除产品开发和测试之外的所有事情。从某种意义上说，是前面两种角色的综合。微软通常有专门的产品策划（Product Planner），他们和市场部门的专职人员一起，负责产品的长期发展和市场推广

微软PM的来历

交流成本问题

项目管理的复杂度似乎跟人员数量的平方成正比。一个团队里若有4个成员，就有6种双向依赖和交流的途径，然后增加一位新成员，就要增加4条新的双向依赖交流的途径。对于N个成员的团队来说，交流的途径总数是n×(n–1) /2，这种N的平方的增长意味着这样的交流对人类来说是不可持续的。

解决办法：把程序员分成Master Programmer（MP）和SlaveProgrammer（SP），MP和其他成员交流，了解需求，MP只写抽象的伪代码，或者对功能的描述；SP根据MP的文档，实现具体的功能。SP只用和MP交流

开发和测试搞不定的事情

随着软件复杂度的提高，用户需求的多样化，市场竞争的日益激烈，光有程序员和销售人员是不够的。销售人员当然可以把顾客的需求直接告诉开发人员，但是开发人员往往听不懂。我们需要专人来把市场/销售人员那一套MBA的套路语言翻译成程序员能懂的规格说明书（Spec）。也就是说，我们需要专门的人才来做下面的事，而这些事往往是程序员不愿意花时间去做的：

• 和客户交谈，组织用户调查，发现用户需求

• 了解和比较竞争对手的产品

• 怎么让软件变得可用（Usable）、有用（Useful）

• 怎么改进团队的流程

PM的出现让团队内部的互动出现了两个新特性：

• 负责一个功能的开发/测试人员和相关的PM密切合作，再由PM代表这一小组去和别的小组或客户代表打交道，大大降低了交流的成本

• 有专人负责开发/测试之外的许多事务和项目进度的管理，让开发和测试人员专注于技术方面的工作

PM做开发和测试之外的所有事情

• 有做功能设计的PM；有些功能或产品需要深入掌握各个计算机科学分支的专业知识才能做好。例如Visual Studio中的各种计算机语言、框架、TFS的项目的项目经理，SQL Server、Windows Server、Azure、Bing Search核心算法等团队的PM

• 有些PM需要对商业和客户有很强的了解能力，例如Office办公软件的PM

• 有些PM需要具备广泛的经验和知识面，以及商业拓展能力，例如互联网MSN部门的PM

• 有些是驱动流程的PM，例如推动几百人的团队完成一个版本的开发，又如保证WindowsPhone在能在几十种不同硬件上发布

• 也有专门深入某一领域的PM，例如负责软件的国际化/本地化（Globalization/Localiza-tion）

• 还有和研究人员合作，琢磨如何将前沿技术引入主流产品，做技术转化的PM

下表列出了Program Manager和一些公司的Project Manager的区别:

Project Manager	Program Manager
是团队的行政领导	和大家平等工作，推动团队完成软件的功能
通常是团队和外界打交道的唯一代表	一个团队可以由很多PM
对项目的功能有最后的决定权	和其他团队成员一起形成决议
管事也管人	管事不管人
不一定做具体工作	一定做具体工作

PM最大、最独特的贡献是什么?

带领团队达成最重要的目标，并保持团队的平衡

在软件行业发展初期，软件都是为维持机器本身的运作服务，或是做科学计算，这时候也许看不出PM的作用。随着产业的发展，软件应用的深度和广度、软件的复杂度、软件团队的复杂度都极大地提高了，这时候我们需要一些人，起到沟通、交换、影响、润滑、讨价还价的作用——就像商业社会的金钱一样——PM就是这样的角色，PM主导的产品中，“不犯大错”成了一个特点

PM 和风险管理

PM做开发和测试之外的事情，开发和测试都是专注于代码，代码之外，还有什么呢？还有很多不确定性——风险。PM要在整个项目的生命周期管理风险。对于软件项目来说，风险是在正常软件生命周期事件之外的、可能发生的影响项目的成功的事件。今天我们在项目中碰到的意外问题，它们就是昨天的风险。一些PM说，我经常担心项目进展，夜里睡不着觉。但是，“担心项目”不等于“风险管理”。既然是不确定性，那就有很多来源，我们可以把风险分成下面的类型：

风险的类别	风险的来源
人员	客户、最终用户、利益关系人、项目成员、合作伙伴
流程	项目的预算、成本、需求
技术	开发和测试工具、平台、安全性、发布产品的技术、与我们产品相关的技术
环境	法律、法规、市场竞争环境、经济情况、技术大趋势、商业模式、自然界

我们通过几个例子来分析各种情况：

• 开发人员签入的代码有一些小问题，这是风险么？这不是风险，因为代码签入带来的负面影响是软件生命周期的正常事件——是一个常态。我们并不期待每个人都永远签入完美的代码。如果有人认为所有的代码签入必须是完美的，此人将是项目的一个风险。在另一种情况下，项目组花大价钱招募某外部公司开发一个关键模块，存在的风险是，外部公司提供的模块质量可能大大低于预期

• 开发人员在项目启动时提出，“我们怀疑，产品目前采用的技术路线可能实现不了我们的设计”，这的确是一个 技术方面的风险。如果到了项目进展的中后期，我们才确认“产品的技术路线的确行不通”，那么风险就变成了一个危机（Crisis）

• 某个国家是否会在将来的一年中发生大地震，导致当地的一个企业陷入困境而取消订单，而导致本公司紧缩开支，本项目的预算遭到削减。这是 自然界触发的风险

• 国家相关法规将来可能有修改，禁止非官方的互联网机顶盒，以及通过这些途径播放内容的App，这是一个来自 法律法规方面的风险

应对风险有几个手段

• 进一步研究
  例如，“听说新的HTML5标准快要出来了，可能会极大地改进用户体验，我们目前用的原生代码很快会被淘汰！”，最好的回应就是做扎实的技术研究。

• 接受，不必为团队完全掌控不了的事情而过多操心
  例如，公司高层可能有人事变动，也许会影响到本项目……

• 规避：能否改变项目的范围，躲开这个风险？
  例如，听说6个月后，监管机构会严格控制视频播放软件和机顶盒的资质，我们的项目能否避开这一领域？

• 转移，能否像击鼓传花那样，把风险交给真正有能力应对风险的团队负责？
  例如，如果我们的软件进军到一个新的国家，可能会受到专利方面的许多指控。那么，我们能否让公司的法务和专利团队负责此事？

• 降低：降低某个风险对团队的危害程度
  例如，我们知道飞行总是有一定的风险，但是我们不能因为这种可能性而不出门。有些公司就有明确规定不能让三个或以上的副总裁搭乘同一个航班

• 制定应急计划
  下半年的预算很可能会缩减，我们不能支持所有的开发和测试人员，但是团队的目标不会有大的变化。这时候我们要准备一两套预案。

风险管理的水平有多个层次

第一层次：啊呀！大问题（Crisis！）

• 由于没有风险管理，对于突发事件没有预案，只能在事发之后才开始了解情况，进行危机管理

第二层次：缓和（Mitigation）并防止问题（Prevention）

• 对风险有一定的准备，能把问题缓和下来

• 更进一步，能动员团队成员、管理层、合作伙伴一起想办法防止事故发生

事实上，对于软件开发过程中常见的风险（不断增加的新需求，随意改动的需求，时间估计不准，人员流动等），我们可以采取更好的流程来缓和或预防问题的发生，例如

• 规定在一个冲刺阶段任何需求都不得变动

• 采用快速迭代、增量改进的办法避免错误估计的影响

• 采用结对编程方式增进团队对代码的了解

第三层次：预计（Anticipation）

• 从定性的猜测进步到定量的预计（预计可以有一定的范围），从而有效地做准备
  例如我们预计到保险相关业务的税费可能会有调整，团队会把相关税费的参数（以及相应的模块）设计为支持动态下载，并进行相应的测试。这样，当税费真的调整时，我们就避免了费时费力地被动应对

第四层次：把问题变为机会（Opportunity）

• 从关注风险的负面影响转化为关注风险能否带来正面的机会
  例如：一个开发PC桌面办公软件的团队，已经处于市场中下游，预计到移动设备的大量发展可能会对PC造成冲击，自己的产品在PC端发展前景更不好。于是提前布局，加强针对移动设备的开发，特别是PC–移动设备的同步功能。经过一段时间的努力，反而在移动和PC端都有很大收获

PM经常和人、管理流程打交道，经常处理“不确定性”，在反复多次对“不确定性”进行处理的过程中，一个团队的风格和习惯就慢慢形成了。因此，PM对企业的文化应该有深刻的认识，并且有直接的贡献。从另一方面说，风险管理和团队已经形成的文化有关，如果团队文化鼓励奖励那些说大话的人，忽略那些指出风险的人，但无人对最后的结果负责，那么，风险管理就是一个高危的职业

PM 的能力要求和任务

成为一个合格的PM，需要哪些能力呢？

1. 观察、理解和快速学习能力PM要能够在一个新的领域中很快上手
PM要能理解用户，能站在用户的角度上考虑问题，观察发现用户不善于表达的需求，体察团队成员的言外之意，倾听老板/客户/利益相关人的弦外之音。要有能够理解别人的处境、心理、动机的能力——同理心。一个PM平时或许能玩转很多高技术的工具，但是当工作需要时，他/她能突然把自己变成一个完全不懂技术的菜鸟用户，从用户的角度来看问题。

2. 分析管理能力
每天项目中发生的事情千头万绪，PM要能够分析出重点，找到优先级，做判断、做决定……一个项目和一个人一样，每天都会碰到各种问题：

• 重要而紧急的

  • 网站崩了！
  • 程序员小飞突然提出离职！

• 重要而不紧急的

  • 按照流量和内容的发展趋势，三个月后，目前的架构似乎撑不住，但是现在还凑合……
  • 程序员们都不写文档，他们三个月前说等忙过之后会写的，但是……

• 不重要而紧急的

  • 老板的老板问到了项目的进度！要写一个PPT，向若干人征求意见，并及时得到反馈

• 不重要且不紧急的

  • 领导想召开全公司大会，要表演节目……

PM如何处理这些事情呢？

3. 一定的专业能力
如果一定要说专业能力的话，PM的专业就是理解和表达，你能否理解不同人的心理、需求和言外之意？你能否借助文字、图表、草图，甚至代码来清晰准确地表达自己的想法？PM 要始终能满怀激情地向用户兜售产品，向团队兜售希望。史蒂夫·鲍尔默的销售能力就是一个极好的例子[注释10]。PM通常也能写代码，能玩转Excel、PPT、Visio、甘特图，会PS，有文字功底，写的博客有人爱读，反正，总得有几招绝活吧！不用说还要有大量的阅读，对IT行业、用户心理、社会都要有广泛的了解

4. 自省的能力
一个PM做第一个项目时可以拍脑袋定工期，拍胸脯打包票，最后拍屁股走人（谁没年轻过呢），但是失败之后要有自省和自我改进的能力

在一个项目中，PM的具体任务

1. 带领团队形成团队的目标/远景，把抽象的目标转化为可执行的、具体的、优美的设计；

2. 管理软件的具体功能的生命周期（需求/设想/设计/实现/测试/修改/发布/升级/迁移/淘汰）；

3. 创建并维护软件的规格说明书，让它成为开发/测试人员及时准确的指导，而不是障碍；

4. 代表客户和用户的利益，主动收集用户反馈，预期用户新的需求。协调并决定各种需求的优先级；

5. 分析并带领其他成员对缺陷/变更需求形成一致意见，并确保实施；

6. 带领其他成员确保项目保持功能/时间/资源的合理平衡，跟踪项目进展，确保团队发布令客户满意的软件；

7. 收集团队项目管理和软件工程的各种数据，客观分析项目实施过程中的优缺点，推动项目成员持续改进，从而提振士气。

著名用户体验专家比尔·巴克斯顿在总结自己几十年的经验时说

过程创新可能超越产品创新，但两个创新并驾齐驱则胜于任何的一个。这是对PM最好的要求