未雨绸缪话风险：识别和监控

我的一篇项目风险管理原创文章《未雨绸缪话风险》，于2020年1月2日在“京东零售技术”公众号上发表之后，得到了广大业界朋友们的广泛好评。风险管理是一个比较大的话题，很难通过一篇文章面面俱到、全面深入地讲解清楚。为此，笔者将通过这篇文章继续对风险管理的话题进行深入地探讨，作为《未雨绸缪话风险》续写。

关于风险和风险管理的基本概念、目标和范围等内容，可以查阅《未雨绸缪话风险》中的“认识风险和风险管理”部分，本文不再赘述。在《未雨绸缪话风险》中的“风险管理五个关键词”部分，如图1所示，概要介绍了风险管理的规划、识别、分析、应对和监控，并通过风险管理模板，将这些关键词前后串联、展示在一起。由于篇幅所限，当时没有对这五个关键词进行更深入探讨，笔者在这篇续写的文章里，将重点解析风险管理五个关键词中的“识别”和“监控”。

在《未雨绸缪话风险》中讲到：“风险识别，是确定可能影响项目预期结果的风险，并将它们记录下来。如果不把具体的风险识别出来，就没办法应对。识别风险的方法和工具有很多，可以从项目不同阶段、不同职能领域，通常采用静默头脑风暴法、访谈、德尔菲法和专家判断等方法来收集，并输出风险登记册。”风险识别的方法有很多种，本文将概要介绍常用的六种方法，并重点分析和讲解其中的两种方法，如图2所示。

任何风险识别的单一方法，都有其自身的局限性。由于篇幅有限，本文重点介绍如何采用“静默头脑风暴法”和“风险分解结构法”相互结合来有效识别风险，以下称为“1-2组合法”识别风险。

头脑风暴法是一种激发思维、改善群体决策的方法，虽然它是一种比较好的思想交流方式，但由于受到与会人员、个人表达和现场环境等因素的影响，就会容易让某些人屈服于现场的权威人士、意见领袖或者跟随大多数人的意见，从而让这些人的想法和观点受到限制，在这些人看来，头脑风暴除了吵得人心烦意乱之外，没有别的好处。因此，常规的头脑风暴法，并不代表所有人都能适应这种氛围。为了能让这些人有效参与到风险识别活动中，笔者推荐团队采用静默头脑风暴法。

简单地说，静默头脑风暴的常规做法是，每一轮用3分钟的时间，在便利贴纸上写下问题的解决方案，这一轮结束之后，每个人将自己写下的方案展示在一个公共区域，然后，大家针对方案的内容进行讨论、碰撞，进行的轮次参照大家讨论的结果来决定。静默头脑风暴最大的好处是，可以更好地挖掘每个人的真实想法，不被其他人的想法所禁锢和干扰，进而有效避免一些意见领袖（话霸）带着大家集体跑偏。

风险分解结构（RBS），是对潜在风险来源的一种层级展现，设计了风险识别框架结构，是对一个项目中所有可能涉及风险类型和子类型的层级分解，它组织并定义了项目风险的总范围，代表着已识别的风险范围说明书中所规定的工作。风险分解结构的设计，强调的是将风险划分成不同的部分（类型）时，必须保证划分后的各部分之间相互独立、所有部分完全穷尽，即所谓的无重复、无遗漏。全面的风险分解结构，有助于识别新风险或者归类已识别的风险，有助于帮团队考虑单个风险的全部可能来源，这与我们在做计划管理的时候，经常用到的工作分解结构（WBS）在理念上有很多相似之处。

拆解识别千百种，全面覆盖第一条。风险产生原因是多种多样的，根据组织或者团队需要，我们可以设计适用于所有项目的通用风险分解结构，也可以针对不同类型项目来设计、制作几种不同的风险分解结构框架，或者量身定制某团队专属的风险分解结构。一个相对通用的风险分解结构，如图3所示。

