从价值交付的角度做 MVPU 拆分

关于目标分解这部分工作，我们需要从多个维度来进行。

首先是商业价值的视角。这个项目能为企业带来哪些重要的商业价值呢？度量这个商业价值的核心指标是什么？比如一个大促项目，比较重要的指标有 GMV、总订单数、总成交客户数、首次下单客户数、超过一定体量的成交商家数等。

其次是用户价值的视角。这个项目能为用户带来什么重要的价值呢？相应的指标是什么？同样是大促的例子，常规的度量用户价值的指标有新买家数、买家满意度、成交用户总数等。

近年来，国内大促项目的用户心智变得越来越淡，我认为核心原因就在于架构师很少关注用户价值的相关指标。大促购物真的有那么高的满意度吗？与去年相比，今年的订单件数、订单金额和访问频次有增长吗？

最后是技术价值的视角。这个项目能为企业带来哪些重要的技术价值？相应的指标是什么？同样还是大促的例子。每秒峰值订单数、机器人会话转人工率、大促会场转化率等，都是对企业技术能力的度量。

除此之外，还有一些其他的附加价值，比如商家增长、全链路履约容量提升、市场渗透、人才培养、技术影响力、企业的社会形象等。这些附加价值，往往不是我们发起项目的主要目的。不过有了这些附加价值，我们就可以从不同的价值维度上对项目做 MVPU 的拆分了。

有时候一个大促要准备好几个月，像阿里这样的公司，细分项目的数量都是以千计。但是细分到单个维度和单个场景，MVPU 就简单许多，比如通过一个反向招商的项目来提升 GMV。所谓反向招商，就是根据最近成交的订单，选取销量和满意度较高的商品。然后邀请这些商品背后的商家参加大促，将商品拿到大促上打折售卖。

平台呢，将会有一套数据驱动的商品圈选逻辑、一个活动报名页面，还有相关的商家推广计划，同时也会对预期的 GMV 贡献有一个估算。

不过这个估算有两个比较大的不确定性：

商家的意愿。有多少商家愿意把自己的爆品拿到大促上做深度的打折售卖？
用户的意愿。这些商品是否属于小众商品？小众商品意味着转化率在特定人群中较高，一旦放到大促主会场面对所有买家做推广，转化率就不一定能保障。

不过想验证这两个 MVPU，也没那么复杂，甚至都不需要开发商家的活动报名页面。只需要通过调研问卷的形式，就可以估算商家的参与意愿和最大折扣力度。而用户意愿，可以通过开发定制化的活动页面，给不同的用户群分别做投放，从而预测转化效率。

这是个常见的投放逻辑，开发这种定向的活动页面和相关的后端应用，在大促之外的其他场景下也可以复用。

同样，你可以用类似的逻辑来拆分会话机器人的项目，找到对应的 MVPU。反向招商项目和会话机器人项目完全不干扰，可以各自以独立的进度来做 MVPU 验证。事实上，大多数项目都是可以独立做 MVPU 拆分的，不需要和其他项目耦合。当然也有特殊情形，比如订单中心的研发可能跟很多项目都形成了耦合。不过即便如此，我们还可以分批次上线。

你可能会有疑惑，大促本来就是一个聚合型项目，这么做当然可以了。但如果是更底层的技术项目，比如多个 BU 之间的数据模型统一的项目，那该怎么办？在没统一之前，怎么度量统一之后的价值呢？其实这种架构统一的项目更好拆分，可以先在风险小、回报大的场景上做统一。一方面，参与方的动力足；另一方面，MVPU 的成本也低。

等做出来一两个案例并确认回报后，就可以固化方案和工具，并加速推广了。越做到后面，你的技术方案越健壮，接入就越容易。这时候不仅得到的回报变低了，实现成本也会降低，最终会得到一个比较高的渗透率。

反倒是一上来就起一个全员都参与的大项目，成本高、压力大，失败的概率也更大。在真正的竞争压力面前，这种 ROI 最大化的路径，是我经历过的最有效的项目推进方法。那种高举高打的方法，最终能获得预期效果的反倒不多。

假设你找到了多个维度的 MVPU 的目标和 KPI，那么下一步就要发挥你的架构师能力，来定义好交付路径了。

交付路径设计

架构师的价值就在于保障整个架构活动的结构性，以及交付顺序的合理性。因而在不破坏整体结构的前提下，我们需要尽早交付 MVPU。主要有如下三件事需要做：

梳理强依赖关系；
控制联调的成本和节奏；
把握速度和结构性之间的平衡。

如下图所示。多个 MVPU 和功能模块之间形成了网状关系，一个 MVPU 是它所有强依赖的组合。很明显，这是一个树结构的遍历问题。

顺便说一句。正如我之前分享的性能优化的案例。我个人喜欢先做 ROI 最大的项目，投入少、验证简单，未来还可以逐步投入人力再做工具的打磨和优化。在这个过程中，我一般不太考虑风险的大小。我的逻辑是，高回报永远伴随着高风险。既然迟早都要面对风险，还不如早点面对，这样自己还能有更多的思考时间，避免走太多弯路。

