产品经理学PMP，有必要吗？

商业论证和制定项目章程

PMP启动项目的第一步，不管项目多大、多紧急，永远都是商业论证和制定项目章程。

商业论证简单来说，就是分析项目在经济利益上是否有利可图。方便高层判断是否要做这个事。商业论证其实有点类似于产品领域的BRD文档（商业需求文档），目的都是判断公司干这个事情，是不是有利可图。

换一个文艺点的说法：商业论证的结论是项目或产品的初心。

商业论证可行后，下一步制定项目章程。项目章程是项目的纲领性文件，其中明确描述了项目和公司战略之间的关系，确立项目的正式地位，同时描述了项目的目标、高层级的需求、期望和风险。

项目章程也是后续项目经理行使权力、进行项目管理的依据，可以说是项目经理的尚方宝剑。商业论证和项目章程在产品领域比较少见，很多都是老板说干就直接干了，很多人可能还会觉得这两个东西是浪费时间。

但是，商业论证和项目章程对于产品来说也是很有借鉴意义的，因为可以让我们从战略大局的角度来认识这个产品，这有助于我们后期不跑偏。

特别是当我们陷入迷茫的时候，商业论证可以坚定我们的信心，而项目章程可以为我们指引方向。

我们不必非要有这两份文件，但是商业论证和项目章程的全局思维方式，是我们必不可少的。

02启动大会与需求评审

PMP在项目启动时，有一个有意思的会议，英文叫kick-off meeting，中文叫法很多，有的叫开踢会议、有的叫启动大会。

启动大会的目的，主要是召集项目团队成员以及各个相关方，传达项目背景和目标等信息，澄清项目相关问题，与团队和相关方就项目目标、项目计划等达成共识，为团队灌输信心，并获得相关方的承诺。

在产品工作中，启动大会比较少见，不过有点类似于我们的需求评审会。很多同学在需求评审的时候，多数都只是关注于如何将需求传达给开发同学，但这其实只是需求评审会的一部分。

一开始就陷入细节的需求评审会很容易被喷得体无完肤，我们其实可以参考PMP启动大会的目标。传达本次版本迭代的背景和目标，目的是告诉开发同学，这次迭代为什么要做？做了以后能带来什么价值？

另外，当团队开始关注目标以后，有时候集思广益可以给你带来意想不到的惊喜。澄清功能需求的相关问题，这一点是大家关注最多的，不用多说。

就本次迭代的目标、迭代计划等信息达成共识。达成共识才能劲往一处使，一个人心甘情愿才能最大限度发挥主动性。

 

03识别风险

产品经理在工作中，最头疼的问题，就是项目延期。项目延期的原因有很多，但是比较常见的有两个：不断的需求变更或发生了风险。

PMP是如何解决风险问题的呢？

首先，PMP将风险分为三类：

1. 已知-已知风险：发生概率已知，造成的影响和后果已知，例如人员不够；

2. 已知-未知风险：发生概率未知，造成的影响已知或发生概率已知，造成的影响未知。例如有核心团队成员离职的风险；

3. 未知-未知风险：发生的概率和造成的影响都未知，例如突然的政策变化或者新政策发布。

前两个风险都是可以也必须是要提前识别的，识别风险的常用方法有：

• 经验教训知识库：参考类似项目遇到的一些风险；

• 头脑风暴：组织团队成员脑暴可能遇到的风险；

• 专家判断：请有经验的专家分析可能存在的风险；

• SWOT分析或PERT分析：针对大方向的风险识别。

第三种风险因为是未知的，没办法做到提前识别，所以需要未雨绸缪，预留一点的资源专门用来处理这些未知-未知风险。

值得一提的是，在PMP中未知-未知风险的预留资源成为管理储备，是不计算在项目预算里的。风险识别成功以后，需要对风险进行定性和定量分析，然后制定相应的风险应对措施。

风险应对措施一般有5种：

1. 风险规避：指的是有风险就不去碰它，绕道走，最极端的风险规避措施就是关闭整个项目；

