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考试准备中关于风险管理的一章的开头。听起来很聪明，但是项目经理如何知道应该预防哪些问题呢？这正是该章节和项目经理的风险管理技巧（同一作者的另一本伟大著作）所专注的内容。从这些书籍和我多年来在识别、分析和处理风险方面的经验中，我学到的是，最好的风险说明格式由三个部分组成：原因、风险和影响。
让我们从一个简单的例子开始。我在几周前开发了一个简单的Ruby gem——Sibit，你只需要在命令行中输入一个命令，就可以使用它检查你的比特币地址余额，并向另一个地址发送付款。它的功能很好，但它所有的操作都通过Blockchain API通过HTTP完成。
这意味着如果有一天API发生改变，这个宝石将停止工作。这是一个风险。现在API的工作方式正好符合宝石的预期，所以还不是一个问题，但这是一个非常预料到的问题。当这种情况发生时，宝石将停止工作，用户将不明白原因，并停止使用它。他们还会认为我是一个不维护、不可靠的垃圾创建者。对我的声誉来说不是很好，对吧？
就像Rita Mulcahy上面建议的那样，我不应该只是等到一个非常失望的用户给我发邮件。我应该主动以某种方式处理这个风险。怎么做呢？嗯，我可以做一些事情。首先，我可以创建一些集成测试来检查API是否仍然支持我期望的协议，并确保我的CI每天运行构建。一旦构建失败，我应该收到一封电子邮件，并根据情况修复宝石，以免用户注意到问题。其次，例如，我可以每周手动检查存储库，以确保它仍然处于良好状态并与API配合工作。
现在，让我们将这个故事转化为正式的风险管理。我从PMBOK风险管理章节中取得了下面小节的标题。
Identify Risks
首先，我们确定风险。它将由三个部分组成：
Cause #1: Sibit works by using the Blockchain API
Risk #1: The API may be changed without notice
Effect #1: Users will be disappointed
原因是我们拥有并且是事实的东西。风险是预期发生的事件，可能发生也可能不发生。效果是如果风险发生会发生的事情。为什么我们需要将其分为三个部分呢？从技术上讲，如果我们把它们放在一起，它会这样听起来：“由于Sibit使用了区块链API，而API可能会在没有通知的情况下发生变化，用户会感到失望。”但是更好的办法是明确定义原因/风险/效果的组成部分，因为我们可能会有不同的风险、效果和原因的组合。例如，如何为现有原因确定一个额外的风险：
Risk #2: The API may go out of the market
这是与之前不同的风险。API不会改变，但将完全从市场上消失。这可能吗？很有可能。这个风险会产生什么影响？和之前一样——用户会感到失望，因为我的Ruby gem Sibit将停止工作。也许还会有其他影响？嗯，让我们想一想。如果整个API都关闭了，我将不得不花费相当多的时间找到一个新的API，学习它，理解它的工作原理，并对我的gem进行很多改动，以使其适应新的API。如果新的API设计有显著不同，我甚至可能无法做到这一点。换句话说，风险#2的影响将是这样的：
Effect #2: It will take time to connect to a new API
另一方面，一旦这个API退出市场，市场上就会出现一个类似的API的机会。如果我们在适当的时机得知这一点，我们就可以利用这个机会为其他用户创建一个类似的API，对吗？因此，风险＃2还有一个额外的影响：
Effect #3: There will be an opportunity to create a similar API
这是一个积极的影响，而我们之前所遇到的影响都是负面的。项目经理的工作不仅是要识别负面影响，还要为大多数风险和原因找到相同数量的积极影响。
总结一下，这就是我们现在拥有的内容：
C1 → R1 → E1
→ R2 → E2
→ E3
明白这个图示了吗？原因 C1 导致了风险 R1 和 R2，每个风险都有一些影响：E1、E2 和 E3。为了能够定义这样一个多层级的图示并避免文本重复，我们需要将每个预期事件分为三个部分。
关于这三个部分，我学到了一些规则。
应该是。原因应该总是听起来像一个陈述句，使用现在时态，因为它陈述的是当前存在的事实，例如：“我们使用Hibernate”，“Java 6不再支持”，“我们的用户中有70%使用Android”，“付款通过PayPal发送”，“GitHub是我们代码库的唯一维护者”，等等。
可能。风险声明应使用词语“可能”，因为这是一种尚未发生但仅是预期的情况，例如“我们可能会失去客户”，“架构师可能会辞职”，“苹果商店可能会延迟审查我们的应用程序”，“投资者可能会退出”，等等。
将会。效果应该使用将来时态来明确陈述我们在未来将会遇到的风险，例如：”我们将会破产”，”我们将不得不重写整个模块”，”我们将再次花费$10,000购买硬件”等等。
毋庸置疑，陈述越短越好。一个正确定义的因果关系和风险应该每个包含最多20个字。较长的陈述只有一个意思：作者对事情的情况不清楚，需要花更多时间调查。
Qualitative Analysis
并非所有的风险和影响都是同样可能发生的，就像你所看到的那样。整个区块链API完全崩溃的可能性非常小，但它很有可能改变其HTTP协议。平等地关注所有的风险是愚蠢的，因为其中一些是“主要”的，而其他一些是“次要”的。我们如何知道哪个是哪个呢？我们给它们分配数字。下面是具体方法。
首先，我们分析所有风险并为每个风险分配一个概率，其中1表示该风险很可能永远不会发生，而9表示该风险无疑会发生。
C1 → R1:7 → E1
→ R2:2 → E2
→ E3
我给上述风险分别分配了7和2。这是我凭借专业判断做出的决策。这里没有数学计算。我只是看了一下风险，并作为项目的所有者/经理做出了个人决策。
然后，我们再次给每个效应分配一个在[1..9]范围内的影响。在这里，1表示我们预期的后果既不会伤害任何人，也不会真正帮助任何人，而9表示效果至关重要（无论是负面还是正面）。
C1 → R1:7 → E1↓:3
→ R2:2 → E2↓:8
→ E3↑:3
再次，我根据我的专业判断选择了这些数字。根据稍微修改的API来更改宝石是一回事（影响程度为3），而根据全新的API重新编写它则是完全不同的工作量（因此影响程度为8）。
最后一步是将它们相乘：概率 × 影响。我们将得到以下风险清单：
C1 → R1:7 → E1↓:3 ⇢ 7×3 = 21
C1 → R2:2 → E2↓:8 ⇢ 2×8 = 16
C1 → R2:2 → E3↑:3 ⇢ 2×3 = 6
你现在可以看到我们列表中的每个项目的内容。尽管列表中第二行的后果更为严重，但其概率较低，在风险的整体图景中，这一行并不是很重要。
我们刚刚所做的被称为定性风险分析：我们确定了哪些风险更为重要，需要立即解决，而哪些风险相对不那么重要，可以暂时忽略。
Quantitative Analysis
我会跳过这一部分。我认为对于一个小型软件项目来说，这并不重要或可行。根据Rita Mulcahy的说法：“作为项目经理，你应该始终进行定性风险分析，但并非所有项目或所有风险都需要进行定量风险分析，可以选择跳过这一步，继续进行风险应对计划。”
Plan Risk Responses
现在是时候开始执行我的应对计划了。在我风险清单中的每一个积极的项目中，基本上有两个选择。
避免。我可以做一些事情来降低风险的概率。对于风险
R2，我能做些什么来确保区块链API在市场上持续存在而不会消失呢？嗯，我可以在推特上宣传它，推广它，甚至可能为它捐款。但我怀疑这些做法是否真的有所帮助。所以在这里避免并不是正确的策略。无论我做什么，我都无法降低这种概率。如果风险R2必须发生，它就会发生。风险R1也是如此。减轻。第二种可能的风险应对策略是减轻影响。看一下影响
E1。如上所述，明智的做法是做两件事情。首先，创建集成测试并配置 CI 在 API 更改时发送电子邮件给我。其次，定期检查存储库以确保一致性，并在 API 更改后立即尽量减少存储库与 API 不同步的时间。
嗯，还有其他选择，比如接受（什么都不做，只是等待）或者转嫁责任（事情变糟时找个替罪羊来承担责任），但它们不太实际。
对于一个“好”的风险（E1/R2/E3），也有两个选择：
利用。我可以做一些事情来加速区块链API的快速消亡，从而使风险R2更快发生，对吗？嗯，尽管在这种情况下听起来像是个笑话，但我们经常选择用积极的风险来推动事情向前发展。这种策略被称为利用。
增强。我可能会采取一些措施来增加效果
E3的积极影响。例如，我可以准备一个类似的API，并将其做好市场准备。当区块链API失效时，我立即推出自己的API，并开始宣传它，说“嘿，那些家伙已经挂了，现在切换到这里吧！”我只是开个玩笑，但你明白我的意思。
所以，简单来说，我们可以将计划与风险或影响联系起来。我们可以用概率或影响来做一些事情。嗯，我们也可以处理原因。例如，如果我只是删除我的宝石并终止项目，我就可以消除整个风险清单，对吧？那样就不会有麻烦了。没有沮丧的用户，没有风险，没有机会。这在某些情况下也可能是一个解决方案（尽管在这种情况下不是）。
底线是，计划可能与原因、风险或效果相联系。我会定义三个计划，都是为了减轻”E1”的影响。
P1→E1: Create integration tests (once)
P2→E1: Configure CI (once)
P3→E1: Check the repo for compliance with API (weekly)
第一和第二项都是一次性操作，我必须尽快完成。一旦完成，它们将减轻E1的影响。计划P3应该每周执行一次，以减轻E1的影响。以下是我的风险清单，以及相应的计划：
C1 → R1:7 → E1↓:3 ⇢ 7×3 = 21
P1, P2, P3
C1 → R2:2 → E2↓:8 ⇢ 2×8 = 16
No plans
C1 → R2:2 → E3↑:3 ⇢ 2×3 = 6
No plans
有意义吗？希望如此。我强烈推荐您阅读《项目经理的风险管理技巧》这本书。它能以更详细的方式解释所有内容，并且读起来很有趣。
我创建了一个简单的网页项目，使得能够将这种类型的风险结构写下来：0rsk.com（它属于Zerocracy产品系列，所以名称以零开始）。你只需登录那里，创建一个新项目，然后“添加”你的风险。试试看。然后，当风险被注册时，你可以给它们附加响应计划。界面非常直观，所以你应该没有任何问题。如果有任何困难，请毫不犹豫地提交问题。
Implement Risk Responses
现在是时候实施计划了，将计划转化为任务。当时机成熟时，0rsk会将计划转化为任务。任务是给项目经理的明确指示。然后您可以自己完成这些任务，或将其委派给项目成员。
在不久的将来，0rsk将与GitHub和其他任务追踪器进行整合，以便在那里提交新任务并监控其执行。请继续关注，很快将有更多功能推出。
还有一个Telegram集成功能。每次需要执行新计划时，0rsk会在Telegram上提醒我，该开始工作了。试试看吧，机器人在这里：@zerorsk_bot。
Honestly, I find this risk-driven way of managing my scope of work very productive and results focused. First, I identify what the most important situations are in my project (which could be people, resources, bank accounts, software products, assets, etc), then I think about risks and I do this regularly, creating a few new risks every day, together with effects. Then, I plan what I can do in order to minimize their probabilities and react to their impacts. Finally, the Telegram bot starts telling me what to do every day.
由于这一切，我不会错过整体范围，它是由我的0rsk项目中的原因-风险-效果-计划结构来定义的，并且我每天都专注于重要的事情。
现在我不再对问题做出反应，而是像Rita Mulcahy建议的那样去预防它们。
你也可以，0rsk 对所有人免费。
附言：有一份由专家精心策划的原因、风险和影响列表，您可以从中选择与您的情况最相关的那个：yegor256/awesome-risks。您甚至可以在那里添加您的想法。
Do you have a formal Risk List in your project?
— Yegor Bugayenko (@yegor256) December 20, 2020
Translated by ChatGPT gpt-3.5-turbo/30 on 2023-08-29 at 05:46
