0rsk.com: Cause + Risk + Effect

The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:

“一个项目经理的工作不应该只关注解决问题,而应该关注预防问题。”这是Rita Mulcahy在她的著作PMP考试准备中关于风险管理的一章的开头。听起来很聪明,但是项目经理如何知道应该预防哪些问题呢?这正是该章节以及项目经理的风险管理技巧 (同一位作者的另一本优秀书籍)致力于解决的问题。我从这些书籍以及我多年的风险识别、分析和处理的经验中学到的是,最好的风险说明格式由三个部分组成:原因、风险和影响。

让我们从一个简单的例子开始。我几周前开发了Sibit,一个简单的Ruby gem,它是一个命令行比特币客户端。你可以通过它检查比特币地址的余额,并通过一个命令行调用向另一个地址发送付款。它运行得很好,但是它的所有操作都是通过Blockchain API进行的。

这意味着,如果有一天API发生了改变,这个gem将无法工作。这是一个风险。现在API的工作方式与gem期望的工作方式完全相符,所以它还不是一个问题,但这是一个非常可预见的问题。当它发生时,这个gem将停止工作,它的用户将不明白原因,只会停止使用它。他们也会认为我是一个创建了一些不维护且不可用的垃圾的创作者。对我的声誉来说并不好,对吧?

就像Rita Mulcahy上面建议的那样,我不应该只是等待一个非常失望的用户给我发电子邮件。我应该以一种积极主动的方式来处理这个风险。怎么做呢?嗯,我可以做一些事情。首先,我可以创建一些集成测试来检查API是否仍然支持我期望的协议,并确保我的CI每天运行一次构建。一旦构建失败,我应该收到一封电子邮件,并根据情况修复这个gem,以免用户注意到问题。其次,我可以每周手动检查代码库,确保它仍然处于良好状态并与API兼容。

现在,让我们将这个故事转化为正式的风险管理。我从下面的小节标题中引用了PMBOK风险管理章节的内容。

首先,我们确定风险。它将包括三个部分:

原因是我们拥有的事实。风险是预期的事件,可能发生也可能不发生。效果是风险发生时将会发生的事情。为什么我们需要将其分为三个部分?从技术上讲,如果将它们放在一起,它会听起来像这样:“由于Sibit使用了区块链API,而API可能会在没有通知的情况下发生变化,用户会感到失望。”但是更好的做法是清楚地定义原因/风险/效果组成部分,因为你猜怎么着…我们可能有不同的风险、效果和原因的组合。例如,为现有原因识别一个额外的风险如何?

这是与之前的风险不同的一种风险。API不会改变,但将完全从市场上消失。这可能吗?很有可能。这种风险会产生什么影响?一样的——用户将感到失望,因为我的Ruby宝石Sibit将停止工作。也许还会有其他一些影响?嗯,让我们想一想。如果整个API关闭,我将不得不花费相当长的时间来寻找一个新的API,学习它,了解它的工作原理,并对我的宝石进行许多改动,以使它能够理解新的API。如果新的API具有明显不同的设计,我甚至可能无法做到这一点。换句话说,第二个风险的影响将是这样的:

另一方面,一旦API退出市场,市场上就会出现类似的API的机会。如果我们在正确的时间知道这一点,我们可以利用这个机会为其他用户创建一个类似的API,对吗?因此,风险 #2 有一个额外的影响:

这是一个“积极”的效果,而我们之前所遇到的效果则是“消极”的。项目经理的工作不仅是要识别出消极的效果,还要为大多数风险和原因找到相同数量的积极效果。

总结一下,现在我们所拥有的是:

理解这个图了吗?原因 C1 导致了风险 R1R2,每个风险都有一些影响:E1E2E3。为了能够定义这样一个多级图并避免文本重复,我们需要将每个预期事件分成三个部分。

我学到了一些关于这三个部分的规则:

  • 可能。风险陈述中应使用词语“可能”,因为这是尚未发生但只是预期的事情,例如“我们可能失去客户”,“架构师可能辞职”,“苹果商店可能延迟审核我们的应用程序”,“投资者可能退出”等等。

  • 将会。效果应该以将来时态来表达,明确说明如果风险发生,我们将来会经历的结果,例如”我们将会破产”,”我们将不得不重写整个模块”,”我们将再花费$10,000购买硬件”等等。

不用说,陈述越短越好。适当定义的原因、风险和影响应该包含最多20个字。较长的陈述只意味着一件事:作者对正在发生的事情不清楚,需要花更多时间调查情况。

并非所有的风险和影响都是同等可能的,正如你所见。整个区块链 API 完全停止的可能性非常小,但它更有可能改变其 HTTP 协议。将同等的注意力放在所有风险上是愚蠢的,因为其中一些是“主要”的,而其他则是“次要”的。我们如何知道哪个是哪个呢?我们给它们分配数字。下面是具体步骤。

首先,我们分析所有的风险,并为每个风险分配“概率”值,其中1表示该风险很可能永远不会发生,而9表示该风险无疑会发生:

我对上述风险分别给予了7和2的评分。这完全是我的”专业判断”,没有涉及到任何数学计算。我只是审视了这些风险,并以作为项目的所有者/经理的个人决策作出了评定。

