【构建之法】第9章-项目经理

本章重点：

• 团队角色分工
• 项目经理的由来和要求
• 项目经理和其他经理的区别
• 软件项目中的风险和风险管理
• PM的专业能力
• 如何开有效的会议

1 PM是啥

PM的M就是Manager，但是P有这几种：Product Manager、Project Manager、Program Manager，在不同的行业和公司，他们的作用各不相同：

• Product Manager：产品经理-正确地做产品。核心要求是，根据市场和用户需求，协调各部门资源，正确地把握产品定位和方向，解决用户的痛点，持续优化产品；
• Project Manager：项目经理-正确地做流程。他们对项目流程负责，即项目从立项到上线按时完成。正确地协调团队内部外部，调配各部门资源和时间，有效进行风险管理，保证一个项目顺利按计划结项，是一个项目经理的核心价值；
• Program Manager：微软的职位名称。微软产品团队三足鼎立的角色分配就是PM、开发、测试。PM负责除产品开发和测试之外的所有事情。从某种意义上说，是前面两种角色的综合。

本章主要介绍微软的项目经理 - Program Manager。

2 微软PM的来历

在微软的早期，随着业务的发展和团队的壮大，下面这两个问题凸显出来：

• 团队成员之间交流的成本急剧增长
• 有很多开发和测试之外的事情，需要专人负责

2.1 交流成本问题

在程序开发中，查尔斯·西蒙尼发现项目管理的复杂度似乎跟人员数量的平方成正比。

该怎么办呢？查尔斯想到了一个办法：他提议把程序员分成两种：

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

这个想法在理论上是好的，但实际上没有人想做SP，刚加入团队的开发人员会问：问什么我不能当MP？这次改革最后不了了之。

2.2 开发和测试搞不定的事情

随着软件复杂度的提高，用户需求的多样化，市场竞争的日益激烈，我们需要专门的人来做下面的事，而这些事往往是程序员不愿意花时间去做的：

• 和客户交谈，组织用户调查，发现用户需求；
• 了解和比较竞争对手的产品；
• 怎么让软件变得可用（Usable）、有用（Useful）；
• 怎么改进团队的流程。

后来，一个名叫贾伯·布鲁门萨尔的程序员提出了Program Manager（PM）这一头衔，并成为了微软第一个PM（1984年，Excel团队）。

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

• 负责一个功能的开发/测试人员和相关的PM密切合作，再由PM代表这一小组去和别的小组或客户代表打交道，大大降低了交流的成本；
• 有专人负责开发/测试之外的许多事务和项目进度的管理，让开发和测试人员专注于技术方面的工作。

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

3.1 微软公司中的PM分类

• 有做功能设计的PM；有些功能或产品需要深入掌握各个计算机科学分支的专业知识才能做好：例如Visual Studio中的各种计算机语言、框架、TFS的项目的项目经理；
• 有些PM需要对商业和客户有很强的了解能力：例如Office办公软件的PM；
• 有些PM需要具备广泛的经验和知识面，以及商业拓展能力：例如互联网MSN部门的PM；
• 有些是驱动流程的PM：例如推动几百人的团队完成一个版本的开发，又如保证Windows Phone能在几十种不同硬件上发布；
• 也有专门深入某一领域的PM：例如负责软件的国际化/本地化（Globalization/Localization）；
• 还有和研究人员合作，琢磨如何将前沿技术引入主流产品，做技术转化的PM。

3.2 Program Manager vs. Project Manager

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

3.3 如何成为一个合格的PM

成为一个合格的PM，需要以下几种能力：

• 观察、理解和快速学习能力：PM要能够在一个新的领域中很快上手，对老板/客户/利益相关人要有***同理心***；
• 分析管理能力：从每天项目中发生的诸多事情中，PM要能够*分析出重点、找到优先级、做判断、做决定等等；
• 一定的专业能力：PM通常也能写代码，能玩转Excel、PPT、Visio、甘特图，会PS，有文字功底，写的博客有人爱读，反正总得有几招绝活！此外，还要有大量的阅读，对IT行业、用户心理、社会都要有广泛的了解。

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

• ***带领***团队形成团队的目标/远景，把抽象的目标转化为可执行的、具体的、优美的设计；
• ***管理***软件的具体功能的生命周期（需求/设想/设计/实现/测试/修改/发布/升级/迁移/淘汰）；
• ***创建并维护***软件的规格说明书，让它成为开发/测试人员及时准确的知道，而不是障碍；
• ***代表***客户和用户的利益，主动***收集***用户反馈，***预期***用户新的需求。***协调并决定***各种需求的优先级；
• ***分析***并***带领***其他成员对缺陷/变更需求形成一致意见，并确保实施；
• ***带领***其他成员确保项目保持功能/时间/资源的合理平衡，***跟踪***项目进展，***确保***团队发布令客户满意的软件；
• ***收集***团队项目管理和软件工程的各种数据，客观分析项目实施过程中的优缺点，***推动***项目成员持续改进，从而提振士气。

著名的用户体验专家比尔·巴克斯顿在总结自己几十年的经验时说：过程创新可能超越产品创新，但两个创新并驾齐驱则胜于任何一个。

这是对PM最好的要求。

4 领导力-高效的团队讨论

4.1 组织高效的会议

一次高效的会议，组织者应该做到：

• 明确会议目的，要解决的问题是什么；
• 推动会议进程，促使与会者在每一个阶段做合适的事情；
• 总结会议，记录要点。

4.2 会议中的思维活动

会议的参加者想到哪里就说到哪里，个人的情绪也自由地发挥，虽然热闹，却是一种无序地交流，效率不高，我们应该把这些无序地活动逐步约束为有序地活动，然后让大家通过一系列地思维活动来分析问题，在一个时间段内只做一类思维活动，决定行动。思维活动有这几种类型：

• 理清事实；
• 表达直觉和感情：这对于会议后续进展有良好地润滑作用。这个思维活动地价值在于，让所有人都看到其余人的情感和直觉，这对整个团队构建互信、包容的文化是很有帮助的；
• 从乐观的角度分析问题：“对、而且…”，如“对，而且写了新的模块之后，可以大大提高登录的速度”；
• 从悲观的角度分析问题：“好，但是…”，提醒风险，如“这个功能可以一键分享用户的很多内容，好，但是这里有用户隐私泄露的风险么？”；
• 从创意角度去分析问题：从乐观角度和悲观角度分析问题都需要创意，所以这个“创意角度”是附属于以上两个思维阶段的。

这样会议就变成：

4.3 总结

平时开会讨论特别杂乱的原因是，在每个具体时段，每个人在扮演的角色不同，别人也没能理解不同人的角色和出发点。

改进的方法是：大家同时从一个角度出发分享，进行类似的思维活动，然后转到下一个角度。

这样，会议的结果将变成：

• 一些共识（consensus）：这些共识在项目当前里程碑结束之前就不必再讨论，也不允许会后再悄悄改变；
• 一些行动（action items）以及行动的负责人；
• 一些好主意（side ideas）以及这些主意的负责人：把这些好主意都放在“好主意停车场”上面，以后时机成熟再启动这些想法。

5 PM和风险管理

风险的类别和来源：

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

应对风险的手段通常有：进一步研究、接受、规避、转移、降低、制定应急计划。

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

• 第一层次：啊呀！大问题（Crisis！）
• 第二层次：缓和（Mitigation）并防止问题（Prevention）
• 第三层次：预计（Anticipation）
• 第四层次：把问题变为机会（Opportunity）