PMP对标的证书对象是项目经理，但对于产品经理也有好处。作者围绕着PMP带给产品经理的一些启示，谈谈如何做好产品之外，以推进项目进程的事，一起来看看吧。

提前1小时交卷，从考场走出来，一个小里程碑算是达成了。虽然PMP考试结果还要一个月之后出来，拿证应该是很稳的。

一、为什么要考PMP？

我本是个不屑于考证的人，80%的PMP持证者并不具备很强的项目管理能力，感觉证书就是个裱金的东西，我还不如把那时间投入到一些产品实践中，还要投入几千块学费。

可我平时自己主要靠书本、网文、办公来巩固产品知识，这次就想换个方式自我提升，据说还有利于升职加薪，就报名了。培训费2000，考试费3900。

当时也纠结过到底是选NPDP（国际产品经理认证）还是PMP？考虑到大众认知、求职网站中，PMP的知名度高一点，最终选择了PMP。

后话：PMP有利于跳槽加薪需要打个问号，但肯定有利于简历筛选时脱颖而出。比如：一个简历上写着PMP的产品经理，人事在筛选简历时肯定会多看两眼。到了面试环节，面试官一般就会考察项目管理的经验，决定他去留的因素是求职者项目管理的经验，而不是项目管理的资质。

1. PMP概念

PMP（Project Management Professional）指的是项目管理专业人士资格认证。它是由美国项目管理协会（Project Management Institute(简称PMI)）发起的，严格评估项目管理人员知识技能是否具有高品质的资格认证考试。

说白了，考了这个证，就相当于你被国际机构认证为具有项目管理等资格啦！

PMP的证书对象是项目经理，此项目经理非互联网管研发的项目经理，此项目经理更接近于大企业的BU负责人、中小企业的副总、总经理。

传统的项目经理，拿着几百万的预算，管理着几十号人，在项目发起人的指示和授权下，制定项目目标，管理着项目运作的方方面面，监督项目运作的效果，确保项目在预算内、按时、保质保量上线，为企业带来效益。

敏捷的项目经理，是一个服务者，对敏捷研发有着深刻的理解。为研发团队、产品负责人、技术人员提供无微不至的支持。通过可视化图表追踪项目的进展，以交付价值为导向，确保项目的相应变化能力。

后话：那PMP对产品经理有什么好处呢？

1、首先产品经理要搞清楚：产品经理的未来是什么？常说产品经理是CEO的学前班，那么PMP里的概念、工具就非常值得借鉴。考取这个证，就是学习成功人士的项目管理经验。

2、PMP的知识点与市面上对产品经理的要求非常接近。比如范围管理中的收集需求、定义范围；比如进度管理中的排列活动顺序、制定进度计划；此外团队建设、成本评估、质量管理、风险意识、沟通意识等，都是一名优秀产品经理必不可少的能力。可以说，能做好项目管理的人，肯定能做好产品经理。

2. 管理的重要性

PMP教材的每个章节，第一小节都是规划管理，不是直接教具体事项该怎么做。比如项目范围管理章，第一节规划范围管理：

规划范围管理是为记录如何定义、确认和控制项目范围及产品范围，而创建范围管理计划的过程。本过程的主要作用是，在整个项目期间对如何管理范围提供指南和方向。

说白了，就是开始干活之前，先把目标、规矩、流程定好，形成一个范围/需求管理的计划。这样干活，才可以事半功倍。

举个例子：

小企业在不断发展中，业务扩大，人员激增，需求量爆炸，往往就会出现：

• 业务多样化，需求很多，且频繁变更
• 业务部门会争夺IT资源
• 沟通成本几何增加
• 时间被压缩，只做功能，没时间关注功能价值

如此，对产研团队就不能简简单单的做需求了，每天为“需求之外”的事情操碎了心，干起活来像无头苍蝇。这个时候，就需要项目经理出面：

• 建立需求管理制度，规范业务的流程制度
• 建立需求排期规则、优先级标准、变更流程
• 规定沟通机制，例如：会议流程/纪要、晨会、5W1H
• 建立需求上线追踪机制，设定产品成功标准

大家会发现，为了做好一个需求，我们往往要付出很多需求之外的努力，甚至需求成功的关键都在于需求之外。

后话：作为产品经理，要不断跳出自己的能力范围圈，为了产品的成功穷极手段。可见，管理意识必不可少。虽然产品经理没有实权，却可抓住各部门的共同目标，连接业务部门，撬动研发团队，实现间接管理资源。

3. 范围、进度、成本

PMP中有一个必考点：项目发生变动时，哪些情况可以在自己的权限内处理？哪些情况需要上报项目管理委员会？解体的关键是看项目的范围、进度、成本是否发生了变化。

