浅谈项目管理进阶

工作多年，从起初是开发妹纸一枚到现在的高级项目经理，虽然专职做PM是最近两年的事儿，但曾经大概也称得上是技术骨干，一个版本从头负责到尾，包括跨FT的合作、跟产品交互讨论需求、版本提测、跟进测试、发布上线，以及发布后的外网反馈、数据上报等等，对项目管理的方方面面也并不算陌生，大概也称得上是个有点儿经验的PM了。这里是想就这些经验跟大家分享下PM的成长历程。

曾经招聘PM的时候，基本上都问过这样一个问题：“PM既不写代码，又不提需求，更不是测试、设计，说白了，他不参与具体的实施工作，那么，你认为，作为一个PM，你的核心价值应该体现在哪里？“

“把人和事儿给理顺了”

“做项目管理说到底就是如何做好对人的管理”

…

其实，我觉得都没错，但总感觉有点儿太务虚，我结合自身的工作经历，谈谈我对项目管理工作的一些看法吧。以下是结合个人经验总结，整理的项目管理能力进阶的金字塔模型，下面分别简单分享下个人想法，不一定对，毕竟项目管理是个相对灵活的工作，没有唯一的答案，更没有对错之分，所谓因地制宜、因事制宜、因人而异。

一、      基础能力篇 —— 项目管理的“三围”

其实也就是大家常说的，把人和事儿给理顺了，尤其是对于由多个不同职能人员组建起来的项目团队来说，把人和事儿理顺，就变更更加重要。为什么呢？因为对于不同职能小组的人员来说，他不一定是完全focus在一个项目上的，比如，对于Android QQ音乐这个产品来说，它的发展是通过一个一个的版本推进下去的，每个版本都以项目的方式在运作，每个版本会涉及到产品、开发、设计、测试、运营等不同职能团队的成员参与，对于每一个职能团队的成员而言，他很可能并不是完全focus在一个项目中，比如音乐后台，他对接的是整个部门后台相关的业务，一个后台开跟进负责不同项目也是常有的事儿，此外，设计师、测试也一样，甚至是主导版本的客户端开发，也会因为多版本并行、外网问题处理、技术攻坚等原因，处理项目之外的事情。所以，需要把人和事儿给理顺了，每个人必须清晰明确自己在这个版本中负责哪些事情，当然，这也是最基本的要求了。说到这里，大家也只看到了“二围”：人和事，那第“三围”呢？既然是项目，那自然离不开时间的约束。说到这里，“三围”齐了：人、事儿和时间。

总结起来就一句话：什么人，什么时间，做什么事儿。听起来很简单，但实际做的好的话，需要cover到项目过程的方方面面。比如：

1.    何时收集版本需求，接口人是誰？

2.    何时评审需求，哪些人来参加评审？

3.    誰负责客户端开发，誰负责后台开发，誰又来负责h5页面开发，誰负责设计，何时联调，何时输出设计，何时提测？

4.    誰负责版本提测，何时提测？

5.    每个具体的开发任务誰来执行，是否需要方案评审，誰来参加评审，又是何时开始开发，何时完成开发？

6.    测试工作由誰来承担，如何分工，测试用例何时编写，何时完成功能测试，何时开始全量测试，又是誰负责专项测试，哪些功能需要专项测试？

7.    何时灰度发布，何时全量发布，誰负责打包，灰度问题誰来收集，又是誰来跟进解决？

8.    版本的推广计划又是怎样的？誰负责跟进安装包的上架，上架后的安装包验证又是誰来执行？

……

说白了，基础能力实际上也体现的是最基本的项目计划能力、信息流的管理能力，对项目各环节做到心中有数，不疏漏，就跟庖丁解牛一样，才有了游刃有余的基础。

二、      执行能力篇 —— 发现问题、清扫障碍

前面说到了项目的“三围”：人、事儿和时间，但是这“三围”能否按预期的目标发展下去，还是个未知数。就跟平日里大家说的减肥和健身的目标一样，我期望达到如何如何的效果，但最终的结果是否好坏还是个未知数，更何况，减肥健身是自己的事儿，这项目呢，是一堆人的事儿，更困难的是，这些具体的事儿，有一大半儿以上都还不是PM亲力亲为的，也就是前面我说的，PM既不写代码，也不提需求，又不做设计，更不是个称职的测试或者体验师，但还要让“三围”能够按预期的方向发展，这就是我要谈的PM进阶第二层：执行能力。执行能力的好坏实际上也就是体现在项目的实际结果和项目计划之间的差别。比如，是否在既定时间、既定预算的要求下，达成了项目的范围目标、质量目标。那如何缩小这一差距呢？我把这一能力归结为发现问题，再到解决问题的能力，清扫影响计划的障碍因素，让项目顺着预期的目标健康发展。其实，PM们平日里组织或者参与的晨会、项目例会等等，说白了，其实是用来发现问题的：工作为什么不能按时完成？是因为人力不够？视觉没到位？技术方案不统一？还是后台联调没有准备好？对于不可抗力因素所带来的影响，我们只能默默接受，在一定程度上缓解影响，除此之外，PM们应该发挥自己的组织协调能力尽最大努力去扫清这些障碍。

