-->

郭东白的架构课_32_22节点三什么样的风险才算是重大风险

你好,我是郭东白。

上节课呢我们讲了架构活动的第三个节点可行性探索,并且介绍了进入节点之前的一些准备工作。

有了这些基础,我们就来看怎么进行可行性探索。

架构活动中的可行性探索工作可以分成四个部分,分别是重大风险发掘风险预估。

重大风险沟通和可行性决策需要预先说明的是我接下来介绍的方法呢,仅仅适用于互联网企业线上业务的风险决策。

如果你主持的是线下或者是o to o项目,比如说大型物流分发中心的建设,那么这种快速决策方法呢就完全不适用。

我们先来看第一个部分呢重大风险的发掘。

在这一步呢我们需要从多个视角对风险做一个全面的挖掘。

第一个视角呢是项目项目交付的视角,我们可以考虑这么几个问题,比如在当前交付时间的约束之下,会不会出现研发动作和设计完全变形的情况呢?当前时间要求和资源输入能不能产出质量上可以接受的实施方案呢?也就是说,方案能不能高于质量底线呢?还有有多个参与项目的团队能不能有效协同呢?我们有没有留出足够的时间让团队处理集中出现的问题呢?你发现这些分析跟我们在第二十节课提出了一个分析很相似,那就是从执行者的视角进行目标合理性的分析。

只不过你现在认为目标已经合理了,你还需要在给定的时间和人力条件的限制了,看看执行会不会出现重大风险。

第二呢是商业价值视角有没有可能会大幅影响最终产生下商业价值的因素呢?比如互联网企业最容易发生的就是恶性竞争,本来很好的一个商业模式,会因为大量而加进进入,最后呢变得无处逃生。

那么当某个大厂进入后或者几十个初创公司入场之后,我们该怎么保障商业价值还能维持在之前估计的水平呢?第三呢是人性视角。

关于人性视角的考量。

我们在人则二中详细简讲解过,比如说整个架构方案是不是符合整个研发人员和用户的人性呢?除了这些视角之外,还有三个视角角实,这是呢有限资源的视角。

意思说呢是你的架构活动所需要的最小必须的资源是不是能够完全到位。

那先看第一个,也就是资源视角中的运营资源发展上线之后,会有足够的运运营资源来帮助项目冷启动吗?如果说这些运营资源不存在,那么项目的预期产出还能保障吗?第二呢是研发资源,企业内部还有什么正在筹划中的重大项目吗?那响相关研发团的资源投入的因素有哪些?如果某个多方拼抢的资源不存在,那么项目的预期产出会发生什么样的重大变化呢?第三呢是技术价值。

影设你的项目是个技术驱动的项目,那么项目的长期技术价值有保障吗?在新技术、开源和sars化的大潮之下,你的技术价值会长期存在吗?这些技术价值是你这个架构活动可以独立创造的呢?还是强依赖于其他项目呢?假设是强依赖于其他项目吗?那你会用什么方法来保障项目的价值创造呢?要知道如果没有其他应用的支持,那么项目自身的价值就很难发挥出来。

简单来说呢,你不要当蒙古国的海军司令,最后呢是其他的风险。

相对整个企业来说,你的架构活动需要特别关注监管风险、法律风险和安全风险吗?其中哪些风险会影响整个架构活动的可达性呢?从这些视角出发呢,我们就完成了对风险的梳理。

从中呢可以看出来,我们在可行性探索的过程中要思考的问题,都是那些会大幅降低一个架构活动预期价值的问题。

而这些问题的答案呢,会决定我们是否要完全叫停整个架构活动,或者对架构目标做出大幅修正。

只有这样的风险才能叫重大风险。

我对我的团队呢有个硬性要求,那就是从每个视角出发梳理出来的重大风险,最多不能超过三个。

这个数量级非常重要。

我们把这个节点呢叫做可行性探索。

这望呢是用最短的时间内发现最大的风险,而不是要求你组织全公司所有的同事,大家呢一起来做风险大扫除。

这里面呢关注动作呢有两个,分别是最短时间和最大的风险。

在我看来,无论是多大的互联网项目,如果你花了超过三个人是才发现风险。

那么你作为项构项目的总架构师呢,其实是不称职的。

