21 节点三：如何通过可行性探索来帮助架构活动避免重大失误？
你好，我是郭东白。从这节课开始，我们就进入到架构活动的第三个环节——可行性探索。
可行性探索是架构师帮助企业避免重大方向失误的最后一个节点。我们曾在法则二里分析过一家公司因为忽略可行性探索而导致重大损失的情况，那么今天这节课，我就来解释一下怎么通过有效的可行性探索环节，来避免这样的重大失误。在这个节点之后，架构活动就是离弦之箭，哪怕发现了重大错误，一般也很难停下来了。
互联网时代竞争非常激烈，决策和执行速度对于企业的生存来说至关重要，所以企业的可行性的探索是区别于其他行业的，需要“快”。不过，这是最容易变成走过场的一个节点，因为大多数人都不太擅长平衡决策速度与决策质量。所以期望通过这节课，你能认识到这个环节的重要性和正确做法，将可行性探索做到实处。
什么是可行性探索？
为什么要做可行性探索呢？我们之前提到过，架构活动往往都有很大的风险。以我的个人经验来看，能达到既定目标的架构活动还不到十分之一，多数架构活动都是以失败收场。
因而可行性探索的目的，就是让决策者和赞助者对架构目标是否可达，形成一个相对清晰的认知。
确认目标的可达（Achievable），也就是在企业的现有条件和时间约束下，目标最终可以被实现。任何架构活动都需要承受一定程度的风险，当某个风险确实发生的时候，这个目标实现的成本（时间、人力、计算成本等）虽然可能会增加，但目标依然可以在新的环境下被实现，而不是完全不可达。
请注意这里的“成本”。可行性探索的过程不同于可行性分析（Feasibility Analysis）。可行性分析是一个非常耗时、详尽的评估活动。然而互联网时代，重在行动，所以我们用“可行性探索”这个词，来特别强调在这个节点上要控制成本，尤其是时间成本。
总的来说，在可行性探索的过程中，架构师需要在最短时间内发现最重大的风险，并对风险发生时的响应预案做出判断。与此同时，架构师也需要把重大风险披露出来，向赞助方确认是否能接受风险和预案。
在互联网时代，可行性探索过程的王道就是从项目赞助者的视角出发，在赞助者的风险承受度之内做理智的冒险。
什么是风险？
这节课我们会反复提到风险，所以我先来简单定义一下风险这个概念。
我们在第16讲里提到过，在架构活动的上下文中，风险特指有可能带来损失的不确定事件。
不过很多人一听到“风险”，会下意识地觉得这是个完全负面的词，继而认为必须采取措施来控制或者最小化风险。其实对于一个架构师来说，风险更多时候是一个筹码。如果能正确使用这个筹码，将会为自己换来时间和成功。反之，如果用错了，也会让自己背上巨大的债务。
打个比方。可以想象一下，你在背包旅行的途中遇到了一条河。河水湍急，河边有一座似乎已经废弃的小吊桥。你现在面临两个选择：从吊桥上走过去，或者往下游再走十公里，那里有一座非常结实的公路桥。
如果冒险过小吊桥并成功，你将赢得半天多的时间。反之，如果掉到河里，那么极端情况下可能就会送命。过不过桥由你决定，所以是否冒险过桥就是握在你手里的筹码。你可以用掉这个筹码来换取时间，也可以选择绕路，放弃这个下注的机会。
对于一个架构师来说，做风险选择是你为数不多的权利之一。我们职业生涯中能换来大量资源的筹码其实没几个，如果不知道怎么去冒险，相当于浪费了上帝递到自己手里的筹码。而且，风险判断力不断提高的过程，也是一个架构师逐步走向资深的过程。
那么怎么才能作出正确的选择呢？这个问题比较抽象，如果把它拆解开来，其实是四个问题：
- 风险有多大？
- 回报是什么？
- 公司对风险承受度有多大？
- 其他的选项的风险和回报是什么？
有了这四个问题的答案，我们就可以着手准备可行性探索了。
可行性探索前的准备工作
通过之前的学习你会发现，在进入每个节点前我们都需要进行一些准备工作。同样的，在进入可行性探索之前，我们的准备工作就是在企业风险决策环境方面做调研。包括调查企业对风险的态度，赞助者对风险的承受度，锁定可以提供决策帮助的领域专家，等等。
老规矩，我需要先解释一些企业层面上的概念，因为架构师必须从全局上理解目标。
第一，调查企业对风险的承受度。不同企业对风险承受的差异非常大。有的企业鼓励冒险，有的企业则对失败的容忍度几乎为零，甚至会惩罚那些冒险的人。因而你的最终决策，必须与企业或者部门对待风险的态度相一致。
假设你在一个对风险几乎零容忍的部门里选择冒险，那就是在胁迫队友了。反之，如果你在一个对风险有高容忍度的部门里，却选择不冒险，那就是在拖公司的后腿了。需要注意的是，企业对风险承受的尺度大小没有对与错，仅仅是企业的选择。而你的选择，只需要控制在企业或部门的风险承受度以内即可，这是你选择冒险的上限。
第二，调查赞助者对风险的承受度。赞助者的风险承受度往往比企业或部门的承受度要小得多，因此这是你选择冒险的下限。
我一般会尽量说服赞助者去冒更大的险，但我也会尊重他的否决建议。这是我们作为架构师的道德底线。归根到底，用筹码下注的人是我们，但是买筹码的则是赞助者。如果不顾赞助者的反对，将他的钱财置于险地，那很可能会失去他对我们的信任。
第三，锁定领域专家。领域专家指那些可以预见单个领域风险，并提供应对方案的人。你期望通过他的经验来帮助自己迅速锁定重大风险，找到最佳的风险预案，并准确评估预案实施的代价。
需要格外注意的是，这个领域专家不能是重大利益的相关方，因为我们希望他能给出更为客观的建议。另外，领域专家不好找。找多了，可能会因为过于关注风险而做出保守的选择。我建议找一到两个专家就足够了。
第四，锁定风险决策的建议者。风险决策建议者这个角色，其实有点像法官。这个角色需要有全局的视角、有判断力、做事公正。你需要依靠他们的判断力，来提升自己的判断质量和决策质量。
与领域专家不同，这些建议者最好与部门利益绑定得比较深，但与架构活动的成败关系不大。我的经验是最好找四到五个决策建议者。人数太多，意义可能不大；人数太少，则可能导致视角不完整。
在准备工作的进行中，你肯定还会面临一系列的挑战，比较常见的几种情况有：
- 领域内部的视角非常狭窄，往往不能看到全局性的风险。哪怕是每个独立领域都没有风险，也不代表整个架构活动是可行的。
- 对可行性的估计没有任何全局标准。量化风险非常艰难，在“什么样的风险才算大”这个问题上，没有任何标准。
- 没有人愿意说“不”。大多数互联网公司都是勇大于谋，过于相信速度和规模效应。在路径选择上不够丰富，在拒绝诱惑上也不够果断。
明确了我们面临的挑战，也做好了准备工作，那么下节课我们就讲讲在这个节点上该如何行王道。也就是怎么从企业决策者和赞助者的视角出发，在风险承受度以内做出理智的冒险选择。
小结
回顾架构活动最初的两个环节，一个是搭建架构环境，目标是建设一个安全的决策环境。另一个是目标确认，目标是锁定架构活动的目标是否正确、合理和可达。
这是非常轻量的节点，除了架构师之外，公司还没有投入任何研发资源。这么做，一是依照我们之前讲过的尊重人性的原则。在进入可行性探索之前，将与这个架构活动绑定的人或利益降到最低。二是，这么做也满足我们之前讲过的最大化商业价值的原则。在正式锁定架构活动的可行性之前，将公司的资源消耗降到最低。
而到了可行性探索这个节点，就要充分利用公司里所有能帮助我们提升决策质量的资源，来确定整个架构活动的目标是可达的。这么做，不是让你变得保守，因为冒险不是一件坏事。反过来，冒险可能是一件会带来巨大回报的事情。因此，我们做的不是耗时数月的可行性分析，而是在冒险精神的支持下做好重大风险的挖掘。
具体怎么做，我们下节课会详细描述。不过在此之前，你首先需要对企业的风险决策环境有清晰的认知。
思考题
- 你参与过带有巨大冒险性质的架构活动吗？有没有获得什么回报呢？你认为决策者为什么能做出这样的判断呢？
- 你所在企业的风险决策环境是什么样的？这个决策环境与行业当下的竞争环境匹配吗？
- 请回顾你的职业历程，你有没有作出过非常保守的决策呢？现在后悔吗？假设你当时冒险了，你的职业命运会有什么不同？
如果这节课对你有帮助，欢迎把课程转发给你的同事或朋友。顺便打个小广告，我刚开了个人抖音号，我会定期发表一些比较新、但是不一定那么成熟的观点。欢迎在抖音上搜索“郭东白”并关注，也欢迎你的批评指正。我们下节课再见！
- 罗均 👍（6） 💬（1）
非常感谢老师提供的关于可行性探索准备工作的Framework，如果早些学习到，就不会碰那么多壁！ 最近学生刚好在推进一个自己认为风险极小的架构活动，不过除“赞助者”外，都认为有“巨大的风险”。最后是通过快速开发demo，测试数据到统计分析，用∂评估风险。目前仍然在等待决策者决策。 从这次遇到的阻力，学生总结的是：无论任何方案，都是有利有弊的。即使回报是给用户带了很好的体验，给企业带了更高的毛利。然而任何新的架构，都必然会损害老架构中组织或团队的利益，也就会触动之前课程提到的“马斯洛人性需求”，应该以谦逊为基础，尽一切可能去帮助他人。
2022-03-16 - 陈桐 👍（5） 💬（1）
有种大开大合搞架构畅快，但是都是公司刚开业，或者不计成本探索新业务。 但是总体不可行。 创业公司要第一时间接入外包，最快方式跑起业务获客。而不是技术架构。这是刚吃饱，才能首要做的事 探索新业务，调查各方风险承受度，也不可行。 甩给你一块新业务，就是要在有限资源，有限时间，目标不合理情况下，做出成绩，才有可能让你承接更大项目。 所以核心关键是MVP，技术架构最小可行性，产品核心点最小可行性，运营产出有限资源下最大化
2022-03-22 - kq yang 👍（5） 💬（1）
这边文章多处验证了组织的高阶理论。一个组织最后只能存留高层试图保留的意愿和风格。自下而上的东西要存留，如果不符合高层期望，是困难的。
2022-03-16 - williamcai 👍（2） 💬（1）
老师，问一个非专业问题，赞助者具体指哪些角色的人，决策者也有可能是赞助者
2022-12-15 - 咏晨桃 👍（2） 💬（1）
个人视角 我所在的部门对于开发制造的风险几乎零容忍
2022-03-15 - 花花大脸猫 👍（1） 💬（1）
第一个问题：最近临时去填一个需求，需求已经完成但是完全不符合用户的需要，修修补补实在没办法，产品以及架构都是新人去投入，那时候保交付优先的思想，所以做了很多定制化的工作，而且对于临时填的这个需求的业务背景以及上下文环境也了解的不够透彻，可想而知，后面就是为了定制而无休止的进行处理。这个事情给我带来的最大一个教训就是：千万要做好风险评估工作，如果自己确实接不了，没必要强接，不然本来不是你的问题，最后强行变成自己接锅了！！
2022-12-22 - 少年锦时 👍（1） 💬（1）
这期的图片怎么是剪纸的骷髅头。。这俩结合还是第一次见
2022-04-15 - 术子米德 👍（1） 💬（1）
🤔☕️🤔☕️🤔 * 📖：可行性探索，可以帮助架构活动避免重大失误 * 🤔：除非这事情做过，否则都存在说起来容易，做起来难，甚至极难的情况。自己的经验里，发现做是否能达到认识同步的可行性探索，比做技术可行的探索，要难得多得多。自己认为可行，在自己认知的框架和视角下，在某个瞬间感觉到信心满满。可是一旦开始推进工作，就会发现大家都在表面的信心满满之下，实际并没有对目标和过程有相同的认识，甚至一开始就心念不合，还一直勉强追赶节奏，这种出格的变扭感，只有一起走几步，一起探索一下，才会发现是否真的适合一起干下去。所以说到可行性探索，居然我先想到的是认识同步的可行性探索，不得不说，必定是我曾经掉进这样的坑里。这些掉坑经验带给我的教训就是，团队一开始的海誓山盟，不如一起在小路上走一段来得更加真情实意。 * 📖：冒风险的机会，是上帝给架构师的筹码，而风险判断力不断提高的过程，就是一个架构师逐步走向资深的过程。 * 🤔：曾经我有过这样的念头，在一个选择的关口，我做出选择时所面临的风险，实际上是回报的杠杆。而且这个念头我曾经在小团队试验过，当时的错觉是因为只有我说了算，所以我不得不这么去选择和决定。后来在较大的团队，反而把这个念头给整没了。觉得我把风险挑明，冒不冒风险不是我的事。现在看来，能识别出风险，算是我的基本能力，但是不去冒风险，可能是我被关在资深门外的重要原因。该如何能打开资深这扇门？绝对不是看到风险，就冒失去挥霍上帝的筹码吧？如果找到几个人，都认可这次得冒失点，必须去挥霍一次上帝出筹码，算是一把钥匙嘛？
2022-03-24 - spark 👍（1） 💬（2）
郭老师，take away~~~ 我最近负责了一个项目，根据我理解的公司战略意图，一些关键目标，可能有决策风险，我没告诉大家我的思考。设计了一个“坑”，让总裁和我，双线PK，同时执行A计划、和B计划。结果我也掉在“坑”里了，辞职干不下去。，有一个体会，战略意图，首先需要对应的思维方式支撑。一个架构师需要有很强的战略意图和相应的思维方式，不然结果会打折扣，A计划和B计划都失败~~~
2022-03-15 - 海鱼美味 👍（0） 💬（1）
风险和回报是伴生关系，高风险高回报，需要把风险降低到可接受的程度以内，不然就是赌博心理。
2022-08-31 - 小昭 👍（0） 💬（0）
理智的冒险。
2023-05-09