PMP有哪些知识点可以迁移到产品领域
最近完成了PMP的学习和考试，三个月的学习和连续四个小时的考试，回想起来真是欲仙欲死。项目管理和产品领域的关联度很大，知识点多多少少有重叠的领域，就连它们的缩写都是PM。
那么在PMP的知识点里，有哪些值得我们（产品汪）学习实践呢？
首先，简单介绍下啥是PMP。
PMP指的是项目管理专业人士资格认证。它是由美国项目管理协会（Project Management Institute(简称PMI)）发起的，严格评估项目管理人员知识技能是否具有高品质的资格认证考试。
PMP包括五大过程组、十大知识领域和49个过程。
01 商业论证和制定项目章程
PMP启动项目的第一步，不管项目多大、多紧急，永远都是商业论证和制定项目章程。
商业论证简单来说，就是分析项目在经济利益上是否有利可图。方便高层判断是否要做这个事。商业论证其实有点类似于产品领域的BRD文档（商业需求文档），目的都是判断公司干这个事情，是不是有利可图。
换一个文艺点的说法：商业论证的结论是项目或产品的初心。
商业论证可行后，下一步制定项目章程。项目章程是项目的纲领性文件，其中明确描述了项目和公司战略之间的关系，确立项目的正式地位，同时描述了项目的目标、高层级的需求、期望和风险。
项目章程也是后续项目经理行使权力、进行项目管理的依据，可以说是项目经理的尚方宝剑。商业论证和项目章程在产品领域比较少见，很多都是老板说干就直接干了，很多人可能还会觉得这两个东西是浪费时间。
但是，商业论证和项目章程对于产品来说也是很有借鉴意义的，因为可以让我们从战略大局的角度来认识这个产品，这有助于我们后期不跑偏。
特别是当我们陷入迷茫的时候，商业论证可以坚定我们的信心，而项目章程可以为我们指引方向。
我们不必非要有这两份文件，但是商业论证和项目章程的全局思维方式，是我们必不可少的。
02 启动大会与需求评审
PMP在项目启动时，有一个有意思的会议，英文叫kick-off meeting，中文叫法很多，有的叫开踢会议、有的叫启动大会。
启动大会的目的，主要是召集项目团队成员以及各个相关方，传达项目背景和目标等信息，澄清项目相关问题，与团队和相关方就项目目标、项目计划等达成共识，为团队灌输信心，并获得相关方的承诺。
在产品工作中，启动大会比较少见，不过有点类似于我们的需求评审会。很多同学在需求评审的时候，多数都只是关注于如何将需求传达给开发同学，但这其实只是需求评审会的一部分。
一开始就陷入细节的需求评审会很容易被喷得体无完肤，我们其实可以参考PMP启动大会的目标。传达本次版本迭代的背景和目标，目的是告诉开发同学，这次迭代为什么要做？做了以后能带来什么价值？
另外，当团队开始关注目标以后，有时候集思广益可以给你带来意想不到的惊喜。澄清功能需求的相关问题，这一点是大家关注最多的，不用多说。
就本次迭代的目标、迭代计划等信息达成共识。达成共识才能劲往一处使，一个人心甘情愿才能最大限度发挥主动性。
03 识别风险
产品经理在工作中，最头疼的问题，就是项目延期。项目延期的原因有很多，但是比较常见的有两个：不断的需求变更或发生了风险。
PMP是如何解决风险问题的呢？
首先，PMP将风险分为三类：
- 已知-已知风险：发生概率已知，造成的影响和后果已知，例如人员不够；
- 已知-未知风险：发生概率未知，造成的影响已知或发生概率已知，造成的影响未知。例如有核心团队成员离职的风险；
- 未知-未知风险：发生的概率和造成的影响都未知，例如突然的政策变化或者新政策发布。
前两个风险都是可以也必须是要提前识别的，识别风险的常用方法有：
- 经验教训知识库：参考类似项目遇到的一些风险；
- 头脑风暴：组织团队成员脑暴可能遇到的风险；
- 专家判断：请有经验的专家分析可能存在的风险；
- SWOT分析或PERT分析：针对大方向的风险识别。
第三种风险因为是未知的，没办法做到提前识别，所以需要未雨绸缪，预留一点的资源专门用来处理这些未知-未知风险。
值得一提的是，在PMP中未知-未知风险的预留资源成为管理储备，是不计算在项目预算里的。风险识别成功以后，需要对风险进行定性和定量分析，然后制定相应的风险应对措施。
风险应对措施一般有5种：
- 风险规避：指的是有风险就不去碰它，绕道走，最极端的风险规避措施就是关闭整个项目；
- 风险转移：指的是将风险转嫁给它人，例如买保险，外包有风险的部分给第三方等；
- 风险减轻：指的是采取措施减轻风险发生的概率或减轻风险发生后造成的影响，例如加强测试，找更靠谱的供应商等；
- 风险接受：指的是碰运气，只留了应对的资源，不采取任何其他措施；
- 风险上报：指的是超出项目经理范围内的风险需要上报，例如国家政策发布。
制定完成风险应对措施后，最后需要将风险的详细信息记录在风险登记册中，并且需要定期对风险进行审查，剔除已发生/已过期的风险，新增新识别的风险。
通过事先识别风险，事中监控风险，事后总结三步，可以有效的降低风险发生的概率以及风险发生后造成的影响。
04 如何评估工时
产品经理常常因为不能准确评估工时而被开发忽悠，被老板嫌弃。如何能有效评估工时呢？PMP提供了几个方法：
1. 类比估算
适用于成熟的常见的项目，通过和类似的项目进行比较，就可以大致评估出工时。比如对于类似登录模块搭建这样常见的通用功能，就可以参考以往的经验。
2. 三点估算
三点估算是一种自下而上的估算方法，使用三点估算的前提是已经完成了对整个项目需求的细化拆解。
三点估算的三点指的是，最可能时间、最乐观时间、最悲观时间，也就是说，针对一个特定的任务，你需要问程序猿小哥三个问题：
产品汪：完成这个功能，你最可能需要多久？
——程序猿小哥：5天吧。
产品汪：那最乐观时间呢？
——程序猿小哥：3天。
产品汪：那最悲观时间呢？
——程序猿小哥：最悲观的话，那我要考虑所有悲观因素，13天吧。
得到三点时间以后，通过三点估算的公式，你就能得出这个程序猿小哥完成整个功能的期望时间：三点估算公式：μ =（最乐观时间+4*最可能时间+最悲观时间）/6。
上面的例子，使用该公式可以得出，程序猿小哥完成这个功能的期望时间是6天。
3. 参数估算
参数估算有点类似现在的机器学习，都是利用历史数据和项目参数，使用某种算法来计算项目所需要的时间。
例如，将项目的功能点数*每个功能点的平均工时，参数估算的准确度取决于参数模型的成熟度和基础历史数据的准确性。
虽然在产品工作中一般都是研发同学估算所需工时，但是产品经理如果对工时有一套自己的估算方法，就不容易被忽悠，而且在对工时提出异议时，也能有理有据。
05 如何控制需求变更
产品工作中不可避免的问题之一就是需求变更。
需求变更和Bug一样是我们想避免但是却避免不了的，需求变更控制不好很可能会影响项目工期。而且频繁的项目变更，会打击团队的士气，同时也会影响产品经理和程序猿同学的关系，不利于建立信任关系。
并且，频繁的需求变更会带来另外一个问题：变着变着就忘记最后的结论是啥了！
因为频繁变更，有时候忙起来就会忘记更新需求文档，到最后验收的时候，产品自己都忘了最后的结论是啥，就容易造成扯皮，大家各执一词。
如果你倒霉一点，很可能还会遇到一个尴尬的事，老板经常会问这样的问题：“这个地方为啥是这么设计的，我记得当时不是这么说的啊？”
这个时候，如果你当时没有记录的话，就会一脸懵逼……飞天大锅稳稳的扛在了身上。PMP中对于需求变更的控制非常严格，有一套完整的变更流程：
项目经理对于不影响基准，包括时间基准、成本基准，的变更可以自己做决定，但是一旦涉及到基准的变更，就需要提交给变更控制委员会进行批准。
变更控制委员会的人员是由项目的各个关键相关方组成的，有高层领导、项目经理、研发负责人、客户代表等多个利益方组成。
所以经过他们审批批准的需求变更，大家都是知情和认可的。这样的流程能极大程度控制变更的数量，也能保证变更的质量，同时能起到及时知会各方的作用。
变更关键的一点是，不管变更有没有被批准，都需要记录到变更日志，亲身经历的血泪史证明，这真的是个好习惯！！
变更日志内容至少要包括以下四项：
- 当时发生的问题
- 提交的变更和提交人
- 需要变更的原因
- 变更被批准或被驳回的原因
这些内容方便对变更进行追溯，也可以在下次遇到类似问题的时候照搬作业，还是后面总结经验教训的素材，可以沉淀为组织资产，一箭三雕~
06 如何进行沟通
项目经理和产品经理，有一个最大的共同之处：很多时候都需要沟通，不是在开会，就是在开会的路上。
PMP总结了导致沟通不畅的九大原因：
我们在日常沟通的时候要注意规避这些不利的因素，在沟通时要注意简洁清晰，详略得当。
什么时候应该详细，什么时候要简洁，我们可以参考下桥哈里窗格：
桥哈里窗格分为四个象限：
1. 你知道，我知道：开放区
处于这个区域，说明是一些共同常识，这部分的沟通可以尽量简洁，比如生活常识，通用公理，行业通用术语这种。
2. 你知道，我不知道：盲目区
这是属于我的知识盲区，这种情况下，你就要尽量详细的给我描述背景，传递我理解这件事所需要的背景或者知识。
认知理论上有一个现象专门对这个进行了描述：知识的诅咒，对于我们知道的东西，往往认为这很简单，对方也肯定知道。但你要知道隔行如隔山。
3. 你不知道，我知道：隐秘区
这是我的秘密，属于我个人独有的知识。适当开放自己的隐秘区，可以增进彼此的关系。
36个问题帮助你找到女朋友，这36个问题本质上就是逐步开放彼此的隐秘区。这也是为什么乐于分享的人，人缘都比较好。
4. 你不知道，我也不知道：未知区
未知区是机会，需要我们共同探索的知识领域。
07 如何管理相关方
你有没有遇到过这样的情况：
“需求明明已经和老板对过了，然后我也已经在拼命推动开发。但是在验收收尾的时候，某业务副总说这个不行，然后要重新来；开发那边责怪我没有事先对清楚需求，导致现在面临加班通宵的局面，但是我也很冤啊。”
还有这种：
“这个需求你跟谁对的，我怎么不知道？”
“我们当时不是这么说的啊，以后这种涉及我的跟我对一下。”
“后端改了有通知到前端吗？我们前端不知道啊，而且测试也没有测出来……”
历史总是惊人的相似，工作中这样的事情经常发生。这可能是因为，你没有做好相关方的管理。
需求你只和领导对了，但是却没有通知到潜在的相关方，导致需求不符合要求，重做；需求你自己写完了，认为天衣无缝，于是直接提给了开发，但是哪里知道根本就是理解错了，重做。
相关方，简单来说就是跟你做这个项目或者需求有任意联系的人。比如说你负责的是某业务后台的搭建项目，那么相关的人就至少有：你的领导、该业务负责人、该业务核心人员（实际使用你后台干活的）、开发人员、测试人员、设计人员。
如何识别这些相关方呢？
可以从是否参与项目与所受影响两个维度来区分。
也可以按照相关方类型来区分：
比如：上游供应商、下游客户、中间有老板、领导、开发团队、测试团队、设计团队、运营团队、业务团队等。
将相关方识别出来之后，那么哪些相关方是需要我们重点关注，哪些相关方是无关紧要的呢？
毕竟我们的精力是有限，必须把我们80%的精力用在关键的20%的人身上，才能保证效率最大化。否则面面俱到只会把自己累死，吃力且不讨好。
08 项目收尾经验教训
复盘很重要！复盘很重要！复盘很重要！
重要的事说三遍~复盘对公司和个人来说，是一个双赢的事。
对于公司来说，复盘沉淀下来的经验教训是公司宝贵的组织资产，可以提高团队的能力，可以为以后类似的项目提供参考，可以尽快让新人成长起来等等。
对于个人来说，复盘才能带来最大的提升。项目的结束不是真正的结束，复盘沉淀以后才是真正的结束，从项目中汲取沉淀经验，才能提高自己的能力。
复盘在网上有很多模板，重要不是要找一个完美的模板，而是要动起来，要真正地开始复盘。
简单介绍一个我使用的复盘方法：
以上就是我总结的PMP中可以迁移到产品工作中的一些方法，欢迎大家一起交流~
如果有想考PMP的同学，也可以交流下经验哈~
作者：Jarvan；公众号：产品叨比叨
本文作者 @Jarvan
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