这个呢我可以举一个很简单的例子。

曾经呢有一个同学给我反馈项目的重大风险,竟然梳理出了一千多项风险。

Excel呢有一百分险,我当时都崩溃了,尤其看着他满心期待求表扬的表情,我实在是哭笑不得。

那么怎么在最最短时间内发现最大的风险呢?一方面呢是要靠自己的判断,另一方面呢则要靠你的关系网络。

你要找到自己在准备环节中锁定的领域专家,把项目背景和情况描述出来,然后呢认真听取他的意见反馈。

这理之后呢,在带着这些答案跟风险决策建议就一起碰撞,试图发现更大的跨领域的风险。

这个过程能跟访谈有点类似,每人呢每次大概是一个小时的样子。

这样来说呢,覆盖一个大项目的所有视角,也就是十几个人我特别想强调呢在这个访谈过程中呢,你自己也要有大量的思考和价值创造。

你需要不断综合多个视角的输入,然后再去加工和提炼每个人的输入。

这样的话呢,每次的访谈都是在之前访谈的基础上,我需要更高质量的思想碰撞。

这种基于高质量思想实验来迅速梳理出重大风险的工作方式,就是风险发掘的王道。

那么霸道的做法是什么呢?就是我们刚才提到的靠大量的地毯式的收索得出的海量风险列表。

这种方方式呢不但不高效,甚至呢是有害呢。

因为这种地毯式的搜索呢,它往往是收集者,从从他人手中汇总而来的。

你往往会把自己的视角局限在单个领域上。

一方面呢你会被这种小小的满足所麻痹。

另外一方面呢,你想要在大量的无效信息中去寻找真正的全局性风险,那么真是难上加难。

完成这一步后呢,你最终要梳理出一个有综合排序的重大风险列表,我建议是不超过五条。

那么这五条风险就是风险预估的输入了。

第二部分呢是风险敞口的预估。

风险敞口的预估呢并不是传统的风险描述,分析建模、预案设计和评估的过程,而更像是思想实验。

你需要呢对重大的风险的逐一梳理,确认某个预案,从重论上来说是存在的。

并且呢保障预案实施之后的大致体验可以被接受。

而且经过预案的缓解之后的残余风险呢在赞助者呢可以承受的范围之内。

在这个阶段呢,你并不是真正要实施并且验证预案来仅是确认预案存在,并且理论上可行,了解这个预案的预期用户体验就行了。

举个例子,假设呢你是年终大促的这种架构师,其中一个项目呢是做支付营销项目。

也就是说呢,使用某个支付渠道的用户会有个性化的额外折扣额,来帮助支付渠道,能以最低的成本迅速拉新。

但这个项目呢有可能没法在大促前完成,那么你就需要确定预案了。

预案可以有很多种,不但可能会影响到最初的方案实施的成本差异也会很大。

就这个案例来说呢,会出现两个极端的情况,一个是全力交付,一个跟原方案最接近的线上方案。

同时你以最小成本交付一个体验折损比较大的降级方案。

另一个呢是基本放弃原来的方案,然后呢分出部分资源做一个用户体验折损最小的预案。

第一种情况呢是极端的降级体验,根本不支持支付营销,而是给每个符合离线筛选条件的用户推送。

一个只能通过这个支付渠道使用的购物券,靠用户呢主动选择支付渠道来激活这个券。

而第二种情况呢,是最小化损失的降级方案。

可能是把呢在线支付营销判断呢放在离线去做,把用户等级和支付营销的优惠额度存在一个分布式的缓存里。

然后呢,在收银台调用这个缓存服务,临时引导用户使用这个有折扣的支付渠道。

那么跟你原有的方案相比呢,也就是在首页导购搜索推荐全链路透出最低成交价格的个性化支付营销。

这两种转化的预估呢肯定要更低的。

不过呢赞助者和决策者呢很可能会接触其中的一种降级体验。

这样一来呢实施风险一下就降低了很多。

就像我们做需求评估,整个风险敞口的预估呢,只是对大致的实施方法和体验。

有个描述,目的呢是确认的确有预案存在,而且一种路径呢是各方可以接受的。

不过在风险评估的过程中呢,对真正的风险敞口你可能并不知情。

