风险识别的七种方法

识别风险这件事，说白了就像是出门前看看天色，决定要不要带伞。没人想被淋成落汤鸡，无论是在生活中还是在工作中。项目开始了，一堆人埋头猛干，突然冒出个问题，整个团队都得停下来救火，这种事谁都不想遇到。所以，提前把可能出问题的点找出来，就是风险识别。它不是一次性的事，而是贯穿在整个项目过程中的。 下面聊聊几种我实际用过，并且觉得靠谱的方法。

1. 头脑风暴 (Brainstorming)

头脑风暴可能是最常用也是最直接的方法了。 操作起来很简单：把项目团队的核心成员，有时甚至可以拉上客户或者其他利益相关方，关在一个会议室里，找个白板，大家随便想，随便说，把能想到的所有潜在风险都列出来。

关键在于气氛。会议的组织者一定要强调，这个阶段不要去评判任何人提出的想法。 哪怕听起来很扯，也要记下来。因为有时候一些看似不靠谱的点，聊着聊着就能引出真正的大问题。我记得有一次我们做一个电商网站项目，一个刚毕业的实习生弱弱地提了一句：“万一上线那天，瞬间进来的人太多，服务器会不会崩？” 当时有些老员工觉得这是常识，没啥可讨论的。但我们还是把它记下了，并顺着这个思路往下挖，结果发现，我们原计划的服务器配置方案确实过于乐观，如果真按那个方案走，上线当天肯定得出事。

怎么开一个有效的头脑风暴会？

找对人：参与者需要对项目有了解，背景可以多样化，技术、市场、运营都该有。

别批评：核心原则就是不批评、不质疑。任何想法都先记下来再说。

要发散：鼓励大家从不同角度想问题，可以搞个思维导图，从一个点发散出去。

重数量：先别管质量，目标是尽可能多地收集风险点。

会后，再组织核心人员对收集上来的所有风险点进行分类、筛选和评估。这种方法的好处是能快速、广泛地收集信息，而且能激发团队的创造力。 缺点是，如果组织不好，很容易跑题，或者被几个声音大的人主导。

2. SWOT 分析 (SWOT Analysis)

SWOT 分析这个工具，很多人在做市场策略的时候用，但它拿来做风险识别也特别好用。 SWOT 分别代表优势 (Strengths)、劣势 (Weaknesses)、机会 (Opportunities) 和威胁 (Threats)。 其中，劣势和威胁这两项，就是风险的重要来源。

• 劣势 (Weaknesses)：这是内部因素。比如，我们团队缺一个懂数据库优化的专家，这就是一个技术风险源。或者，项目预算给得特别紧，这也是一个财务风险。
• 威胁 (Threats)：这是外部因素。比如，我们正在开发的产品，市场上突然出现一个强有力的竞争对手。或者，相关的政策法规突然变了，导致我们产品需要重新设计。这些都是威胁。

SWOT 分析的好处在于它提供了一个结构化的框架，强迫我们从内部和外部、有利和不利四个维度去全面思考。 我之前参与过一个新产品的战略规划，我们就用 SWOT 分析法。在分析“劣势”时，我们发现团队成员都太偏技术，对市场和运营的理解不够，这是一个巨大的内部风险。在分析“威胁”时，我们注意到一个潜在的政策变动，可能会影响我们产品的合规性。通过这个分析，我们提前识别了这两个重大风险，并及时引进了市场顾问，同时让法务团队提前研究了应对预案。

做 SWOT 分析的时候，要尽量客观。最好是让不同部门的人都参与进来，避免视角单一。

3. 清单分析法 (Checklist Analysis)

这个方法听起来有点“笨”，但特别有效，尤其对于一些有成熟经验可以借鉴的领域。清单分析法就是拿一张根据历史经验总结出来的风险列表，然后一项一项地对照当前的项目，看看是否存在同样的问题。

这张清单从哪来？通常是基于公司过去做过的类似项目。每次项目结束，都应该做复盘，把遇到的所有问题和风险都记录下来，慢慢就积累成了一份宝贵的风险清单。比如，软件开发项目可能会有这样的清单：

需求变更是否频繁？

核心技术人员是否有离职风险？

第三方接口是否稳定？

项目交付时间是否过于紧张？

这种方法的好处是系统、高效，能防止遗漏那些常见的、重复出现的风险。 我之前在一家管理很规范的公司工作，每个新项目启动时，项目经理都会拿到一份长达十几页的标准风险核对表，这份表是公司十几年项目经验的结晶。我们只需要逐项检查，就能快速识别出 80% 的常规风险。

当然，它的局限性也很明显：它只能帮你找到已知的风险，对于那些全新的、从未遇到过的问题，清单就无能为力了。所以，这个方法最好和其他方法结合起来用。

4. 假设与约束分析 (Assumption and Constraint Analysis)

