测量网站风险

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

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