比如说刚才讲的支付营销项目,可能两家公司签订了对赌协议。

如果拉新项目达不到预期呢,电商平台要向支付渠道赔付一定数额的营销费用,那么风险敞口就一下子大了很多。

我们再来讲另外一个话题,我们之前呢还提到了呢评估重大风险,缺乏统一标准这种情况每个风险的具体场景不同,所以在领域呢也有很大的差异,很难用同一套标准来描述。

我建议你用五个参数来量化你面临的重大风险,然后呢再针对每一个备选方案进行组合。

那么你跟执行者呢就能给出预案被迫实施后的大计估计值了。

这些参数分别呢是总时间成本、总人力成本、总资金成本、效果折损和用户体验损失。

其中呢效果折损呢是是降级方案,造成商业价值或者商业效果的损失。

而用户体验损失有两种方法来计算,一种呢是通过用户的复购率降低值来量化用户体验的损失。

另外一个量化方法呢比较客观。

另外,保障用户复购率持平所需要的营销购物券的成本。

这样一来呢,你就可以把用户体验这种比较抽象的指标呢量化成一个资金成本。

缺点呢是实施起来比较麻烦。

那可以看到呢,在出具方案细节之前,各个维度的参数呢都很难估算。

好在呢我们其实不是做可行性分析,而是做可行性探索。

那么只需要参数在数量级上合理就可以了。

这个时候呢,大多数有经验的领域专家都能给出一个预估。

比如说对效果折损专家呢肯定没法回答具体折损多少这个问题。

但是对有几成折损,我估计呢你能得到一个比较靠谱的回答。

比如说折损绝对不止一成,至少有三成,不过也不会超过五成。

那经过预估之后呢,你会发现自己之前练出的最大的五个风险现在已经不是最大了。

如果预案呢可以实施完成的话,那么这五个风险的等级呢会下降。

如果时间允许呢,你还可以再多看几个风险。

也许你会问,到底看几个合适呢?你可以琢磨一下,我们在这个环节呢只有一个目标,就是发现那些有必要叫停项目或者大幅更改整个架构活动目标的风险,这才是所谓的重大风险。

其他的风险呢都是架构,是要带领大家有克服的困难。

所以呢真正达到能够叫停一个项目的风险呢啊其实是很少的。

在我的经验来看呢,一般一个项目最多呢也就是两三个重大风险。

第三部分呢是风险沟通。

当梳理出重大风险之后呢,你这个架构师呢不仅要持续关注,还要确保相关执行者也在持续关注。

除了自己的团队成员之外呢,有些风险预案呢还涉及外部的合作渠道,比如说支付营销合作渠道啊,企业的支付部门、某个啊支付机构或者银行卡组织等等。

你也需要知晓你的风险情况、降级预案,以及可能对用户体验产生的影响。

当然了,你没有权利来同步,而是要建议赞助者去怎么做。

一方面呢通知合作方呢是一个绑架行为。

另外一方面呢,合作方知晓风险之后呢,可能会帮你出主意,找到更好的解决方案。

你可能问了,如果支付知道在知晓风险之后撤回合作了,那该怎么办?是的呢,这种可能性呢的确存在。

不过从我自己的经验来看呢,如果你主动分享自己遭遇的困难,那么你得到的帮助的可能性将远远大于被拒绝的可能性。

反之呢,我也见过有些架构师绑架合作者的做法。

这种人的态度是呢,最终只要我量起来了,你还是得跟我玩。

或许决策者可以做出这样极端的决策。

但是你作为架构师,我认为你根本不应该懂这样的心思背后的原因呢。

我们在法则六里已经再三强调了,良知是这个架构师这个职能的必要条件。

况且呢也没这个授权。

最后呢是风险决策,这呢是可行性态节点中最重要的一环。

在此之前呢你已经收集了架构活动的重大风险的认知。

也从全局上对风险有了比较深刻的认知。

收集预估估训的过程程。

其实呢也让你建立了一套全局的风险评估标准。

在风险评估的过程中呢,你肯定受到了决策者赞助者和执行者的立场以及风险承熟度。

那么在最后的决策环节呢,你呢就是将你收集到的重大风险,相应预案,参与者的风险承受度都表达出来作为建议。