2. 风险转移：指的是将风险转嫁给他人，例如买保险，外包有风险的部分给第三方等；

3. 风险减轻：指的是采取措施减轻风险发生的概率或减轻风险发生后造成的影响，例如加强测试，找更靠谱的供应商等；

4. 风险接受：指的是碰运气，只留了应对的资源，不采取任何其他措施；

5. 风险上报：指的是超出项目经理范围内的风险需要上报，例如国家政策发布。

制定完成风险应对措施后，最后需要将风险的详细信息记录在风险登记册中，并且需要定期对风险进行审查，剔除已发生/已过期的风险，新增新识别的风险。

通过事先识别风险，事中监控风险，事后总结三步，可以有效的降低风险发生的概率以及风险发生后造成的影响。

04如何评估工时

产品经理常常因为不能准确评估工时而被开发忽悠，被老板嫌弃。如何能有效评估工时呢？PMP提供了几个方法：

1. 类比估算

适用于成熟的常见的项目，通过和类似的项目进行比较，就可以大致评估出工时。比如对于类似登录模块搭建这样常见的通用功能，就可以参考以往的经验。

2. 三点估算

三点估算是一种自下而上的估算方法，使用三点估算的前提是已经完成了对整个项目需求的细化拆解。

三点估算的三点指的是，最可能时间、最乐观时间、最悲观时间，也就是说，针对一个特定的任务，你需要问程序猿小哥三个问题：

产品汪：完成这个功能，你最可能需要多久？

——程序猿小哥：5天吧。

产品汪：那最乐观时间呢？

——程序猿小哥：3天。

产品汪：那最悲观时间呢？

——程序猿小哥：最悲观的话，那我要考虑所有悲观因素，13天吧。

得到三点时间以后，通过三点估算的公式，你就能得出这个程序猿小哥完成整个功能的期望时间：三点估算公式：μ =（最乐观时间+4*最可能时间+最悲观时间）/6。

上面的例子，使用该公式可以得出，程序猿小哥完成这个功能的期望时间是6天。

3. 参数估算

参数估算有点类似现在的机器学习，都是利用历史数据和项目参数，使用某种算法来计算项目所需要的时间。

例如，将项目的功能点数*每个功能点的平均工时，参数估算的准确度取决于参数模型的成熟度和基础历史数据的准确性。

虽然在产品工作中一般都是研发同学估算所需工时，但是产品经理如果对工时有一套自己的估算方法，就不容易被忽悠，而且在对工时提出异议时，也能有理有据。

05如何控制需求变更

产品工作中不可避免的问题之一就是需求变更。

需求变更和Bug一样是我们想避免但是却避免不了的，需求变更控制不好很可能会影响项目工期。而且频繁的项目变更，会打击团队的士气，同时也会影响产品经理和程序猿同学的关系，不利于建立信任关系。

并且，频繁的需求变更会带来另外一个问题：变着变着就忘记最后的结论是啥了！

因为频繁变更，有时候忙起来就会忘记更新需求文档，到最后验收的时候，产品自己都忘了最后的结论是啥，就容易造成扯皮，大家各执一词。

如果你倒霉一点，很可能还会遇到一个尴尬的事，老板经常会问这样的问题：“这个地方为啥是这么设计的，我记得当时不是这么说的啊？”

这个时候，如果你当时没有记录的话，就会一脸懵逼……飞天大锅稳稳的扛在了身上。PMP中对于需求变更的控制非常严格，有一套完整的变更流程：

 

项目经理对于不影响基准，包括时间基准、成本基准，的变更可以自己做决定，但是一旦涉及到基准的变更，就需要提交给变更控制委员会进行批准。

变更控制委员会的人员是由项目的各个关键相关方组成的，由高层领导、项目经理、研发负责人、客户代表等多个利益方组成。

所以经过他们审批批准的需求变更，大家都是知情和认可的。这样的流程能极大程度控制变更的数量，也能保证变更的质量，同时能起到及时知会各方的作用。

变更关键的一点是，不管变更有没有被批准，都需要记录到变更日志，亲身经历的血泪史证明，这真的是个好习惯！！