如果三个其中任一个有变化，项目经理都要上报进行决策，除此之外，则可以由自己决定。

对于互联网产品来说：

• 范围意味着：产品服务的对象是谁？要实现什么样的目标？功能做大做小？MVP？
• 进度意味着：分几阶段完成产品？产品迭代要多快？什么时候上线？
• 成本意味着：有多少资金？研发团队/服务器大资源有多少？要不要加班？

这对产品经理来说非常有借鉴意义。

产品方案有多个举棋不定时，需求有疑问想要“打扰”上级时，都可以考虑范围、进度、成本3个维度，从而发挥个人的主观能动性。

业务部门做提需求，什么都要时，完全不考虑实现成本（范围太大），则可以通过进度、成本的影响，理性劝退。

研发同事出于写代码简单，要求改需求时，则可以告知范围被修改，会导致目标无法实现，理性沟通。

产品需求难有完美的实现方案，更多的产品需求都是结合公司面临的目标（范围）、市场机会（进度）、资源（成本）做出的当下的最合理的方案。

二、90%的时间用来沟通

优秀的项目经理每天会花90%的时间在沟通上。

产品经理作为各部门衔接的桥梁，应该花多少时间在沟通上呢？

我个人的亲身体会是：一天开到5个会，脑袋就开始昏昏沉沉，跟我说要罢工。现在回想做产品最轻松的日子，就是作为新人天天写文档的时候。

沟通是个体力兼脑力劳动，对人的精力消耗极大。如果碰到的是很难沟通的人，那简直是对内心的折磨。

现实是：这是不可避免的！而且，随着产品越做越大，要接触的人肯定会越来越多。

PMP专门有2章讲和沟通相关的管理：项目沟通管理、项目相关方管理。

沟通管理中包含规划沟通、管理沟通、监督沟通。

相关方管理中包含识别相关方、规划相关方参与、监督相关方参与、监督相关方参与。

结合起来，通俗来讲，总结为以下4点：

1. 项目启动阶段，识别相关方，相关方包括：领导、所有研发同事、所有业务同事、用户、合作企业、会影响项目的同行、会影响项目的机构/组织，以及其他有可能影响到项目的人/组织。比如：金融APP识别相关方时，除了将公司内的领导同事，公司外的用户，还要把金融监管机构、银行、网络平台、圈内KLA等列为相关方。
2. 项目规划阶段，对识别的相关方，制定沟通目标、沟通计划、沟通方式。
3. 项目执行阶段，对相关方侧重分类，进行管理，使用人际关系与团队技能，使相关方都能在项目运作期间对项目做出正向的反应。这里的人际关系与团队技能包括：冲突管理、谈判、情商、激励、团队建设等。
4. 项目监督阶段，光有沟通管理办法还不够，还要监督沟通的效果，毕竟不是所有关联方都会配合项目。假如现有沟通办法效果不佳，则要不断优化。

三、敏捷开发

敏捷是一个术语，描述软件开发方法，强调增量交付、团队协作、持续规划和持续学习。敏捷宣言概述了四个价值观：

• 个人和交互优先于流程和工具
• 工作软件优先于全面的文档
• 客户合作高于合同谈判
• 响应变化优先于遵循计划

敏捷脱胎于丰田汽车的精益生产思维，有多个分支理念，其中最知名和广为流传的是Scrum，以至于很多人认为“Scrum=敏捷”。关于Scrum框架的介绍尽在下图，详情建议大家自行去学习了，它的理念和框架对产品经理的工作启发可以说非常多。

在移动互联网时代，敏捷受到了中国创业公司的热力追捧。因为它可以在适应需求的快速变化，能快速交付产品，帮助公司抢占市场。可惜这点被很多一知半解的老板玩坏了，敏捷成了可以随意变更需求的说辞，成了研发加班常态的原因，成了产品经理不按规矩办事的借口。

如果所在的企业打着敏捷的旗号，实际却走在玩坏的道路上。那么，将研发模式推入正道，便是产研团队的第一重任。

结语

PMI机构成立至今已超过50年，其教材是一本厚厚的包罗万象的书，其理念已遍布全球各行各业，给企业、个人带来很多指导。我作为一名经验颇丰的产品经理，独立负责过项目的从0到1，学习考取PMP给了我很多启发，意识到为了产品成功，自己要做的、能做的还有很多，产品之内要细细打磨，而很多，在产品之外。

最后，引用一段上下级对话作为结尾：

下属：我对现况不满，我想要更大的权力，调动更多的资源，才能帮助公司做出更大的贡献。

上级：我要先看到你做出的贡献，才会评估是否给你更大的权力。