架构中保障交付关键动作之降低不确定性

不确定性的来源有多个方面。首先是目标的不确定性。这主要是赞助方对目标的不确定而导致的。

第二是资源的不确定性。这是互联网时代架构师所面临的最大挑战。无论是国内还是国外的互联网企业，往往通过类似于虚拟机超卖的方案去刺激团队的产出。

企业往往会同时有多项研发活动，而企业的整体研发资源不足以完成分配给所有研发活动的任务。那么架构师就必须在有限的研发资源池里争抢份额，以保障架构活动的交付。

两个生存法则是必要条件：确保架构活动的目标正确，以及最大化项目的商业价值。这是王道。当然，还有其他法则要遵守。

比如尊重人性，发掘参与者的利益诉求，最大化参与者的个人投入度。否则当架构目标与参与者个人及其团队利益并不完全一致时，就需要投入额外的激励来保障他们的投入度。

除技术资源外，还有运营资源、办公环境等等也是有限的资源，我们需要与合作的项目经理来保障这些资源是充足的。项目上线后，相关功能在多个场景下的入口流量保障（首页、搜索、推荐、大促承接页、详情页等），对于项目的成败也至关重要。

其实在互联网的研发环境下，只要是有限的资源，最终都会变成稀缺资源。发布窗口、物理机、计算资源、算法、A/B 测试，都可能成为意想不到的交付障碍。就像协调多数人参与的时间窗口资源，经常是大企业里架构项目的瓶颈。

第三，商业与技术环境的不确定性。最好的办法就是在缩短阶段性交付周期的同时，增加技术方案的抽象性。缩短阶段性交付周期，怎么理解呢？在一个大项目的初期，无论是架构师还是其他参与者，对项目的理解都比较有限。如果把架构活动拆分成多个阶段性的交付点，在线上看反馈。那么我们就可以根据线上数据来看商业或技术环境变化对架构目标、商业效果的影响，而不是凭空猜测。

增加技术方案的抽象性，指的是尽量提升 API 设计对技术选型的鲁棒性，也就是提升接口和模型设计的抽象性。那么在之后的交付阶段，我们就能对次优的技术选型做更正或者升级。

第四，用户需求的不确定性。指用户需求与我们的期望不一致，或者用户需求随着时间发生了较大变化。

应对方案除了从人性出发的设计思考外，还可以基于增量价值来交付单元。通过线上用户的真实行为来判断用户需求是否与之前的调研一致，同时根据预期行为偏差和效果分析，来决定是否需要对用户体验做出调整。

除了上述因素外，还有文化环境、组织结构等其他不确定性因素存在，不过它们很少在架构活动期间发生巨大变化，我们就不需要做相应的应对策略了。

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