您现在的位置是：首页 >技术杂谈 >架构阶段性交付前的准备工作网站首页技术杂谈

阶段性交付进入准备工作，主要有如下三个方面。

1. 阶段性 MVPU：从目标用户的视角看，最小可用的价值单元是什么？用户是如何感知到这个功能的价值的？
2. 阶段性目标：用什么量化指标来度量这个功能的价值？如何通过 A/B 测试来验证这部分的价值？要知道，做拆分的主要目的就是尽早拿到一个结论性的量化评估。
3. 最短路径：在不破坏项目结构的前提下，交付 MVPU 的强依赖是什么？这是我们架构师必须给出的答案。当然，强依赖可能包括一些非技术的依赖，比如招募参与前期实验的商家、营销费用和培训内部运营人员等。

在准备工作的过程中，还会有下面四个方面的挑战。

1、项目的原子性

有些人非常反对对架构活动做拆分。一方面认为项目是一个整体，只有项目完全交付之后，项目的价值才能体现出来。另一方面，则是担心将价值较大的项目拆分后，剩下那些价值较小的项目就可能烂尾。

对于前者，很少见到一个完全不可拆分的项目。哪怕是合并部署这样的项目，也可以先合并部署最大、最相关的两个应用，看看真实效果和难度。

对于后者，这种考量的确成立。有些价值不够高的项目永远没人管，比较常见的就是网关。人人都需要，但是放在自己的团队中，怎么做都不划算。哪怕是专职的网关团队，也并不想支持，因为网关是最难量化到商业增值的。

对于这种情况，建议专门起一个项目来做网关改造，而不是把网关项目附着在另外一个大的项目上。

2、项目的最小化浪费

很多架构师认为拆分会浪费测试和联调资源。的确，拆分之后，联调和上线成本会增加不少。但这是一个基于总成本的决策问题。

如果说整个项目大概率会失败，那么拆分其实是明智的选择，至少可以避免更大的浪费，或者挽救一些有价值的子项目。我们做 MVPU 拆分，想解决的主要问题就是减少缺乏提前验证而导致的浪费，而不是减少提前验证带来的浪费。

3、项目的大规模验证

有一种说法是“没有规模化部署之前，得出来的结论不靠谱。哪怕提前验证，得出的结论也是错误的”。这种说法在某些大数据和氛围烘托的场景下的确有一定的道理，比如双十一大促和春晚红包。

越是大规模投入的场景，越是要对底层逻辑做验证。有很多非常失败的玩法，完全可以通过小规模验证来避免。而且多数时候，产品逻辑、营销效果、人群行为的验证，都可以拆分开，并不是每个子项目都要在全量数据之下才能验证的。

4、项目的探索空间

项目本身是高风险的，太早验证，得到的负面结论会让赞助者丧失信心，项目很容易被取消。

这个担心的确有根据，尤其是在大公司里。但是我觉得这是架构师与赞助者期望设定的问题。架构师的命运是与公司深度绑定的，而不是绑定在项目上。我们跟赞助者都是在一个高风险的赛道上寻求长期回报，所以都应该做好失败的准备。做互联网很少有江郎才尽的时候，重要的是尽早发现自己的弱点，并快速迭代招数。

对于一个架构师来说，正确决策比持续努力更重要。

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