PM真的不是PM

上周写了一篇《PM意识2.0》，前同事老A留言给我说：“PM已死！”一句话勾起很多回忆啊~当年，我们在一家内资IT公司，我是质量总监，他是研发总监，带四五个PM。老A负责所有项目的计划和监控，还要接口所有项目的质量问题。整天加班、开会，根本停不下来。其实老A是很成熟的研发总监，他曾在外企管过横跨七、八个国家，三五百人的“小项目”，大场面见多了，所以会抱怨PM不是PM，研发总监也不是研发总监。

图片来自网络，版权归作者所有

去年我和一位美国主任评估师，共同参与了一家国内软件企业的CMMI评估。访谈时，PM陈述的工作内容，更像是一名开发工程师兼做任务管理的综合体。而IT总监的阐述，则更像是一位真正的PM。事后，我跟这位外国友人聊了一下，他说，从他目前的经验与获知的信息来看，中国的PM基本上都不是PM。

这话听着让人心里不是滋味。我也从那时起，开始着重观察和研究PM这个岗位。很遗憾，我没能证明外国友人是错的，反而加深了这个认识。

PM都在干嘛？为什么中国的PM不是PM？

答：陷在软件开发的冲刺（非Agile中的sprint）和抢救过程中，和无休止的会议与沟通中。一言以概之，PM就是在管P，甚至连P都管不了。这就是PM的真实写照，尴尬、悲哀！但PM自己不能无动于衷，更不能无能为力！PM的胜任，除了个人能力外，更重要的是发挥公司在生产经营过程中，赋予这个角色的作用。接下来，我会从软件开发工作的目标的角度，梳理出真正的PM，应该关注和管理哪些方面。

“软件开发，是将用户需求转化为有效软件解决方案的一系列活动”，是一个追求最终质量的过程。过程，包含两部分要素——“要做完的事”，及相关角色。“要做完的事”即工作，经过WBS（Work Breakdown Structure），会被分解成一系列任务。任务及其之间的关系，以及实现任务的方法，叫做程序（Procedure）。被设定来执行工作的角色，在工具和设备的帮助下，实现任务，最终支撑工作过程的完成。

凡奉信息版权所有

上图呈现了“交付质量——软件开发的工作目标”，与支撑目标实现的过程的三大要素：

1. 程序，实现任务的方法及任务的关联性

2. 角色，执行工作的角色及责任

3. 工具和设备，支撑工作完成的适当的工具和设备

现在的PM之所以不是真正的PM，是因为PM的着眼点，仅仅是关注程序——充其量是开发经理的角色。而真正的PM，为了保障项目的最终成功，应该站在更高的层面——过程的高度，将程序、角色和工具设备三个方面协调起来，并不断优化其效能，以实现交付高质量的最终目标。

图片来自网络，版权归作者所有

还有一点需要特别提出来的是，当我们在谈论过程时，在人这一方面，只谈到了角色（Role）而非个人（Individual）。角色被设定在过程中是死的，是理想化的；而个人是活的，在过程中的绩效表现，是不见得理想的。

比如，我们需要一个需求工程师的角色，他的责任是充分理解客户的需求，并将需求转化为设计与开发的有效输入。而实际担任这个角色的个人Jack，虽然职位上是需求工程师，但Jack并不胜任和喜欢这份工作。

作为PM，你的工作除了上面说的过程管理外，还包含将Jack变成（或替换成）具备充分知识、技能，以胜任角色要求，并且充满工作意愿和干劲的这样一个人。PM不是要承担HR的工作，实际上也不可能，而是要发挥自身的领导力，让既有团队充分发挥主观能动性，实现组织发展与个人发展的协同。

图片来自网络，版权归作者所有

如果给PM的核心能力设定一个标准的话。一个合格的项目经理，需要具备的关键核心能力包括：质量先导意识、领导能力，以及过程能力。质量先导意识决定了PM会在项目管理中如何改进过程、发挥领导作用；而过程改进能力和领导能力，又反过来支撑PM实现软件开发的终极目标，交付高质量的软件产品。

凡奉信息版权所有

接下来，我们将基于PM的核心能力架构深入探讨。