你好，我是郭东白。从这节课开始，我们就进入到架构活动的第三个环节——可行性探索。
可行性探索是架构师帮助企业避免重大方向失误的最后一个节点。我们曾在法则二里分析过一家公司因为忽略可行性探索而导致重大损失的情况。那么今天这节课，我就来解释一下怎么通过有效的可行性探索环节，来避免这样的重大失误。在这个节点之后，架构活动就是离弦之箭，哪怕发现了重大错误，往往也很难停下来了。
互联网时代竞争非常激烈，决策和执行速度对于企业的生存来说至关重要，所以企业的可行性的探索，是区别于其他行业的，需要“快”。不过，这是最容易变成走过场的一个节点，因为大多数人都不太擅长平衡决策速度与决策质量。所以期望通过这节课，你能认识到这个环节的重要性和正确做法，将可行性探索做到实处。
为什么要做可行性探索呢？我们之前提到过，架构活动往往都有很大的风险。以我的个人经验来看，满足既定目标的架构活动还不到十分之一，多数架构活动都是以失败收场。
因而可行性探索的目的，就是让决策者和赞助者对架构目标是否可达，形成一个相对清晰的认知。
确认最终目标的可达（Achievable），也就是在企业的现有条件和时间约束下，目标最终可以被实现。任何一个架构活动都需要承受一定程度的风险，当某个风险确实发生的时候，这个目标实现的成本（时间、人力、计算成本等）虽然可能会增加，但目标依然可以在新的环境下被实现，而不是完全不可达。
请注意这里的“成本”。可行性探索的过程不同于可行性分析（Feasibility Analysis）。可行性分析是一个非常耗时、详尽的评估活动。然而互联网时代，重在行动，所以我们用“可行性探索”这个词，来特别强调在这个节点上要控制成本，尤其是时间成本。
总的来说，在可行性探索的过程中，架构师需要在最短时间内发现最重大的风险，并对风险发生时的响应预案做出判断。与此同时，架构师也需要把重大风险披露出来，向赞助方确认是否能接受风险和预案。
在互联网时代，可行性探索的过程的王道就是从项目赞助者的视角出发，在赞助者的风险承受度之内选择做理智的冒险。
这节课我们会反复提到风险，所以我先来简单定义一下风险这个概念。
我们在第16课里提到过，在架构活动的上下文中，风险特指有可能带来损失的不确定事件。
不过很多人一听到“风险”，会下意识地觉得这是个完全负面的词，继而认为必须采取措施来控制或者最小化风险。其实对于一个架构师来说，风险更多时候是一个筹码。如果能正确使用这个筹码，将会为自己换来时间和成功。反之，如果用错了，也将会让自己背上巨大的债务。
打个比方。可以想象一下，你在背包旅行的途中遇到了一条河。河水湍急，河边有一座似乎已经废弃的小吊桥。你现在面临两个选择：从吊桥上走过去，或者往下游再走十公里，因为那里有一座非常结实的公路桥。
如果冒险过小吊桥并成功，你将赢得半天多的时间。反之，如果掉到河里，那么极端情况下可能就会送命。过不过桥由你决定，所以是否冒险过桥就是握在你手里的筹码。你可以用掉这个筹码来换取时间，也可以选择绕路，放弃这个下注的机会。
对于一个架构师来说，做风险选择是你为数不多的权利之一。我们职业生涯中能换来大量资源的筹码其实没几个，如果不知道怎么去冒险，那么相当于浪费了上帝递到你手里的筹码。而且，风险判断力不断提高的过程，也是一个架构师逐步走向资深的过程。
那么怎么才能作出正确的选择呢？这个问题比较抽象，如果把它拆解开来，其实是四个问题：
风险有多大？
回报是什么？
公司对风险承受度有多大？
其他的选项的风险和回报是什么？
有了这四个问题的答案，我们就可以着手准备可行性探索了。
通过之前的学习你会发现，在进入每个节点前我们都需要进行一些准备工作。同样的，在进入可行性探索之前，我们的准备工作就是在企业风险决策环境方面做调研。包括调查企业对风险的态度，赞助者对风险的承受度，锁定可以提供决策帮助的领域专家，等等。
老规矩，我需要先解释一些企业层面上的概念，因为架构师必须从全局上理解目标。
第一，调查企业对风险的承受度。不同企业对风险承受的差异非常大。有的企业鼓励冒险，有的企业则对失败的容忍度几乎为零，甚至会惩罚那些冒险的人。因而你的最终决策，必须与企业或者部门对待风险的态度相一致。
假设你在一个对风险几乎零容忍的部门里却选择冒险，那就是在胁迫队友了。反之，如果你在一个对风险有高容忍度的部门里，却选择不冒险，那就是在拖公司的后腿了。需要注意的是，企业对风险承受的尺度大小，没有对与错，仅仅是企业的选择。而你的选择，只需要控制在企业或部门的风险承受度以内即可，这是你冒险的上限。
第二，调查赞助者对风险的承受度。赞助者的风险承受度往往比企业或部门的承受度要小得多，因此这是你冒险的下限。
我一般会尽量说服赞助者去冒更大的险，但我也会尊重他的否决建议。这是我们作为架构师的道德底线。归根到底，用筹码下注的人是我们，但是买筹码的则是赞助者。如果不顾赞助者的反对，将他的钱财置于险地，那很可能会失去他对我们的信任。
第三，锁定领域专家。领域专家指那些可以预见单个领域风险，并提供应对方案的人。你期望通过他的经验来帮助自己迅速锁定重大风险，找到最佳的风险预案，并准确评估预案实施的代价。
需要格外注意的是，这个领域专家不能是重大利益的相关方，因为你希望他能给出更为客观的建议。另外，领域专家不好找。找多了，你可能会因为过于关注风险而做出保守的选择。我建议找一到两个专家就足够了。
第四，锁定风险决策的建议者。风险决策建议者这个角色，其实有点像法官。这个角色需要有全局的视角、有判断力、做事公正。你需要依靠他们的判断力，来提升自己的判断质量和决策质量。
与领域专家不同，这些建议者最好与部门利益绑定比较深，但与架构活动的成败关系不大。我的经验是最好找四到五个决策建议者。人数太多，意义可能不大；人数太少，则可能导致视角不完整。
在准备工作的进行中，你肯定还会面临一系列的挑战，比较常见的几种情况有：
领域内部的视角非常狭窄，往往不能看到全局性的风险。哪怕是每个独立领域都没有风险，也不代表整个架构活动是可行的。
对可行性的估计没有任何全局标准。量化风险非常艰难，在“什么样的风险才算大”这个问题上，没有任何标准。
没有人愿意说“不”。大多数互联网公司都是勇大于谋，过于相信速度和规模效应。在路径选择上不够丰富，在拒绝诱惑上也不够果断。
明确了我们面临的挑战，也做好了准备工作，那么下节课我们就讲讲在这个节点上你该如何行王道。也就是怎么从企业决策者和赞助者的视角出发，在风险承受度以内，选择理智地冒险。
回顾架构活动最初的两个环节，一个是搭建架构环境，目标是建设一个安全的决策环境。另一个是目标确认，目标是帮助你锁定架构活动的目标是否正确、合理和可达。
这是非常轻量的节点，除了你之外，公司还没有投入任何研发资源。这么做，一是依照我们之前讲过的尊重人性的原则。在进入可行性探索之前，将与这个架构活动绑定的人或者利益降到最低。二是，这么做也满足我们之前讲过的最大化商业价值的原则。在正式锁定架构活动的可行性之前，将公司的资源消耗降到最低。
而到了可行性探索这个节点，你就要充分利用公司里所有能帮助你提升决策质量的资源，以确定整个架构活动的目标是可达的。这么做，不是让你变得保守，因为冒险不是一件坏事。反过来，冒险可能是一件会带来巨大回报的事情。因此，我们做的不是耗时数月的可行性分析，而是在冒险精神的支持下做好重大风险的挖掘。
具体怎么做，我们下节课会详细描述。不过在此之前，你首先需要对企业的风险决策环境有清晰的认知。
如果这节课对你有帮助，欢迎把课程转发给你的同事或朋友。顺便打个小广告，我刚开了个人抖音号，我会定期发表一些比较新、但是不一定那么成熟的观点。欢迎在抖音上搜索“郭东白”并关注，也欢迎你的批评指正。我们下节课再见！