在这里插入图片描述如上图所示。1 是整个架构活动的目标，a、b、c 是三个 MVPU，它们各自依赖的交付任务由带箭头的线来表示。比如对于 MVPU a 来说，任务 2 是它的强依赖，而任务 3 是它的弱依赖。

一个 MVPU 是一个树状结构，比较容易计算总交付成本和交付时长。其中 c 节点与整个架构活动的目标无关，它只是附属在架构活动上的一个“小确幸”，不应该作为 MVPU 的选择。如果说一个节点始终没有通向节点 1 的路径，那么这些节点可以看作技术的自嗨任务，应该砍掉，或者作为低优先级任务。

如果要交付 MVPU，那就需要跟团队同学提前做联调。很多技术同学非常讨厌中途停止编码去配合其他团队做联调，所以我们不能把 MVPU 的交付做得过于频繁。我的建议是在两周到一个月之间。因为大项目的联调成本很高，交付过于频繁会打乱研发节奏。但是如果超过一个月还没有交付任何的 MVPU，积攒的风险就会变得很高。

最后是把握速度和结构性的平衡。还是拿性能优化的项目来举例。我们第一个 MVPU 的交付完全没有考虑结构性，只想看清楚价值是否成立。确定价值成立后，我们才开始设计更稳定的架构。

当然，如果是个重构项目，这么做就有点激进了。整个架构活动的结构性和价值交付，跟我们确定的交付路径的价值最大化，就是一对互相冲突的矛盾。在互联网企业里，架构师始终面临一个现实的问题——架构活动是随时可以被抢占的。事实上，的确也应该被抢占。所以这两个目标之间是在博弈。

也就是说，在一个 MVPU 带来的小确幸、项目的整体结构性、最终目标这三个选项中，哪个更重要？关于这个问题，我们在法则一就给出了答案：先提升最终目标的成功概率。

如果只有一份资源，那么到最终目标最短路上的强依赖必须要先完成。而那些与最终目标没有形成依赖关系的小确幸，只能算是附加提案，是大架构活动的一个伪需求，应该舍弃。至少不需要放在你的注意力范围之内。

交付跟踪与路径调整

在交付的过程中，你还需要跟踪每个任务的进度，把实际观察到的结果跟 MVPU 的目标反复做校准。任务进度的跟踪属于项目管理层面的问题，这里不做更多的解释。我们主要讨论 MVPU 的目标达成情况。

多数时候，你会发现目标没有达到预期，这是很正常的。我们的假设往往过于乐观，逻辑也不够严谨。这是个非常重要的决策点。因此我们必须寻找目标不满足预期的原因，看看问题出在哪里，是否有解。

比如用户转化率远低于预期，那么研发人员、 BI 分析师、用户调研员、市场分析师都可以来帮忙寻找根因。在这个过程中，技术人员可能会发现设计和算法实现的问题，营销人员可能会发现营销发案的设计问题，用户调研人员会发现用户群的定位偏差，等等。不过无论如何，这个排查过程都会影响交付的进度，这也是为什么有些项目选择不做拆分的理由。

不过我们既然选择了分阶段交付，那么这些排查就是有必要的。举个例子，我曾经经历过一个叫 SABbc 的项目。控货商 A 从供应商 S 那里拿货，卖给跨境的进口商批发商 B。批发商 B 再卖给零售商 b，最后零售商 b 卖给了终端用户 c。

这么长链路的商业模式，注定了会失败。不过在老板的压力下，大家还是硬着头皮冲上去了。项目 Owner 还是比较聪明的，他先做了 S2A 的环节，很快就发现找不到愿意拿货的控货商 A。因为这是一环套一环的长链路，其中一环失败了，整个链路都会失败。不过老板还是坚持继续尝试，只不过尝试的范围和投入都大幅缩小了。

结果呢，好几百人日的大项目，最终上线跑了两个多月，得到的订单收入还不够给参与项目的研发人员每人买一杯咖啡。不过，也多亏项目 Owner 先做了 S2A 的环节。虽然项目失败了，但最终的浪费比之前的规划小了一个倍数。

这个例子比较有代表性。在一个大公司里，哪怕做分阶段的交付，也很少有架构活动会在一个 MVPU 上线效果不满足期望的时候，选择立即停下来。大多数时候，在一些人员排查问题时，项目组的其他成员还在持续交付。你可能会问，既然这样，为什么还要耗费时间做分阶段交付呢？

因为这个发现和后续排查的动作，其实给了整个决策团队一个调整的机会。很多因素都会影响项目的结果，比如用户没有意愿，或者是商业模式不成立。这两种情况非常棘手，要做大范围的目标或产品方案的调整。

但是其他因素，比如产品细节和技术实施问题、竞争对手的干扰、合作伙伴出现问题和用户恶意行为等，都有很多应对方案。越早发现问题，就越有时间来调整，从而提升最终的成功概率。

比较好的例子是与第三方供应商深度合作。如果在项目初期就请一两个供应商参与，以最简易的方式完成集成，然后迅速进入试运营，那么考虑不周的设计很快就会暴露出来。这么做，虽然会延长整个项目的交付时长，但是重大风险，在全面上线之前几乎都排查得差不多了。

这里有一点需要稍微注意一下。架构师往往没有权力去调整整体的项目计划和上线节奏，一般要由决策者来拍板。