项目经理除了催进度还能做什么？

PM听说过一个关于 PM(Project Manager，项目经理)的经典讽刺是：PM 就是指望 9 个女人能在 1 个月生出 1 个小孩的二货。

在我是个程序员的时候，听到过很多前辈跟我吐槽：PM 就是一群啥都不知道又喜欢指手画脚的家伙。虽然在很多时候，动手做的人确实比背后指手画脚的人更有发言权，也不否认很多团队真实有这样的 PM 存在;但往往悲剧的是，动手做的人以为自己能够创造新世界，偏偏客户和 PM 要的却只是一堵能挡风的墙而已。

PM 不被重视反而被鄙视的团队可能存在这样一个理念：认为团队并不需要 PM 来管理，项目照样能够按时交付。

这种团队理念其实是相互矛盾的：团队人员多的时候，高度自治基本很难;团队人员少的时候，大部分场合下 PM 由 Leader 兼职，很难不被重视。如果指望团队成员的高度自治实现项目成功交付，不如让团队清楚的了解项目有随时失败的可能。因此，大部分人都会有个疑问：PM 除了催进度，还能做什么?

[[193755]]

除了催进度，PM 还能做什么?

PM 每天做的最多的事情就是：张三，昨天接口怎么样了?李四，功能联调过了吗?王五，咱们什么时候能出高保真……PM就是在不断的识别项目风险，然后跟进风险问题。

技术实现有难点是项目风险;开发资源不够或者资源项目分配不协调也是项目风险等等，这些风险都可能影响到项目无法按期交付。特别是在项目启动初期，PM 工作更难开展：

除了要识别项目风险以外，还需要快速了解项目的上下文(包括业务关系、人员关系、资源分布等)，快速的把资源合理的分配到项目中，完成项目信息同步并获得团队成员的认同和支持(包括那部分认为自己不需要被管理的成员)。然后，PM 需要一遍又一遍的去确认项目的风险和进度是不是在合理的计划范围内。

除了实现项目，团队成员还要做什么?

从一个开发程序员的角度来想，经常会反感 PM 问自己的进度，认为这是对自己开发能力的一种怀疑和监视。在这里，我可以很负责任的告诉你：PM 肯定不是为了监视你。出于项目进度更新机制的需要，如果开发不能准确、主动的更新自己的工作进度，那么被 PM 轮询追问开发进度可能是最有效的反馈项目进度的方法。

举个最直观的场景例子：

敏捷项目管理过程中，每天早上 10 分钟的站会要求汇报工作进度。如果卡片上的工作任务验收条件正好跟汇报者脑海里的细节匹配上了，可能会迅速的得到完成时间节点;对于不能及时验收的任务，汇报者的反馈有两个方向：乐观的估算验收时间节点;或者跳进技术难点讨论的深坑里。无论哪个方向，未验收的任务都会在下次轮询时被再次提起。

[[193756]]

PM 除了每天/周轮询项目进度，还需要根据轮询得到的结果出不同的数据报告。在完成报告的过程中，可能某个重要任务的进度已经被更新了，所以团队人员会因为某个重要并且紧急的问题被PM询问很多次。

PM 的项目管理必备技能

PM 不被重视的辛酸是其次，最考验 PM 的其实还是如何看清项目过程中的主要矛盾，规避项目中可能出现的坑，

我们把这项调和所有项目资源的技能称为扯皮。

比如，在给客户演示产品功能的时候，有客户提问：数据报表的展示效果后面是不是还会再丰富一点?这种情况下，PM 如何回答?

客户并没有明确要求增加需求，也没有提出需求变更，往往 PM 需要权衡提这个问题的人是什么角色?如果是增加需求，可能的风险点在哪里?如果是需求变更，会不会对当前项目的收尾有影响?还有其他人对这个问题的反应会如何?

成熟的 PM 会考虑一系列因素后，然后给出一个合适的答案，因为项目团队中没人比 PM 更适合花时间去跟客户讨论需求的范围了。

总结

其实，每份工作/或者每个角色天生都自带优越感，比如销售会看不上只会闷头开发的技术人员，技术 Leader 看不上只会指手画脚的 PM ，甚至在技术开发的世界里从程序语言、编辑器、平台、到{是写在 if 的同一行还是下一行，不同阵营的人都存在一条鄙视链。主要原因是对其他角色工作的不够了解，甚至错误的认为别人的工作都比自己 low，以上坐进观天的思维很容易进化成非理性的观点，不利于整个项目团队的合作。

如果换位试想一下，就好比你不应该因为不会弹钢琴，而被一个会弹钢琴的人鄙视一样，我们首先应该尝试去理解每个角色的工作，至于每个角色是做好还是做坏，那都是后话。

建议

在项目团队中，PM 如何更好的与项目团队协作的问题提出以下几点建议：

1. PM催进度的根本原因是进度不明确：如果每个任务有明确的负责人和有效的进度更新机制，PM 就会降低催进度的频率。比如：