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

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

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

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

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

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

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

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

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

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

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

Tips1：

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

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

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

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

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

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

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

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

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

Tips2：

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

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

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

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

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

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

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

Tips3：

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

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

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

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

• 一种是只有几行文字，内容为一些关键结果；
• 另一种是一些长篇大论，内容精彩、过程完善，让你感觉ta处理的实在是太漂亮了。

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

• 第一种只有关键结果的，就真的是解决了很关键的问题，项目推进了不少；
• 但长篇大论的，往往没有解决什么问题，甚至还遗留了一些尾巴。

作为一个刚摆脱写报告没几年的项目经理，每每在查看团队人员的报告时，我的脑海中都能浮现出来他们的心理斗争：“我推进了这么多，还要写汇报，项目经理都看不到吗？真是的，把结果写完了就得了！”

“又是摸鱼的一天，啥都没干，怎么应付日报呢？把今天跟那个谁的聊天记录润色润色多写写吧，字数多了兴许项目经理就不看了。”

Tips4：

有时不要太相信自己的第一感受，认为报告内容越多工作量越大、进展越大，大多数结果都是相反的。

五、开大会常常是省下来几分钟，浪费了几小时

2017年，我们接了一个乡镇企业建立的大型地产园区的智慧化项目，当时这个园区的楼还没盖完，我们是和这个园区的弱电总包同时进场开工，负责弱电和我们智慧化项目的甲方是同一个人，我们都喜欢叫他老关。

年底，我们智慧化这边已经上线完毕，事情都做完了，弱电这边的项目却出现了很大的延期问题。

作为一个老派管理人员的典型代表，老关异常喜欢召开汇报大会，每周都会聚集弱电相关企业对接人加上我（由于我们跟某些企业要做数据对接，所以我也被迫要参加）一共30+人，在一个大型会议室里逐个汇报工作和难点，老关现场解决问题。

但是问题真的有被解决么？

答案当然是否定的。因为每个供应商出现的问题都有很合理的理由，合理到老关帮不上忙，但老关也急，所以每次供应商大会老关都会开成进度催促大会，占用大家一上午的时间然后散场。

会议的结果是什么呢？

也许老关不知道，每次会议散场之后，各个供应商之间交流得出的结果都是：还需要继续延期！也就是说，每周的这个进度汇报会完全没有任何作用。

互联网公司没有同样的问题么，当然有，而且还不少，各位自己体会。

Tips5：

大型会议是个浪费时间的好东西，很多重点问题也许不需要召开全员大会，找到几个关键负责人开一个小型站会，可能5分钟不到就解决了。

六、客户最需要的东西你现在一定没有

刚做项目经理的那两年，项目进行到验收阶段的时候，我们去跟客户沟通验收流程，总是会发现客户需要各种各样的验收材料，比如详设文档、数据库设计原理、产品原型及说明文档、相关证书等等。

这些材料也许往往都是我已经有了ABC，但客户那边一定要ABCD。

实际交付给客户的需求也同理，往往都是我们上线了ABC功能，客户一定要ABCDE功能。

Tips6：

在项目交付的任何时期，都要定期与客户沟通客户的期望以及需求，不管是功能方面、运营方面、验收方面还是什么，能想到就要沟通，否则就会出现遗漏性问题。

七、获得了意外的钱财，一定会带来相同金额的意外损失

其实这一点跟那句俗话很像，“贪小便宜吃大亏”，而且这里的“钱财”不一定就真的特指真金白银，有时候给项目进行“镀金”也是同理。

还是2017年，在年底为了推进一个国企项目的顺利验收，项目组决定将公司新推出的一个产品功能F赠送给客户，作为回报，客户将给我们的初次验收流程开绿灯。

但是意外发生了，在2018年初公司认为F功能比较累赘，且除了赠送的这个客户没有其他客户愿意购买，遂决定砍掉F功能不再更新维护。

2018年年中在推进这个过期客户进行终验的时候，客户表示F功能BUG较多且功能不完善，虽然是赠送的功能但也要保证质量交付，所以我们不得不再次协调了20多个研发工作日来去将这个功能完善，给公司内部造成了一定的损失。

Tips7：

给项目或产品镀金要慎重，小心贪小便宜吃大亏，接到意外的项目同理。

八、问题无法解决，就当它是一种特色吧

在每个项目上，我们都做不到尽善尽美，让客户对所有功能点都满意的情况不太可能出现。有些问题既然无法解决，不如就去拥抱它，并将它转化为自己的特色。

2018年在做一个地产公司合同管理的项目时，我们就遇到了这样的问题.由于我们设计的合同管理相关流程十分复杂，无法最终解决“小白可以上手即用”的问题，客户对此也提出了质疑。

后来经过内部数次流程梳理得出结论：无法解决。

随后我们调整了对客户的应答方向，将原本的“功能十分好用”改为了“我们将提供完善的售后服务”，功能上线后派出专人对客户进行培训，并且现场指导一周，将所有人教会。

结果也很不错，客户对功能不是特别满意，但是对我们的售后服务赞不绝口。

Tips8：

没人能预判出所有风险，没人能解决完所有的问题，但遇到了就要去面对它，说不定有可能将风险转化为商机呢。

风险管理相关绝不止于这么一点点，墨菲定律在项目管理的应用场景也绝不止于软件交付项目，感觉展开的话内容可以写完一本10万字的书，今天就先到这，各位同僚共勉。

本文作者 @李强~

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！