PMP知识，有哪些值得运营人学习实践的？

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