架构中保障交付关键动作之降低不确定性-Toy模板网

这篇具有很好参考价值的文章主要介绍了架构中保障交付关键动作之降低不确定性。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

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

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

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

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

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

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

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

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

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

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

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

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