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