在图3中，采用风险分解结构法，展示了通用场景下的项目风险主要来源，列举了技术风险、管理风险、商业风险和外部风险等四大风险类型，可以将这层结构看作是第一层级的风险包。按此往下划分，是每种风险类型（风险包）中的子类型，以图3中管理风险类型为例，旗下列举的是在该风险类型中可能发生的风险子类型，包括但不限于组织管理、资源管理和沟通协作等，可以将这层结构看作是第二层级的风险项。按此再往下划分，是属于在第三层级中的每个风险项可能涉及的风险点。不是每个项目都必须划分到第三层级结构，可以视项目规范大小而定。

笔者以一个自己曾亲身经历过的“日本冲绳旅游项目”作为示例，介绍如何使用风险分解结构法来识别该项目可能的风险，如图4所示。

在图4中，采用风险分解结构，列举了“日本冲绳旅游项目”中可能遇到的风险包、风险项和风险点，分别对应图4中的第2行、第3行和第4行，实际可以穷举的风险项和风险点内容不只是这些。我们自己能控制的风险，更多地是内部风险，譬如，准备用多少人民币去兑换日币，在什么时间进行兑换的汇率最合适；在有限的资金和时间范围内，如何做好日程安排；在日本旅游期间的手机网络连接，如何保证通畅且不被多扣费等。对于大多数的外部风险，都不是我们自己能够控制的，譬如，在环境天气的风险项中，如果出现了刮台风、下暴雨等风险点，就会导致交通状况的风险项发生。为了预防这些风险发生，我们就需要做好与此相关的风险防御和应对工作。

通常来讲，很多走迭代交付的团队，在其迭代过程管理活动中，一般都没有专门的风险识别活动。风险的识别，往往是在团队的每日站会或者日常协作中，由团队成员将识别到的风险暴露出来，然后，再由项目经理将已识别的风险内容整理成风险邮件发给相关干系人。这种风险识别的方式，虽然也有效，但经常会让项目经理识别风险的时机落后于团队成员，有时候会比较被动，也比较滞后。为了充分发挥项目经理的核心价值，引领团队尽早尽快地识别风险，除了其他的风险识别活动之外，笔者建议在迭代管理过程中，增加一个简短有效的风险识别活动，可以放在团队迭代计划会的末尾时段进行。采用“1-2组合法”进行风险识别过程的示意图，如图5所示。

在图5中，概要描述了采用“1-2组合法”进行风险识别活动的输入、过程和输出。其中，迭代需求和迭代计划，作为风险识别过程的输入，经过一系列的处理过程，输出风险报告和风险，这里重点分析风险识别过程列中的四个步骤。这里是在迭代过程中集中进行的风险识别活动，要点如下：

开展时机：团队迭代计划会（临近结束）的末尾时段（也可以单独组会）

参与人员：团队全员参与

步骤1，静默头脑风暴：每个团队成员各自取不同颜色的告示贴纸，在团队约定每个风险类型（风险包）中，分别写上自己认为在本期迭代中，可能发生在每个风险类型（风险包）中的风险项或者风险点。

步骤2，各自轮流讲述：由项目经理引领团队成员，将各自写有风险项或者风险点的告示贴纸，分别贴在看板墙的指定区域，同时，每个人要向其他人概要描述自己在告示贴上记录的风险点。

步骤3，聚类并筛选风险点：当每个人轮流讲述完自己在告示贴上写的内容之后，项目经理引导大家对看板墙上的所有告示贴的内容进行聚类，也就是把在告示贴上写有相同或者相近内容的条目进行聚合、归类，这个步骤类似数学运算中的“合并同类项”。

步骤4，确认讨论应对举措：针对步骤4中确认的风险项或者风险点，进行集中讨论，并制定相关的应对举措。

其中，步骤1、步骤2、步骤3和步骤4的用时参考时间，分别是3分钟、5分钟（视团队的人数）、2分钟和8分钟。这样在每个迭代正式开始之前，用不到20分钟左右的时间，项目经理引领团队成员把本期迭代可能发生的风险，都提前识别出来，并做好应对方案，对于展示项目经理工作价值、提升团队交付的效率和效果，都是不无裨益的。

【案例分析】

