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

一些背景故事

坊间流传着很多关于PM（Project Manager，项目经理）的笑话，在这些不无刻薄的笑话中，PM往往被描述成一个盲目应承客户，不了解实际情况而又喜欢指手画脚、专门坑开发的家伙。毋庸置疑，这些笑话当然出自那些“聪明的”开发（不过你得承认，这些笑话并非空穴来风）。

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

我记得在刚加入ThoughtWorks的时候，私底下经常听到这种论调：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的职责更多的是进行动态调整。所以团队内部至少需要保持信息的流通，虽然可能短期来看可能会影响开发速度，但是从整体上来看，可以减少很多不必要的浪费。

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