管理风险的第一步是按照“必要的”精确程度判断某个特定行动带来的风险。我们之所以用“必要的”而不是“尽可能的”，是因为你也许能够更加精确地判断出风险，但考虑到你的产品或会有些小问题，这就说明精确的风险评估是不必要的，此时一个粗略的分析就足够了。分析、评估或估计风险的方法有很多。你的工具箱中容纳的分析方法越多，那么在正确的时间为正确的活动选择了最正确的方法的可能性就越大。我们准备介绍三种判断风险的方法。我们会讨论每种方法的优缺点和准确度。

管理风险的第一步是按照“必要的”精确程度判断某个特定行动带来的风险。我们之所以用“必要的”而不是“尽可能的”，是因为你也许能够更加精确地判断出风险，但考虑到你的产品或会有些小问题，这就说明精确的风险评估是不必要的，此时一个粗略的分析就足够了。分析、评估或估计风险的方法有很多。你的工具箱中容纳的分析方法越多，那么在正确的时间为正确的活动选择了最正确的方法的可能性就越大。我们准备介绍三种判断风险的方法。我们会讨论每种方法的优缺点和准确度。



第一种评估方法是直觉法。当某人由于处在某个位置(如运营团队的VP)或由于天生具备以感知风险的能力，而需要决定通过不通过某个行动时，可以采用这种方法。如前所述，某些人天生具备这种能力，组织中具备这样的人才对组织非常有利。然而，我们要提醒你有两点需要担心。首先，这个人是真的具备以下意识地识别风险的能力，还只是你希望他具备这种能力?
 
换句话说，你跟踪过他对风险判断的准确程度吗?如果你没有跟踪过，那么在你考虑将它看作种比猜测更准确的方法之前，应该眼踪分析一下。其次，如果这个人判断出的风险确实具有一定准确度，你也一定不想让你的组织只依赖于某一个人。你需要让组织中的多个人都能明白如何评估风险。理想的情况是，组织中的每个人都了解风险的重要性，知道评估和管理风险的方法。作为一个直觉法的例子，假设我们虚构的公司 Aliscalel中的运营团队VP汤姆・哈德具备这种能够现场对问题以及通过/不通过某项行动作出决定的能力。在每个人的印象中，他的决定从来没有被质疑过，总是正确的，至少在团队的记忆中是这样。他的团队刚刚做好把HRM应用的一个版本发布到生产环境中的准备，请求汤姆批准今晚把代码发布上去。过去周三晚上10点到12点是指定的维护时间窗；这并不是因为这时停机，只是因为这个时间段内流量少，比较适合执行高风险的行动。今晚，在这个时间窗内要拆分数据库，这是计划好且被批准过的。汤姆没有向团队进行解释，就决定今晚不能发布新代码，预计可以明晚发布。他的团队接受了这个决定，因为即使他们是工程师，与生俱来对一切持怀疑态度，但没有人曾对汤姆的通过不通过的决定产生过质疑。那天深夜，数据库拆分做得一团糟，整个团队被迫工作到黎明，回退了所有的变更。软件开发团队早晨听到这个消息，很高兴汤姆没有通过那个昨晚发布代码的请求。

这种直觉法的优点是非常快。一个真正的专家，与生俱来就能够对某些任务的风险大小有根本的认识，这种人能够在几秒钟内就做出决策。正如我们讨论过的，这种方法的缺点是这个人可能不具备这种能力，只是由于几次关键的救场，让他误以为自己有这种能力。这种方法的另一个缺点是不可复制。人们通常需要在业界工作过多年，通过磨炼自己的专业技能，才能开发出这种能力，这不是可以从一个小时的课程中就能学到的。这种方法还有一个缺点，即把决策都留给了一个人来做，而不是依靠一个团队，这时团队成员之间可以互相质疑对方的数据和结论。这种方法的准确度会因做决策的人、采取的行动以及许多其他可变因素而有很大不同。也许某个人在这星期内，非常善于评估风险，而下一周就完全失准了。

我们要介绍的第二种方法是交通灯法。采用这个方法判断一个行动的风险时，要把这个行动分解成最小的组成部分，然后给它们划分风险程度，可以是绿色、黄色或红色。所谓最小的组成部分，可以是一次发布的版本中的一个功能，也可以是维护步骤列表中的一个配置变更的步骤。划分的粒度取决于几个要素，包括团队执行这些评估可以投入的时间和精力。在每个组件都被分配了代表风险程度的颜色后，有两种方法可以计算出该行动可能带来的整体风险。第一种方法是给每种颜色分配一个风险值，计算每种颜色的组件的数量，用这个数量乘以风险值，然后将这些值加起来，再除以组件的总数。得出的值最接近哪个风险值，就把那个值的颜色作为整体风险的颜色。

对微信小程序行动、发布或维护中的个别项目的风险评估是由非常熟悉低层组件的人来做的，他们通过分析各种因素，如任务的难度、完成任务需要的工作量(通常工作量越大，风险越高)以及该组件与其他组件之间的交互(交互的组件越多或者其他组件是以这个组件为中心的，风险越高)等来确定给这个组件分配绿色、黄色还是红色。工程师或其他专家可以用它们衡量整体列表中某个特定功能或按某个粒度划分的项目的风险。