你好，我是郭东白。上节课我们讲了为什么要做阶段性的价值交付，以及进入阶段性价值交付环节的准备工作。有了这些学习基础，这节课我们就可以进行阶段性价值交付了。
在交付的过程中，主要有三部分工作：目标分解、定义交付路径，以及项目交付跟踪与路径调整。
从价值交付的角度做 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 上线效果不满足期望的时候，选择立即停下来。大多数时候，在一些人员排查问题时，项目组的其他成员还在持续交付。你可能会问，既然这样，为什么还要耗费时间做分阶段交付呢？
因为这个发现和后续排查的动作，其实给了整个决策团队一个调整的机会。很多因素都会影响项目的结果，比如用户没有意愿，或者是商业模式不成立。这两种情况非常棘手，要做大范围的目标或产品方案的调整。
但是其他因素，比如产品细节和技术实施问题、竞争对手的干扰、合作伙伴出现问题和用户恶意行为等，都有很多应对方案。 越早发现问题，就越有时间来调整，从而提升最终的成功概率。
比较好的例子是与第三方供应商深度合作。如果在项目初期就请一两个供应商参与，以最简易的方式完成集成，然后迅速进入试运营，那么考虑不周的设计很快就会暴露出来。这么做，虽然会延长整个项目的交付时长，但是重大风险，在全面上线之前几乎都排查得差不多了。
这里有一点需要稍微注意一下。架构师往往没有权力去调整整体的项目计划和上线节奏，一般要由决策者来拍板。
完成阶段性交付
整个交付过程就是逐个遍历之前的 MVPU 树，最终完成整个架构的目标。我们已经描述得很清晰了，这里就不再赘述。
小结
我们这节课讲了怎么从架构师视角来组织阶段性的价值交付。这个过程，其实在最大程度上保护了活动参与者和赞助者的利益。哪怕架构活动不能满足预期，但是一个真正有价值的 MVPU 却是可以独立存活的，从而减少项目的浪费。
在这种交付方式之下，我们是随着时间逐渐交付用户价值的，而不是把所有的系统集成置后，在架构活动交付的最后期限才来一个系统大集成。在互联网时代，这么做的好处是显而易见的：给自己和团队赢得了宝贵的试错机会和调整方案的时间。
原本这应该是项目交付的一个基本原则，但国内的大公司却很少这么做。原因很简单，很多大公司设定的项目交付日期本来就不合理。排期就是一个决策者一句话压下来的，所有人都知道完不成，但大家都认为自己团队可以逃脱木桶最短板的命运。所以人人都硬着头皮接了下来。
结果就是无论团队任务重不重，能集成的最早日期，就是整个架构活动的上线日期。日子一到，多数团队都没有准备好，所以一上线就掉链。这种做法的伤害极大，不仅影响整个项目，还会破坏公司的整体文化。
通过这节课，我期望你能意识到最小价值交付单元方法的优势，也希望你能在自己主导的项目中认真尝试一下。我相信它会带给你不一样的惊喜！
思考题
三个思考题，任选一个作答。
你有没有碰到非常成功的 MVPU？这个 MVPU 为企业带来了哪些价值呢？
有的项目自始至终都没有度量过商业价值、用户价值和技术价值。你参与过这种佛系的项目吗？参与这种项目的感受是什么？轻松、意外，还是失落？
请你估算一下，在你参与过的项目中，MVPU 占项目总投入的比例大概是多少？可以描述一下项目背景，并给出以人日计算的大致成本。