如何用墨菲定律来管理项目风险？

编辑导语：产品经理在管理每一个项目时，都是有很大的风险存在的，那么应该如何规避和化解这些风险呢？本文作者另辟蹊径，用墨菲定律来进行项目的风险管理。并且结合相关案例，为我们做了细致的分析，希望看完后能够对你有所帮助。

前一段时间，在总结风险管理的时候发现“风险”这个东西很空，很难总结。

尝试了用文字去归纳“风险”，发现风险出现的形式、频率、概率都跟每个项目相关，无法归纳成通用的概念。

又尝试了用案例去总结分析，发现案例终归只能是案例，它不会完整地出现第二次，即便第二次出现，形势和内容也一定会发生或多或少的变化。

后来我明白了，项目中一定有人参与，有人参与的话“人”就是其中最大的风险变量，这让我的总结归纳陷入了僵局。

直到最近读书的时候，偶然翻到了《墨菲定律》这本书，看完其中的内容后我豁然开朗。《墨菲定律》不就是对人一生的风险总结结果吗？为什么我不能尝试用墨菲定律来研究总结风险管理呢！

仔细琢磨后还真有所突破，下面我们先来总结一部分：

一、只要某个部分可能出问题，那么最后它一定会出错

在项目开始初期，产品经理或者项目经理们都会梳理整个产品或者项目的总体流程以及关键节点，这个时候我们经常会突然灵光一现，发现这边有个小问题，这个小问题在项目后期可能会产出有一定影响的BUG。

很多时候我们“依据经验”的觉得：“这点小问题以小张的代码能力一定不会出错的”、“老李做架构这么久了不可能连这点小问题都看不到”等等。

但是偏偏他们就会出错，他们就是看不到！

Tips1：

在进行项目管理时，所有梳理出来的无论大小的问题都要记录，当做一定会出现的“风险”来跟团队成员沟通处理，哪怕他们会觉得你啰嗦。

二、出问题的部分一定是最重要且基础的部分

每个项目执行过程中都会有一些“关键路径”，也就是比较重要的部分——这些部分可能是电商产品的支付能力、OA产品的工作流引擎、IM产品的push通道等等。

它们很重要，但又很普通，普通到我们会认为这就是基础能力，甚至有时我们都不会注意到它们。

但是没错，一旦它们扮演了这种重要的角色，在项目执行过程的尾声，它们一定会出问题！

记得有一次我在做一个地产项目的电商产品，过程很顺利，产品功能策划、设计、沟通汇报都做的很完美，在研发的伙伴们进行开发时我甚至开始跟客户畅想功能上线之后每天过万流水的场景了。

但是在预估的研发完成时间前一天，研发老大给我打来的电话：“客户微信公众号的支付目录没有申请过，需要走流程申请，顺利的话大概会延期两个星期。”

我当场崩溃式发表：“支付目录这么基础的东西为什么现在才提出来，开发时没有人注意过吗？”

最终得到的所有反馈都是“这个能力太基础了，我们接触到的所有客户都具备这个能力，只有你的客户没有。”

Tips2：

前期项目梳理的时候，着重关注那些重要且基础的能力部分，无论是支付能力、服务器、数据库、工作流、存储还是其他，只要它重要且基础，就会出错！

三、每当感觉一切顺利，就更大的问题等着你

我本人是做项目管理的，服务过数十个企业客户，交付过N多产品和服务，几乎没有完完全全按照项目初期制定的项目计划完整执行下来的项目，并且绝大多数项目都或多或少的遇到了一些问题。

有一次在给某个大型股份制企业做一个百万级的项目，项目过半，一切都进行得非常顺利——流程一切顺利、BUG也都在客户察觉之前修复完毕、上线准备工作准备就绪、运营方案也已经跟对接人讨论妥当，都没有问题。

可是就在甲乙双方都认为这会是一次完美的项目交付时，一个大大的意外降临了。

在我开心地准备验收文档的某一天，客户突然给我打电话：“强仔啊，有个坏消息跟你说一下，我们总经理突然给咱们项目指派了一个顾问，小道消息是这个顾问想取代你们做这个项目，而且顾问跟总经理关系很好，你早做准备！”

随后而来的就是一系列的找茬式审核项目，收尾工作异常坎坷。

Tips3：

不要被表象迷惑，每个项目都会出现问题的，甚至完全不出问题才是最大的问题（因为一定会存在隐藏问题）。所以当项目进行的时候，如果你发现过程特别顺利，那么一定要从头检查，并且跟团队成员多沟通一下，是不是遗漏了什么。

四、进度报告越长，工作进展越小

在项目推进过程中，很多管理人员会要求团队成员定期写日报、周报等来给自己汇报工作。

如果您恰好也是接收日报、周报的人，那么您一定看到过这么两种报告：

一种是只有几行文字，内容为一些关键结果；

另一种是一些长篇大论，内容精彩、过程完善，让你感觉ta处理的实在是太漂亮了。

但仔细研究这两类报告就会发现：

第一种只有关键结果的，就真的是解决了很关键的问题，项目推进了不少；

但长篇大论的，往往没有解决什么问题，甚至还遗留了一些尾巴。