项目经理是大傻B吗？

一些背景故事

坊间流传着很多关于PM（Project Manager，项目经理）的笑话，在这些不无刻薄的笑话中，PM往往被描述成一个盲目的承诺客户需求变更，不了解实际情况而又喜欢指手画脚的专门坑开发的家伙。毋庸置疑，这些笑话当然是那些聪明的开发发明的（不过你得承认，在很多团队，这些笑话其实是实实在在每天都在发生着的）。

在智力工作中，对于开发的实际进度，开发速率等问题，具体着手做的人永远比在背后指手画脚的人更有发言权。软件开发正是一项智力活动，优秀的软件无 法通过人力的堆积而产生。一个关于PM的经典的讽刺是：PM就是那些指望着9个女人在1个月内生出1个小孩的二货。从传统的意义上来说，这个笑话还真是一 针见血。

我记得在加入ThoughtWorks不久的时候，私底下经常听到这种论调：PM基本就是项目上被人鄙视（当然大家不会表现的那么明显就是了）的角色，基本上负责团队建设去哪儿这种杂事儿就行了，团队的其他人员可以高度自治，并不需要被管理，项目就会如预期般按时交付。

这些论调在某些情况下可能是对的。但是如果在国内项目的这个上下文里，没有一个专业的PM来协助项目，控制需求，划定项目范围，与客户谈判等等，没有任何一个项目是可以真正成功交付的，指望高度自治的开发们来完成项目？咱们还是现实一些吧。

一个悲剧的事实是，开发人员往往都恃才傲物，有时还会带着一幅要来拯救世界的心态来做项目，这事实上和客户的期望，以及PM的期望是有很大出入的。 在项目启动之初，PM会面临重重困难：首先，团队里的每个人都不好管，而且每个人都认为自己不需要被管理（当然这种想法在大部分时候都是错误的）；其 次，PM需要和客户快速建立信任，并推动项目进入正轨；最后，往往留给PM自己的时间也非常有限，他们也需要学习大量的项目相关的上下文（业务上下文，人 员关系，资源协调等）。

除了催进度，PM平时还干点啥？

本质上开说，PM其实就是一个轮询器：识别所有的项目风险，然后不断跟进。项目风险可能是技术风险，比如某个技术上压根搞不定的问题。也可能资源风 险，比如人手不够，或者开发者很多，但是没有足够的设计师协助，这些风险都会导致项目无法按照时间交付。一个客观事实是，所有项目都会变化，做完售前到需 求分析结束之后，需求可能会发生巨大变化，如果还按照报价来做项目很可能会亏本。

PM的一个重要职责就是在项目之初将项目范围定下来，这个范围的划分非常依赖经验：划得少了团队得天天加班，累得跟狗一样，然后才能保证交付（据我 的经验，虽然项目一般不会天天加班，但是总会有一些攻关，打补丁的事儿，最后还是会累成狗），划得多了客户不买单，意思是就这个小功能你要做两个月，绝对 不行。PM需要协调这些不一致，还需要和销售，客户等方面不断谈判，写方案，排计划，简而言之，也是累跟狗一样（而且潜在的，还可能被那些天真幼稚的开发 坑 — 开发经常会高估自己的开发速度，反正我还没遇到过低估的，你见过吗？）。

我们每天看到的PM干的最多的事情就是：元芳，那个接口怎么样了？什么时候能做完，有什么blocker？李柯，昨天说的代理的事情怎么样了？小波，高保真什么时候出？何方，我们周三下午要showcase，麻烦你订一下会议室吧……

除了写代码，Dev平时还干点啥？

如果脱离开PM的角度，做为一个孤傲的开发，时常会觉得PM为什么老是问我进度，是不是怀疑我的能力？为什么监视我的工作？相信我，其实他才不想监 视你。但是你设想一下：如果你不参与代码编写，每天只是看旁边的哥们写，你如何知道他实际的进度呢？而且众所周知，开发很难准确的更新自己的工作进度，而 且遇到问题也很少积极主动的报告，通常都会自己埋头尝试解决。那么，轮询显然是一种成本最低，反馈最快的方法。

不主动更新进度是另外一个大问题，不过这个得单独说。关于更新进度，典型的的场景是：早上站会的时候，开发目光呆滞的盯着某个卡片，努力回忆其中的 验收条件以及自己的当前进度，如果恰好脑海中的技术细节和卡片的描述在某个点上匹配了，他会迅速的告诉你，目前进展良好，今天上午应该就可以做完。开发在 更新进度时，不是盲目乐观，就是跳进太细节的地方进行讨论，最后讨论的结果就是：跟没更新一样，除了浪费了10分钟时间。但是别忘了，PM会在15分钟之 后再来轮询一次。

PM每周都需要汇总很多数字，比如本迭代完成的点数，剩余的点数，总体进度如何，有没有人有请假计划，遇到什么blocker，每个blocker的具体原因，每个风险点的最终日期是何时，等等等等。他肯定不能记住这些数字，所以可能一天之内向你询问数次。

PM的其他职责/技能

上边说到的其实只是描述PM的辛苦，而最微妙，最考验PM的是其“察言观色”的技能。这绝对是一个工作经验在10年之内完全无法获得的技能（而且是 在中国的项目上工作10年）。比如，在showcase的时候，有个客户说，嗯，挺好，整个流程就是这样的，后续你们的UI是不是还会美化？如果你遇到这 个情况，请问，这个客户是什么意思？