除此之外呢,我还想特别强调三点。

第一点呢,这个建议呢需要你站在决策者的视角上做出一个对全局有利的决策,而不是赞助者或者是执行者的视角。

第二点呢,你要敢于冒险。

互联网时代呢时间呢是最稀缺的资源,所以冒险相对而言是更为有利的选择,不冒险反倒是一个不负责任的表现。

第三呢是冒险要理智。

作为架构师呢,你需要对重大风险发生之后的用户体验损失、商业价值损失等等进行准确的数量级评估。

同时呢也要对预案能挽回的部分呢有个预估。

一旦冒险失败了,你还可以用时间来补偿。

最终呢在这些信息的基础上呢,你需要给出一个可行或者不可行的总建议。

这里呢我也特别强调一下,不可行的建议是一个完全合理的选择,甚至是一个好的选项。

为什么我敢这么说呢?从个人的经验来说呢啊不论在国内还是国外,那些大的架构项目,真正能取得成功的不多,是是之之二。

但是可行性探索呢却是几乎十之八九,都被跳过了。

很明显呢,大家在这个能避免重大错误的最后防线上做的工作太少了。

事实上呢,这跟很多企业推行强执型的文化呢是分不开的。

在这种企业里,个别给出不可行建议的人,甚至会被打上守旧和退缩的标签,丧失职业发展的机会。

不过呢多数企业呢还是能容忍讲真话的人。

那么我们作为架构师,应该如实的传递风险,让决策者来做最终的选择。

当然呢你也可以对架构目标做出调整的建议,尤其是风险主要来自交付压力的情况。

这四个部分的工作全部完成之后呢,你会得到决策者的输入。

比如,对架构活动是否可行的判断、对风险承受度的矫正、对预案的改进建议,以及对架构目标和交付时间的调整等等。

需要注意的是呢,这些都是呢你需要进行完整的文档录入,然后同步和分享给团队的。

如果项目可行呢,那你进入架构规划环节之前呢,其实对重大目标都有了非常清晰的判断了,毫无疑问就会大大提升整个架构活动的成功概率。

如果项目不可行,我相信你在这个过程中积累的判断能力,以及开放的心态,全局的思维也会给你带来新的机会。

好了,今天的内容呢就是这些。

我来总结一下,我们在这节课呢讲了可行性探索的过程。

这个结节的重要价值在于你可以帮助企业避免重大损失。

因为你要站在赞助者的视角上,尽量发掘重大风险,寻找重效预案。

寻保项目目标是最终可达的这呢是所有节点上最后一个能以极低成本来避免损失的机会了。

这个过程呢并不需要你花很多时间,也不需要很多人的参与。

重要的呢是你和参与者把注意力放在重大风险的梳理上。

所以这个过程呢行王道的做法就是找到那些具备高质量思考的、具备丰富经验的人,让他们从各自的视角去发掘重大风险,然后在这群人中迅速迭代你对风险的全局性思考,不断提升相应预案的质量。

在此之上呢,你要形成完整的、全局的、量化的风险评估以及重大风险链表,并及时跟执行者和赞助者做沟通。

最终呢你要站在决策者的视角上,以相对乐观和敢于冒险的心态提出可行性建议。

需要格外注意的是呢,无论如何都不应该隐瞒风险,绑架其他的参与者。

如果你能做到这些呢,并且跟决策者确认项目确实可行,那你就可以放心大胆的往前推进了。

最后呢是三道思考题。

第一题呢你有没有给出不可行的建议?现在回头来看呢,你当时的判断正确吗?有没有为企业避免了损失呢?第二题,有没有参与过知其不可而为之的架构活动呢?最终的结果是什么呢?为什么会是这样的结果呢?第三题,你参与的架构活动中有没有出现过一些重大风险,被参与者忽视的情况?根因在哪里?你认为靠什么机制可以避免这种情况呢?如果这节课对你有帮助,欢迎你把课程转发给你的朋友和同事顺便打个小广告。

我刚开了个人抖音号,我会定期发表一些比较新,但是不一定那么成熟的观点。

欢迎在抖音上搜索郭东柏并关注,也欢迎你的批评指正。

我们下节课再见,拜拜。