为什么做技术 PM 这么难？

什么样的PM（项目经理）是真正专业且优秀的？这是相对棘手的问题。因为PM们平时看上去更多的就是组织、沟通、协调，预定会议、组织聚餐、项目周报等杂活，但是这显然是片面的。

PM自己作为参与评审的其他角色，如何更深入、更客观的看待专业PM的能力及贡献呢？今天，我们邀请菜鸟资深技术专家伊郎，与大家分享他的观点。

项目管理是商业组织的常态，越是目标性强的组织越需要项目经理。从中高层管理者的角度来看，通过项目经理能打破部门墙，快速组织内部资源，是拿到管理者设定的阶段性结果最直接的方式。因为“项目”就是为交付一个独特的产品或服务所做的临时性努力。

每一个专业的PM都清楚，项目的目的就是为了“结束”。Kick Off一个项目的目的是为了Close这个项目，进入一个项目的目的是为了退出这个项目。所以PM一开始就是要深刻理解这个项目的目标，以及如何才算是完成了这个目标，以便“结束”和“退出”。这种以始为终的思考和做事方式，是组织在追求阶段性结果更要经常采用的手段。反过来讲，一些BU或部门在PM的任命机制和退出条件上在一开始就没有想清楚，以至于PM最终在述职的时候也无法说清楚到底为了什么结果负责？这更多是BU或部门负责人在目标指向性不足的体现。

让专业的人干专业的事情，PM对项目整体运作效率及结果起着最关键的作用。大量的调查及研究结果表明，大中型项目中有20%-30%的时间是用在了各种沟通中，在一些官僚化的组织，这个比例甚至达到了40%。这里所说的沟通，包括各种计划、评审、讨论、汇报以及总结等。每一个环节的“有效组织、识别风险、解决冲突、达成共识、鼓舞士气”无一不依赖于PM的专业能力。

PM的个人能力在项目的运作效率和最终取得的结果上至关重要。我看到很多技术面试官对PM的综述就是“沟通协同能力强”，希望能横向地跟自己以及周边的技术Leader做比较，PM们承担了很多主管本应该承担的职责。且PM们Leader的是一个虚拟团队，这个虚拟团队中还通常有各种不同风格的“老板”，这比主管们带领一个实体团队来实现一个项目目标要更难。

PM专业的表现背后需要很多专项能力的积累。我们看到的可能是“有效组织、识别风险、解决冲突、达成共识、鼓舞士气”等，这背后需要很多专项能力的积累。

如“识别风险”，如果是方案风险，那这背后需要很强的“技术、业务理解力”，甚至是浸淫某个行业之后的经验判断；如果是组织风险，那这背后是对“干系人识别及管理”或“工作分解结构”的深入分析能力；再如“达成共识”，这个不是简单地劝大家各退一步：你出价10HC，他要加20HC，最终在15HC达成共识。这样看似是“共识”，其实可能是“共输”。而真正“达成共识”的背后需要PM善于利用“First Thinking Principe”，懂得理解问题背后的问题，应用强悍的谈判能力去取得的“多赢”。相对于双11、618等项目，更难的是内部组织变革或者有争议的项目，后者更能体现PM们的专项能力积累。

PM模式也带来一些运作弊端需要管理层补位的。如在一些大公司，大型项目在成本意识上是比较淡薄的。这些项目因为大老板的重视，反而对PM在组织资源方面的能力要求低了。也正是因为这类项目没有单独的成本估算，PM们为了项目最终“成功”，能多找到资源就多投入。

再譬如，关于项目过程和结果的运营，有各种海报、各种邮件的项目未必是真的大项目和好项目。这里需要作为管理层有一个清楚的认识和适当的补位。另外不得不说，PM最终所做的事情和能力在很多时候讲出来的、写出来的，好像谁都能做。其实有很多具体过程中的胶着，很难抽象到两三千个字去表述。就像公司内部很多人（几乎任何岗位都有）自我调侃说“转行去做PD，不行就做HRG”。其实无论是PD还是HRG都是非常需要专业能力的。当前的转岗乱象正是对这个岗位的专业能力，识别、把控不足。

最后想对PM们说，PM是强专业，也是强需求，有的是大家认识不足，需要我们共同去发出声音。我们一起努力。

 往期推荐：

•    ……

技术琐话 

以分布式设计、架构、体系思想为基础，兼论研发相关的点点滴滴，不限于代码、质量体系和研发管理。