某敏捷团队采用迭代交付模式，在每次迭代计划会之后，团队成员总是信心满满，而到迭代结束之后，却总是由于各种各样的原因而无法完成迭代计划，后来，团队成员经过不断地迭代回顾发现了最根本的原因，就在于对迭代过程风险的识别和应对工作做的不到位，于是，团队开始尝试着在每次迭代正式开始之前，进行一次集中的全员参与的风险识别活动。该团队采用“1-2组合法”来进行风险识别，并按照图5中的过程步骤执行，得出了风险识别的结果内容，如图6所示。

在图6中，团队在风险类型（风险包）上约定了时间、质量、资源和范围等四种类型。首先，在每个风险类型中，通过步骤1到步骤3的操作，识别出每种风险类型（风险包）可能涉及到的风险项，譬如，在风险类型“资源”中，测试物料工具，是否能遵照计划的约定做到按时提供，并且可用；外部接口人，首次沟通协作，彼此在配合程度上能否做到默契等。以此类推，得出其他风险类型中可能涉及到的风险项。

然后，筛选出两三个最有可能发生的风险项，继续拆分旗下的风险点（笔者建议：在落地执行层面，为了节约团队时间，只针对筛选出的那些最有可能发生的并且准备应对的风险项，来继续拆分风险点，而不用对每一个风险项都去拆分风险点。举例：假如风险项“测试物料工具的提供”发生的概率很大，那么，就对该项进行拆分，譬如，将该风险项拆分成：各角色的测试账号准备，卡、包、券和商品SKU分配，指定型号的测试手机准备等风险点）。最后，执行步骤4，针对某些特定的风险项和风险点，团队共同讨论确认应对举措，输出风险报告或者风险登记册。

 在输出风险报告或风险登记册之前，还需要对已识别的风险做优先级排序，也即通过它们的风险等级、风险概率、风险影响和风险曝光度等方面综合评定。关于如何使用风险优先级的评估工具，可以查阅《未雨绸缪话风险》中的“风险管理五个关键词”模板工具表的部分内容，本文不再赘述。这里将团队识别出来计划应对的风险点，作为记录在风险登记册的示例，如表1-1和表1-2所示，其中，表1-2是表1-1的延续。

在表1-1和表1-2中，主要以风险包“资源”中的风险项“测试物料工具的提供”作为示例，列举了该风险项中可能三个风险点。在电商项目中，当涉及到与团队之外的上下游部门协作的时候，这类风险发生的概率非常高，产生的影响也很大，而这类风险一旦发生，不仅会造成导致团队开发、测试工作停滞、需求延期，甚至还经常会影响整个APP客户端版本的延期集成和发布。这类风险，通常都发生在团队之外的上下游协作部门，一般的应对举措是：将识别的风险点都可视化出来，梳理出风险点可能涉及到的所有干系人，约定好彼此各方都共同确认沟通方式、协作规则和关键时间点，并以正式邮件的方式发给所有干系人，尤其是测试物料工具提供方的对接人及其领导，同时，项目经理每天按固定节奏来跟进各干系人的风险处理进展，并做好风险预警。

无论是一个项目，还是一批项目，在它们从启动、立项、规划、执行到上线发布的全生命周期中，项目信息在各阶段、各环节、各干系人之间的有效传递和及时同步，是确保项目成功的重要保障之一。统计数据表明，有很多风险产生和项目失败的根本原因，除了项目前期的风险识别工作不充分、不到位之外，就是由于项目信息未能在各阶段、各环节、各干系人（尤其是核心干系人）之间进行有效传递或者及时同步造成的。因为，想要做到这一点，确实很不容易。

以下内容是关于“项目信息有效传递和及时同步对项目风险影响”的描述，如图7所示，内容节选自我的著作《互联网项目管理实践精粹》（作者杜炎，电子工业出版社2018年3月出版发行，京东商城有售），欢迎指正。

