郭东白的架构课_41_31_节点六_如何组织阶段性的价值交付
你好，我是郭东白。
在阶段性交付的过程中，主要有三部分，工作目标分解定义、交付路径以及项目交付跟踪和路径调整。
我们先来讲目标分解，看怎么从多个维度来分解项目的价值。
首先是商业价值的视角，这个项目能为企业带来哪些重要的商业价值呢？度量这个商业价值的核心指标是什么？比如说一个大促项目，比较重要的指标有GMV总订单数、总成交客户数，还还有首次下单客户数，以及超过一定体量的成交商家数。
其次是用户价值的视角。
这个项目能为用户带来什么样的重要价值呢？相应的指标是什么？同样是大促的例子，常规的度量用户价值的指标有新买家数、买家满意度、成交、用户总数等。
近年来，国内大促项目的用户心制变得越来越大我，认为核心原因就在于架构是很少关心用户价值的相关指标。
大促真的有那么高的满意度吗？跟去年相比，今年的订单件数、订单金额，还有访问频次有什么增长吗？最后呢是技术价值的视角。
这个项目能为企业带来哪些重要的技术价值？相应的指标是什么？同样是大促的例子，每秒分值、订单数、机器人、绘画转人功率、大促会场转化率等等，都是企业技术能力的度量。
除此之外呢，还有一些其他的附加价值，比如说商家增长、全链路、履约容量提升，市场渗透，还有人才培养技术影响力，企业的社会形象等等。
这些附加价值往往不是我们发起项目的主要目的。
不过有了这些附加的价值，我们可以把项目从不同的价值维度上做MVPU的拆分了。
有时候呢一个大促要准备好几个月，像阿里这样的公司呢，细分项目的数量都是以千计的。
但是细分到单个维度和单个场景MVPU就简单很多了。
比如说通过一个反向招商的项目来提升GMV.所以反向招商，也就是根据反新成交的订单选取销量和满意度都比较高的商品，然后邀请这些商品背后的商家参加。
大促把商品拿到大促上打折售卖。
那么平台呢有一套数据驱动的商品圈选逻辑，一个活动报名页，还有相关商家的推广计划，同时呢也会对预期的GMV贡献有个估算。
不过这个估算呢有两个比较大的不确定性。
一个呢是商家的意愿，有多少商家愿意把自己的爆品拿到大促上，做深度打折售卖呢？另一个是用户的意愿。
这些商品呢是不是属于小众商品？小众商品意味着转化率在特定人群中比较高，一旦放到大促主会场。
面对所有的买家做推广，转化率就不一定能保障。
不过想验证这两个MVPU也没那么复杂，甚至都不需要开发商家活动。
报名页面只需要通过调研问卷的形式，就可以估算商家参与的意愿和最高折扣力度。
而用户的意愿呢可以通过开发人群定制化的活动页面，给不同的用户群分别做投放，从而预测转化效率。
这是呢是个非常常见的投放逻辑，开发这种定向的活动页面和相关的后端应用，在大促之外的其他场景呢也可以复用。
同样呢你可以用类似的逻辑呢来拆分，会化机器人的项目，到对对应的用PU反向招商的项目和绘画集成的项目，目全不干扰扰，可以以各的进度做MVPU验证。
事实上呢大多数项目都可以独立做MVPU拆分的，不需要和其他项目耦合。
当然呢也有特殊情形，比如说订单中心的研发可能跟很多项目都形成了耦合。
不过即使是这样，我们还可以分批次上线，你可能会有疑惑。
大促呢本来就是一个聚合型的项目，这么做当然可以了。
但如果是更底层的技术项目，比如说多个BU之间的数据模型，统一的项目，那该怎么办呢？在没统一之前呢，怎么度量统一之后的价值呢？其实这种架构统一的项目更好拆分，你可以先在风险小回报大的场景上做统一。
一方面呢餐与方的动力足，另外一方面呢MVPU的成本也比较低等，做出了一两个案例并确认回报之后呢，你就可以固化方案和工具，然后加速推广了。
越做到后面你的技术方案越现状，接入呢就越容易。
这时候不仅得到了回报变低了，实现成本也会降低，最终呢还会得到一个比较高的渗透率。
反倒是呢一上来就起一个全员都参与的大项目成本高，压力大，失败的概率也更大。
在真正的竞争压力前面，这种ROI最大化的路径是我经历过最有效的项目推进办法。
那种高举高打的办法呢，最终拿到真实效果的反倒不多。
假设呢你找到多个维度的MVPU的目标和KPI.那么下一步呢你就要发挥你架构师的能力来定义好交付路径了。
架构式的价值呢就在于保障整个架构活动的结构性以及交付顺序的合理性。
所以呢在不破坏整体结构的前提下，我们需要尽早交付MVPU.主要呢有三件事情需要做，一呢是梳理强依赖关系，二是控制联调、成本和节奏。
三呢是把握速度和结构性之间的平衡。
我在文档里呢放了一张图，图里呢就展示了这个交付路径，多个MVPU和功能模块之间形成了网状关系。
一个MVPU呢是它所有强依赖的组合，很明显这是一个树结构的便利问题。
就像我们之前分享的性能优化案例，我个人呢喜欢先做ROI最大的题题投入验验，简简未未来呢可以逐步投入人力，再工工具，强磨磨优优化。
在个过程中呢我一般不太考虑风险的大小。
我的逻辑呢是这样的，高回报永远伴着高风险。
既然是迟早都要面对的风险，还不如早点面对，而自己呢也会有更多的思考时间，避免走太多弯路。
我呢再来解释一下这张图的内容呢，你图里面呢一呢是整个架构活动的目标。
Abc呢是三个MAPU,他们各自依赖的交付任务，有带箭头的线来表示。
比如说对MAPUA来说呢，任务二呢是它的强依赖。
任务二呢是它的弱依赖。
一个MVPU呢是一个树状结构，比较容易计算总交付成本和交付时长。
其中c节点跟整个架构活动的目标呢没有关系，它呢只是附属在架构活动上的一个小确性。
N应该呢作为MAPU的选择。
如果说一个节点始终没有通向节点一的路径，那么这些节点呢可以看作是技术的自害任务，应该砍掉或者作为低优先级的任务。
N如果要交付MAPU呢，那你就需要跟团队同学呢提前做联调。
很多技术同学非常讨厌中途停止编码，去配合其他团队做联调。
所以呢我们不能把MAPU的交付呢做的过于频繁。
我的建议呢是在一两周到一个月之间，因为大项目的链调成本呢非常高，交付过于频繁，会打乱研发的节奏。
但如果超过一个月都还没有交付任何MAPU,那积攒的风险呢就会变得特别高。
最后呢就是握握度度结构性的平衡。
当然，如果个能优化的项目来举例，我们第一个MAPU交付完全没有考虑到结构性，只是想看清楚价值，是不是成立确定价值。
成立之后呢，我们才开始设计更稳定的架构。
当然如果这是一个重构项目呢，那么这么做呢就有点激进了。
因为架构速度的结构性和价值交付，我们确确定的交付路径价价值最大呢其实是一顿矛盾。
互互联企企业呢呢构构呢呢始终面临着一个现实的问题，那就是架构活动呢随时可以被抢占。
事实上呢的确也应该被抢占。
因为这是两个目标之间呢在做博弈。
也就是说呢，在一个MVPU带来的小确幸项目的整体结构性最终目标，这三个选项中间哪个更重要？关于这个问题呢，我们在法则一呢就给出了答案，那就是先提升最终目标的成功概率。
如果呢只有一份资源，那么最终目标的最短路径上的强依赖也必须完成。
那么跟最终目标还没有形成强依赖关系的小确性呢，只能算算附附体题，是大架构活动的一个伪需求。
应该什么弃？至少呢不应该放在你注注力范围之内。
在交付过程中呢，你还要跟踪每个任务的进度，把实际观察到的结果跟MVPU的目标反复做校准。
这呢就是我们接下来要讲的交付跟踪和路径。
调整任务进度的跟踪呢属于项目管理层面的问题。
这里呢不做更多解释，我们主要讨论MEPU的目标达成情况。
多数时候呢你会发现目标没有达到预期，这呢其实是很正常的。
我们的假设呢往往过于乐观，逻辑也不够严谨。
这呢是一个非常重要的决策点。
我们必须寻找目标，不满足预期的原因，看看问题出在哪里，是不是有解。
比如呢，用户转化率远低于预期。
那么研发人员、BI分析师，还有用户调研员、市场分析师都可以帮忙寻找根因。
在这个过程中呢，技术人员可能会发现设计和算法实现的问题。
营销人员呢可能会发现营销文案的设计问题。
用户调研人员呢会可能会发现用户群的定位偏差等等。
不过无论如何，这个排查过程都会影响交付的进度，这也是为什么有些项目选择不做拆分的理由。
不过我们既然选择了分阶段交付，那么这些排查就是有必要的。
举个例子呢，我曾经经历过一个叫SABBC的项目供货商，a呢从供应商s那里拿货卖给跨境进口批发商capital b批发商大b啊capital b再卖给零售商b最后呢零售商小b卖给了终端用户，c这么长链路的商业模式几乎注定会失败。
不过在老板的压力下呢，大家还是硬着头皮冲上去了。
项目owner呢还是比较聪明的，他呢先做了s to a的环节，很快呢发现了找不到愿意拿货的控货商a因为这是呢一环套一环的长链路，其中一环失败呢整个链路都会失败。
不过老板呢还是坚持继续尝试，只不过尝试的范围和投入都是要大幅缩小了。
结果呢好几百人日的项目最终上线跑了两个月，得到的订单收入呢还不够，给参与项目的研发人员每人买一杯咖啡。
不过呢也都会向owner先做s to v环节，所以项目失败了。
在最终的浪费呢比之前的规划小了一个倍数。
这个例子呢比较有代表性。
在一个大公司里呢，哪怕是做分阶段交付，很少有架构活动。
在一个MAPU上线效果不满足期题的时候，会选择立即停下来。
多数时候呢，在一些人员排查问题的时候呢，项目组的其他人员还在持续交付。
你可能会问，既然是这样的话，为什么还要耗费时间做分阶段交付呢？因为这个发现和后续排查的动作，因为给了决策团队一个调整的机会，很多因素呢都会会影响到项目的结果。
比如说用户没有意愿或者商业模式不成立，这两种情况呢非常棘手，要做大范围的目标和产品方案调整。
对，但是呢其他的因素，比如说产品细节和技术实施问题，竞争对手的干扰，还有合作合作伙伴出现问题以及用户恶意行为的。
都呢有很多应对方案越早发现问题呢就越有时间来调整，从而提升最终的成功概率。
越较好的例子呢是跟第三方供应商的深度合作。
如果在项目初期就邀请一两个供应商参与，以最简易的方式完成集成。
然后迅速进入试运营，那么很多考虑不周的设计很快就会暴露出来。
这么做呢，虽然会延长整个项目的交付市场，但是重大风险在全面上线之前几乎排查的差不多了。
这这里有一点呢，稍微要注意一下，架构师呢往往没有任何权利去调整整体合作计划和上线节奏一般呢都要由决策者来拍板。
到这里呢我们就要完成阶段性交付了。
整个交付过程呢，其实就是遍历之前的MVPU数，最终完成整个架构目标的过程。
我们已经描述的比较清晰了，这里就不再赘述。
好了，这节课呢内容呢就是这么多。
我来简单总结一下，我们从这节课呢讲了一个架构师视角在该怎么组织阶段性的价值交付。
这个过程呢，其实最大程度的保护了参与架构活动者和赞助者的利益。
因为哪怕是架构活动不能满足预期，但是一个真正有价值的MVPU却可以独立存活。
这个过程中呢也能减少整个项目层面的浪费。
在这种交付方式之下，你不是把所有的系统集成之后，比如说在架构活动交付的最后期限才做好一个系统大集成。
你呢是随着时间逐渐交付用户价值的。
在互联网时代，这么做的好处呢其实是非常明显的。
你给自己和团队都赢得了宝贵的试错机会，还有调整方案的时间。
这呢本来是项目交付的一个基本原则，但是在国内的大公司呢却很少这么做。
其实原因很简单，很多国内大公司呢设定的项目交付日期本来就不合理。
而排期呢就是一个决策者一句话压下来的所有人都知道完不成。
但是大家都认为自己的团队可以逃脱木桶最短板的命运，所以人人都硬着头皮把项目接了下来。
结果就是呢不论团队任务重不重，能集成的最早日期其实就是架构活动中上线日期。
日子一到，多数团队都没准备好，最后一上线就掉脸。
这种做法呢伤害非常大，不它影响到项目会破坏到整个公司的文化。
因此呢我期望这节课能让你意识到我们介绍的最小价值单元法的优势。
也呢希望你能在自己主导的项目上认真尝试一下，我相信它会给你带来不一样的结果。
最后呢是思考题环节任选一个来回答。
第一题呢，你有没有碰到过非常成功的MVPU这个最小价值单元为企业带来了什么价值呢？第二题，有的项目呢自始至终都没有关度量过商业价值、用户价值和技术价值。
你参与过这种佛系的项目吗？参与这种项目的感受是什么？很轻松，很意外，还是很失落。
第三题，有的时候呢，一个大项目中真正关键的MAPU只占整个项目总投入的一小部分。
你估算一下你参与过的所有项目中的MAPU所占项目投入的比例是多少？请你给一下你参与过项目的背景，以及以人日计算的大致成本。
如果这节课对你有帮助呢，欢迎你把课程转发给你的同事或朋友，也多谢大家关注我的抖音号，郭登白也，欢迎大家在那里发表评论。
也尤其呢是关于一些新话题的建议，那么我们下节课再见。