你好，我是郭东白。上节课我们讲了架构活动的第三个节点——可行性探索，并介绍了进入节点前的一些准备工作。有了这些基础，这节课我们就开始学习怎么进行可行性探索。
架构活动中的可行性探索工作，可以分成重大风险的发掘、风险预估、重大风险沟通和可行性决策四个部分。需要预先说明的是，我接下来介绍的方法仅仅适用于互联网企业线上业务的风险决策。如果你主持的是一个投资数亿、建设占地２万平米的大型物流分发中心的建设，那么这种快速决策的方法论则完全不适用。
在这一步，我们需要从多个视角对重大风险做一个全面的挖掘。
第一个是项目交付的视角。在当前交付时间的约束之下，是否会出现研发动作和设计完全变形的状况（请参看第20讲）？当前的时间要求和资源投入，能否产出质量上可以接受的实施方案？也就是说，实施方案是否高于质量底线？多个参与项目的团队能否有效协同？我们是否留出了足够的时间，让团队去处理集成中出现的问题？
事实上，这还是我们之前提到的，从执行者视角去分析目标合理性的问题。只不过，现阶段你认为目标已经是合理的了，所以就需要在时间和人力的限制条件下，看看执行过程中是否存在重大风险。
第二个是商业价值的视角。是否存在会大幅影响最终产出的商业价值的因素？比如互联网企业最容易发生的就是恶性竞争。本来很好的一个商业模式，会因为大量玩家入场最后变得无处逃生。那么怎么保障当某个大厂进入后，或者几十个初创公司入场后，我们的商业价值还能维持之前预估的水平呢？
第三个是人性视角。关于人性视角的考量，我们在法则二中详细讲解过，比如整个架构方案是否符合关键研发人员和目标用户的人性。
第四个是有限资源的视角。指的是你这个架构活动的最小必需资源是否能够到位，主要包括运营资源、研发资源和技术价值。
首先是资源视角下的运营资源。方案上线后，会有足够的运营资源来帮助项目冷启动吗？如果不存在这些运营资源，那么项目的预期产出还能保障吗？
其次是资源视角下的研发资源。企业内部还有什么正在筹划中的重大项目吗？影响相关研发团队在你这个项目中投入资源的因素有哪些？如果某个多方拼抢的资源不存在，那么项目的预期产出会发生重大变化吗？
最后是资源视角下的技术价值。假设你的项目是个技术驱动的项目，那么项目的长期技术价值有保障吗？在新技术、开源和SaaS化的大潮下，项目的技术价值还会长期存在吗？这些技术价值是你这个架构活动可以独立创造的，还是强依赖于其他项目？
假设是强依赖于其他项目这种情况，比如是全企业统一埋点、算法特征工程平台、统一的自动化测试框架，或者全企业的数据中台等技术项目。那么你会用什么办法来保障自己这个项目的价值创造？如果没有其他应用的支持，那么项目自身的价值则很难发挥出来。简单来说，就是“别当蒙古国的海军司令”。
最后是其他风险。相对于整个企业来说，你的架构活动是否需要特别关注监管风险、法律风险和安全隐私风险？有哪些风险会影响架构活动的可达性？
综上，从这些视角出发，我们对风险进行了较为完整的梳理。从中可以看出，我们在可行性探索过程中要思考的，都是那些可能会大幅降低一个架构活动预期价值的问题。这些问题，会决定我们是否要完全叫停整个架构活动，或者是对架构目标作出大幅修正。实际上，也只有这样的风险，才称得上重大风险。
我对我的团队有个硬性要求：从每个视角出发，梳理出来的重大风险最多不能超过三个。这个数量级非常重要。我们这个节点之所以叫做可行性探索，就是期望用最短的时间发现最大的风险，而不是要求你组织公司所有同事来做一个风险大扫除。
这里的关键动作有两个，分别是“最短的时间”和“最大的风险”。在我看来，不论是多大的互联网项目，如果你花了超过3个人日才发现上述风险，那么你作为项目的总架构师其实是不称职的。
还可以再举个很简单的例子。曾经有一个同学给我反馈项目中的重大风险，他竟然梳理出了1000多项风险，汇总成了一个有100多页的Excel。我当时都要崩溃了，尤其是看着他满心期待求表扬的表情时，实在是哭笑不得。
那么如何在最短时间内发现最大的风险呢？一方面要靠自己的判断，另一方面则要靠自己的关系网络。
你要找到之前在准备环节中就已经锁定的领域专家，把项目背景和情况描述出来，然后认真听取他的意见反馈。整理好之后，再带着这些答案，与风险决策建议者一起碰撞，试图发现更大的跨领域的风险。这个过程与访谈十分类似。每人每次大概是一个小时的样子。一般来说，覆盖一个大项目的所有视角，也就是十几个人。
我想特别强调的是，在这个访谈的过程中，你个人也要有大量的思考和价值创造。你需要不断综合多个视角的输入，并进行加工与提炼。这样的话，每一次的访谈，都是在之前访谈基础上的更高质量的思想碰撞。这种基于高质量的思想实验来迅速得出重大风险的工作方式，就是风险发掘的王道。
前面提到的靠大量地毯式搜索得出海量风险列表的过程，则是霸道。不但不高效，甚至是有害的。因为这种地毯式搜索，往往是你从其他人手中汇总而来的。那么得到的风险，往往局限在单个领域。一方面，你会被这种小小的满足所麻痹；另一方面，想要在大量的无效信息中找到真正的全局性风险，简直是难上加难！
发掘完重大风险后，还有一个不可忽略的收尾步骤，那就是最终要形成一个有综合排序的重大风险列表。需要注意的是，这个列表将是风险预估的主要输入，我建议数量最好不要超过5个。
风险敞口预估并不是传统的风险描述、分析、建模、预案设计和评估过程（时间较长），而更像是思想实验。你需要对产出的重大风险逐一梳理，确认某个预案在理论上是存在的，并确保预案实施之后的大致体验可以接受。而且，实施预案后的残余风险，仍然在赞助者可以承受的范围之内。
在这个阶段，你不需要真正实施并验证预案，仅仅确认预案存在且理论上可行，了解这个预案的预期用户体验就行了。
举个例子。假设你是年终大促的总架构师，其中有一个项目是支付营销项目。也就是使用某个支付渠道的用户会有个性化的额外折扣额，来帮助支付渠道以最低成本迅速拉新。但是这个项目现在有可能无法在大促前完成，那么你就需要确定预案了。
预案可以有很多种，不仅可能影响到最初的方案，而且实施成本的差异也会很大。就这个案例而言，现在有两个极端的预案，分别是：
第一种极端的降级体验根本不支持支付营销，而是给每个符合离线筛选条件的用户，推送一个只能通过这个支付渠道使用的购物券，靠用户主动选择支付渠道来激活这个券。而第二种极端的降级方式，可能是把在线的支付营销判断放在离线去做，把用户等级和支付营销的优惠额度存在一个分布式缓存里。然后在收银台调用这个缓存服务，来临时引导用户使用这个有折扣的支付渠道。
与原有的方案对比，也就是在首页、导购、搜索推荐全链路透出最低成交价格的个性化支付营销，这两种体验的转化效果肯定会更低。不过赞助者和决策者很有可能接受其中一种降级体验。这样一来，实施风险一下子就会降低很多。
就像我们做需求评估一样，整个风险敞口的预估只是对大致实施方法和大致体验有个描述，目的是确认的确有预案存在，而且其中一种路径是各方都可以接受的。
不过在风险评估的过程中，对于真正的风险敞口，你可能并不知情。比如刚才讲的支付营销项目，可能两家公司签订了对赌协议。如果拉新效果达不到预期，电商平台就要向支付渠道赔付一定数额的营销费用，那么风险敞口一下子就大了很多。
我们之前还提到了重大风险评估缺乏统一标准这种情况。每个风险的具体场景不同，所在领域也有很大的差异，因而很难用同一套标准来描述。我建议你用如下几个参数，来量化你面临的重大风险。然后再针对每个备选方案进行组合，最后给出预案被迫实施后的估计值：
总时间成本。
总人力成本。
总资金成本。
效果折损，也就是降级方案造成的商业价值或商业效果损失有多大。
用户体验损失。一个方法是，通过用户的复购率降低值来量化用户体验的损失。另外一个比较客观的量化方法，则是保障用户复购率持平所需要的额外的营销购物券的总成本。这样一来，你就可以把用户体验这样比较抽象的指标，量化成一个资金成本，只不过实施起来可能比较麻烦。
可以看到，在出具方案细节前，各个维度的参数都难以准确估算。好在我们不是做可行性分析，而是做可行性探索，因此只需要参数在数量级上合理就可以了。这个时候，大多数有经验的领域专家都能做出一个预估。比如针对第四个维度，他肯定无法回答“具体折损多少”这个问题。但对于“有几成折损”，你将会得到类似于“绝对不止一成折损，至少有三成、但不会超过五成”这样的回答。
经过预估后，你可能发现之前列出的最大的五个风险，现在已经不是最大的了。如果预案可以实施完成，那么这五个风险的等级就会下降。如果时间允许，你还可以再多看几个风险。
也许你会问，到底看几个才合适呢？我们在这个环节只有一个目标，就是发现那些有必要叫停项目或者大幅更改整个架构活动目标的风险，这才是所谓的重大风险。其他的风险，其实都是架构师要带领大家克服的困难。所以真正大到能叫停一个项目的风险，是很少的。从我的经验来看，一般一个项目最多也就两三个重大风险。
当梳理出重大风险后，不仅你这个架构师要持续关注，同时还要确保相关执行者也在持续关注。
风险预案涉及的不止是自己团队的成员，有些还涉及外部的合作渠道。比如支付营销、合作渠道、企业的支付部门、某个支付机构或者银行卡组织等等。他们也需要知晓你的风险情况、降级预案，以及可能对用户体验产生的影响。
当然，你没有权力来做这个同步风险的沟通，而是需要建议赞助者去这么做。 一方面，不通知合作方是个绑架行为。另一方面，合作方在知晓风险后，可能会帮你出主意，找到更好的解决方案。
你可能会问，如果支付渠道在知晓风险后撤回合作，那该怎么办？是的，这种情况的确存在。不过从我的经验来看，如果你主动分享自己遭遇的困难，那么得到帮助的可能性将远远大于被拒绝的可能性。
反之，我也见过有些架构师强行绑架合作方的做法。这种人的态度是：“反正最后只要我的量起来了，你还是得跟我玩。” 或许决策者可以做出这样极端的选择，但是你作为架构师，我认为根本不应该动这样的心思。背后的原因，我们在法则六里已经再三强调了，良知是架构师这个职能的必要条件。
最后是风险决策，这是可行性探索节点中最重要的一环。
在此之前，你已经收集了架构活动的重大风险和预案，也从全局上对风险有了比较深刻与全面的认知。收集、预估和排序的过程，其实也让你建立了一套全局性的风险评估标准。而且在风险评估的过程中，你肯定也收集到了决策者、赞助者和执行者的立场和风险承受度。
那么在最后的决策环节，就是将你收集到的重大风险、相应预案、参与者风险的承受度以及你所作出的建议，完整地表达出来。我想特别强调三点：
你需要站在决策者的视角上，作出一个对全局有利的决策建议，而不是从赞助者或者执行者的视角。
要敢于冒险。互联网时代，时间是最稀缺的资源，所以冒险相对而言是更为有利的选择，不冒险反倒是个不负责任的表现。
冒险要理智。作为架构师，你需要对重大风险发生后的用户体验损失、商业价值损失等，进行准确的数量级的评估。同时，也要对预案能挽回的部分有个预估。一旦冒险失败，你还可以用时间来弥补。
最终，在这些信息的基础上，你需要给出一个可行或者不可行的总建议。这里我也特别强调一下，“不可行”的建议是一个完全合理的选择，甚至也会是一个好的选项。
为什么我敢这么说呢？从我个人经验来看，不论国内还是国外，大的架构项目真正能取得成功的不过是十之一二。但是可行性探索呢，却几乎是十之八九都被跳过了。很明显，大家在这个能避免重大错误的最后防线上，做的工作太少了。
事实上，这与很多企业推行强执行的文化是分不开的。在这种企业里，个别给出“不可行”建议的人，会被打上“守旧”和“退缩”的标签，甚至丧失职业发展的机会。不过，多数企业还是能容忍讲真话的人的。那么我们作为架构师，应该如实传递风险，让决策者来做最终的选择。
当然，你也可以对架构目标的调整做出建议，尤其是风险主要来自交付压力的情况下。
当完成上述工作后，你会得到来自决策者的几乎所有输入。比如最终对架构活动是否可行的判断，对风险承受度的矫正，对预案的改进建议，以及对架构目标和交付时间的调整，等等。
针对这些输入，你需要整理成架构文档，完整录入并分享给团队成员。如果项目可行，那么在进入架构规划环节前，你就已经对重大风险有非常清晰的判断了。毫无疑问，这会大大提升整个架构活动的成功概率。如果项目不可行，我相信你在探索过程中积累的判断能力、开放的心态和全局性的思维，也会给你带来新的甚至是更大的机会。
我们这节课讲了可行性探索的整个过程。这个节点的重要价值在于你怎么帮助企业避免重大损失。在可行性探索的过程中，你需要站在赞助者的视角上，尽量发掘重大风险，寻找有效预案，确保项目目标最终的可达性。
这是所有节点上，最后一个能够以相对较低的成本来避免损失的机会了。这个过程，并不需要花费很多时间，也不需要很多人的参与。重要的是你和活动参与者把注意力放在重大风险上，以及可能会导致项目叫停的风险上。
在这个过程中，行王道的做法就是找到那些具备高质量思考和丰富经验的人，让他们从各自的视角出发去发掘重大风险。然后在他们思考的基础之上，你需要迅速迭代自己对风险的全局性思考，不断提升相应预案的质量。
在此之上，你还要形成完整的、全局的、量化的风险评估和重大风险列表，并及时与执行者、赞助者做沟通。最终，你需要站在决策者的视角上，以相对乐观和敢于冒险的心态，做出可行性的建议。需要格外注意的是，无论如何，架构师都不应该隐瞒风险，绑架其他参与者。
如果能做好这些准备工作，也与决策者确认项目确实可行。那么接下来，你就可以放心大胆地往前推进了。
三个思考题，任选一个：
如果这节课对你有帮助，欢迎把课程转发给你的同事或朋友。顺便打个小广告，我刚开了个人抖音号，我会定期发表一些比较新、但是不一定那么成熟的观点。欢迎在抖音上搜索“郭东白”并关注，也欢迎你的批评指正。我们下节课再见！