mirror of
https://github.com/cheetahlou/CategoryResourceRepost.git
synced 2025-10-07 10:36:40 +08:00
119 lines
12 KiB
Markdown
119 lines
12 KiB
Markdown
<audio id="audio" title="10 | 风险管理：如何系统化应对风险？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/fc/6c/fc1aced71262c57a342625d89fc47a6c.mp3"></audio>
|
||
|
||
你好，我是雷蓓蓓，今天我们来聊一聊风险管理。
|
||
|
||
其实，项目风险是一种不确定的事件或条件，一旦发生，就会对至少一个项目目标造成影响，比如范围、进度、成本、质量等，项目风险也可能对**组织或组织的目标**造成影响，比如财务、声誉等。
|
||
|
||
项目从构思的那一刻起，就存在着风险。而应对风险的方式，并不总是规避。如果风险给项目造成的威胁在可以承受的范围内，并且与可能得到的收获是相平衡的，那么这个风险就是可以接受的。
|
||
|
||
要想在充满不确定性的大环境下取得成功，组织应该致力于在整个项目期间，积极而又持续地开展风险管理。
|
||
|
||
## 系统化风险识别
|
||
|
||
**风险识别的主体，应该包含项目中的团队成员在内的各方干系人**，而不只是项目经理。组织中的每个层级，都必须有意识地积极识别，并有效管理风险。**系统化的风险识别，是一个反复进行的过程，应该从构思阶段开始，贯穿项目规划和执行的始终**。
|
||
|
||
结合执行中常见的各类风险，我给出了一份项目典型风险列表，你可以在[网盘](https://pan.baidu.com/s/1PsjWdNi2A-UwIrcLkMnycA)中获取，提取码是q45a。你可以对照这个风险清单，对你的项目情境下可能出现的风险，进行概率及影响程度的量化分析，从而形成你自己的初始风险清单。
|
||
|
||
识别风险过程的主要输出，就是初始的风险登记册，**包括已识别的风险清单，以及潜在应对措施清单。对于已识别的每个风险，都要评估其概率和影响，并进行优先排序**。
|
||
|
||
其中，风险概率是指每个具体风险发生的可能性，风险影响则是风险对于项目目标（进度、成本、范围、质量）的潜在影响。
|
||
|
||
<img src="https://static001.geekbang.org/resource/image/61/19/618f09c0f15d71f34fcaa51d356de119.jpg" alt="">
|
||
|
||
>
|
||
图片来源：《项目管理知识体系指南》
|
||
|
||
|
||
上图是《项目管理知识体系指南》中给出的，风险对项目目标影响程度的评估量表。其中，造成成本增加大于40%、进度拖延大于20%的风险，就属于最高影响程度级别的风险。
|
||
|
||
你可以通过访谈或会议的形式来进行风险概率和影响的评估，参与人员包括熟悉相应风险类别的人员，以及项目外部的经验丰富人员。以下是一个风险登记册的示例：
|
||
|
||
<img src="https://static001.geekbang.org/resource/image/04/14/04afc55480897f0fa5d1a1aa85e7d214.jpg" alt="">
|
||
|
||
## 冰山下的风险
|
||
|
||
实际上，执行中最大的风险，不是那些显而易见的、冰山上的风险，那些冰山下看不见的风险，往往才是最要命的。通常，项目组中最坏的情况是，大家对项目里的风险避而不谈，避谈风险的原因可能是：
|
||
|
||
- 缺乏风险的沟通渠道
|
||
- 提出来也没有用
|
||
- 老板会认为自己没能力管好当前的项目
|
||
|
||
试想一下，你的项目中鼓励坦诚沟通风险吗？你的项目中有恰当的程序和渠道，可以让你跟干系人沟通项目风险吗？
|
||
|
||
**没有人反馈风险，不代表没有风险**。我曾经见过一个项目组，在某个时间段，他们的业务迅猛扩张，临时招了一大批实习生，从事内容基础建设工作。日常工作时，管理者只是把任务交待下去，跟这些实习生缺乏深度沟通。由于业务繁忙，很少有人带这些实习生，于是，他们逐渐形成了一个与外界隔绝的小集体。直到一次重要里程碑交付前，大量实习生离职，影响到了部门重要KPI的达成，这个群体才引起了部门管理层的关注。
|
||
|
||
如果一个项目经理只能依靠正常的渠道识别项目风险，这类问题就不可避免。那么，如何识别冰山下的风险呢？
|
||
|
||
其实，当寻常的渠道不管用的时候，就要看项目经理的信息网络了。项目经理一定不能脱离团队。如果没有群众基础，只是坐等着别人给你上报风险，那你的工作就远远没有做到位。
|
||
|
||
一个优秀的项目经理，必须是一个优秀的“情报人员”，上至最高的项目发起人及组织的各层决策者，下至项目最边缘的人群，比如外包、实习生、短期借调支持人员等，你都要跟他们建立广泛且深入的联系。
|
||
|
||
你可能会问：“我不擅长人际交往，是不是就没办法做到这些呢？”当然不是。有很多内向型的项目经理，也做得非常好。其实，**你需要的是一颗真诚交流的心，去关注项目中的每个角色、每个成员的需求，理解他们的困难，愿意为他们提供发展的机会，帮助他们去获得更大的成功，仅此而已**。
|
||
|
||
如果说，你还需要一个简单有效的办法，**那你就先去观察一下，在吃饭的时候，你的团队分成了哪些群体**。这些自然划分的群体，哪些是你经常交流的？哪些是你缺少交流的？在工作之余，你要多关注和你缺少交流的群体，抽时间和他们多吃饭多沟通，让自己站在他们的视角想问题。这样一来，很快你就可以扩展自己对于冰山下项目风险的理解。
|
||
|
||
**记住，你识别出的风险越多，项目的风险就越低。**
|
||
|
||
## 风险应对措施
|
||
|
||
接下来，你需要为识别出的每个风险，制定相应的风险应对措施。**对于发生概率很高的严重风险，一定要提前准备风险应对方案和危机应急预案**。一旦风险和危机来临，应急预案就可以有效地降低风险的损失和危机带来的灾难。
|
||
|
||
比如“双十一”之前的故障演练应急预案，你就需要针对每一种可能发生的线上突发状况，提前确定好处理步骤、责任人、预计时长，甚至是每一步的指令或脚本，以免在出现突发问题时，手忙脚乱导致出错。
|
||
|
||
同时，**在项目排期时，你要确保有相应的故障演练计划，并且做好充分的准备**。也许有些风险预案永远也用不上，但是这并不是说它们是多余的。在风险降临的危机关头，它们的价值就会凸显出来。
|
||
|
||
在项目执行期间，已识别的风险会不断地变化，新的风险也会产生。你需要在每周的项目状态同步会议上，对风险进行再评估，并通过**周期性的风险审查，来识别新的风险**。
|
||
|
||
## 树立正确的风险观
|
||
|
||
###
|
||
|
||
**1.治未病，建立系统性保健机制**
|
||
|
||
举世瞩目的“阿波罗”登月计划，让项目管理开始风靡全球。当时的肯尼迪航天中心，流传着两个很有意思的“黑话”：沙包、打伞。“沙包”指的是把任务的延期藏起来，不到最后一刻不做汇报；“打伞”是说虽然你延期了，但还有更倒霉的家伙也延期了，而且率先被暴露了出来。你看，即便在“阿波罗”计划里，瞒报延迟、寄希望于他人“打伞”也是无法杜绝的事情。
|
||
|
||
可是，为什么会有那么多的瞒报呢？因为在当时，及时汇报延期往往只会招来一顿责骂。实际上，越是严格控制的系统，越是有问题都窝着藏着，很可能一出问题就是大问题。事物的发展，总是从量变开始的。为了防止风险演变成问题，就要在项目早期，建立系统性的保健机制。所谓的“治未病”，就是说要未病先防，**事后不如事中控制，事中不如事前控制。**
|
||
|
||
“春江水暖鸭先知”，关于执行中的风险，群众永远是最有发言权的。如果这个系统是健康的，一定是可以自行去呈现和反馈风险的。而建立系统性保障机制的关键就在于，**你要致力于持续改善人与人之间的互动品质，提升项目团队的健康度。**
|
||
|
||
经常做**匿名的问卷收集或访谈**，定期做一场坦诚布公的复盘会，都是系统性保健的好方法。
|
||
|
||
做调查问卷，是项目经理了解团队的重要方式之一。在每个重要版本结束时，你都可以用调查问卷的形式，收集大家的意见，其中有两个典型的问题：
|
||
|
||
- 对这个版本研发过程的综合评分（包括迭代方式、工作量、工作压力、团队配合、时间管理等各个方面），这反映了过程满意度；
|
||
- 对这个版本功能设计的满意度，即产品认可度。
|
||
|
||
**你要坚持在多个版本中反复使用，积累数据**。这样一来，你就可以通过各个版本的数据变化，看到团队状态的起伏和健康度的走势。当团队对产品的发展方向产生疑虑或不认可，抑或是对过程中的管理方式或协作状态不满的时候，你要允许团队各抒己见，充分沟通表达。事先预防永远胜过事后纠正，如果你有意识地在团队中构建这样的常规反馈渠道，系统性风险提示和保健的作用就会逐渐发挥出来。
|
||
|
||
上医治未病，如果你还不具备“望闻问切”的功力，那么匿名问卷，就是一个非常简单的措施，你一定可以做到。
|
||
|
||
###
|
||
|
||
**2.积极管理致命风险**
|
||
|
||
其实，项目经理不是只要管理好常规执行风险就可以了，真正会导致项目失败的致命风险，往往在项目一开始就埋下了。比如，公司高层对于项目的态度和预期、项目目标与组织战略目标的一致性、项目所依赖的重要资源方的合作关系、竞争对手及行业市场状况的变化、政策变化、监管风险等。
|
||
|
||
我作为项目经理的第一个项目，开工半年多就被紧急叫停，这让我对项目的致命风险有了深刻的体感。要管理好这些致命风险，确实不是仅凭项目经理一人之力就可以做到的。但是，如果我们只是一直做容易的事，做会做的事，对这些致命风险视而不见，就会把项目置于危险的境地。
|
||
|
||
一旦致命风险真的发生，很可能会回天乏力。有经验的项目经理，可以从过往经历的失败中，敏锐地嗅到危险的味道。那么，项目经理可以做些什么呢？
|
||
|
||
- 第1步：**挖掘出这些致命风险，把它们变为可见的、可谈的**。很多管理者非常关心执行中的风险，却对于这类致命风险讳莫如深，只留在自己脑子里，这样反而是最危险的。致命风险的挖掘，通常会让我们对项目背景的理解更加透彻，并对那些影响到项目生死存亡的关键要事，有更加清晰的认知和规划部署。
|
||
- 第2步：**正视风险，不存侥幸心理**。你要和发起人一起想办法，发动核心团队，合力去制定应对策略。
|
||
- 第3步：**在项目的核心团队中，周期性地梳理和同步风险状态**。
|
||
|
||
其实，在互联网领域，成功突围者大多都是一路坎坷，从各种致命风险中爬出来的，堪称九死一生。致命风险的存在，本身就是一种警醒。**加速构建核心能力，不断拓宽“护城河”，才是最根本的应对之道**。
|
||
|
||
## 总结
|
||
|
||
总结一下，今天，我给你介绍了系统化风险识别的方法，以及项目典型风险列表。根据风险概率和影响，你需要召集项目组成员完成风险登记册以及风险具体评估，制定相应的风险应对措施及应急预案，同时对冰山下的风险保持敏感。
|
||
|
||
实际上，风险是一种不确定的事件或条件，用辩证的眼光看，风险的另外一面就是“机”。互联网领域的产品创新，大多是一场跳进未知的冒险，这给传统的风险观带来了极大的冲击。在项目管理的过程中，步步为营的风险管理之外，积极把握不确定性带来的机会，提升系统的反脆弱能力，达到最优的效果，是项目经理需要持续修炼的功课。
|
||
|
||
## 畅所欲言
|
||
|
||
最后，我想请你来聊一聊，你自己所在的项目组中，是否存在冰山下的风险？你有哪些识别风险的好办法吗？
|
||
|
||
欢迎你畅所欲言，我在留言区等你，也欢迎你把文章分享给你的朋友。
|
||
|
||
|