为了避免由于项目信息传递失真、同步不及时等原因，而引发的项目风险、问题或者来自业务方升级投诉等事件的频繁发生，需要建立风险监控长效机制，充分发挥项目管理部作为公司“军机处”、“情报局”的作用，充分体现项目经理掌控项目信息、把控项目走势的优势。这里推荐构建两种机制来监控风险：每日风险简报的撰写和推送机制，风险案例管理库的建设运行机制。每日风险简报的撰写和推送机制，是将当前正在运行的一批项目，每天由各业务线（模块）项目经理识别并收集出各自负责项目的风险，按照每日风险简报模板来撰写登记风险，并推送给那些能影响项目走势的核心干系人。风险案例管理库的建设运行机制，是将各类项目中所遇到的风险、问题及其解决方案，提炼成适用于某一类风险、问题的处理规则，并汇编成册，同时，还可以把过往由于风险管理不当而造成的重大失误和影响做成教学视频，这些风险案例手册和视频，都按照某种目录结构放在公司内部协同管理工具Confluence上分享，让团队成员引以为戒。

由于篇幅有限，本文重点介绍每日风险简报的撰写和推送机制。首先，根据你所在组织、团队和项目的特点，制作一份每日风险简报的撰写模板，模板内容力求突出重点、言简意赅，举例如图8-1和图8-2所示；然后，圈定每日简报的推送对象，你想哪些人谁了解这些信息，譬如，推送对象范围可以圈定为各职能部门经理、总监、产品副总裁或者研发副总裁等，正如在图7中所描述的那样，确保重要项目信息在核心干系人（各级领导）之间能够有效传递、及时同步，避免在团队内部出现由于重要项目信息传递不到位、同步不及时等原因，而导致外部合作方去找部门高层领导升级投诉事件的发生（在由多部门来协同开发的项目中，难免与外部门合作团队之间发生纠纷和升级投诉事件，所以，也不怕发生这类事件，就怕发生纠纷和升级投诉事件的时候，高层领导对此事一无所知，没有提前获取来自本部门团队内部的重要信息传递、同步，还得需要从投诉方那边的人来从头开始了解事件的来龙去脉，这就会让高层领导感到很被动了，有一种被打脸的感觉）；最后，每日风险简报的收集、维护和推送，可以指定某一位项目经理兼职来做，也可以由多名项目经理轮流兼职来做。

图8-2是图8-1的内容延续，以图8-1目录结构模板中的第1.1条作为展开示例，概要讲述了在每日风险简报中需要呈现的汇报要点及其概述，在你的团队中实际使用这种方法的时候，不必拘泥于模板内容。需要特别关注的是图8-2中关于“风险详细描述”和“风险对应举措”内容的举例，通过提出一系列问题来提醒自己做好风险监控，由于篇幅所限，不再逐一举例具体问题的实例来赘述。图8-1中的“重点需求进展”的模板，与图8-2类似，读者可以尝试自己来设计模板，区别在于需求维度和项目维度的所处层级不同，但在“风险详细描述”和“风险对应举措”的部分是一样的。

本文作为《未雨绸缪话风险》的续写，重点解析了风险管理五个关键词中的“识别”和“监控”，并给出相关的操作方法、实践案例和参考模板等提供读者参考。笔者原本打算对《未雨绸缪话风险》原文中“常见风险分析与应对”中的场景案例进行扩充，但由于篇幅和时间关系没有去写，这里就以迭代过程管理为示例，列出在迭代过程的各阶段中，可能发生的典型风险点及其检查方法，这些风险点都需要被团队提前识别出来，如图9所示。

在图9中，介绍了迭代过程经常划分的五个阶段，每个阶段选取了三个典型风险点及其检测方法作为示例。典型风险点及其检查方法，并不只是局限于此，有兴趣的读者可以根据自己团队的特点，继续补充完整，让你在团队中使用这些方法的时候真正地发挥其作用。凡事预则立，不预则废。成于思，败于随。全面掌握风险管理方面，围绕着“规划、识别、分析、应对和监控”这五个关键词来进行风险管理，才能做到未雨绸缪，防患于未然。同时，想要做好风险管理，也离不开《未雨绸缪话风险》原文中的“风险管理成功秘诀”九段论。