架构中重大风险的发掘过程

需要从多个视角对重大风险做一个全面的挖掘。

1、项目交付的视角

在当前交付时间的约束之下，是否会出现研发动作和设计完全变形的状况？当前的时间要求和资源投入，能否产出质量上可以接受的实施方案？也就是说，实施方案是否高于质量底线？多个参与项目的团队能否有效协同？我们是否留出了足够的时间，让团队去处理集成中出现的问题？

2、商业价值的视角

是否存在会大幅影响最终产出的商业价值的因素？比如互联网企业最容易发生的就是恶性竞争。本来很好的一个商业模式，会因为大量玩家入场最后变得无处逃生。那么当某个大厂或者几十个初创公司入场后，怎么保障我们的商业价值还能维持之前预估的水平呢？

3、人性视角

关于人性视角的考量，比如整个架构方案是否符合关键研发人员和目标用户的人性。

4、有限资源的视角

指的是你这个架构活动的最小必需资源是否能够到位，包括运营资源、研发资源和技术价值。

首先是资源视角下的运营资源。方案上线后，会有足够的运营资源来帮助项目冷启动吗？如果不存在这些运营资源，那么项目的预期产出还能保障吗？

其次是资源视角下的研发资源。企业内部还有什么正在筹划中的重大项目吗？影响相关研发团队在你这个项目中投入资源的因素有哪些？如果某个多方拼抢的资源不存在，那么项目的预期产出会发生重大变化吗？

最后是资源视角下的技术价值。假设你的项目是个技术驱动的项目，那么项目的长期技术价值有保障吗？在新技术、开源和 SaaS 化的大潮下，项目的技术价值还会长期存在吗？这些技术价值是你这个架构活动可以独立创造的，还是强依赖于其他项目？

假设是强依赖于其他项目这种情况，比如是全企业统一埋点、算法特征工程平台、统一的自动化测试框架，或者全企业的数据中台等技术项目，你会用什么办法来保障自己这个项目的价值创造呢？如果没有其他应用的支持，项目自身的价值就很难发挥出来。简单来说，就是“别当蒙古国的海军司令”。

最后是其他风险。相对于整个企业来说，你的架构活动是否需要特别关注监管风险、法律风险和安全隐私风险？有哪些风险会影响架构活动的可达性？

综上，从这些视角出发，我们对风险进行了较为完整的梳理。从中可以看出，我们在可行性探索过程中要思考的，都是那些可能会大幅降低架构活动预期价值的问题。这些问题，会决定我们是否要完全叫停整个架构活动，或者是对架构目标作出大幅修正。实际上，也只有这样的风险才称得上重大风险。

从每个视角出发，梳理出来的重大风险最多不能超过三个。这个数量级非常重要。这个节点之所以叫做可行性探索，就是期望用最短的时间发现最大的风险，而不是组织公司所有同事来做一个风险大扫除。

此文章为5月Day11 学习笔记，内容来源于极客时间《郭东白的架构课》，推荐该课程。