测量网站风险

管理风险的第一步是根据“必要”准确度确定特定行动的风险。我们使用“必要”而不是“尽可能”的原因是因为您可以更准确地判断风险，但考虑到您的产品可能存在一些小问题，这意味着无需进行准确的风险评估。在这一点上，粗略分析就足够了。有许多方法可以分析，评估或估算风险。您在工具箱中使用的分析方法越多，就越有可能在正确的时间为正确的活动选择正确的方法。我们将介绍三种判断风险的方法。我们将讨论每种方法的优缺点和准确性。

管理风险的第一步是根据“必要”准确度确定特定行动的风险。我们使用“必要”而不是“尽可能”的原因是因为您可以更准确地判断风险，但考虑到您的产品可能存在一些小问题，这意味着无需进行准确的风险评估。 软件开发

的，此时一个粗略的分析就足够了。分析、评估或估计风险的方法有很多。你的工具箱中容纳的分析方法越多，那么在正确的时间为正确的活动选择了最正确的方法的可能性就越大。我们准备介绍三种判断风险的方法。我们会讨论每种方法的优缺点和准确度。 第一种评估方法是直觉法。当某人由于处在某个位置(如运营团队的VP)或由于天生具备以感知风险的能力，而需要决定通过不通过某个行动时，可以采用这种方法。如前所述，某些人天生具备这种能力，组织中具备这样的人才对组织非常有利。然而，我们要提醒你有两点需要担心。首先，这个人是真的具备以下意识地识别风险的能力，还只是你希望他具备这种能力?换句话说，你跟踪过他对风险判断的准确程度吗?如果你没有跟踪过，那么在你考虑将它看作种比猜测更准确的方法之前，应该眼踪分析一下。其次，如果这个人判断出的风险确实具有一定准确度，你也一定不想让你的组织只依赖于某一个人。你需要让组织中的多个人都能明白如何评估风险。理想的情况是，组织中的每个人都了解风险的重要性，知道评估和管理风险的方法。作为一个直觉法的例子，假设我们虚构的公司Aliscalel中的运营团队VP汤姆・哈德具备这种能够现场对问题以及通过/不通过某项行动作出决定的能力。在每个人的印象中，他的决定从来没有被质疑过，总是正确的，至少在团队的记忆中是这样。他的团队刚刚做好把HRM应用的一个版本发布到生产环境中的准备，请求汤姆批准今晚把代码发布上去。过去周三晚上10点到12点是指定的维护时间窗；这并不是因为这时停机，只是因为这个时间段内流量少，比较适合执行高风险的行动。xxxx 今晚，在此时间窗口中拆分数据库，计划和批准。 Tom没有向团队解释，并决定今晚不发布新代码。预计将于明晚发布。他的团队接受了这个决定，因为即使他们是工程师，他们对所有事情都自然持怀疑态度，但没有人质疑汤姆决定通过这个传球。那天晚上，数据库拆分一团糟，整个团队被迫工作到天亮，扭转了所有的变化。 软件开发团队在早上听到了这个消息，并且非常高兴汤姆没有通过昨晚发布代码的请求。这种直观方法的优点是速度非常快。一个真正的专家，能够对某些任务的风险有一个基本的了解，可以在几秒钟内做出决定。正如我们所讨论的，这种方法的缺点是这个人可能没有这种能力，但由于几次关键的救援，他错误地认为他有这种能力。该方法的另一个缺点是它无法复制。人们经常需要在这个行业工作多年，通过磨练他们的专业技能，他们可以发展这种能力，这是从一小时的课程中学不到的。这种方法也有一个缺点，即当团队成员可以质疑彼此的数据和结论时，将决策留给一个人而不是依赖团队。取决于做出决定的人，采取的行动以及许多其他变量，这种方法的准确性可能有很大差异。也许有人非常善于评估本周的风险，下周它将完全失灵。我们要介绍的第二种方法是交通灯方法。当使用此方法判断动作的风险时，动作被分解为最小的组件，然后风险分为绿色，黄色或红色。最小的组件可以是已发布版本中的功能，也可以是维护步骤列表中的维护更改步骤。分区的粒度取决于几个因素，包括团队在执行这些评估时可以花费的时间和精力。 在为每个组件分配一个代表风险程度的颜色后，有两种方法可以计算该操作可能带来的总体风险。第一种方法是为每种颜色分配风险值，计算每种颜色的组分数，将该数乘以风险值，然后将这些值加在一起并除以组分总数。值的值最接近风险值，该值的颜色被视为整体风险的颜色。 微信小程序操作，发布或维护中的各个项目的风险评估由非常熟悉低级组件的人员完成。他们分析各种因素，例如任务的难度和完成任务所需的工作量（通常工作量越大）风险越高）组件与其他组件之间的交互（组件交互或组件越多）其他组件以此组件为中心，风险越高等，以确定是否为组件分配绿色，黄色或红色。工程师或其他专家可以使用它们来衡量整体列表中的特定特征或按特定粒度分类的项目的风险。