如果你能回答上这个问题（而不是提出问题），那说明你还离PM差十万八千里。成熟的PM会先判断，问这个问题的人是什么角色，以及他在系统中的话语权如何，还有其他人就此问题的反应如何等等因素，然后找到一个合适的答案。

PM另一个绝技是扯皮（不是贬义），开发会花一个下午（我是说10分钟）去跟客户讨论需求的范围吗？或者会为5个人天来讨价还价吗？我想开发大概会说，尼玛，找其他供应商吧，老子不伺候了。

一个项目的成功，需要多方合作，这里说的合作并不局限在甲方和乙方之间，即使乙方的团队之中，也需要很紧密的合作。比如项目经理和开发，设计师之间 的合作。如果仅仅从开发的角度来看，PM有时候看起来就是和客户站在一起来整开发的一样，比如催进度，过分保守的估算人天（导致团队加班赶工）。PM需要 释放团队中的负面情绪，保证团队士气，还需要他做一些开发不屑于做的琐碎的事情。

设身处地，提他人着想

本质来来说，每个项目都是一次生意。在去掉那些繁杂的流程和形式之后，做一个项目和你去菜市场买菜其实并无二致。举个例子，根据传统，软件开发界特 别喜欢找建筑行业做类比，我也找个建筑方面例子。装修房子的时候，我们会要求施工方提供图纸（水电改造，基本设计等），按期交付（确定工期），同时会界定 项目范围（比如刷墙，贴地砖，吊顶，封阳台等等），会要求工人按时来上班，正常出勤，认真工作，直到项目结束。过程中我们还会讨价还价，比如捎带着把栏杆 拆除，捎带着敲掉一面隔离墙等等。在过程中，我们还会敲敲地砖，检查过门石，检查吊顶，测试水电等等。作为甲方，这些活动相信没有人会觉得过分。

但是一旦我们做乙方，也就是施工方的时候，情况就全变了。比如客户要求打卡，有人会觉得不爽，客户要求代码review，有人会觉得不爽，要求代码 有设计文档，有人会觉得不爽，要求设计有多个备选方案，有人会觉得不爽。大多数情况下，这都是虚无缥缈的虚荣在作祟，这种情况所在多有，不过还不致命。一 旦涉及到讨价还价（不是商务上的讨价还价，而是和客户就工作量达不成一致，或者就某个技术方案达不成一致之后），开发全部歇菜，一言不合，转身就走，压根 不具备讨价换件的能力，这样还怎么做生意啊？设身处地想一下，如果你是甲方，当提出了一些合理的要求（比如需要一方提供验收标准，通过验收测试等），结果 施工方还一脸的“我不跟你说了，你就是以大傻B”，你能乐意吗？

如何合作？

说了这么多，这两种角色在同一个项目上要如何合作呢？我想，作为开发来说，有这样几点可能：

首先，理解PM的工作。在很多时候，开发会有莫名其妙的优越感（其实每个角色都会有了，比如销售看不上技术人员，技术Lead看不上PM等等），主要原因其实是坐井观天，对其他角色的辛苦和工作不清楚。然后错误的认为别人的工作都很low。

之前听一个同事讲过一个小session，里面有一点我印象非常深刻：不要因为一个人不会某个技术而鄙视他。就好比你不应该因为不会弹钢琴，而被一个会弹钢琴的人鄙视一样。道理很简单，但是开发在长期的“宅”生涯或者坐井观天中，进化出了这种非理性的观点：如果一个人连vim（此处的vim可以换成任何其他技术）都不会，就压根不足以谈人生。

其次，学习如何报告进度。PM催你的根本原因是进度不明确，如果每一个潜在的风险都清楚的显示着进度，而且有明确的负责人，PM就会降低轮询的频率。这需要开发经过刻苦的练习才能达到：

• 站会前自己花3分钟整理一下昨天做的工作
• 根据story的验收条件（最好有和BA/QA一起的讨论需求），进行合理的任务划分（tasking技能）
• 可以借助便签纸等工具，帮助自己明确进度（划分了5个子任务，昨天完成了3个，那么可以粗略的估计为60%）

再次，合理估算。有些时候，新人（来自于传统管理环境的新人）可能会误以为PM是一个管理的角色，或者处于某些考虑会在PM询问进度时做出一些错误 的回答。比如PM在迭代启动会议上是问这个迭代我们有没有可能做完所有计划内的任务，作为一个负责任的开发，你需要在第一时间指出那些“非理性”的期望， 以便PM进行更加准确的计划。

• 明确告诉PM，有哪些需求是不可能按时交付的，PM会根据实际情况来重新定计划，并和客户确认
• 明确告诉PM一些可能的风险，团队整体对交付负责，而不是PM，或者开发

按照经验，项目从来就不会按照计划进行，在做好一个粗略的计划之后，PM的职责更多的是进行动态调整。所以团队内部至少需要保持信息的流通，虽然可能短期来看可能会影响开发速度，但是从整体上来看，可以减少很多不必要的浪费。

简而言之，要站在别人的角度考虑问题：如果换做是你，你会怎么做？