接下来,我们为每种影响分配一个”影响度”,同样在”[1..9]”的范围内。在这里,1表示我们所预期的后果既不会对任何人造成伤害,也不会真正帮助任何人,而9表示该影响至关重要(无论是正面还是负面)。

再次,我根据我的专业判断选择了这些数字。根据稍微改变的API来更改宝石是一种情况(影响为3),而为全新的API重新编写它则是完全不同的工作量(因此影响为8)。

最后一步是将它们相乘:概率 × 影响。我们将得到以下风险清单:

你现在可以看到我们列表中每个项目的含义。虽然列表中第二行的后果更为严重,但概率较低,在风险总体图中,这一行的重要性较小。

我们刚才所做的被称为定性风险分析:我们确定了哪些风险更重要,需要立即解决,哪些风险较不重要,可以暂时忽略。

我会跳过这一部分。我认为对于一个小型软件项目来说,这并不重要或可行。根据Rita Mulcahy的说法:“作为项目经理,你应该始终进行定性风险分析,但并不是所有项目或所有风险都需要定量风险分析,可以选择跳过它,进入风险应对计划阶段。”

现在是时候开始实施我的回应计划了。在我的风险清单的每一条“积极”事项中,基本上有两个选择。

  • 减轻。第二种可能的风险应对策略减轻影响的效果。看看效果E1。如上所述,明智的做法是做两件事情。首先,创建集成测试并配置 CI 在 API 更改时向我发送电子邮件。其次,定期检查存储库以确保一致性,并在 API 更改后立即缩短存储库与 API 不同步的时间。

嗯,还有其他选择,比如“接受”(什么都不做,只是等待)或“转移”(在事情不顺利时找一个替罪羊来承担责任),但它们的实用性较低。

对于一个“良好”的风险(E1/R2/E3)也有两个选择:

  • 增强。我可以采取一些措施来增加效果E3的积极影响。例如,我可以准备一个类似的 API 并使其上市。当区块链 API 停止服务时,我立即推出自己的 API,并开始宣传它,说:“嘿,那些家伙已经倒闭了,现在切换到这里吧!”我只是开个玩笑,但你明白我的意思。

所以,简单来说,我们可以将计划附加到风险或影响上。我们可以通过概率或影响来采取行动。嗯,我们也可以处理原因。例如,如果我只是删除我的宝石并终止项目,我可以消除整个风险清单,对吧?就不会再有麻烦了。没有沮丧的用户,没有风险,没有机会。在某些情况下,这也可能是一个解决方案(尽管不是在这种情况下)。

关键是计划可以附加到原因、风险或影响之一。我会定义三个计划,都是为了减轻“E1”的影响。

首先两项是一次性操作,我必须尽快完成。一旦完成,它们将降低E1的影响。计划P3应每周执行,以降低E1的影响。以下是我的风险清单及相应计划:

有道理吗?希望如此。我强烈推荐你阅读《项目经理的风险管理技巧》(Risk Management Tricks of the Trade for Project Managers)。它以更详细的方式解释了所有内容,而且读起来很有趣。

我创建了一个简单的网络项目,可以将这种类型的风险结构写入其中:0rsk.com(它属于Zerocracy产品系列,所以名称以零开始)。你只需登录那里,创建一个新项目,然后“添加”你的风险。试试看。然后,当风险被记录时,你可以给它们附加响应计划。界面非常直观,所以你应该没有问题。如果有任何困难,请毫不犹豫地提交问题(submit an issue)。

现在是时候开始实施计划了,将计划转化为任务。当时机成熟时,0rsk会将计划转化为明确的指示,供您作为项目经理使用。然后您可以自己完成这些任务,或者委派给项目成员。

在不久的将来,0rsk将与GitHub和其他任务跟踪器进行集成,以在那里创建新任务并监控其执行情况。请保持关注,很快将推出更多功能。

还有一个Telegram集成功能。每当需要执行新计划时,0rsk会在Telegram中提醒我,提示我是时候开始工作了。试试看吧,机器人在这里:@zerorsk_bot

老实说,我发现这种以风险为驱动的工作范围管理方式非常高效和结果导向。首先,我确定项目中最重要的情况(可以是人员、资源、银行账户、软件产品、资产等),然后思考风险,并且定期进行这样的思考,每天都会创建一些新的风险以及相应的影响。然后,我制定计划,以最小化这些风险的概率并应对它们的影响。最后,Telegram机器人会每天告诉我该做什么。

多亏了这一切,我不会忽视整体范围——它是由我的0rsk项目中的因果-风险-影响-计划结构来定义的——而且我每天都专注于重要事项。

现在,我不再对问题做出反应,而是预防它们,就像Rita Mulcahy建议的那样。

你也可以做到,0rsk对所有人都是免费的。

附注:有一个经过筛选的因果、风险和影响列表,你可以从中选择与你的情况最相关的事项:yegor256/awesome-risks。你甚至可以在那里添加你的想法。

Translated by ChatGPT gpt-3.5-turbo/42 on 2023-12-15 at 06:54

sixnines availability badge   GitHub stars