每个项目都建立在一系列的假设和约束之上。把这些假设和约束条件识别出来，然后分析它们，就能找到很多潜在的风险。

• 假设 (Assumptions)：是指我们在做计划时，认为是正确的、真实的因素，但实际上它们并不确定。 比如，我们假设某个关键技术组件在下个月能够按时开发完成。但如果这个假设不成立，整个项目进度就会被打乱。这就是风险。
• 约束 (Constraints)：是指限制我们选择范围的因素。 比如，项目必须在六个月内完成，或者预算不能超过 100 万。这些都是约束。约束本身就是风险源，比如紧张的时间表会增加项目延期的风险。

我经历过一个项目，客户要求我们在一个很老的系统上做二次开发。我们的一个核心“假设”是，这个老系统的文档是准确完整的。结果项目进行到一半，发现文档和实际系统有很多对不上的地方，导致我们花了很多额外的时间去研究代码，项目差点延期。从那以后，我养成了个习惯，在项目初期就把所有的关键假设都列出来，然后逐个去验证，或者至少为那些不确定的假设准备好备用计划。

做这个分析，第一步就是把所有假设和约束都写下来。然后团队一起讨论：如果这个假设是错的，会怎么样？这个约束条件对我们来说意味着什么？通过这种方式，很多隐藏的风险就会浮出水面。

5. 文档审查 (Documentation Reviews)

有时候，风险就藏在一大堆项目文件里。仔细审查项目计划、合同、需求规格说明书、技术方案等各种文档，可以发现很多问题。

比如，在审查需求文档时，你可能会发现有些需求描述得模棱两可，不同的人可能有不同的理解。这在未来就可能导致开发出来的功能不是客户想要的，造成返工风险。审查合同的时候，可能会发现一些付款条款对我们很不利，或者对交付成果的验收标准定义不清，这些都是合同风险。 现在甚至有公司在开发基于人工智能的文档审查系统，通过自然语言处理等技术来自动识别文件中的问题和缺陷。

我有一次接手一个外包项目，在仔细阅读了项目合同和技术方案后，我发现合同里约定的交付时间，和技术方案里评估的开发工作量存在明显的矛盾。简单说，就是时间根本不够。我立刻把这个问题提出来，经过和客户的重新协商，我们调整了项目范围和交付计划，避免了一次几乎必然会发生的延期纠纷。

所以，不要嫌看文件麻烦。项目经理和核心团队成员，一定要花时间把关键文档从头到尾仔细看一遍，很多风险在你签字之前就能避免掉。

6. 根本原因分析 (Root Cause Analysis)

根本原因分析通常用来分析已经发生的问题，但它同样可以用来识别潜在的风险。 它的核心思想是不断追问“为什么”，从而找到问题的最深层次原因。 这种方法可以帮我们思考，哪些深层次的原因可能会在未来引发问题。

举个例子，我们可以用“鱼骨图” (也叫因果图) 这个工具。 假设我们要识别“产品上线后用户体验差”这个风险，我们可以把“用户体验差”作为鱼头，然后从“人、机、料、法、环”等几个方面（鱼骨）去分析可能的原因。

人：开发人员技能不足？测试人员经验不够？

机：服务器性能太低？用户手机适配没做好？

法：开发流程不规范？测试用例覆盖不全？

通过这样系统性地分析，我们就能识别出很多可能导致最终风险发生的具体原因，然后针对这些原因去制定预防措施。这种方法的好处在于，它能帮我们透过现象看本质，找到那些真正需要解决的根本性问题，而不是只处理表面症状。

7. 专家访谈 (Expert Interviews) / 德尔菲法 (Delphi Technique)

有时候，识别风险最快的方法就是直接去问那些有经验的人。 这些人可以是公司内部的技术专家、资深项目经理，也可以是外部的行业顾问。

直接进行一对一的访谈就很有效。但如果要系统地汇集多位专家的意见，并且避免互相影响，可以用“德尔菲法”。 这个方法的操作稍微复杂一点：

1. 匿名征求意见：你把需要识别风险的主题发给一群专家，让他们匿名写下自己的看法。

2. 汇总反馈：你把收集到的所有意见进行整理、归纳，形成一份匿名的汇总报告。

3. 多轮迭代：你再把这份汇总报告发给所有专家，让他们参考别人的意见，来修正或补充自己的看法。

4. 达成共识：重复上面两步，通常经过几轮之后，专家的意见会逐渐趋于一致，最终形成一份比较可靠的风险列表。

这种方法的好处是能充分利用专家的智慧，而且匿名的方式可以避免权威偏见或从众心理。 之前我们公司要做一个涉及到全新技术领域的项目，内部谁都没经验。我们就请了三位外部专家，用德尔菲法来帮我们识别技术风险。几轮邮件沟通下来，我们得到了一份非常有价值的风险清单，里面提到的好几个坑，我们自己之前想都没想过。这为我们后来的技术选型和研发路径规划提供了关键的依据。