三、      综合能力篇 —— 风险管理、影响力建设

如果要在执行能力之上，再拔高一个层次，那就是这里说到的综合能力了。如果说前面的能力可以靠突击培养迅速形成，那综合能力就得靠经验、靠资历、靠个人建设以及长期积累下来的对业务的了解程度。这里简单说两个因素，一个是风险、一个是影响力。这两个因素也是体现PM价值的重要因素。

先说风险。在这一领域PM应该做的是，具备风险识别的能力，并且能够把对这些风险进行避免、消除，或者缓解的措施应用到项目管理的过程中。百科上说，风险就是损失的不确定性；这种不确定性即包括损失是否发生的不确定性，也包括发生时间的不确定性，以及损失程度的不确定性；一般跟利益相关联，表现在我们预期的结果（好的方向）与实际额结果的偏差。这一点上，跟执行能力有些类似，不同的是，前面的能力层次是以对待确定性结果为前提的，这里是以对待不确定性结果为前提的。在项目中，风险的发生最终可能表现在产品交付延期、质量不达标，以及可能因此导致的各种纠纷。比如，交付的产品质量不合格，客户不买账，甚至可能引发投诉；交付延期可能导致客户产品其他连带的经济损失等。在一般的互联网项目中，延期也是其中的重要风险之一，但我认为并不是最重要的风险，当然，也并不能因此而不重视项目延期，项目能够顺利有计划的完成，也是刺激团队正向发展的因素之一。在互联网项目中，我个乐意把凡事有可能对用户造成伤害的，或者对公司利益造成损害的事件定义为风险。其实伤害用户也间接等同于损害公司利益。

PM需要具备这样的识别风险，以及应对风险的能力，而且，我认为这也是PM的核心价值所在，同时，PM这个角色本身，也赋予了他能够相较于其他角色更好的承担该职责。怎么说呢？在一个由众多不同职能角色组成的项目团队来说，每个职能角色更专注的是自己所负责的领域，更乐意去解决自己所在领域的问题，至于项目，那不是“我”的事儿，即便是对于一个有心想做一个大公无私的好公民的人士来说，也经常因为同时需要兼顾的事情太多，而必须得有所舍弃。比如，在QQ音乐团队，后台同事几乎对接的是整个部门的业务，同时需要做很多事情，除了内部需要应付的各种诸如服务部署、高负载警告、低负载迁移等等，还有来自策划、运营以及其他任何可能角色提出的业务支撑需求，如此说来，在后台同学的严重，事儿比项目可能更实在些。对于驱动项目前进的主力军同学，也就是客户端开发同学来说，情况虽然稍微好点儿，但也不见得他们就是实打实的全职在为一个项目服务，他们很可能要对付突如其来的用户投诉，或者是解决某个棘手的技术问题。如果把每一个职能角色都看作是一个树木的话，那么PM们需要做的是，不光看到一颗一颗的树，更应把这些因项目集结在一起的树木，看成一片森林。说到底，对于PM来说，看树不是真的为了看树，而是为了看好这一片森林。也因为PM能够看到这片森林，所以，当把森林当作一个生态的时候，PM应该能及时发现，整个生态链是否健康，是否资源分配不合理，是否需要做疾病预防等等。具体到项目里，就风险问题，下面也列举个一二三来。比如：

1.    在需求阶段，PM应能识别到这一需求是否牵扯到其他平台，是否有新老版本的兼容问题，是否与其他的需求相关联，时间点是否受限，需求是否可能给用户带来困扰，对于存在争议或者风险的措施，是否应该加上后台开关等？

2.    在规划阶段，PM应该能够发现人力安排是否合理，孰重孰轻，核心需求的提测时间是否合理？

3.    在实施阶段，PM应该意识到，对于核心需求是否有必要做相关的技术评审，是否需要专项测试，测试人力的衔接是否恰当，涉及的数据监控上报是否完备，跟设备相关的问题，在测试期间是否有覆盖到足够的机型？

4.    在发布阶段，PM更应能关注到，和版本相关的其他环节是否准备就绪，测试结果如何，发布后的用户反馈如何，是否需要做其他的改善？

……

最后，我们再谈谈影响力建设。说笼统点儿，无非是两个方面：一是，结果是否是好的；二是，过程是否顺利。这两个方面都需要照顾到，不能只看结果忽略过程，更不能只看了过程不顾结果。说实在点儿：要能帮助到大家。这体现在，能否帮大家达成好的结果，能否帮大家解决项目中的问题。分析影响版本效率的因素有哪些？这些因素不止是开发环节、可能还是测试、或者某个具体的角色？并且还能解决这些问题，不管是通过流程，还是通过其他手段。不光如此，当我们谈影响力的时候，你需要顾及的是，你可能不只是个PM。比如，当大家讨论自动化测试的时候，你是否能根据经验提出一些建设性的意见？又比如，当CM发出用户反馈分析日报后，你是否能够结合版本的情况，提出改进意见，以帮助到项目团队？

说到这里，总算是快完结了，自感学识粗浅，也只体会到了这三层，我想PM这个岗位，因为有着“不确定性“才有着”无限的可能性“，也因此，还有更高更远的层次等待着我们去探索，去攀登，期待有更多同事的分享和感悟。